By Marc Alexander

Most tracking setups weren't designed. They built up, one campaign and one agency at a time, until nobody could say how data gets from the website to the reports. Here's the shape worth aiming for, whatever the size of the site.

It has five layers. Each one has a single job, and each one hands over to the next in a way that anyone can check.

  1. 1. One consent platformDecides what each visitor has agreed to, by region, and tells every tag.
  2. 2. A dataLayer the website writesThe site says what happened: a page view, a product view, a form sent, a lead.
  3. 3. One web containerGoogle Tag Manager turns those events into tags, and checks consent on every one.
  4. 4. A server-side container on your own subdomainReceives one stream from the browser, checks consent again, and decides what each platform gets.
  5. 5. The destinationsGA4, Google Ads, Meta and the rest, with BigQuery for reporting.

There should be one source of truth for consent, and every tag should read from it. That means a consent platform that:

  • applies the right rules for each region, so visitors in the UK, the EU and the US each see the right banner (see region-specific consent in Tag Manager)
  • supports Google's Consent Mode v2 natively, without custom code bridging the gap
  • keeps a record of each visitor's choice, which you'll need if a regulator asks

Nothing else should make its own consent decisions. When a tag has its own consent logic, sooner or later it disagrees with the banner.

2. A dataLayer the website writes.

The website knows what just happened. The tags don't. So the site should tell them, by pushing a named event into the dataLayer each time something important happens:

  • page_view, with the page type and anything else reports are split by
  • view_item_list and view_item, with the product or listing details in GA4's item format
  • form_view and generate_lead, with the form type and a lead reference
  • purchase, only for real sales, with the order ID and value

The alternative is tags that scrape the page: reading button text, or watching for a "thank you" message to appear. It works until the next redesign, then it stops without telling anyone.

A lead is a lead, not a sale. Send generate_lead with a value you've agreed on, or none at all. Never record an enquiry as a purchase: it ruins revenue reports and misleads any ad platform bidding on it.

Write these events down in a specification before developers build them. The measurement plan says what you need to know; the dataLayer specification says exactly what the site sends. Your dataLayer decides which questions you can answer, so it's worth getting right.

3. One web container.

One Google Tag Manager container should cover every site, market and hostname you run. Where markets need different IDs, a lookup table handles it inside the container. Separate containers for each site multiply the work and the mistakes.

  • Every tag has a consent check. Google's tags follow Consent Mode. Every other tag waits for the right consent before it fires.
  • No custom code doing the site's job. If a tag has to scrape the page or work around missing events, fix the dataLayer instead.
  • Few people can publish. Each release is reviewed before it goes live, and custom code is limited to the people who need it.

4. A server-side container on your own subdomain.

With server-side GTM, the browser sends one stream of events to a server on your own subdomain, such as data.yoursite.com. The server then passes each platform only what it needs.

  • Consent is checked again before anything leaves your server, so a mistake in the browser doesn't reach a platform.
  • You control the data. Personal data can be removed or hashed, and each platform gets only the fields you choose.
  • The browser does less. One stream replaces a pixel per platform, which helps page speed.
  • Each domain gets its own endpoint. A site on another domain needs its own first-party subdomain, not a shared one.

Hosting can be simple. Managed hosts such as Stape run the server for you.

5. The destinations.

  • GA4 for analytics, exported daily to BigQuery for reporting you can rely on
  • Google Ads with enhanced conversions
  • Meta, TikTok, LinkedIn and others through their conversions APIs from the server

When a conversion goes to a platform from both the browser and the server, both copies carry the same event ID so the platform counts it once. The guide to duplicate conversions covers the other common causes of double counting.

What goes away.

A setup built this way doesn't need second or third tag managers, scripts that scrape pages, timers polling for consent, duplicate pixels or consent workarounds for each vendor. There are fewer scripts on every page, and fewer places for things to break.

Do you need all five?

Not always. A smaller site can do very well with the first three: one consent platform, a proper dataLayer and one well-kept container.

The server-side layer earns its place when ad spend is significant, when you run several sites or markets, or when you need tight control over what leaves your site. If you mainly want first-party Google tags, the Google tag gateway may be enough.

Whatever the size, the order matters. Start with consent and the dataLayer. Everything above them depends on getting those right.

Getting there.

  1. Write the dataLayer specification, agreed with the people who'll use the reports.
  2. Have developers add the events to the site.
  3. Build the container against the specification, with a consent check on every tag.
  4. Add the server-side container once the browser side is clean.
  5. Test it all, including consent from each region, before anything is removed.

Marc Alexander designs and builds tracking this way, from the dataLayer specification to server-side tagging. The GA4 mini audit shows how far your setup is from it today.