The UX of Event Architecture — An Amplitude Reintegration Story

Imagine if your entire Amplitude instance were as intuitive as working with a ‘page_view’ event — simple, universally understood, and effortless to use. In data and software engineering, every decision — from naming variables to designing data structures — shapes a hidden aspect of a users experience (UX). That user could be your customer, another developer or a future version of you. In event visualisation tools specifically, the interplay of naming conventions and event structures make the difference between an intuitive experience that people love to use and one that they dread.

Zip reintegrated Amplitude over 18 months ago to solve 3 main problems:

1. Amplitude data had become less trusted as we couldn’t always reconcile the data in it with other internal systems.
2. Onboarding new employees to using Amplitude was challenging due to the tribal knowledge surrounding team events and their usage.
3. Knowledge silos meant that it was difficult for someone to look at data across wholistic user journeys as that would require them traversing these knowledge silos.

We addressed these challenges by implementing the following steps:

1. Removing all direct integrations of apps and services with Amplitude
2. Switching to collecting events using Snowplow into Snowflake and egressing to Amplitude.
3. Redesigning event structures in Amplitude to optimise for the end user experience in Amplitude.

This has resulted in our Amplitude instance having < 30 core events while providing coverage across all main journeys at Zip. Here’s how we got to where we are today.

Framing UX as an Optimisation Problem

Improving something without a clear framework to assess solution quality can be challenging to say the least. We approached this by defining the goal for event taxonomy in Amplitude as maximising valuable event coverage and intuitiveness while minimising the number of unique events.

• Valuable Event Coverage is a measure of how well you can track and analyse key user behaviours within your experience.
• Intuitiveness is a measure of how little specialised knowledge is required to effectively use and understand Amplitude and it’s events.
• Unique Events are a measure of how many uniquely named events are in your taxonomy.

If someone requests tracking on a specific user behaviour, simply responding with ‘No’ doesn’t address the problem. Effective solutions must increase event coverage. However, focus should be directed towards making changes while minimising new events and maximising intuitiveness. Assessing the number of new unique events is relatively straightforward, the real challenge lies in defining and achieving intuitiveness within this context.

Intuitiveness is a function of your project, not an event

Intuitiveness must be considered in the context of the entire project, not just at the level of individual events. Let’s say you want to track clickstream data off a website and your event structure is <page_title>_<section>_<button_copy>. This approach would lead to numerous events like ‘homepage_hero_sign_up,’ which may seem fine individually, but if there are 4000 different combinations, your Amplitude users are likely to encounter difficulties. This leads to a situation where only a few events — those critical to key user journeys — are frequently used, while the rest become costly noise.

Ignoring this issue and allowing individual engineering and product teams to create events freely — even with strict naming conventions — can dramatically increase the number of unique events over time. This often results in the need for tribal knowledge to navigate the system, leading to a decrease in overall intuitiveness and poor onboarding experience.

That said, it’s still crucial to ensure events are named clearly and appropriately.

Naming events

If you’ve worked with digital analytics it is high likely that you’ve encountered a poorly named event, but what exactly makes an event name ineffective? There’s three main issues that contribute to an event being poorly named:

• Inconsistent formatting (e.g. snake_case vs. camelCase) or spelling errors.
• Ambiguity: The name doesn’t clearly capture what the event is describing.
• Domain knowledge required: The name requires domain knowledge to understand, often due to the use of acronyms or terms unique to your business. It can also require domain knowledge by being too specific in it’s application, rendering it useless to the majority of users.

In contrast to bad events, we can say that good events have:

• Consistent formatting with other events and free of spelling errors.
• Clear and descriptive: The name accurately captures what the event represents (we’ll revisit this point later).
• Universally understood: The name is free of business-specific jargon and can be understood without domain knowledge.

Now that we understand the importance of considering the entire project’s intuitiveness and have identified the elements of a good event name, the next step is determining how to structure these events effectively.

Structuring events

Events should include all essential information that users would reasonably expect. For instance, a transaction event without an amount is incomplete and could lead to frustration. When structuring events, the key is to focus on what should inherently be part of the event, rather than tailoring it to answer specific questions. Prioritising deep domain coverage in Amplitude provides more lasting value than merely addressing individual queries.

To achieve this, start by identifying the questions users want to answer in Amplitude, but aim for the ability to deeply explore the relevant domain as your ultimate goal. This approach ensures that your events are not just functional, but also valuable for exploratory analysis.

In addition to structuring events effectively, it’s crucial to establish clear ownership. One common question users may have is, “Who can I talk to about making a change to or understanding this event better?” To address this, we associate every event with a specific team and service in Snowplow, and we route that information into Amplitude. Even with multiple teams at Zip sending page view events daily, each one can be traced back to the team responsible. Additionally, any team can easily filter “Any Active Event” by their team name to quickly see all the events they are sending into Amplitude.

By structuring events thoughtfully and ensuring clear ownership, you create a system that is not only more intuitive but also easier to manage and evolve.

Applying this to funnel analytics

At Zip, all funnels (Signup, Login, Update Schedule etc…) are tracked with 4 events. These events together provide a comprehensive framework for tracking and analysing every aspect of a funnel journey.

• funnel_start: Declares the type, attribution, and start of a funnel.
• funnel_section_start: Declares the section name and the instance of the funnel it’s related to.
• funnel_section_outcome: Declares the outcome for a specific section, the instance of that section, and the reason for failure if it wasn’t successful.
• funnel_outcome: Declares the outcome for an instance of a funnel and the reason for failure if it wasn’t successful.

Introducing these four events allows us to track any funnel journey without increasing the number of unique events.

The ‘funnel_’ prefix groups these events in the UI, making it easier for users to explore and understand funnel data intuitively. Like our page_view example, they also encourage exploration — they all have a funnel_type property which enables any user to self-discover all the funnels tracked like this. They don’t require domain knowledge of a specific funnel to be able to explore drop-offs and conversion rates.

Although these events require some initial knowledge to use, this knowledge is easily transferable across different funnels and projects. For instance, you can create a funnel visualisation in Amplitude by combining ‘funnel_section_start’ and ‘funnel_section_outcome’ (where outcome = ‘success’) and grouping by ‘section_name.’ This will produce a graph showing the conversion rate at each step of the funnel. Once this is understood any funnel can be explored without any prior knowledge about the steps.

Summary

When designing events in Amplitude, design them with a new starter in mind. Keep your unique event count small, and be mindful when introducing new events into Amplitude. As you increase Amplitude’s coverage, consider this key question: How can we add XYZ to Amplitude in the most intuitive way, using the fewest events and requiring the least amount of prerequisite knowledge?

If an event does require prerequisite knowledge, ensure that this knowledge is portable. It’s better to require general knowledge of data structures that enable broad data exploration than specific business knowledge tied to particular processes. For example, needing to understand the expected sequence of steps and the specific event representing each step is non-portable knowledge and should be avoided.

As always, thoughts and feedback are welcome!

Interested in joining the team? You can reach out to Hannah Scott for more info or apply through the links below:
- Data Engineer: https://lnkd.in/gx_p_st9
- Data Analyst (12 month FTC) : https://lnkd.in/gtUEgg7h
- Senior Analyst, Data Management: https://lnkd.in/gXa7UpcK

Bonus Section

Abstraction Levels

I wanted to highlight a key consideration that didn’t quite fit into the previous sections: the tension between higher abstraction, intuitiveness, and prerequisite knowledge. I’m still wrapping my head around this, but it’s an important aspect of event design. As you raise the level of abstraction, there comes a point where domain knowledge is no longer necessary to use an event. However, going too far can reduce intuitiveness. For example, our funnel event names convey a lot of detail, allowing users to infer how our funnel tracking works without needing additional context.

If we continued raising the abstraction level to a single funnel event, we’d lose this clarity, making our project less intuitive. Finding these sweet spots is the art of Amplitude event design.

Explicit success tracking

There’s a delightful aspect of the section_outcome events which is that it allows a clear distinction between 3 outcomes.

1. Outcome = ‘success’ is your happy path.
2. Outcome = ‘failure’ is a user expressing intent to get through but being blocked for one reason or another.
3. The absence of an outcome event is a true drop off where a customer abandoned without attempting to complete.

The distinction between buckets (2) and (3) above is incredibly valuable when determining how to optimise conversion rates as a product team. Optimising UX and copy won’t help if user’s are already trying to get through but being blocked because of a system issue and likewise solving errors won’t help if no one is trying to get through because they’re dropping off before.