Zero-to-one product design · Enterprise SaaS · MarTech
Making complex conversion tracking usable for marketers without limiting technical teams.
MessageGears could help enterprise teams send highly personalized campaigns at scale, but customers lacked a clear way to define and measure the actions that mattered after a message was sent.
Conversion Events & Goal Tracking introduced a new system for defining customer behaviors, connecting those behaviors to campaign goals, validating incoming data, and monitoring event activity over time.
The challenge was not simply designing another configuration screen. It was designing a system that could be approachable for marketers, flexible for technical users, and reliable enough for teams to trust the data behind campaign decisions.
The Challenge
Customers could send sophisticated campaigns, but the platform did not provide a comprehensive way to define the behaviors that represented success.
A conversion might be:
Without a structured conversion system, marketers had limited visibility into what happened after campaign engagement.
At the same time, technical users needed control over event data, schemas, field mappings, schedules, and SQL-based configuration.
A major prospective customer also required stronger conversion tracking capabilities, turning the gap into both a user problem and a business risk.
System Thinking
Introducing behavioral conversion data affected campaign configuration, events, goals, attribution, reporting, analytics, terminology, schedules, extraction, history, errors, and notifications.
Adding one capability changed the meaning of several existing parts of the platform.
Research
I reviewed how competing marketing and customer-engagement platforms approached conversion tracking, behavioral analytics, dashboards, reporting, and event configuration.
The research included Braze, CleverTap, Airship, OneSignal, Customer.io, Iterable, Hightouch, MoEngage, WebEngage, and other analytics and messaging platforms. The goal was to understand definitions, data volume, goal configuration, technical depth, reporting language, and the path from setup to analysis, not to copy an existing pattern.
What the research revealed
The Core Product Question
The solution could not force every user into the same level of complexity. It needed to reveal technical depth only when the user's task required it.
User Needs
One system. Two levels of technical depth.
Product Strategy
Structured event configuration
Direct data control
Rather than creating two disconnected products, both experiences were designed around the same event structure. This allowed the interface to adapt to the user's level of technical control while keeping event definitions consistent across the platform.
Core Experience
The create state establishes the structure of the system before asking users to configure individual events.
Users first choose the data source and then add either custom events, purchase events, or both. The empty state communicates the two supported event types without immediately exposing every configuration option.
Event Configuration
The configuration experience organizes event setup into clear sections so users can understand what the system needs and why. For custom events, users define the event name, label, type, IDs, timestamp, attributes, and notification behavior without needing to understand the underlying data architecture.
Required information is grouped first. Optional attributes remain available without dominating the primary task.
Flexibility
A custom event might represent an add to cart, content view, signup, button click, or account action. A purchase event adds commerce-specific requirements such as purchase identification, cost, item ID, and product attributes.
Both conversion types use the same interaction model, keeping the system learnable while allowing each type to expose the fields it needs.
Goal Tracking
Marketers needed to tell the platform which behaviors represented campaign success. The Goals experience lets users name a goal, choose Event or Purchase, select an event, confirm when it was last seen, add multiple conversions, and define the attribution window and qualifying campaign interaction.
Event → Goal → Attribution → Campaign Performance
Attribution
A conversion occurring after a campaign interaction does not automatically mean the campaign caused it.
The controls let marketers define a duration, time unit, and qualifying interaction such as Click, Open, or Delivery.
The goal was to provide enough control for meaningful attribution without turning campaign setup into a technical analytics exercise.
Preview + Validation
Conversion tracking depends on the quality of the event data feeding the system.
The Preview experience provides a tabular view of records including user ID, timestamp, event name, platform, device information, and custom properties.
Preview reduces uncertainty before an event becomes part of campaign measurement.
Failure States
Event extraction can fail because of invalid queries, unavailable data, schema changes, connection problems, or unexpected values. Those failures cannot remain hidden.
The preview surfaces extraction errors and preserves technical details for troubleshooting without forcing every user into raw debugging.
Surface the problem.
Preserve the context.
Provide a path forward.
Technical Experience
Technical users required control over database connections, schema, catalog, table, SQL definitions, field mappings, parameters, preview, schedules, history, status, and notifications. The deeper workflow remained consistent with the marketer-facing event model.
Operational Trust
A conversion event can work today and fail later. History gives users visibility into update version, start and completion time, events added, status, query details, and failure messages.
Schedule controls determine refresh frequency. Notification settings alert users when extraction issues occur.
Together, these features move the experience beyond configuration and toward ongoing operational confidence.
System States
Enterprise workflows rarely exist only in their ideal populated state. The design accounted for the full lifecycle so users always understood what the system was doing.
Decisions
Give marketers a structured configuration path before exposing database-level complexity.
Keep custom events, purchase events, goals, and technical configuration aligned around the same concepts.
Allow users to preview incoming data before using it to evaluate campaign performance.
Schedules, history, status, errors, and notifications are part of the product, not secondary admin details.
Platform Impact
Conversion Events introduced behavioral concepts that needed to remain consistent across metric terminology, engagement definitions, cross-channel reporting, campaign and job analytics, conversion reporting, goals, and information hierarchy.
This required decisions beyond the new screens themselves and reinforced a broader principle:
New features have to fit the language and mental model of the entire platform.
Cross-Functional Work
I partnered with Product Management, Engineering, and other stakeholders to align user needs, business requirements, data structures, technical feasibility, existing patterns, metric definitions, validation behavior, and implementation details.
Design critique was especially important because seemingly small terminology or interaction changes could affect multiple parts of the analytics experience.
Outcome
The work delivered a zero-to-one conversion tracking system connecting event definition, campaign goals, validation, technical configuration, and ongoing monitoring.
Reflection
The real design challenge was creating a system that could be simple and advanced at the same time without feeling like two disconnected products.
This project reinforced that enterprise product design is not only about reducing fields or making a screen easier to scan. It is about understanding where complexity is necessary, deciding who needs to see it, and giving users enough visibility to trust what the system is doing.
Simplicity should be the default.
Control should still be available.
Have a Complex Product Problem?
Whether you are shaping a new SaaS product, improving an existing workflow, or figuring out what needs to be built next, All Hatched can help turn complexity into a clearer product direction.
