What a tagging plan really is
A tagging plan is the contract for your data. It defines, before a single line of code, what you collect, why, and in what form. Everything else flows from it.
Most sites have no plan. They have an accumulation of tags placed as needs arose: a clic_bouton event here, a form_submit there, a lead added three months later by someone else. Six months on, no one knows which event measures what. GA4 reports contain duplicates, parameters change names from one page to the next, and every analysis starts with an archaeological investigation.
The tagging plan breaks this cycle. It is a single document that answers three questions for every measured interaction: which event, triggered by what, with which parameters. It aligns the marketing teams (who define the goals), data teams (who use the figures), and development teams (who implement). Without this foundation, your decisions rest on data you can neither verify nor compare over time.
This rigor is not just an analytics comfort. Clean data is also a technical signal. The same teams that master their collection generally master their on-page markup, a point any serious SEO agency checks during an audit. Clean tracking and clean architecture go hand in hand.
Mapping the events before coding
Start by listing the actions that matter to the business, not the technical clicks. A good event answers a business question: 'how many prospects requested a demo this month?', not 'how many times was this blue button clicked?'.
The method is top-down. Start from the goals, deduce the conversions, then the micro-conversions that lead to them, and only then the secondary interactions. This hierarchy avoids the classic trap: tracking hundreds of events, 90% of which never serve a decision.
The three levels of events
Structure your mapping into three distinct layers. This clarifies implementation and QA priorities.
The actions that generate direct value: purchase, quote request, appointment booking, sign-up. They are few in number and must be 100% reliable. Any error here distorts your ROI.
The intent signals that precede a conversion: add to cart, viewing a pricing page, downloading a resource, deep scroll on a key page. They feed the optimization of the journey.
The usage events that enrich the analysis without being goals: opening an FAQ accordion, video play, using a filter. To be tracked sparingly, only if an analysis question justifies it.
For each event, document the exact trigger (click, submission, element view, scroll threshold) and the page or component concerned. An event without a precisely defined trigger is a source of gaps between what you think you are measuring and what you actually measure.
This mapping discipline matches the one applied to server-side tracking, where each event passes through your infrastructure before reaching the tools. See our guide on server-side tracking to make collection reliable once the plan is defined.
A naming convention no one circumvents
The naming convention is what distinguishes a living plan from an abandoned one. A simple, strict rule applied without exception beats a perfect rule that everyone interprets their own way.
The basic principle: a single format for all event and parameter names. Lowercase snake_case has become the standard, notably because GA4 already normalizes in that direction. No accents, no spaces, no random capitals. demande_devis, never Demande Devis nor demandeDevis.
Recommended structure
Adopt an object_action structure for event names. The object describes the entity concerned, the action describes what happens to it. This makes the plan self-documenting and easier to sort.
| Criterion | Chaotic naming | Strict convention |
|---|---|---|
| Format | ClicBouton, form-submit, Lead | bouton_clic, formulaire_envoi, lead_genere |
| Readability | Ambiguous, depends on the author | Predictable, self-documented |
| Comparison over time | Broken by renames | Stable, can be tracked historically |
| Parameters | Inconsistent (page_url vs url_page) | Normalized and reused |
| New-joiner onboarding | Several days of investigation | Reading the plan is enough |
Parameters deserve the same rigor as events. Define a library of reusable parameters (page_type, cta_position, form_id) with their expected type (string, integer, boolean) and their allowed values. A page_type parameter that sometimes accepts home, sometimes accueil, sometimes Homepage is unusable for segmentation.
ecom_, lead_, media_). This avoids name collisions when the plan grows and several teams contribute to it.Governance: who decides, who validates, who documents
A tagging plan without governance degrades from the very first sprint. Governance defines the process by which an event enters the plan, is validated, then implemented. It answers one question: who has the right to modify the company's data?
Appoint a single owner of the plan, the data owner. They arbitrate additions, enforce the convention, and settle naming conflicts. Without a clear owner, every team adds its tags in its own corner and consistency collapses.
The validation circuit
The typical workflow follows four steps, in this order, with no shortcut.
A team expresses a measurement need tied to a goal. It fills out a form: which business question, which proposed event, which parameters.
The data owner checks consistency with the existing plan, applies the naming convention, and confirms that no equivalent event already exists.
The validated event is added to the plan, then developed in the tag manager or the data layer, in line with the documented specification.
Before going to production, you verify in a test environment that the event fires at the right moment with the right parameters. No tag goes to production without testing.
Maintenance is the most frequent blind spot. A plan goes stale: features disappear, goals change, tags become orphaned. Schedule a quarterly audit to compare the documented plan with the actual collection, spot events that no longer fire, and remove those that no longer serve any analysis.
This governance of first-party data takes on new strategic value in the era of generative AI. Correctly measuring your AI share of voice requires clean collection of traffic from ChatGPT, Perplexity, or the AI Overviews, segments still poorly isolated by default in most analytics setups.
Only 11% of domains are cited by both ChatGPT and Google's AI Overviews. Without a tagging plan distinguishing these traffic sources, you cannot measure where your AI visibility is actually progressing.
Tooling and deployment without breaking what exists
The right tool depends on your maturity. Start simple. A shared spreadsheet remains the most robust and universal foundation of a tagging plan: one row per event, with columns for the trigger, the parameters, the status, and the owner.
For complex sites or large teams, dedicated platforms such as Avo, Iteratively, or Segment Protocols add a decisive layer: automatic validation. They continuously compare the actual collection to the defined schema and alert as soon as an event deviates. That is the difference between hoping the plan is respected and knowing it.
From plan to data layer
The plan materializes technically in the data layer, the data layer that exposes your events to the tag manager. Three principles for a lasting deployment.
First, the data layer must be populated server-side or in the rendered HTML, not only by JavaScript executed late. This point goes beyond analytics: LLMs do not execute JavaScript, so structured data present from SSR serves both your tracking and your visibility in AI engines. A clean data layer is consistent with a citable page.
Then, version your plan like code. Every change must be traced, dated, and attributed. Data that can be tracked historically requires a plan that can be tracked historically.
Finally, test systematically before production. A wrongly triggered event in production can pollute weeks of data before being detected. The cost of testing is always lower than the cost of a distorted history.
To speed up implementation, start from proven templates rather than a blank page. Our GEO Audit Templates Pack includes a tagging plan outline and a governance grid ready to adapt to your stack.
Clean tracking is only worth it if it captures the right signals. Request your free GEO audit: we identify collection gaps and opportunities for citation by AI engines.
Questions fréquentes
What is a tagging plan?+
A tagging plan is a document that lists every event to be collected on a site or application, along with its trigger, its parameters, and its naming format. It serves as a shared reference between marketing, data, and development teams to guarantee consistent and reliable collection.
What is the difference between a tagging plan and a tracking plan?+
The two terms refer to the same thing. 'Tracking plan' is the most common form in English, while 'tagging plan' is also widely used among professional teams. Some teams also speak of a data layer specification when the document describes the data layer in detail.
What tools should be used to manage a tagging plan?+
A simple shared spreadsheet is enough to get started and remains the most universal foundation. For complex sites, dedicated tools such as Avo, Iteratively, or Segment Protocols add automatic schema validation and detection of gaps between the plan and the actual collection.
How often should a tagging plan be updated?+
Every time a feature is added, a journey changes, or a new business goal appears. In practice, the plan must be updated before any tag development, never after. A quarterly audit then allows you to detect gaps between the documented plan and the actual collection.
