Instrumentation is the backbone of data-driven product management, and yet it’s still a mystery for many PMs.
Product instrumentation involves adding tracking and analytics tools into your product to measure user interaction and gain valuable insights into overall performance.
Although it’s a technical concept, it’s so impactful on a day-to-day basis that every PM should at least grasp the basics.
In this article, you will learn what instrumentation is, why you should care about it, and how to implement it within your team.
Instrumentation is the process of defining data events and setting up tools to collect and process these events. Data events are snippets of information that are sent from your product to your analytics tool of choice, such as Google Analytics or LogRocket.
As an example, let’s see how you would answer the question of how many users visited a specific page of your app. Because LogRocket’s autocapture starts capturing all user actions once it’s installed, it captures navigation events every time a user visits that page. To understand the total number of users who visited that page, you’d simply create a chart of users and add a “visited URL” filter for the page you want to track.
The total number displayed on the chart is the sum of all navigation events collected in a specific time period. These events can be later processed within LogRocket to develop meaningful segmentation, cohort analysis, correlation analysis, etc.
Analytics tools with autocapture capabilities, such as LogRocket, Heap, and the like, enable you to capture every event automatically, so you can answer any analytics question without needing extra instrumentation. However, tools like Google Analytics, Mixpanel, and Amplitude, require you to manually tag every event you want to track — which means range and variety of data you can analyze is limited to what you’ve already thought to track.
The challenge with instrumentation is that only so much can be provided out of the box. Each product is different, with a unique user flow and needs. So while you get the basics out of the door, you’ll get a very limited picture without some custom work.
Now let’s walk through the steps you should take to implement product instrumentation:
There’s a chance you have more than one user type on your platform.
For example, you can have:
Choose your most important user type. We’ll revisit other types later.
Here, specificity is the key. Go with as many details as you can. For example, you could define a journey with the following:
Consider alternative journeys and failure journeys as well.
There’s probably more than one path a user can take. You can finalize your purchase by browsing the platform, by finding a link in Google, or by receiving a private message from the seller. Capture all of them.
Not every journey results in success. There might be a scenario where, after applying filters, the results page is blank. Capture these situations as well.
Turn the user journeys into a sequential list of events. For example, your buyer’s journey could be defined as the following events:
There are various taxonomies on how to name the events, but there’s no one right way. The most important part is to keep event names consistent and maintain the same structure. Otherwise, it might be hard to figure out what event does what.
Events can come with various properties. Properties are additional, dynamic data points that are transmitted with events. These can help us avoid needless event repetition and overcomplication.
For example, let’s say you mapped all potential user journeys for your subscription products, and at some stage, you might have the following events:
Keeping six separate events for that would be messy, but with the use of properties, you can combine these events into a single event with a few dynamic properties:
As a result, instead of having six separate events, you have only one with two dynamic properties. Based on these properties, you can later filter and process these events in your analytical tools of choice.
A proper use of properties reduces the number of needed events.
You can also attach a user property to an event.
It’s similar to event properties, but instead of asking, “What exactly happened?,” they ask, “Who made the action?”
Define the optimal way to differentiate your users and build user properties around that. For example, you might find it interesting if it’s a new user or returning user, or if it’s an individual or an enterprise individual:
You’ll also notice that many events repeat as you repeat the instrumentation exercise for your other user types.
Then, instead of adding brand new events, you can specify additional user properties to differentiate the users.
The last step is to actually implement the defined events in the code.
Robust instrumentation is time-consuming. As a PM, you might need to decide what information you need right now and what you can save for the future, as well as how to balance the need to get the right data with the need to deliver new functionalities for the users.
From a high-level perspective, it might seem like instrumentation is a niche and technical aspect of building software. That might be true, but I believe product managers should be interested in the instrumentation process and contribute to it.
A product manager’s input during the process of implementing instrumentation can:
It might be tempting to leave all instrumentation to the dev team, but the truth is, developers aren’t the people responsible for the iterability of the next sprint.
It’s your job to understand what type of data you might need to analyze to assess the performance of a given solution and decide on the next steps.
Way too often, the PM wants to get specific information about the feature usage just to learn that the team doesn’t collect that type of data.
That’s an instrumentation failure.
There’s no better way to understand the nitty-gritty of the product you are working on than through learning instrumentation.
If the instrumentation was done correctly, you’ll get to know all possible user flows, failure scenarios, and much more.
You’ll also be able to look at data in a more specific and isolated manner, instead of just relying on high-level aggregated dashboards.
It’s easier to look for insights if you know what you can see. Sometimes, simply knowing what type of events and data you collect can help you guide your thinking on what to analyze next and where to seek potential correlations.
For example, you might learn that you collect information on which entry point users used to purchase a premium subscription. This might motivate you to segment users based on that to define which entry points perform best and which ones need further improvement.
Instrumentation is a powerful tool that product managers often neglect.
Although it’s a technical topic, PMs can benefit from understanding instrumentation. It helps them by:
Learning instrumentation improves the way you think as a product manager and is also one of the most efficient ways to improve your data skills.
Featured image source: IconScout
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
A strategy map is a tool that illustrates an organization’s strategic objectives and the relationship between them using a visual diagram.
Insight management is a systematic and holistic process of capturing, processing, sharing, and storing insights within the organization.
While agile is about iterative development, DevOps ensures smooth deployment and reliable software updates.
Aashir Shroff discusses how to avoid building features or products that replicate what’s already in the market but, instead, truly stand out.