The Tagging Plan Is Not the SDR

The False Comfort of the Ledger

Every analytics team has that document. A spreadsheet, forty tabs deep, listing every eVar, prop and event in the report suite. What each one captures. Where it is set. Which processing rules touch it. The Solution Design Reference, kept with genuine care and updated after every release.

And when a report breaks, someone opens the ledger, points at a row and declares the mystery solved.

I have spent years implementing Adobe Analytics with users, for users, and I will tell you the uncomfortable truth. The SDR, for all its essential detail, cannot save you. It was never designed to. Teams maintain a flawless technical ledger for years and still end up with tracking that is technically correct and commercially irrelevant. The problem is rarely the quality of the documentation. The problem is that the SDR alone is not sufficient.

Machinery Versus Intent

The SDR is inward-looking by design. It records the current configuration of every variable. What does eVar7 capture? Where is event12 set? These are questions about machinery. An SDR documents the machinery, never the purpose.

A tagging plan begins somewhere else entirely. It begins with the user. What does the user do on this feature? Why does that journey matter to the business? Which moments deserve measurement and which are noise? Only when those questions are answered does the plan reach for the technical means. Where the SDR is a technical ledger, the tagging plan is a narrative of user behaviour translated into measurement.

I have written before about the silent battle for eVar7, in which two features quietly fought over a single variable until the reports lied to everyone. An SDR can record that collision after the damage is done. A tagging plan prevents it before a line of code is written, because variable allocation is a strategy decision, not an act of archaeology.

Without this perspective, teams build technically correct tracking that captures nothing the business actually needs. A lot of dashboards are crowded with perfectly implemented events that answer no question anyone has ever asked. That is the most expensive kind of waste in analytics. You pay for the collection, you pay for the storage, and you pay again for the confusion.

Three Documents, One Source of Truth

A tagging plan alone is not the answer either. The mature approach is a set of three interrelated documents.

At the top sits the tagging strategy, the constitution of measurement. It defines the measurement philosophy, the governance standards, the naming conventions, the variable allocation policy, the data layer standard and the privacy framework. Every other document must obey it.

Beneath it sits one tagging plan for each new feature, tightly scoped and journey-first. It opens with an executive summary and business objectives, moves through annotated user journeys, and lands on the implementation specification. That specification table pairs every tracking point with its business justification, its trigger, its data layer path and its Adobe variable, so one glance shows both what is tracked and why.

At the base sits the consolidated data dictionary. Every tracking point from every plan is aggregated into a single master record with governance columns. Added date, reviewed by, status. When a variable is superseded, it is marked deprecated with a reference to its replacement, retained as history rather than deleted. The dictionary grows with each feature and shrinks with each retirement, a living record of the entire implementation. It is also the only document an auditor, a new joiner or a developer from another team ever needs to read, which spares them the archaeology of excavating dozens of feature plans to understand one variable.

Three Habits That Make It Real

First, document the business justification for every data point. State the question the data answers, the decision it enables and the stakeholder who requested it. Before any tracking point earns a place in the plan, it passes three questions. Does it support a stated business objective? Will someone actually use this data to decide within the quarter? Can the team implement and maintain it without sacrificing other priorities? If any answer is no, the tracking point is excluded. A specification without a justification is a cost. With one, it becomes an investment you can defend in a budget review.

Second, treat the data layer as a contract. Before any plan is signed off, a frontend developer confirms that every required field exists on the page at the moment the tag needs to fire. Product categories that live in a database but never reach the data layer have killed more tagging plans than any technical failure.

Third, wire tagging into agile. Tracking requirements belong in acceptance criteria. Validation belongs in the definition of done. Fifteen minutes of plan maintenance belongs in every retrospective. Teams that skip these habits ship features with data gaps and call it velocity.

Read the Story, Not the Ledger

When you next review your documentation, resist the obvious test. Do not ask whether every variable is documented. Ask whether a new analyst could read the document and understand what the business wanted to know, and why. If the answer is no, you have a ledger. Ledgers record. They do not think, and they do not prevent the next collision.

The tagging plan thinks in journeys. That difference is the whole game.

Want to Know More?

If you want to know more, check out Adobe Analytics: A Champion’s Handbook. The tagging plan chapter goes deeper than this post can, with specification templates, sample test cases and an agile integration checklist you can lift straight into your next sprint. And if your battleground lies elsewhere, the handbook walks the whole journey, from data collection and workspace analysis to APIs, governance and the road to Champion.