Standardized Event Tracking (a.k.a. how dreams become reality)
When Madison joined Backstage, everyone in the organization was using data via Amplitude to inform their decisions. However, because the data points weren't standardized, usability and trust in the data were low. In this "How I Amplitude" session, Madison walks us through how she turns product dreams into tracked realities.
“It's great when everyone in an organization can make data-backed decisions. But, if each team works from different data points, it's hard to clearly understand what's going on in your business.”
A guide for collecting data in a standardized way
When I arrived at Backstage, the team had been using Amplitude for several years. The problem was that each team was defining and using data points in their own way. Over time, the trust and usability of the data decreased. Understanding the customer journey became difficult.
With the team, we tackled this problem by developing a process for tracking events. The process enables us to standardize the data so everyone from marketing through product can understand and use the same data points.
Steps to standardize event tracking
- Work from the wireframe to design the data story
- Get the dev team bought-in
- Document events to make it easy for the dev team to instrument
- Amplitude Data is leveraged to:
- Block new events from Production project until added to plan
- Track event plan changes branch is created and labeled with Jira epic number
- Events are added to tracking plan and documented with screenshots
Step 1: Work from the wireframe to design the data story
We always involve the data team in development upfront. As soon as the product or marketing team starts a new initiative, a member of the data team will be there during the planning process to understand their goals and review the designs.
After working with other teams to understand what will happen on the development side, the data team plans the data we'll track. We design events for each part of the customer journey and map them out on a FigJam template.
This sets the scene for the data that’s about to be tracked by defining the user journey.
The template includes several levels for each step of the customer journey:
- The user action
- A visual
- The event we'll track
- Any page events
- Any user identity updates
Here are the template components in detail.
Epic
At the top of the user journey, we call out the Jira epic associated with the development work. That way, anyone using the template always has a reference point for the journey. We'll also record the scenario—an overview of the user journey and what we're trying to track.
Action and visual
Under the epic, we note down the actions the user takes at each step and add a screenshot or design view of what the product looks like during the action.
Track events
We note down any of the track events that we want to be called during the action. We include the event name and all the event properties that need tracking.
Depending on your setup, you may have front-end or back-end events. I color-coded the events to indicate whether the front-end or back-end teams will need to program the event.
Page
I also like to call out any page or screen events currently being tracked. It's one way to reduce the duplication of events.
For example, if someone wants to know how many people land on the homepage, your initial reaction might be to create a homepage event. However, if you already have Amplitude's page tracking turned on, then that event is already being logged.
Recording the page events you're already tracking encourages you to reflect on whether you really need to create a new event. Often, at the top of the funnel, there's not a lot of extra information you need that's not included in a page event.
User identity updates
Another piece of information we add is where the user identities update.
When you update an identity, you don't always need an event associated with it. If the data point fits into a user property, you can save on the number of events you track.
Let's say someone signed up as a talent agent. We might decide to have the signup event and then a sub-event that says, “Now this talent user is an agent at the event level.” However, including that information in the user's identity is more valuable. When you update a user in Amplitude, the property stays with them throughout their journey. Doing it this way means you don't have to worry about adding that the user is an agent in every track event from here on out.
The template in action
Here's a scenario from the Backstage platform: We invite new users to join an agency roster on Backstage, and we want to track each person’s progression through the signup flow.
The first user action in the flow is clicking on the invitation email and landing on the information page.
“Invited viewed' is the event that corresponds to the first user action.
It's the start of the funnel, so we mainly want to track whether or not this was an existing user. We created a workflow step called '”Invited Viewed.” Arguably, we didn't need this at the event level, but it helped us when thinking about the funnel and grouping.
We note the page event and the identity updates.
We always include a subproperty, where the event comes from—whether that's the web, the server, or if you're using Amplitude on iOS. We also note that this is when an identity is created, and we will receive the anonymous ID number and initial UTM parameters.
And when someone landed on this page, they were also getting a page track call at this point, but it only gave us the information that they landed on the agent invite page, and it didn't really have the level of detail that we needed because this was a model on top of a single page that was being persisted throughout, this detailed user journey.
The other thing that I was able to note here is this is when an identity is going to be created. We're going to get the anonymous ID and all of the initial UTM parameters
Continue through each step of the new user journey
And then from there, I duplicate this step and now when the talent clicks confirm, we need to fire another event. I named it the same so that we can have this nice categorization of a single interaction and then the detailed step by step what happened.
So in this case, when someone confirmed, we switched the workflow step to confirmed.
And still track that existing user.
And in this case, we want to track the name of the agency that they were joining. So we put that in as a subcategory as well for property.
And, because we wanted track that agency name. This event ended up being a server side event because that data was not collected in the front end. And when this event occurred, it was sending information to our server. So we were able to say, “Hey, server, when you get this information, also send this event up into our customer journey in Amplitude.”
And then page name is still the same.
Identify a unique way to track each step in the journey to analyze drop-off
And then from there, there are a couple more steps that happened, but eventually they end up signing up. And so that's what I have listed here to note that sign up is first initiated, and I call this out so that we have a new page name when the user progresses to this point.
And then once they fill out the information and actually create an account, we have another customer event fired from the backend. This notes an account created and any associated event properties you want with that.
And more importantly, we have the identity updated with the user ID and whatever custom properties you wanna track for that user from that point on.
So in this case, it was really important for us to capture the fact that this user would sign up via the sign up flow of the agency talent, in this case.
Step 2: Getting the dev team bought-in
Once we've filled out this FigJam template to get this detailed customer journey view, we present it during our engineering kick-offs. The template shows everyone what analytics we need to collect. This helps our engineers better understand where the events need to come from and what type of events they need to update—for example, a new event or an identity update.
In the kick-off meeting, we get buy-in from the development and product teams so everyone moves forward with a shared understanding of what we'll track.
A framework that the team uses to understand which events they want to track is:
- What am I trying to answer?
- What are the metrics tied to those answers?
- What are the data points I need to build those metrics?
And all of this rolls back up to the team’s North Star Metric.
Step 3: Document events to make it easy to instrument
After kick-off, the product team details all the events in Notion. They describe the event, why we're recording it, and the event properties.
The Notion step is arguably unnecessary because it duplicates the information we put into Amplitude. However, once the events are in Notion, it's easy for the developers to pick them up and implement them one at a time. They have all the details of the event and where it needs to be fired.
Step 4: Track events in Amplitude
Now, we'll go into Amplitude Data and build the plan from the FigJam template. We add all the events to the tracking plan, add the screenshots, and categorize them to the Epic.
We add all the events we want to track to the tracking plan in Amplitude.
Final Thoughts from Madison
Before, data was sometimes an afterthought in the process. Developers would complete development work. Then, the product team would ask for data points that the development team hadn't planned for and weren’t asked to instrument.
Developers would have to go in afterward and figure out how to get these data points. Management would also get frustrated because the new product updates would be released, and the events wouldn't be there as expected. We needed a proper tracking process and more clarity to get the value we needed from the data.
Now, having data and analytics planned upfront benefits us all. Additionally, we're moving to use Amplitude more as a customer data platform. For example, the marketing team also uses the data to segment and engage with users. As a result, being on the same page regarding how we define data is more important than ever before.
Join the community!
Connect with Madison and other practitioners in our community. The Cohort Community exists to help people become better analysts. We focus on actionable programs, sharing best practices, and connecting our members with peers and mentors who share in the same struggles.