Before You Add Another Analytics Event, Write a Tracking Plan

A driving school added a 'button_click' event to its booking page to see how many people started the enrollment form. Three months later, a different staff member added another button-click event to a separate page, using the exact same event name but attaching different properties to it. When someone finally tried to build a report combining both, the numbers were meaningless — 'button_click' now referred to two unrelated actions on two different pages, merged into one indistinguishable bucket.

Why event-based analytics is more fragile than pageview analytics

Modern analytics platforms have largely moved from counting pageviews toward tracking discrete events — a form submission, a video play, an add-to-cart, a scroll-depth milestone. This gives far more granular insight into behavior than a pageview count ever could. But it also removes a guardrail that pageview tracking had built in: a pageview is automatically defined by the URL that generated it, while a custom event's name and structure are entirely up to whoever sets it up, with no enforced consistency between one event and the next unless a business builds that consistency itself.

What a tracking plan actually is

A tracking plan is a single reference document — a spreadsheet is usually sufficient — that lists every custom event a business intends to track, what it means, when it should fire, and what additional properties (metadata) get attached to it. It exists for the same reason a UTM taxonomy exists: consistency has to be designed in advance, because retrofitting consistency onto data that's already been collected inconsistently is rarely possible after the fact.

• Event name — a short, consistent identifier following one naming pattern across the entire site (verb_noun, like form_submit or video_play, is a common and readable convention)
• Trigger definition — the exact user action that should cause this event to fire, described precisely enough that two different people implementing it would build the same thing
• Properties — the additional data attached to the event, such as which form was submitted or which video was played, with a fixed, agreed list of property names reused across similar events
• Owner — who is responsible for that event firing correctly, useful once more than one person is capable of adding tracking to the site

A naming pattern that scales past the first few events

The specific naming convention chosen matters less than picking one and applying it everywhere. A common, readable pattern uses a lowercase verb followed by a noun, separated by an underscore — form_submit, video_play, cta_click — with properties as a separate structured field rather than encoded into the event name itself. The failure mode to avoid is descriptive but inconsistent naming, where one event is called 'Contact Form Submitted' and a functionally identical event elsewhere is called 'submit_contact,' making it impossible to combine them in a report without manual reconciliation.

1. List every event currently firing on the site today, exactly as it's actually named in the analytics platform, not as it was intended to be named
2. Group events that represent the same underlying action but have inconsistent names or properties
3. Agree on one canonical name and property structure for each group going forward
4. Document the canonical list in a shared tracking plan, and require any new event to be added to that document before it's implemented, not after
5. Migrate or map old inconsistent event names where feasible, and accept a visible seam in historical data where it isn't

An event name is a promise that the same action will always be labeled the same way. Break that promise once, quietly, and every report built on it afterward inherits the crack.

Where this connects to broader reporting

A tracking plan isn't only useful at the moment of implementation — it becomes the reference document anyone building a dashboard or funnel report should consult before assuming what an event means. Without it, a marketer building a conversion funnel has to guess whether 'checkout_start' and 'begin_checkout' refer to the same action or two different ones, and that ambiguity compounds every time a new person touches the analytics setup. A living tracking plan, reviewed whenever a new event is proposed rather than built once and forgotten, is what keeps event-based analytics trustworthy as a site's tracking needs grow more complex.

For businesses whose reporting has grown past what a single person can hold in their head, formalizing this kind of documentation is a reasonable part of a broader analytics engagement — see how NetWebMedia approaches reporting infrastructure at the services overview.

← Back to all articles