You Need a Lean Data Taxonomy to Scale Self-service Analytics

Taxonomy design goes hand-in-hand with product analytics. Regardless of your industry, company size, product portfolio or data maturity, you can’t establish scalable product analytics without a lean taxonomy. This is especially important when you consider that most companies will need to track cross-platform and cross-product user journeys, and set up their product analytics instrumentation in a way that anticipates future scenarios.

In other words, you need to future-proof your data taxonomy from the moment you launch a product analytics solution. Follow the key principles below to set your product analytics up for success in the long-term.

Best Practices for Future-proofing Your Product Analytics and Data Taxonomy

1. Invest heavily in the taxonomy of your first product

Product analytics is a team game and it requires you to define clear roles and responsibilities for people involved in the process. A strong setup requires involvement from two critical roles:

• A business lead (often head or VP of product) who will define the core set of use-cases that need to be covered by product analytics
• A technical lead (often senior engineering role) who will drive the technical side of analytics implementation

Both of these roles should have a cross-platform and cross-team view on the product to be able to make decisions on the product level. If there are multiple product and engineering teams that will be involved in the implementation, it is crucial that these two roles are able to coordinate the teams. This will ensure consistency of product analytics regardless of the number of teams involved. Keeping the broader leadership team in the loop often creates additional momentum and excitement around product analytics and helps to elevate the work in the company-wide roadmap.

Once your team is ready to build the product taxonomy, you should establish a big picture of where your product is at before diving into nitty-gritty details. To do this, think through top-down questions that product analytics will answer for your team, such as:

If you establish a common understanding on these fundamental questions among your team(s), you will always be able to expand the coverage of your product analytics and dive deeper in the areas with the biggest potential (e.g. unclear use-paths, biggest drop-offs).

Once you’ve defined the use cases for product analytics, it’s time to define your data taxonomy. Namely, this consists of:

• Events
• Event Properties (context of events)
• User Properties (context of a user).

Your goal at this stage is to keep the taxonomy as lean as possible, aligned with the questions above. In our experience, instrumenting just 20-30 events is enough to answer about 90% of the questions that teams consistently ask.

Oftentimes, just a handful of events will produce solid answers to common business questions. This will provide your company with an understanding of the real (not simply the intended) user journeys, and unlock new insights, such as:

• the real personas of the product
• the friction points in the user journeys
• why some users convert and others do not
• which UI improvements should be made on drop-off moments

You can learn more about documenting events, event properties, and user properties in Amplitude’s Data Taxonomy Playbook. Key points include keeping the taxonomy lean, using consistent naming conventions, and striking the right balance between instrumenting events and properties.

2. Stay away from tracking low-level UI elements

Tracking low-level and unimportant UI elements is the #1 sign of non-scalable product analytics, in our experience on Amplitude’s professional services team. Oftentimes, it’s reflective of an instrumentation approach that mixes up the definitions of events and event properties.

For example, your product team might be working on a bet to improve the checkout flow of your product. As they work on this bet, they might test a few iterations that add or remove UI elements. While trying to gauge the performance of each test, there might be a natural tendency to track events like:

• Checkbox clicked
• Button clicked
• Toggle swiped
• Field text clicked

If your initial taxonomy fills up with UI elements like the ones above, it might be time to take a step back and regroup. Yes, the team has been working on improving the checkout flow and has been adjusting those elements, but remember: The goal of this flow is still that the users are able to move seamlessly through it. What the business wants to see as a user journey in analytics is likely “Checkout Started” → “Payment Method selected” → “Payment Details Selected” → “Transaction Submitted.” This type of flow is much more informative and scalable than something ilke: “Button Clicked” → “Checkbox Selected” → “Field Text Clicked”. If you’re still seeking granularity as you evaluate the conversion between steps, you can address this with two alternative methods:

1. Instrument UI elements in the event properties of events. For example, a “Transaction Submitted” event can have a property that indicates if user performed the action using a checkbox, button click, or other UI element.
2. Use A/B tests to improve conversion on steps with high drop-off. For example, if you observe high drop-off between steps 1 and 2, it’s often more effective to run an A/B test with a modified UI and observe objective results on your sample, rather than to instrument multiple elements during the iteration process.

3. Establish the link to business outcomes

Ultimately, your product analytics setup should reveal how your digital products drive your business.

With a well-instrumented data taxonomy, there are plenty of factors your team can explore in the user journey, such as:

• personas
• common paths
• impact of releases to key metrics
• conversion drivers
• user journeys
• and more

We see that teams that succeed in product analytics always close the loop between the the events they track, the business they are in, and the “engagement game” their product plays.

(The engagement game refers to one of three primary “games” your product drives: transaction, attention, or productivity. Read more about these methods in Amplitude’s Mastering Engagement playbook.)

For example, if your product falls into the “productivity game,” you could have a great onboarding funnel, but that great onboarding funnel isn’t enough to match your business goals. Your product ultimately has to fulfill the productivity promise; this means users should be returning to use the core features that drive value (productivity) for them. In addition to tracking the success of your onboarding flow, be sure to leverage product analytics to assess how users repeat critical actions.

​​4. Don’t track everything at once

Tracking data is perceived as a must in most of digital companies these days and the tech industry makes it increasingly easy to collect, store, and process vast amounts of data. Companies that start with product analytics and already have a CDP or a data warehouse are often inclined to skip the taxonomy design step and just start streaming in all the precious data they have already collected.

The practice of Professional Services at Amplitude comes back to the old principle: less is more. Showing a set of 10 relevant and self-explanatory events to your Amplitude users is always better than showing a list of 600 events (often with duplicates and without crucial event properties) to people who just need an insight about how many active users are out there or what the critical conversion rate is.

It is completely in your hands to instrument lean and concise taxonomy that drives self-service scalable product analytics—the type of analytics your colleagues will be delighted to use in day-to-day tasks.

From one product to cross-product analytics

Delivering a lean initial implementation of product analytics unlocks insights for every digital team: marketing, product, engineering, and more. With these reliable insights, you also pull the organization towards data-informed culture. Teams start to move away from data bottle-necks to self-service analytics and shorten the cycle to insights from weeks to minutes.

The lean taxonomy of the first product sets the standard of product analytics in the company and allows other teams follow the example. Successful cross-product analytics is only possible when each and every product has well-instrumented taxonomy connected to the business outcomes the company wants to achieve.