How a data layer works
A data layer is a named JavaScript object sitting on the page — usually window.dataLayer — into which the website pushes information in a fixed, agreed format. Tag Manager watches that object, turns its keys into variables, and hands them to whichever tags need them. Nothing is scraped off the screen: the site states the facts, and the tags read them.
Two kinds of information go in. The first is the state of the page as it loads — what type of page it is, whether the visitor is signed in, which product is being viewed, which currency the shop is using. The second is events pushed as things happen: a form submitted, an item added to a basket, an order completed, each carrying the details that event needs.
The naming is the real substance. A key called order_value means whatever the developer and the marketer agreed it means, and every tag downstream inherits that decision.
Why the data layer matters
Without one, tags have to guess. They match a button by its CSS class, read a price out of visible text, or infer a sale from a thank-you URL. All of that works until somebody redesigns the page, renames a class or changes the confirmation address — and then measurement fails silently, because a tag that finds nothing does not raise an error. Weeks of data can be gone before anyone notices.
It also gives every destination the same source. Analytics, ad platforms and your CRM all read the same pushed value, so a lead counted in one place is the same lead in the others. That is what makes server-side tracking and consent handling practical later: the values already exist in a clean form, ready to be forwarded rather than rebuilt.
Common mistakes with the data layer
The usual technical fault is overwriting the array instead of adding to it. Assigning a fresh value to window.dataLayer after Tag Manager has loaded throws away everything already collected; push to it instead. The next is timing — pushing a value after the tag that needs it has already fired, so the tag reads an empty variable. On single-page sites this gets worse, because values from the previous screen linger and end up attached to the next one.
The riskiest mistake is not technical at all. Personal details such as an email address, a phone number or a full name do not belong in the data layer, because anything sitting there can be read by any script on the page and sent onwards. If a platform needs a customer identifier, it should be hashed or handled server side, never left in the open.
How to act on it
Write the specification before any code exists. List each event, when it fires, every key it carries and the type each key holds — text, number, true or false. Keep it in one document that both the developer and whoever manages Google Tag Manager work from, and treat a rename as a change that needs agreement, not a tidy-up.
Then verify rather than assume. Open preview mode, walk the real journey on a real device, and confirm each variable resolves at the step where it is meant to. If you are starting from nothing and the budget is tight, specify only the events that touch money — enquiry, booking, purchase — and add the rest once those are stable and trusted.