Why You're Losing Marketing Data - and How the Tracking Stack Fixes It

You open Google Analytics, look at last month’s sessions, and quietly trust the number. Most marketers do. It feels like the truth.

It usually isn’t. Depending on your audience, somewhere between 15% and 40% of your tracking data never arrives at all. It leaks out along the way - blocked by ad blockers, expired by browsers, dropped by privacy settings - long before it reaches a report. You’re making budget decisions on a measurement that’s missing one in every three to seven visitors.

This post is an in-depth look at the marketing technology stack (the “martech stack”) as it relates to web analytics - the chain of systems your data travels through from the moment someone lands on your site to the moment a number shows up in a dashboard. We’ll walk it one layer at a time. For each layer, three questions: what is it, what goes wrong there, and what can you do about it?

We’ll use a typical Google Analytics 4 (GA4) setup as our running example, because it’s the tool most readers already know. You don’t need to be technical to follow along - where a piece of jargon is unavoidable, it gets explained in plain language the first time it appears.

The Big Picture

Before we zoom in, here’s the whole journey. Data flows left to right, from the visitor’s browser all the way out to your analytics and advertising platforms - GA4, Facebook, Google Ads, and the rest:

┌─────────┐    ┌──────────┐    ┌──────────────┐    ┌──────────────────┐    ┌────────────┐    ┌─────────────────┐
│ Browser │───▶│ Website  │───▶│ Client-Side  │───▶│  Server-Side     │───▶│ Analytics  │    │ Marketing       │
│ (User)  │    │ & Server │    │ Tag Manager  │    │  Tag Manager     │───▶│ Platforms  │    │ APIs            │
└─────────┘    └──────────┘    └──────────────┘    └──────────────────┘    └────────────┘    └─────────────────┘
                                                           │                                        ▲
                                                           └────────────────────────────────────────┘
                                                             Facebook CAPI, TikTok Events API,
                                                             Google Ads, Pinterest, Snapchat, LinkedIn…

Read that as a relay race. A visitor arrives (browser). Your website loads a small piece of code that organizes tracking. That code hands events to a tag manager running in the browser, which decides what to send where. In a more advanced setup, it passes everything to a server-side tag manager - a copy of that decision-making system running on your own server instead of inside the visitor’s browser. From there, clean data fans out to your analytics platform (GA4) and to the marketing platforms that optimize your ads.

Every arrow in that diagram is a place where data can leak. Let’s go layer by layer.

Layer 1 - The Browser

What it is: The starting point. Everything begins with a person visiting your website in a browser - Chrome, Safari, Firefox.

When the page loads, it runs little bits of JavaScript that quietly send “pings” back to analytics and advertising systems: a page was viewed, a button was clicked, a purchase happened. To remember who’s who between visits, the browser stores small text files called cookies.

The catch: the browser is the visitor’s home turf, not yours. Modern browsers actively work to limit tracking, and visitors install tools to block it. Here’s what you’re up against:

How to work around it

Most of these constraints (the browser protections and ad blockers) are tackled further down the stack - the fixes live mainly in Layers 2 and 4, where we move tracking onto your own domain and server. We’ll get there. The one constraint you can address right here, at the browser, is consent.

Consent Management Platforms (CMPs). A CMP is the tool behind the cookie banner you’ve seen everywhere (Cookiebot, OneTrust, Usercentrics). It’s the direct answer to the consent-requirement problem: it asks visitors for permission and acts as a gate, so tracking only fires when someone agrees.

Keeping some data when consent is declined. A blunt cookie banner means losing everyone who says no - but you don’t have to go completely dark. Different platforms offer a privacy-friendly fallback for declined visitors:

• GA4 uses modeled data. Through Google Consent Mode v2, GA4 and Google Ads send anonymous, cookieless signals (“someone was here, but we won’t identify them”), and Google uses statistical modeling to estimate the visits and conversions it couldn’t measure directly. This combination is effectively required for EU audiences in Google advertising as of March 2024. Two catches, though: it only switches on once your property clears a fairly high traffic bar (roughly 1,000 users a day with consent granted, sustained for at least a week, plus a similar volume of consent-denied events), so smaller sites never get it. And because the numbers are produced by a machine-learning model rather than measured directly, they’re estimates - useful for spotting trends, but not figures you can fully trust.
• d8a.tech uses anonymous tracking mode. When consent is declined, no cookies are dropped at all - yet sessions are still stitched together on the server using a technique called a session stamp. It takes the bits of information that are still available about the visit and turns them into a short-lived, privacy-friendly identifier, just long enough to connect the page views within a single session. Crucially, it can’t be used to build a profile of a person: once the session ends, the stamp is gone, so there’s nothing to follow a visitor across visits. This is arguably the stronger option: unlike GA4’s modeled data, it works at any traffic level and the sessions it reports are actually measured rather than estimated by a model.

Layer 2 - Your Website & Web Server

What it is: Your site’s pages, the server they’re hosted on, and the first bit of tracking code baked into the page.

In a standard GA4 setup, your site’s <head> contains a small script that loads the tag manager container - usually Google Tag Manager (GTM). Think of GTM as a control panel where your team configures all your tags without touching the website’s code. Alongside it sits something called the data layer: a tidy list of facts about the page (“this is a product page,” “the cart is worth €80,” “this is a logged-in customer”) that your tags can read from.

The page essentially says: “Browser, go fetch the tag manager from Google, then let it take over.”

What goes wrong

• The tag manager is loaded from googletagmanager.com - an address on every ad blocker’s block list. For a meaningful share of visitors, that request is blocked, and when the control panel never loads, none of your tracking fires.
• Because it’s loaded from Google’s domain rather than your own, browsers treat it as an outsider and apply extra privacy restrictions.
• The data layer only knows what your website can tell it from the browser. Anything that lives in your back-office systems (a customer’s lifetime value, their CRM segment, your profit margin on an order) simply isn’t available.

How to work around it

The common thread to every fix below: make the tracking come from your own domain instead of Google’s. A browser treats a request to your own address the way you’d treat a letter from your own company - trusted and unblocked - versus a letter from a stranger.

Google Tag Gateway

Google’s own first-party solution. It sets up a relay so that tracking loads through a path on your domain - yoursite.com/gt/… instead of googletagmanager.com. Same setup, same tags. The important thing it changes is the context the tracking runs in: instead of pulling code from Google’s servers, everything is served from the same domain as the website itself. That makes the whole setup look far more legitimate to a browser and to ad blockers than a request off to Google, so much less of it gets blocked.

Why companies use it: Recovers visitors that would otherwise be blocked, without changing how their tags are built.

Stape Custom Loader

A feature from Stape.io that serves the tracking script under a custom, randomized filename from your own subdomain (something like data.yoursite.com/abcxyz.js). Ad blockers look for both familiar addresses and familiar filenames; this dodges both. It can even disguise the outgoing measurement data so it doesn’t look like tracking.

Why companies use it: It pushes data-collection rates about as high as they’ll go by sidestepping every common blocking trick.

Self-hosting the tag manager script

Here your own server fetches the tag manager from Google, keeps a copy, and serves it to visitors directly from your domain.

Why companies use it: Total control over how the script is delivered (you can cache it and tune it), plus a genuine privacy win - the visitor’s IP address is never handed to Google just to load the script. That matters under GDPR, though the benefit only holds if your server isn’t itself hosted on Google Cloud.

Enriching the data layer from your server

Instead of relying only on what the browser knows, your server can inject extra facts into the page as it’s built - customer value, CRM segment, order margin. This gets higher-quality data into your tracking without exposing sensitive back-office data to every script running in the browser.

Layer 3 - The Client-Side Tag Manager

What it is: A tag manager is a control panel that lets your team add, change, and remove tracking tags (the little snippets that send data to GA4, Facebook, and so on) without editing the website’s code each time. It watches for things to happen on the page - a page view, a click, a checkout - and decides which tags fire, when, and with what data. The most popular tag manager on the market by a wide margin is Google Tag Manager (GTM), and in the standard setup it runs inside the visitor’s browser.

In the default setup, each tag does its own thing right there in the browser: the GA4 tag pings Google, the Meta Pixel pings Facebook, the TikTok pixel pings TikTok, and so on. Every one of them adds its own code and makes its own network calls.

What goes wrong

• Slow pages. Every tag adds weight - more code to download and run. A heavy container drags down page-load speed, which hurts both conversions and SEO.
• Lost data. Each of those browser-side pings can be blocked by an ad blocker or fail on a flaky connection. Some loss is guaranteed.
• Privacy exposure. Everything you put in the data layer is readable by every tag in the container - including third-party vendor tags. They can see data they have no business seeing.
• Tags fighting each other. Multiple tags grabbing at the same page elements or cookies can break one another in ways that are painful to debug.

How to work around it

Send less from the browser

Move as many tags as possible off the browser and onto your server. There are two ways to do this. You can rebuild the tracking logic yourself in your own backend code, which is a lot of work. Or, far more conveniently, you can switch to a server-side tag manager - the same kind of control panel, but running on a server you own instead of in the visitor’s browser. That’s the whole subject of Layer 4 below; for now, just know it’s the practical route most teams take.

Either way, the browser’s job shrinks to three steps:

1. Collect the behavior (page views, clicks, purchases).
2. Send one consolidated message to your server.
3. Let the server fan it out to Facebook, TikTok, Google Ads, and the rest.

Lighter pages, far less third-party code touching your visitors’ data.

There’s a quieter benefit too: control over who sees what. In the browser, the data layer is an open book - every tag in the container can read everything in it. Once you’re collecting server-side, you can enrich events with sensitive data (customer value, segments, margins) on the server, where it’s never exposed to third-party scripts the way data-layer values are.

Use GA4 as the only messenger

A popular, clean pattern: the only tag firing in the browser is the GA4 tag. It carries the data to your server, and every other platform is fed from there. One messenger instead of a dozen.

A custom messenger

For teams that don’t want to be tied to GA4 at all, the browser can send a plain data package straight to the server, which is then built to understand it. This keeps your setup independent of any single analytics vendor.

Layer 4 - The Server-Side Tag Manager (sGTM)

This is the layer that fixes most of the problems raised above, so it’s worth covering in more detail than the rest.

What it is: A server-side tag manager is a copy of your tag manager that runs on a server you control, rather than inside the visitor’s browser. The browser sends it the raw behavior; the server then does the work of cleaning, enriching, and forwarding that data to GA4 and your ad platforms. Because the heavy lifting happens on your infrastructure, it’s invisible to ad blockers and immune to most browser restrictions.

Where it runs

You have to host it somewhere, and there are three broad routes:

• Google Cloud Run is the option Google currently recommends. It scales down to nothing when idle (so you only pay for what you use) and integrates cleanly with the rest of Google’s stack. The trade-off is that you need some Google Cloud comfort to run it well.
• Managed services like Stape.io or Addingwell take the hosting off your plate. These are a good fit if you want a more independent setup with extra automation and observability built in (easy monitoring, anti-ad-block features, simple configuration). A big plus for European businesses: they can be hosted without any non-EU subprocessors, which simplifies GDPR compliance considerably.
• Self-hosting with Docker on your own servers gives you total control and keeps everything in-house. The catch is that the full operational effort - uptime, scaling, updates, monitoring - is entirely on you.

The single most important fix: serve it from your own domain

By default, your server-side tag manager lives at some random-looking address that has nothing to do with your brand (like gtm-abc123.appspot.com). To browsers, that’s a stranger.

The fix is to put it on your own domain. There are two ways to do that:

• A subdomain - something like t.yoursite.com or data.yoursite.com. Technically it’s a one-line DNS change, which makes it the most common choice.
• A path on your main domain - something like yoursite.com/metrics/. Google made this same-domain (same-origin) option available for its tag setup, and it’s the stronger of the two for cookie longevity, because the tracking shares the exact same domain as the site. It’s a bit more work to set up: it usually needs a CDN or load balancer routing that path to your tag-manager server, rather than just a DNS record.

Either way, the payoff is large:

• The cookies are still first-party either way - that part doesn’t change. What changes is that they’re now created under the same top-level domain as your website rather than some unrelated address. That makes the whole setup more resistant to ad blockers and to the browser heuristics that punish tracking which looks like it’s coming from a third party.
• Requests to your own domain aren’t blocked by most ad blockers, the way requests to googletagmanager.com are.

This is the change that makes stable, long-lived visitor identity possible in Safari - something browser-side tracking alone simply can’t deliver.

More you can do at this layer

Once your data passes through a server you control, you can do things that are impossible in the browser:

• Set a stable visitor ID (FPID). The server can set a durable first-party cookie that survives Safari’s restrictions, giving you a steady identifier. The key difference from a normal tracking cookie is how it’s set: it comes back in the server’s response and is marked HttpOnly, meaning JavaScript in the page can’t touch it. Browsers treat server-set, HttpOnly cookies as more trustworthy than the ones tracking scripts create, so they’re given a much longer lifespan. GA4 picks this cookie up automatically and uses it to recognize returning visitors, sharply improving accuracy on Safari.
• Add data. Look up a customer’s CRM segment, lifetime value, or an order’s margin from your own systems and attach it to the event before it goes to analytics.
• Protect personal data. Scramble (hash) email addresses and phone numbers before sending them to Facebook or Google, so the raw details never leave your control. This is required by those platforms anyway.
• Strip, filter, and limit what each vendor sees. Remove fields a given vendor shouldn’t receive, and throw out bot traffic and malformed events before they pollute your reports (garbage in, garbage out - this is your last line of defense). It’s also a privacy upgrade: in the old browser setup, every vendor’s code could read your whole page and all its cookies, whereas now each vendor only gets the specific facts you choose to send.
• Avoid double-counting. If you send an event from both the browser and the server for safety, the server can spot the duplicate (using a shared event ID) and keep just one.

Layer 5 - Analytics Platforms

What it is: The final home for your behavioral data - where reporting, analysis, and audience-building happen. For most readers that’s GA4, but it’s far from the only option. Matomo is the long-standing open-source favorite, often self-hosted; Adobe Analytics is the enterprise heavyweight; Snowplow pipes raw events into your own data warehouse; and d8a.tech is a modern take on the whole category, with a built-in reporting UI and native data-warehouse integrations so your data lands in storage you own from day one. (Whether each tool collects in the browser or on the server matters less than it used to - they all support both somehow.)

What goes wrong

The pain at this layer isn’t really about collecting the data, it’s about what owning a platform costs you:

• No real data ownership. With most hosted analytics, your raw data lives on the vendor’s servers under their terms, not yours.
• Your data feeds their ad products. Some “free” analytics earn their keep by using your data to improve the vendor’s advertising business.
• Heavy maintenance. Self-hosting an open-source platform at scale is a real engineering commitment - databases, scaling, upkeep.
• Punishing enterprise pricing. The platforms that do give you depth and control often come with eye-watering enterprise licenses.

d8a.tech is built to solve most of these at once: you keep ownership of your raw events in your own warehouse, you’re not the product, and you skip the heavy self-hosting effort - while still getting a familiar reporting interface on top.

How to get more out of it

Own the raw data

The most valuable move at this layer is getting the raw, event-by-event data into a warehouse you control. With GA4 that means turning on the BigQuery export, which ships unaggregated data into Google’s data warehouse daily and unlocks custom attribution, deeper segmentation, and joins with your other business data that the standard reports can’t do. Other platforms offer their own routes to the same end - the principle is the same: hold the raw events yourself.

Collect server-side

Every platform here supports server-side collection in some form, and routing data through your server (rather than the browser) buys you the same wins each time: no loss to ad blockers, the chance to enrich events first, and lighter pages. Same destination, far more of the data actually arrives.

Layer 6 - Marketing Platforms (Fed From Your Server)

What it is: The advertising platforms you feed conversion data to so they can optimize your campaigns - Facebook, TikTok, Google Ads, and the rest.

What goes wrong

The traditional way to feed these platforms is a browser pixel - the very same kind of tracking script that ad blockers and Apple’s iOS privacy prompts love to block. The result is undercounted conversions, which means the platforms are optimizing your budget on incomplete information. You can also end up double-counting if a conversion fires from more than one place.

How to work around it

Every major platform now offers a server-to-server connection so you can send conversions straight from your server, bypassing the browser entirely. The main ones:

• Facebook - Conversions API (CAPI)
• TikTok - Events API
• Google Ads - Enhanced Conversions, plus Conversion Adjustments for updating a conversion after the fact (a refund, a revised order value)
• Pinterest, Snapchat, LinkedIn, Microsoft Ads, Criteo, Twitter/X - each has its own Conversions API or equivalent

Across the board, these platforms actively recommend the server-side route, for two reasons. It improves data accuracy by recovering conversions lost to ad blockers and iOS, and it lets them deduplicate events using a shared event ID - so a conversion sent from both the browser and the server is counted only once. Sensitive identifiers like email and phone are scrambled before they’re sent.

The Default Setup vs. the Improved Setup

Putting it all together. Here’s the typical setup most sites run today - note how every line is a leak:

Browser
  ├── loads gtm.js from googletagmanager.com         ← blocked by ad blockers
  ├── fires GA4 tag to google-analytics.com           ← blocked by ad blockers
  ├── fires Meta Pixel to facebook.net                ← blocked by ad blockers
  └── sets cookies via JavaScript                      ← capped by Safari to 7 days

The result: 15–40% of your data lost depending on audience. Short-lived cookies in Safari, so returning visitors look new. Every third-party script can read your page. And a slow, heavy page on top of it all.

Now the improved setup - everything routed through your own domain and your own server:

Browser
  └── loads custom-named JS from yoursite.com/somepath    ← not blocked (first-party, custom path)
        └── sends GA4 stream to yoursite.com/somepath     ← not blocked (first-party, via proxy)
              └── Server-Side Tag Manager (behind yoursite.com/somepath)
                    ├── serves the web container's JS back to the browser
                    ├── sets a stable ID cookie via the server   ← not capped by Safari
                    ├── enriches events with your own data
                    ├── sends to GA4
                    ├── sends to Facebook CAPI (data scrambled)
                    ├── sends to TikTok Events API
                    ├── sends to Google Ads Enhanced Conversions
                    └── sends to other ad platforms

The result: Near-complete data collection. A stable view of each visitor across browsers. Almost no third-party code in the page. And full control over exactly what data reaches each vendor.

Quick Reference: Every Fix in One Table

Keep this as a cheat-sheet. It maps each technique to the layer it lives on, what it does, and the main reason to bother:

The One Idea Worth Keeping

The stack looks intimidating, but the through-line is simple: the less of your tracking that happens in the visitor’s browser, the less data you lose. That comes down to two things working together - moving the work onto a server you control, and piping the data to your vendors through your own website’s domain, so it’s far harder for ad blockers to spot and block in the first place.

Just don’t expect to set it up once and forget it. Tracking-prevention features and ad blockers keep evolving, and their detection algorithms get smarter with every release. Whatever clever workaround is winning today, the browser makers and blocker maintainers are working to catch it tomorrow. A good measurement setup is never truly “done” - it’s an ongoing cat-and-mouse game, and the setups that hold onto their data are the ones that keep adapting.

That’s exactly why it pays to build on something flexible. d8a.tech is designed to run server-side and is perfectly suited for this job - giving you a setup you can keep evolving as the rules change, while you stay in full control of your own data.