Event Taxonomy Without Becoming an Archaeological Spreadsheet

The problem

After a team realizes that chaotic tracking hurts, it often falls into another exaggeration.

Someone creates:

• a huge spreadsheet
• fifty columns
• too many conventions
• too much review

In theory, that would bring order.

In practice, it usually brings abandonment.

Because nobody can keep up with bureaucracy that is bigger than the original problem.

Mental model

Event taxonomy should work like a coding convention.

Which means:

• simple enough to be used
• strong enough to prevent chaos

If it does not change the team’s real behavior, it is not a system.

It is dead documentation.

Breaking the problem down

The minimum that needs to be standardized

You do not need to standardize everything.

But you do need to standardize enough to avoid ambiguity in the central points:

• event name format
• accepted verbs
• common properties
• convention for error, attempt, and success

That core already removes a lot of noise.

Canonical events matter more than local micro-variations

A lot of mess starts when every screen creates its own dialect.

Example:

• signup_started
• start_signup
• register_begin
• registration_started

Most of the time the product wants to measure the same thing.

A strong taxonomy tries to converge on a few canonical names.

That is not pedantry.

It is what lets you compare journeys later.

Shared properties are also part of the taxonomy

Some teams only think about the event name.

But a lot of the chaos lives in the properties.

Examples of fields that usually benefit from convention:

• source
• plan_type
• platform
• error_code
• variant

If each event names the same idea differently, the problem remains.

Documentation needs to be operational

Useful taxonomy documentation usually answers quickly:

• what does this event mean?
• when does it fire?
• which properties are expected?
• is there a similar canonical event already?

If the document reads like a thesis instead of a quick usage guide, it will age badly.

Evolution needs a change rule

Without that, the team only stacks versions:

• checkout_started
• checkout_started_v2
• checkout_started_new

That is a symptom that nobody agreed on how the contract should evolve.

Sometimes the right answer is:

• keep the same event
• adjust a property
• version consciously
• deprecate the old one

The important part is not to turn history into archaeological digging.

Simple example

Imagine the product search area.

Without taxonomy:

• searched
• search_done
• result_click
• open_result
• search_error_screen

With minimum taxonomy:

• search_submitted
• search_results_loaded
• search_result_opened
• search_failed

Common properties:

• query_length
• source
• results_count
• error_code when there is a failure

That already solves a lot.

Without a giant spreadsheet.

What usually goes wrong

• Creating a taxonomy so detailed that nobody follows it.
• Ignoring shared properties and focusing only on event names.
• Allowing too many synonyms for the same behavior.
• Not treating semantic changes like contract changes.
• Using the _v2 suffix as a permanent solution.
• Centralizing review so much that the team starts avoiding instrumentation.

How someone more senior thinks

A more mature person tries to protect two things at the same time:

1. consistency
2. speed of use

If you only protect consistency, it becomes heavy process.

If you only protect speed, it becomes chaos.

The sweet spot is usually:

• a few rules
• clear examples
• canonical names
• short documentation
• conscious evolution

Interview angle

This can appear in questions like:

• “how would you keep events consistent?”
• “how would you prevent each team from instrumenting in a different way?”
• “how would you organize tracking in a large product?”

The interviewer wants to see whether you:

• think in contracts
• understand the operational cost of standardization
• avoid both chaos and bureaucracy

Weak answer:

I would make a spreadsheet with all the events and standardize the names.

Strong answer:

I would define a minimum convention for names and common properties, with a few canonical events per journey. The documentation needs to be short and operational, because if the system becomes too heavy the team will work around it and consistency will disappear again.

Closing

A good taxonomy does not call attention to itself.

It just keeps tracking readable six months from now.

If understanding the data requires a veteran teammate to translate everything, the taxonomy failed.

And if registering a new event requires a bureaucratic ritual, it also failed.

The middle ground is what lasts.