Tag Management & Data Layer

A tag management system is quickly set up. After that, different teams and agencies add tags, names are assigned inconsistently and old scripts keep running. At some point figures contradict each other, pages get slower, and “what exactly are we measuring here?” no longer has a quick answer.

The system itself is only a tool for order and fast changes. Whether the data is right in the end depends on the measurement plan, the data layer and how the container is built. That is why we do not start in the container, but with the questions the data is supposed to answer.

Audit: what is really running in the container

A container consists of tags (code that sends data to a destination), triggers (the conditions under which a tag fires) and variables (the values both use, such as order value or page type). In the audit we go through all three and look for duplicates, paused tags, tags for finished campaigns or cancelled services, and references to page elements that no longer exist. Then there are scripts hard-coded in the page that send data around the container. You only find those by looking at the page itself.

We also check what actually arrives, and compare a few key figures with the source system, for example orders in the shop against recorded purchases. And we clarify who creates tags, who maintains them and who may publish. The result is a list of what stays, what is adjusted and what goes.

Measurement plan: questions first, then events

We derive the measurement plan from the business questions, not from what could technically be measured. At which step of checkout do most people drop out? Which forms lead to enquiries that arrive in the CRM? For each question we define the event, parameters, trigger, destination and definition. That keeps the plan manageable and avoids events nobody analyzes.

We align the definitions with the BI team’s KPI catalog, so a metric means the same thing in the dashboard and in tracking.

The data layer as a contract between website and tags

The data layer is a structured object on the page into which the website writes information and events, such as page type, product, cart or order. Tags read their values from there and no longer from text or elements on the page. A new design then no longer breaks tracking, and all tags get the same values, for example the same order value with or without shipping. The figures also come from the system that knows them, the shop, rather than from the front end.

We describe the data layer as a specification: event names, fields, data types, example values and the moment at which an event is sent. Development implements it, the analytics team builds the tags on top, and we check the result. Even if data is later forwarded through a server of your own, the data layer remains the source.

Keeping the container in order

A few rules keep the container readable. A fixed naming scheme of type, target and event, for example tag_analytics_purchase, trg_event_purchase and var_dl_order_value, shows what an element does without asking anyone. Triggers and variables are defined once and reused, and folders group things by topic.

On permissions: few people should be allowed to publish, and access for agencies is granted for a limited time. Google Tag Manager offers read, edit, approve and publish levels per container.

For load time, only tags that are needed should run, and only on the right pages. We look harder at scripts from external providers, since they affect load time the most. Which tags may start only after consent is also reflected in the container, but that is a topic of its own.

Versions, environments and approval

Changes to the container affect data collection immediately. Every publication should therefore create a named version with a short description, so that you can go back to the last working one if something goes wrong. Google Tag Manager now suggests a name and description for a new version itself, based on the changes in the workspace.

Whether a system comes with environments is a real criterion when comparing. Tealium iQ has Dev, QA and Prod built in, in Google Tag Manager you create your own, and the systems from Adobe and Matomo also have development, staging and live stages.

Tealium offers a built-in approval workflow as an option for production, while according to Google it exists in Google Tag Manager only in the 360 edition. Where the system has none, we set up sign-off by a second person as a process.

Testing happens in preview mode: does the tag fire on the right event, and are the values correct? For critical events such as orders, automated browser tests are an option. We document the measurement plan, the data layer specification, the naming convention and a change log with owners.

Which system fits, and what stays independent of it

The choice usually follows the analytics platform rather than individual features. If you use Adobe Analytics, its own tag management serves you best. If you run Matomo yourself and want data sovereignty, you can use its tag manager. Without such a tie, Google Tag Manager is the normal choice. When in doubt, hosting and data protection requirements, team size and the approval process you want decide.

The measurement plan and the data layer do not depend on the tool, because they describe what is measured, not where it runs. If you build them cleanly and vendor-neutrally, you can switch systems later, or move parts of the measurement to a server, without reinventing your tracking.