Tracking Plan and Event Schema
Ampliteers Jennifer Rudin and Anuj Sharma answer users burning data governance questions, covering when to use event or user properties, staging environments, and how to QA your setup.
Use Case #1: Event vs User Properties - When and How to Use Either
The key differentiator is where you add more value—is it to your user, or is it the action that the user took?
If it’s to the user, then you use the user property. Use the event property if it’s to the event or action a user took. That’s the easiest distinguishing factor.
The best place to use user properties is where you want properties to maintain state. This means you set a property, and the next event you trigger will apply the same property. Because it’s a user property, it doesn’t change with every event or even every ten events, but over time. For example, a user’s subscription status doesn’t change often, so you apply that as a user property.
On the other hand, we have event properties.
Let’s say a user clicks an element. While not generally recommended, you will have events like element clicks or page views if you are interested in auto or default tracking. To make more sense of those events, you would add many more properties.
Properties like the page a user came from or is going to, the URL, the badge, and the path, add more meaning to events and would be used as event properties.
There can sometimes be something of a gray area with this. For example, when deciding whether plans should be at the user and organization levels. For the most part, it’s a steady value and, therefore, a user or group property. But at the time of an upgrade or downgrade, you want to capture the previous value and the new value, so it can also be a useful event property, too.
It’s important to not get too caught up with your taxonomy.
Use Case #2: Tips to QA your setup
It’s easy to QA within Amplitude, but not everyone knows how to do it.
There's a lot you can do in Amplitude to for QA purposes, using features like Amplitude Observe.
Let’s say an event had a few required properties. The event shows up, but the properties required might not. This means you don’t have any indication until you manually go into the event, look at the properties, and verify that the required properties are missing.
Amplitude makes all this easy. If you mark the property as required, and it doesn’t show up in the event, you can subscribe to warnings so you receive emails about data that’s invalid or doesn’t line up with your taxonomy. This improves the QA process.
When we’re looking at unexpected events in Amplitude, it means a developer has coded for that event. It’s hard for Amplitude to identify who wrote the code to add the event.
Looking at the data, you can identify if that event is from a specific application or platform. Planning for events in Amplitude allows you to add owners to events, who you can go back to when needed. However, we can’t identify the developers who added the event. However, by clicking on the “use by” tab and looking at whether any specific users have queried the event in an Amplitude chart or cohort, you may be able to identify the developer when they tested it. Doing this may give you a faster lead on who’s expressing interest in the data.
The value of documentation
It’s important to have a shared understanding of an event trigger and to document it with a clear description of the event or properties used.
Use clear colloquial terminology that every business unit can understand. Everyone, including sales and marketing departments and those working in engineering teams and product teams, should all be able to use the data and make the most of it. If the trigger for the event can’t be explained in words, a screenshot could help as well.
It’s also helpful to use tags in documentation when adding events in addition to categories. You can add a single category to an event, but you can also use multiple tags for filtering. If you have specific release cycles for adding events, you can add tags to identify when the event was added. Some users even tag events with a JIRA ticket number, for later reference, too.
To Block or Delete an event
Knowing whether to block or delete an event depends on what you’re trying to do.
When you block an event, you stop ingesting it into Amplitude but it still stays within your taxonomy. You can look at the historical data and build charts from that information.
Deleting an event blocks ingestion and removes it entirely from your taxonomy. You cannot build charts using the event's historical data. If you have charts already built from the old data, they will remain in Amplitude.
So, if you want to completely remove an event from the UI (user interface) so users cannot build a chart from the event and don’t want it to be ingested, you should delete it.
You might have events in your taxonomy you haven’t used in years, which users are unlikely to go back to run or build a chart from. But if you have use cases for that event and would like to use the historical data, block the event instead.
Staging environments
As a rule, even when working with new customers to implement Amplitude, we recommend sending out all your events to a development environment first. Have it validated there and then move to a production environment.
You should follow that setup, test your events with your developers in a development environment before then moving over to production.
Using branches in Amplitude is also helpful. You can have branches to work on with your developers. This doesn’t impact production or data within the main branch or pollute anything with the primary use cases that you might have in your main branch. You create new events, test, make sure it’s valid, then merge into your main branch.
Using the GTM template vs. Amplitude SDKs
When questioning whether to use the Google Tag Manager template instead of tagging things using the Amplitude SDKs, the recommendation is to use tag manager when you have limited resources or are low on time.
If you have the dev resources and can spend time building out a taxonomy for Amplitude, use the SDKs, get events directly through the SDK, and have a customized taxonomy.
The way Anuj thinks about implementations as a first step is to think about your business goals and KPIs to track. You can then gauge what business goals you’re answering and how Amplitude can help you answer them.
Start breaking down business questions and you’ll identify the event you need. These are the properties required for the event. Based on that, build your taxonomy and reach out to development to get that data from Amplitude.
When you’re using the GTM template, it’s the other way around, instead of implementing the template. Whatever you have in GTM flows into Amplitude, where you have the option to customize your tracking and create custom events to track easily.
If building a taxonomy is much easier for your end users to understand, then that’s the way to go. But if you’re on a time crunch, GTM templates would be how you get started quickly.
When to use specific vs. generic events
The way to think about a generic event versus a specific event is how critical it is in your user flow. If it is part of your critical user journey, you need that event individually. If it’s not, and you just need to build a specific user path, it could be a generic event.
Think of it in terms of using a journey chart analysis, pathfinder, or anything that shows multiple events a user took from A to B. If you see that redundant events show up and cause confusion, do your best to consolidate them into one and break them down by property.
Focus first on what your core KPIs are to your business around analytic measurement needs and cohorting needs to know how you will target for campaign and life cycle marketing.
When should a tracking plan be driven by user properties?
Tracking plans are ideally your entire taxonomy. They’re not restricted to user properties or event properties—it’s the whole dataset you’re tracking.
From an Amplitude perspective, your tracking plans will be based on events. User properties don’t apply in Amplitude if you're not tracking events. You need at least one event to show up in Amplitude for user properties to apply.
If you were to only pass through identify calls, you could never be able to build an event-based chart. Instead, you would only be able to build a user composition chart or look at the user lookup view, which would only be comprised of user properties and no events, which would be limiting. In Amplitude, you really want to be creating events.
Join the community!
Connect with Jenn, Anuj, 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.