From metrics to events: How to build the best tracking schema for you

As a specialist in tracking and analytics systems and founder of deepskydata, I get a lot of questions about designing schema. If you read my previous blog post, you know that you probably need a tracking plan. Now, you just need to decide what metrics to prioritize and which events to track to get the most out of your data. 

Easy, right? 

On the surface, designing an event schema is simple: You pick the metrics you want to measure first, and then you define the events that will help you track those metrics. 

In reality, picking those metrics can be quite complex.  

For starters, most product teams are tracking too many events. In my opinion, 50+ events are already too many to track, especially when it comes to product and marketing analytics. 

Without the right data setup, you’ll drown in data that doesn’t tell you anything important about your product. You’ll miss how metrics relate to each other, and you won’t be able to gather the insights you need. 

Fortunately, I have a better way. Here’s a tried-and-true three-step method to design an event schema that will serve your business. 

When building their tracking setups, most teams I’ve worked with make the same mistake: They define their event schema from the application level. I can’t judge—I’ve certainly been guilty of doing the same thing in the past. 

These teams log into their application or their software, go through the typical user journey(s), see where they can click and what actions are relevant, and track an event for each one. 

The problem with this approach is that you will always end up with too many events. Even more annoying, there will still be key events that you aren’t tracking that can tell you important information about how your business or product is doing. 

When we do this, we’re choosing and tracking events at a low level, within the application. 

Instead, I recommend defining events from the top down, starting from an overarching business or product perspective. What are the most important performance metrics for your business? What is your North Star metric? 

Once you’ve defined the most important metrics you can build a metrics tree to track them (more on that in step 2), and finally identify and track the events that will drive those metrics (you guessed it — that’s step 3). 

If you’re unsure how to build an events schema setup for your business, building a metrics tree is an excellent starting point. 

On a most basic level, a metrics tree is a growth model. I recently spoke to Abhi Sivasailam, CEO and founder of Lever Labs, about subscription analytics and how to design metrics trees (in this case, to analyze MRR).  

As Abhi explains on the Levers Labs blog, a metrics tree is “the structural backbone that binds every metric to its business significance…every metric derives legitimacy from its lineage back to the North Star.”

The higher a metric is on the tree, the more impact it has on the North Star metric and the performance of the business. The lower down the tree you go, the narrower the impact of each metric gets—but each metric always relates to the rest of the tree. 

The metrics in a tree can have two kinds of relationships: components relationships or influence relationships. 

In component relationships, the metrics have a direct, quantifiable impact on each other. “It’s true by construction, it’s true as a formula, and it’s true by definition,” Abhi says. Component relationships are constant. 

For example, in the MRR metrics tree above, leads x win rate = new customers. With 6,201 leads and a 56% win rate, we have 210 new customers. 

The second type of relationship we have is an influence relationship. These are metrics that are (positively) correlated but don’t have the same quantifiable connection. “It’s a probabilistic relationship,” Abhi explains. 

In the MRR metrics tree above, speed to lead and win rate have an influence relationship, Abhi says. “Speed to lead is usually positively correlated to win rate,” he says. “The faster I connect with someone, the more likely I am to win them. But it isn’t true by formula.” 

Building a metrics tree requires three steps: 

If you need more help, Abhi also has a great Miro template to help you start designing your own metrics trees. 

Once you’ve designed your metrics tree and identified which metrics to track, the next step is getting the data you need to calculate those metrics. 

In a classic data model, it’s often tricky to introduce new metrics, because it requires you to add or otherwise modify your data model, which takes a lot of time and effort. 

This is why I recommend using event data. Event data is easier to get and easier to model because you can build it on top of your existing data models. 

Start by looking for existing event data. If you don’t see any events, look for timestamps and unique identifiers. For example, in a table full of account data, you will have a unique identifier, probably an account ID, and a timestamp from when the account was created. Together, these give you an “account created” event with an account ID property attached. 

This event-focused approach makes it a lot easier to find the metrics we need and build a metrics tree. It also gives us the flexibility to modify our metrics tree in the future. 

Here’s an example of a metrics tree that I developed for a post on how to measure a data platform: 

So, how do we get from event data to these metrics? 

If you look at the metrics tree example above, you see two revenue streams: subscription revenue and compute revenue. Compute revenue is unique to data platforms, also called usage-based revenue. Data platforms run jobs for a specific amount of time, and they charge for these jobs in different ways, like price per second or a credit system. For context, that’s what that branch of the metrics tree represents. 

This is an extensive metrics tree, and we have a lot of information to help us start building an event schema. 

You can see the full breakdown of the events I tracked in this Miro board. The blue boxes are the entities. The orange are the events tracked, and the green are the properties for each event. 

As you can see, the event schema for this metrics tree is pretty minimal: The three entities are account, job, and subscription. We don’t need to track hundreds of events. This is more than enough to get started, and having these values allows us to calculate all of the metrics that we need to fill out our metrics tree. 

For accounts, for example, we track the events “account created” and account deleted,” and we use the properties account ID, account industry, account subscription, account size, and account age. 

We do the same for the job and subscription entities, and we’re ready to start tracking. That’s all we need to get started.

Designing an event schema like this might look complicated at first glance, but it really isn’t. In my experience, the entire process can be completed in a week or two. Once you’ve implemented event tracking, you can start gathering data to report on these metrics immediately. It’s that straightforward. 

As you can see, when you have an efficient metrics setup, like a metrics tree, you can easily figure out which events you need to calculate to report on those metrics—without the 50 or even 100+ events you don’t need. 

Determine your North Star metric, design your metrics tree, build your event schema, and upgrade how your team works with data. 

This content originally appeared on my YouTube page. Subscribe for more event data conversations and explainers.