In short
- A tagging plan is a document, not a tool. It states which event exists, with which parameters, triggered where, sent to which destination.
- Without it, a figure becomes unverifiable within six months. Two people give two answers to the same question, and nobody can settle it.
- A consistent naming convention beats a perfect one. Renaming an event afterwards cuts your history in two and breaks the reports.
- Duplicating the same event between browser and server is the leading cause of wrong figures. It triggers no alert and is fixed with a shared identifier.
A scene that comes up in almost every audit we run. We ask how many quote requests the site generated last year. Marketing gives one number, sales gives another, markedly lower.
Both are right. Marketing counts an event fired when the thank-you message appears, including when the visitor reloads the page. Sales counts the records that actually reached the CRM, duplicates removed.
Nobody can arbitrate, because nobody knows exactly what that event measures. It was set up two years earlier by a provider who has since left. That is precisely the hole a tagging plan fills.
What a tagging plan contains, and what happens without one
A tagging plan is a table, often a simple shared spreadsheet, describing every measured event. Four columns are enough: the name, the exact condition that fires it, the parameters it carries, the destinations that receive it.
It is useless as long as everything is fine. It becomes decisive the day a figure looks abnormal, a developer rebuilds the checkout, or a new provider takes over the account.
Without it, the knowledge lives in one person’s head and fades fast. We regularly take over analytics accounts with more than forty events, half of them no longer used, with nobody able to say which can be removed safely. A team that no longer knows what it measures stops using it.
Naming: consistent first, perfect never
Naming conventions are the subject teams spend the most time on for the least benefit. Lower case or upper case, underscore or dot, English or the local language: these debates burn meetings.
What matters is that one single rule applies to every event, including those added in two years by somebody else. A plan mixing add_to_cart, AddToCart and cart-add for the same action makes every analysis painful, however good each individual name is.
Our practical rule: action name in lower case, separated by underscores, in English if you send to Google Analytics 4 or Meta, which already impose English for their standard events. Write it at the top of the document, and stick to it.
What a late rename costs Renaming an event does not rename the history. Data collected under the old name stays there: your reports show a drop to zero on one curve and a sudden appearance on another.
You then have to maintain two names in every report, every audience and every dashboard, until the old period leaves your analysis window. Count half a day per connected tool and a year of shaky year-on-year comparisons.
The parameters that matter, and those added out of reflex
An event with no parameters says almost nothing. An event with thirty parameters costs development time and carries a compliance risk for fields nobody will ever read.
On a purchase, six parameters carry the essentials: order identifier, amount, currency, items with reference and quantity, shipping method, promotion code. The first is the most important, because it is what allows deduplication and reconciliation with your back office.
On a contact request, three are enough: the form identifier, the page that triggered it, the request type. The rest belongs in the CRM.
The parameters added out of reflex are always the same: screen resolution, browser, page title, local time. Your tools already collect them, and no commercial decision has ever depended on them.
One exception deserves your attention: never let an email address, phone number or name travel in clear text inside a parameter. A personal identifier sent to advertising platforms must be hashed, and must rest on clear, documented consent.
Tag managers: what they simplify, what they expose
A tag manager such as Google Tag Manager solves a real problem: changing measurement without an application release. What used to take three weeks in a developer queue takes twenty minutes.
The price of that flexibility is rarely stated. By default, anyone with publish access pushes a change to production, on every page, with no review and no test. We have seen a container published from a phone on a Friday evening, duplicating the purchase event all weekend without anyone noticing.
Two settings are enough. Limit publish rights to two people, leaving editing open to those who need it, and use environments to validate before going live.
Event duplication, the leading cause of wrong figures
Since server-side measurement became widespread, the dominant failure is no longer the missing event, it is the event counted twice. The browser sends the purchase, the server sends the same one, and the platform records two conversions for one sale.
Contrary to its reputation, Google Analytics 4 does not deduplicate on its own. Meta and Google Ads do, but only if both sends carry the same event identifier, a field that is empty by default.
The tagging plan is where that rule gets written: for each event, one single source, or two sources with an explicitly named shared identifier. We cover the mechanism and the reconciliation table that reveals it in our article on tracking that lies to you in silence.
The mistake to avoid Installing server-side measurement without switching off the browser send, on the grounds that too much data beats too little. The result is not more data: it is revenue at double the real figure, and automated bidding optimising on phantom conversions.
The check takes five minutes: compare seven days of real orders against the purchases seen by each platform. If one number is exactly double another, you have found it.
The validation routine before going live
A tagging change is tested like an application deployment. Here is our sequence, about an hour for a batch of three or four events.
- Re-read the plan before touching the container. The name, the trigger and the parameters go into the document first, never the other way round.
- Preview inside the tag manager. Preview mode shows whether the tag fires, and above all whether it fires only once.
- Check the values, not just the firing. DebugView, in Google Analytics 4, shows each parameter with its value: an amount at zero or an empty currency goes unnoticed at the previous step.
- Test refusing consent. Reject the banner, redo the journey, check that nothing leaves. This test fails more often than teams imagine.
- Redo the journey in real conditions. One real one-euro order, with a promotion code, on mobile, beats ten preview tests.
- Compare figures at twenty-four hours. The next day, set your back-office orders against the conversions recorded by each destination.
The sixth is the one everybody skips, and the only one that proves the whole thing works: the first five validate an intention, the last one validates a result.
A minimal tagging plan template
Here are the two foundations we lay at the start of an engagement. They fit in one spreadsheet tab and cover most of an SME’s needs.
| Event | Trigger | Parameters | Destination |
|---|---|---|---|
| generate_lead | Server response confirming the form was saved | form_id, page_path, request_type | GA4, Google Ads |
| phone_click | Click on a telephone link | page_path, position | GA4 |
| file_download | Click on a downloadable document | file_name, page_path | GA4 |
| appointment_booked | Confirmation returned by the booking tool | booking_id, service_type | GA4, Google Ads |
| Event | Trigger | Parameters | Destination |
|---|---|---|---|
| view_item | Product page displayed | item_id, item_name, price, currency | GA4, Meta |
| add_to_cart | Add confirmation returned by the site | item_id, quantity, value, currency | GA4, Meta, Google Ads |
| begin_checkout | Entry into the first checkout step | value, currency, items | GA4, Meta |
| purchase | Payment validated server-side, one single source | transaction_id, value, currency, items, shipping_tier, coupon | GA4, Meta, Google Ads |
| refund | Refund recorded in the back office | transaction_id, value, currency | GA4 |
Tagging debt, and how to take over an unknown account An account with no plan accumulates debt: events whose definition nobody knows, tags nobody dares touch, reports nobody opens. Starting from scratch does not repay that debt, it destroys the history.
Export the last thirty days of events, rank them by volume, document the top ten by tracing their trigger in the container. Mark the rest “undocumented, not for reporting”, without deleting anything: you will sort them once you have seen what is used.
Frequently asked questions
What exactly is a tagging plan?
It is the document listing every measured event: its name, the condition that fires it, the parameters it carries and the tools that receive it. It exists so that two people give the same figure to the same question, six months after whoever configured it all has left.
Who should write the tagging plan in an SME?
The marketing lead owns it, because they know which decisions the figures must inform. The technical part is filled in with the developer or the agency. This document must never belong to the provider alone: if it leaves with them, you start from zero.
How many events should a site measure?
Between five and ten for a brochure site, between eight and fifteen for e-commerce. Beyond that, the extra events stop being consulted and their maintenance becomes a net cost. The right question is not “can we measure it” but “which decision changes depending on the result”.
How do I know if my events are counted twice?
Compare seven days of real orders against the conversions shown by each platform. A ratio close to two to one signals duplication between browser and server. The fix is to designate one single source, or to make both sends carry the same identifier.
Do we need a tagging plan if we already use Google Tag Manager?
Yes, and that is when it is most useful. A tag manager describes how a measurement is set up, never why it exists or what it counts. Without that complement, a container of forty tags is unreadable to whoever inherits it.
Where to start this week
Open a spreadsheet, list your ten highest-volume events from the last thirty days and fill in the four columns. Where you cannot answer, write “unknown”: those lines are what produce your disagreements about figures in meetings.
This exercise takes half a day and gives more clarity than changing tools. It is the basis of any serious work on data reliability and performance.
A clean tagging plan decides what you send. It says nothing about what actually arrives at the destination, and the gap between the two is the most expensive blind spot we see in audits: broken tracking never warns you. Daily reconciliation is what turns a plan into a guarantee.
Unsure what your events actually measure? On a first engagement, we open your tag container and your back office side by side, and compare seven days of orders against what each platform recorded: the gap shows within minutes. Let’s talk.