Making Amplitude an effective part of your workflow means dedicating time to proper instrumentation. But instrumenting your product is a continuous—and sometimes challenging—process of thinking up front, working across different teams, and building it into your onboarding process.
To help you and your team get up and running, we asked Ampliteers for their top tips for instrumenting your product.
If you are just getting started setting up Amplitude and tracking events, we recommend starting with our 5 Step Guide to Sustainable Instrumentation and Data Taxonomy Playbook.
1. Add instrumentation to your product development lifecycle
If your instrumentation is insufficient or non-existent, it’ll be near impossible to effectively analyze your product.
Product instrumentation is best thought of as an ongoing process and Miles Monaghan, Senior Sales Engineer at Amplitude, suggests that you “make instrumentation a part of the product development lifecycle.” Specifically, he recommends that you, “plan and instrument events as you plan and release new features.”
“Make instrumentation a part of the product development lifecycle.” —Miles Monaghan, Senior Sales Engineer
Miles, one of our Senior Sales Engineers here at Amplitude, at his desk in our San Francisco HQ.
2. Prioritize what you instrument
Tracking every metric is neither practical nor reasonable; it’ll drain your resources while producing excessive amounts of unhelpful findings. The better approach is to pinpoint a few key performance indicators (KPIs) that paint the best picture about how your product and features are doing. Then, you can identify how best to track the user actions that contribute to your KPIs.
“Don’t instrument everything.” —Wendy Vang, Enterprise Solutions Architect
As Wendy Vang, Enterprise Solutions Architect at Amplitude puts it, “don’t instrument everything. Instrument your key flows and user actions, learn how to utilize and organize the data better, and iterate.”
Structure, which can be as simple as a taxonomy spreadsheet, goes a long way when instrumenting.
3. Take a conversational approach
Sometimes it is not immediately obvious which metrics you should focus on. Eric Hwang, Principal Sales Engineer at Amplitude suggests that you, “think about your metrics first in a conversational way (for example, we want to know how many people convert to premium, how many people purchased X product, or how many people subscribed to Y subscription). Speaking conversationally makes it much easier to identify the important metrics and KPIs that you will eventually need.”
“Think about your metrics first in a conversational way.” —Eric Hwang, Principal Sales Engineer
Eric adds that “once you’ve identified the most important business drivers and needs, you can begin to identify the specific actions that compose that flow or metric. This ensures that you’ll have implemented comprehensively for all of your required metrics, KPIs, and desired analyses.”
4. Don’t make event definitions too high-level
Teams sometimes fall into the temptation to instrument high-level events to aggregate usage (e.g. the event Click tracks the combined activity for Click Login, Click Search, and Click Purchase) which can lead to confusion, and data trust issues. A better approach is to instrument the user action, such as ‘Complete Purchase’ or ‘Play Song’.
Create events that represent user actions within your product.
Jessica Chiu, Solutions Architect at Amplitude, recommends creating events that represent user actions within your product. “Instead of tracking clicks and views, it is easier for your team to actually leverage the data and discover insights by tracking user actions. This will also help ensure that your taxonomy is flexible and can scale as you grow, since the UI of your product may change significantly but the underlying critical user actions will remain the same.”
Jessica Chiu, a Solutions Architect, suggests focusing on user actions—not just clicks.
5. Involve your engineering team in the early stages of instrumentation
Your engineering team will play a fundamental role in successfully instrumenting your product. Wendy Vang advises you to include engineers early on in the instrumentation process. “Don’t just make a ticket and forward the instrumentation work to Engineering,” Wendy says. “Inform and involve your engineering team in the scoping of the instrumentation and expect compromises to what you want to track based on technical feasibility.”
“Don’t just make a ticket and forward the instrumentation work to Engineering.” —Wendy Vang
6. Know the essentials
According to Xin Cao, Enterprise Solutions Architect at Amplitude, a couple of things need to happen to fully instrument your product. As he puts it, “always have two things: an entry and exit step for your critical paths and a counter user property for actions users can take in the product (for example total purchases, total songs played, or total items added).”
“Always have two things: an entry and exit step for your critical paths and a counter user property for actions users can take in the product.” –Xin Cao, Enterprise Solutions Architect
7. Send the right data to the right project
Data can get messy when you’re working with different products and platforms, creating obstacles when trying to accurately run analyses.
To keep your data organized, Jessica Chiu recommends that “data for different products should be sent to different projects. Data for different platforms of the same product should be sent to the same project so that you can do cross-platform analysis. If you’re unsure of whether or not to separate your data into different Amplitude projects, the general rule of thumb is the same data taxonomy (equivalent events and properties) should be sent to the same project. This also means that it’s important to have consistent syntax across platforms.”
“The general rule of thumb is the same data taxonomy should be sent to the same project.—Jessica Chiu
8. Educate new hires about data taxonomy
Data taxonomy is only effective when everyone is onboard. As employees come and go, getting your team in sync with your product instrumentation is a continuous process. To keep you clued into your data taxonomy practices, Wendy Vang suggests that you make instrumentation, “part of the new-hire process to teach how your data taxonomy is structured and how to instrument data for engineers.
Getting your team in sync with your product instrumentation is a continuous process.
Wendy Vang recommends that teams introduce instrumentation to new hires as early as possible.
9. Instrument the context in which an Event is performed
In any modern application, a feature can be accessed or used from various parts of your product. A single feature, such as “Save to Favorites”, could be made available in various screens, states, flows, or UI components. Tareq Ismail recommends that you “should instrument the context in which each event was performed, especially the source, location, or component in where it was done to best understand how people are getting to functionality or content.”
“Instrument the context in which each event was performed.” —Tareq Ismail
By instrumenting the source, location, or component, as an event property you can see where users access that feature the most.
Tareq adds that, “once you dig in, you may find multiple levels of abstraction that provide more context of that particular event (for example, where an event was clicked from in the UI layout, what page the user was on, what state the user was in, etc. can all be considered as source/referral depending on the case).”
10. Verify events before production
Before you dig too far into instrumenting your product, take some time to plan out what you want to measure. Dana Levine, Product Manager at Amplitude suggests that you “set up development and production versions of your projects so that you can verify your events before they go into production. Before you start instrumenting events, figure out what you want to measure.”
“Before you start instrumenting events, figure out what you want to measure.” -Dana Levine, Product Manager
According to Dana, “you may have particular flows that you want to measure, or you may care most about how much users interact with particular parts of your application.”
