Editor’s note: this article was originally published on the Iteratively blog on January 10, 2021.
A is a living document (or it can live in a tool like ) and it usually outlines what events and properties to track, what they mean and where they are tracked. It helps codify a single source of truth for your analytics and provides your developers with the details they need to instrument the analytics tracking (or schema) in your product’s code base.
And why do you need one? Well, without a tracking plan it’s very hard to know what events you’re capturing in your product and what they mean. It also helps ensure the data you capture is consistent across your sources (think iOS, Android, web, backend) and gives data consumers an understanding of what data they are able to explore for analysis in tools like Amplitude, or directly in your .
Besides the tracking plan, you also need a process around how you . This process usually involves your product managers, data analysts and developers.
In this post we’ll explore some ways to ensure you and your team are successful and can reap the benefits of a tracking plan and process, taking your analytics to the next level.
Start with your goals and metrics
It’s crucial that you start by and then work your way down to what events you need to properly report on that metric. Without a link between your goals, metrics and events you’ll most likely end up with a sprawling tracking plan and data you don’t actually need, while missing out on events crucial to your business.
It also helps you prioritize events for instrumentation and hopefully forces product managers and data analysts to think about not only the goal or the metric of success for a new feature but how that translates into actual tracking needed in the product to measure that.
Don’t forget event and user properties
Properties are where you can capture all the details associated with an event or user. They describe the context around the event or the user and allows your analysts to be able to group, filter, and cohort.
There are two kinds of properties: event specific (e.g. the revenue amount associated with a purchase event) and user specific (e.g. demographic information about a user). Most events and users will have multiple properties associated with them and as with your events, we recommend you only capture what you need and start small.
Establish consistency and keep it simple
A major culprit of issues is inconsistent naming conventions. You might have one team capturing an event as “Song Played,” while another team is capturing the same event as “Song_Played.” This leaves analysts with lots of data munging or worse yet, incomplete reports.
Agree on a naming convention for your events and properties and ensure it’s clear to everyone involved with defining and instrumenting analytics tracking ().
Along with your naming conventions, settle on a , e.g. “Object-Action.” First choose your objects (e.g. “Song”), then define actions users perform on that object (e.g. “Played,” “Paused”) to construct events like “Song Played” or “Song Paused.” And finally, agree on a tense (e.g. “Song Played” or “Song Play”).
Determine where to capture events
You have options when it comes to analytics tracking and it’s important to understand the pros and cons to determine the optimal mix that fits your business and analytics needs. Many companies limit themselves by only capturing events client-side and not taking advantage of server-side event capture.
Collecting events on the server is more reliable and we recommend you always capture your mission-critical events there. While server-side tracking is somewhat limited with less access to information about the user (e.g. IP address, user agent, referrer, and UTM parameters) it’s much more reliable and resilient.
Client-side tracking allows for much richer information and is where you should capture events where you do require the context for how an event occured (e.g. for a first page view you want to capture UTM parameters and referrers to understand where the visit came from). But bear in mind that ad blockers and browser restrictions such as ITP and ETP can limit your client-side tracking, so you want to find an optimal mix of richness and reliability.
Keep separate dev and production environments
This one is straight forward, but we still see companies sending data from their development environments to their analytics destinations. Don’t dirty your production data and make sure you keep your environments separate.
Enforce your tracking plan
Many teams treat analytics tracking as an afterthought and do not apply the same practices as they would to other code. This naturally results in analytics bugs that you’ll have to fix downstream, or worse, that you don’t discover at all. We see many teams losing trust in their data that way and once the trust is gone it’s hard to build back!
To mitigate that it’s crucial you validate and enforce your analytics tracking. We’ve written a outlining various ways of validating your data according to its specifications.
To summarize, there are several ways to enforce your tracking and they usually fall into one of two categories: reactive or proactive approaches, and you can enforce your tracking plan, or analytics schema, in the client, in the pipeline and at the destination (usually a data warehouse or analytics destination). We always recommend dealing with quality issues at the source, i.e. ensuring that your instrumentation matches what is spec’ed out in the first place and then verifying that with and as a part of CI/CD.
Assign an owner
. Accountability is needed to ensure your tracking plan is kept up to date. In another , we dive into who could be that owner and how you build a process around your analytics tracking.
The takeaway? We believe the product team is best placed to be the owner of your tracking plan and we recommend having a clear process for analytics tracking, ensuring event tracking is going out with every new product release. This means defining a clear process for your event tracking and entrusting the product team to take ownership by empowering them with the right tools and training.
Document everything
We can’t stress the importance of up-to-date documentation. Without it, analytics tracking will easily become messy, teams will start forgetting to include tracking as a part of the release process and you start the downward spiral of not trusting your data.
Manual documentation can be tedious and easy to forget, but we strongly recommend documenting the following at a minimum:
- Analytics tracking guidelines: An overview of the complete process, including your , how to define new events, who’s responsible for what and links to related resources.
- : The actual list of events and properties, including descriptions, from where they’re tracked, since when and who’s the owner.
- Instrumentation process: Include a process document on how to ensure new events are implemented, down to the Jira ticket-level, requirements around instrumentation, testing, validation and more.
Many companies use Google Sheets, Notion or Confluence pages to manage these documents. With Amplitude’s , that’s all done for you automatically, .
Get to best practice with Amplitude
Amplitude helps data teams, product managers, and engineers define, instrument, verify, and collaborate on analytics tracking. We proactively solve the data quality issues that arise from inconsistent event naming and missing tracking, and provide a workflow for managing the evolution of your tracking.
We ensure teams get high quality data that’s ready to use by empowering them to get analytics tracking right the first time. If you’re interested in trying out Amplitude for your company, or to learn more.