Data Gone Wild: A Survival Guide to Event Taxonomy

In this article, Ofir breaks down common pitfalls in event tracking, provides specific solutions for data governance, and shows how to build an event model that aligns with real user journeys while maintaining consistent, clear data structures.

The piece is long, detailed, and provides thorough context. If you want to jump down to specific parts, use the links below!

1. How to properly categorize events into four key types:
2. .

Today I hope to help you understand why "track everything, make sense of it later" is bound to fail. The flip side of this means we need to find a way to scale your event tracking with proper data governance. And create your event taxonomy that makes sense.

To break this down, I'll cover the following:

• Defining events and properties based on your product assets and user paths
• Identifying Actions and Attributes
• Event naming that reflects the world of the user
• Making the data easy to learn (Data Democratization)
• Granularity of events
• Consistent style and verb tense

Finally, we'll put these concepts into practice by creating a user event model for Google Slides.

Exciting, right? Let’s dive in. 😊

The setup is simple: a simple web client and server sending events to their CDP, which forwards them to both Amplitude (itself a CDP) and a data warehouse.

It seems so straightforward, so manageable. With product-market fit still uncertain and investors demanding rapid iteration, who has time to think deeply about data governance?

"Look at all these screens!" their enthusiastic Head of Growth. “Just track everything! We'll make sense of it later!"

• Software Platforms: Different developers, from different teams, writing different code using different languages, running multiple live code versions on different platforms
• Products: Multiple product features or product lines sharing the same data plan; tracking for users, teams, contracts or projects; customer support impersonation
• Integrations: 1st and 3rd parties introduce new terminology, contradicting semantics and add operational dependency on tracking, non-user (data exchange) events
• Trust and Accountability: Inconsistencies between tracking data and other data sources raise questions about data validity
• Legal Compliance: Handling ownership, data access requests, data privacy audits
• Data Discovery and Democratization: How to make taxonomy accessible to all employees in an organization; how to handle and grasp thousands of assets.
• Velocity: Make sure governance doesn’t slow down the team from getting results

But fear not, dear reader. I’ve gone through all of this so you don’t have to.

Today, I’ll share some ways to turn this messy setup around.

To track at scale without losing your mind, I recommend a number of solutions: Unified Event Protocol, Developer APIs, Data Plan Observability, and Data Quality Observability.

I cover each of these briefly in my presentation if you want to dive deeper. And you can find me in the if you want to go deeper.

Today, I’ll focus on two important pieces of Data Governance:

• Building a data model around the user’s journey
• Defining the taxonomy guidelines

Let’s get started.

A User Walks Into A Website:

A user lands on a music website ➡️ They navigate to an artist page ➡️ User searches for a song and tries to add it to a playlist ➡️ The user then has to create a new playlist ➡️ Navigate to that playlist ➡️ And finally, they play the song 🏆

We'll call this User Story A. Here’s a traditional way of describing this with events:

Issue #1: Too hard to read event names.

Issue #2: Too hard to identify significant events.

Issue #3: Too many event names - every single item, element, action, etc having their own event name will cause an explosion of the namespace aka not good.

Now, let’s retell this story with a focus on solving the problems above.

These four event types differ in a few key ways, which I’ve outlined below. Most importantly, they vary in how conclusive they are in helping us determine whether something actually happened - business outcomes are the most conclusive and UI interactions are the least conclusive.

Here’s the original event taxonomy with my color coding applied:

And here’s my simplified model utilizing Amplitudes property names to illustrate what the action is.

Keeping it simple

• By using a single "Screen View" and single "Click" event instead of multiple for each Screen View and Click, we keep things very simple.
• By letting the properties carry the context, we keep the Event names simple.
• Doing the above makes it a lot easier to identify the significant events we want to spend more time with.

Consistency lets us ask better questions

• Because we’re using predefined properties that are consistent across all events, we can slice the data and start asking interesting questions like:
• How did I get this outcome?
• What was the screen associated with a certain outcome?
• What were the funnels that led to a certain outcome?
• What’s the funnel completion ratio?

Let it be this: focus on the business outcomes first.

When a new team in my org comes to me and says “I’ve got a new feature, how do I track it,” my first question back to them is, “what are the business outcomes?”

Then I ask about the navigation aspects. Then I ask about screens and maybe we create some funnels. And finally, if they really want to track UI, sure, I won’t stop them, but I show them why tracking UI is far less impactful than the business outcome itself.

Once you’ve developed the broad strokes of the data language you’ll be speaking, it’s time to define how to speak that language.

In other words, it’s time to create your taxonomy guidelines. I know, it’s very exciting, be sure you’re sitting down and have someone nearby in case you faint from joy.

But trust me here - your future self is looking back at you now and begging you to do this right from the start.

Soon you’ll put all of these skills into practice with a Google Slides event flow, so get ready.

Ramping up

Before going further, make sure you’re familiar with everything here - - that's 101 stuff and won't be covered below.

Choose Your Naming Convention

There’s no wrong answer to which style you choose, but in my humble opinion, there’s definitely a right answer:

Chicago Style Title Case Is a Great Choice for a Successful Data Plan

It's readable, consistent, and gives us a reliable baseline that we can convert to any other case if needed.

And most importantly, Amplitude supports Title Case across events, properties, and property values:

Everyone loves talking about subject-action patterns and noun-verb relationships, but none of that means anything until you create a glossary.

Your glossary defines what your subjects are - the things receiving the actions - and the actions themselves, and that’s just the tip of the iceberg:

• Subjects (nouns and compound nouns)
• Actions (verbs)
• Common Abbreviations
• 3rd Party Terms
• Namespaces
• "Block Words"
• Name Separators

For a detailed walkthrough of each of these, click .

Across each of these, you’ll need to make decisions on:

• Casing and Hyphenation
• Singular and Plural forms
• Present and Past tenses
• Readability, Clarity and Brevity
• Adherence to common usage conventions in your domain (in my company, we look at home remodeling and have terms like 'floor plan')
• Choice of ONE language (especially important for international sites)

A few of the things I always fight for in my glossary are:

• Using "Visitor/Visitors" instead of longer terms like "Anonymous User"
• Proper hyphenation for compound terms like "Signed-In User"
• Consistent handling of compound words (e.g., Playlist as one word)
• Using clear, semantically correct terms even if longer (e.g., "Phone Number" vs just "Phone")
• Standardizing common abbreviations (e.g., "Sales Rep" vs "Sales Representative")

Naming conventions by event types

Remember our four event types?

• 🟢 Business Outcomes
• 🔴 Screens
• 🟡 Funnel Steps
• 🔵 UI Interactions

It’s important we have distinct naming conventions for each.

Confused yet? Good. This stuff isn’t easy, I know, but it’s 10x easier than the alternative - decoding a tangled mess of disorganized data at 3AM on a Saturday because your CEO just discovered Meta analytics and now has 47 'quick questions' about why their numbers don't match yours". Trust me.

The best way to get comfortable with all this is practice, so let’s do that now.

If you were in charge of naming this Google Slides screen for tracking purposes, what would you call it?

✅ "Google Slides - Edit"

And here’s why:

• Clear product name ("Google Slides")
• Simple hyphen separator
• Action/view type at the end ("Edit")
• Consistent with other screens like "Google Slides - Present" or "Google Slides - Browse"
• Scales nicely across the whole application:
  • "Google Slides - Present"
  • "Google Docs - Edit"
  • "Google Sheets - Edit"
• Easy to read in analytics dashboards
• Easy to group and filter

See the pattern? [Product] - [View Type]. Simple, consistent, clear.

In order to properly define our Business Outcomes and Funnels, we first need to name our containers and elements.

What would you name each of these containers?

It’s harder to see these so I’ll just show you what I named each one. Big thing to note here is that when you see the same thing repeated (like each “Theme Card” in the “Theme Selector”), just use the same name for all of them.

Why? Because you can't predict how many there'll be, and you don't need to. One "Theme Card" name covers them all.

Let’s put it all together and, using the naming system above, outline what events happen when someone clicks “Share” on Google Slides. You may want to open a new Google Slide on your own (go to and go through the actual flow).

Provide the following for each event in the flow:

• Screen Name
• Funnel Name (if applicable)
• Container Name
• Element Name

(pause here to try it on your own before reading below)

Ready?

Here’s how I broke it down:

For a detailed walkthrough, click .

One thing to focus on: why did I code the Slides Name Updated as a Business Outcome?

Because something actually changed in our system. The presentation has a new name in the database. Unlike UI clicks which might or might not lead to changes, this represents a real, permanent change to the data. It's the kind of thing product managers care about when measuring feature adoption.

See how we have different types of events telling different parts of the story?

• 🔵 UI Interactions tell us HOW users are doing things
• 🟡 Funnel Steps tell us WHERE users are in a process
• 🟢 Business Outcomes tell us WHAT actually happened

That last one is crucial. There's a big difference between "user clicked save" (UI Interaction) and "slides name was updated" (Business Outcome). The click might fail, the network might be down, but a business outcome means something actually changed. That's why we track them separately and give them special attention.