What is a tracking plan and how do you build one?

In short: a tracking plan (also called a tagging plan or measurement plan) is the reference document describing everything your site must measure: every event, its variables, their format, and the exact moment it fires. It is the contract between the marketing team that needs the numbers, the developers who write the code, and the tools that receive the data. Without it, nobody can say whether the tracking is correct.

The question I ask at the start of every engagement: "would it be possible to share your tracking plan with us?" There are three possible answers. There isn't one. There is one, in a spreadsheet nobody has opened in eighteen months. Or there are three, and they tell different stories.

All three have exactly the same consequence: nobody on the team can claim the collected data is correct, because there is no reference to compare it against. The result: QA never happens, and everyone "assumes" the tracking is more or less reliable (or not).

In this article I will walk through what a tracking plan that actually gets used contains, how to build one in the right order, and why most of the ones I come across have quietly become wrong.

What is a tracking plan?

A tracking plan sets out the specifications of your measurement. It answers a single question, for every interaction on the site: what do we collect, with which information, and when?

You will see it called a tagging plan, a measurement plan, or in French a plan de marquage, depending on the team and the tooling. They are the same object.

Watch out for a very common confusion: a tracking plan is not a Google Tag Manager container, and not a GA4 configuration. The container and the configuration are IT implementations. The plan comes before them, it is the definition of the business needs, and it is what lets you judge whether the implementation is compliant. Reading your GTM container to find out what you measure is reading the code to guess the spec: possible, but backwards.

If the data layer itself is not yet clear, start with this article — the tracking plan describes what the data layer must contain, so the two are read together.

The line to remember: without a tracking plan you do not have tracking to verify, you have tracking to discover.

Why not having one costs more than you would think

The cost is never one visible outage. It is an accumulation of friction nobody attributes to the right cause:

• QA becomes impossible. Testing a data layer means comparing what is sent against what should be sent. With no clear tracking plan, only the second half of the exercise is left: watching events go by and nodding.
• Every new request triggers an excavation. "Do we already track wishlist adds?" Two hours across GTM and GA4 to answer something that should take ten seconds.
• Arbitration goes in circles. Marketing is certain the event was requested, engineering is certain it was never specified. Both are right, because nothing was written down.
• Regressions go unnoticed. A release breaks a parameter, and since no reference states what that parameter should hold, the error lives in the reports for weeks.
• Changing agency or consultant puts you back to square one. The knowledge was in the head of somebody who left.

That last point is what usually decides teams. A tracking plan is knowledge that stays in the company.

What should a tracking plan contain?

Here is the structure I use on client work. One row per event, and these columns:

The last three columns are the ones people skip, and they are the ones that keep the document alive. Without status, there is no way to know what is actually live. Without an owner, a detected anomaly has nobody to be assigned to. Without destination, you assume validating the data layer is enough, when the data may well never reach the tool.

How to build a tracking plan, step by step

Start from business questions, not from events

Mistake number one is starting from GA4's recommended events list and ticking whatever looks applicable. You end up with a plan that is complete and useless.

Start from the questions the business has to answer. "Which channel brings repeat buyers?" "Where in the funnel do we lose the most carts?" "Is the new size guide actually used?" Each question then dictates specific events and variables, and crucially: an event that serves no question does not belong in the plan, nor in the site's code. A tracking plan is judged as much by what it excludes as by what it lists.

Map the real journeys

Take the journeys as they actually exist, including the unglamorous ones: the account area, internal search, payment error states, the mobile path when it differs from desktop. Regressions almost always settle in the journeys that get documented least.

Fix naming conventions once, properly

One casing convention, snake_case preferably, applied everywhere. And when a standard exists, use it: GA4's ecommerce events (view_item, add_to_cart, begin_checkout, purchase) are documented, expected by the native reports, and understood by whoever works on this after you. Inventing cart_add costs you the standard reports and a permanent translation layer. The expected parameters are detailed in our GA4 ecommerce data layer article.

Specify down to the format, with an example

"Send the price" is not a specification. price: decimal number, excluding tax, dot separator, never null — that is one. Every variable deserves a real example value. This is what turns a statement of intent into an implementable document, and it is also what makes QA automatable later.

Have a developer review it before you freeze it

A plan signed off by marketing alone always contains at least one impossible or very expensive request: a variable that does not exist server-side at firing time, a value only known after an async call. Thirty minutes of technical review saves three rounds of QA.

Decide who updates it, and when

Almost nobody formalises this step. A tracking plan with no owner and no update trigger starts dying the day it ships. The right reflex: the plan is updated in the same release as the site change, not afterwards.

What it looks like in practice

A row in the plan describes a contract. Take add_to_cart: fires on click of the add button, variables item_id, item_name, price, currency, quantity, all required, destinations GA4 and Meta.

Translated into a data layer push, it is exactly this:

window.dataLayer.push({
  event: 'add_to_cart',
  ecommerce: {
    currency: 'EUR',
    value: 29.90,
    items: [{
      item_id: 'SKU-123',
      item_name: 'Crew neck t-shirt',
      price: 29.90,
      quantity: 1
    }]
  }
});

QA then means putting the two side by side: the push observed in the browser, and the row in the plan. Any gap is a bug, and it can be qualified without argument. That is the point at which the plan stops being documentation and becomes a control instrument.

The mistakes that make a tracking plan useless

• The plan that describes the tooling instead of the need. A list of GTM tags is not a tracking plan, it is an inventory.
• The plan with no format and no example. It will be interpreted, and therefore implemented three different ways.
• The plan nobody reviewed technically. It ships 80% complete, and the missing 20% is the part that carried the value.
• The frozen plan. By far the most common. It was correct the day it shipped, the site has changed twelve times since, and it now describes a site that no longer exists. A wrong plan is more dangerous than a missing one: people trust it.

A tracking plan is not a document, it is a living contract

This is the real problem, and a better spreadsheet does not solve it. Your tracking plan is correct on the day you ship it. Then the site changes: a product page redesign, a new funnel, a new feature going in, a migration. Every change can break the contract silently, and the document will not tell you. It has no way of knowing.

This is precisely the gap MayIA° fills. The tracking plan becomes an executable reference: LLM agents replay the journeys like a user, compare every observed event against what the plan declares, before and after each release, and the alert arrives when the gap appears — not three months later when an analysis comes out wrong. The document states what should be true; continuous verification states what still is. It is the same logic as data quality monitoring, applied to your own reference document. If you are at the stage of comparing approaches, we have covered the automated dataLayer QA tools and what separates them from QA done by hand.

In closing

If you take one thing away: the tracking plan is not a kickoff deliverable, it is the reference everything else is verified against. Start from business questions, go down to the format of every variable, have a developer review it, and name the person who maintains it.

And if you do not have one, or you suspect yours no longer describes your site: that is the first project to run, before any tracking optimisation. Let's talk — we are happy to look at it with you at Smart Bees.

FAQ

What is the difference between a tracking plan and a tagging plan?

None, they are two names for the same document. "Tracking plan" is the dominant term in English practice, "tagging plan" is more common in enterprise tooling, and "measurement plan" is the term Google's own documentation uses. The French equivalent is plan de marquage.

Who should write the tracking plan?

Framing belongs to whoever owns the measurement need, a data analyst or analytics consultant, because the plan starts from business questions. But it is only valid after a developer reviews it, since only they can say whether a variable is actually available at firing time.

What tool should I use to build a tracking plan?

A spreadsheet is enough in the large majority of cases: it is shareable, versionable, and nobody needs training. Dedicated tools earn their place once the plan passes a few hundred events or has to be consumed by code. The format matters less than having a named owner.

How often should a tracking plan be updated?

Not on a frequency, on a trigger: every site change that touches collection. A scheduled quarterly review leaves the plan wrong between passes. The rule that works is that updating the plan is part of the same release as the site change.

Is a tracking plan really necessary with GA4?

More than before. GA4 rests on a free-form event model where almost everything is configurable, so nothing stops you collecting anything under any name. Universal Analytics imposed a structure; GA4 leaves you to define it, which makes the plan mandatory rather than optional.

How many events should a tracking plan contain?

As many as there are business questions to instrument, and no more. A plan of thirty genuinely used events beats one of two hundred whose reports nobody opens. Every event collected is an event to QA and maintain: volume has a cost.