Open your ad platform and your analytics side by side for the same date range. Google Ads says 10,000 clicks. Analytics says 7,200 sessions. Nobody flags it, because there is always some gap and everyone has learned to live with it.
That subtraction is the most useful thing in the sheet and almost nobody runs it. Do it on your own numbers before you read the rest of this. Whatever that percentage is, it is the share of traffic you are paying for and measuring nothing about.
Some of it is genuinely unavoidable. Ad blockers, mistyped redirects, people who hit back before the page painted. But a large piece of it is something more specific, more fixable, and almost never looked at: your tracking is waiting for permission that the visitor never gave, and by the time it stops waiting they are gone.
The banner is a gate, and Google says so plainly
Most sites now run a consent management platform. It puts the banner up, and it decides when your tags are allowed to run. There are two ways to configure that, and the difference is not cosmetic. Here is Google's own documentation on the first one:
Google tags from loading until a user interacts with a consent banner. This setup transmits no data to Google prior to user interaction with the consent banner.
Read that again with a bouncing visitor in mind. In that configuration, a person who never touches the banner produces no data at all. Not anonymized data. Not a partial hit. Nothing loads.
Now consider who actually touches a consent banner. People who are staying. Someone who lands from an ad, reads two lines, decides it is not for them, and closes the tab has no reason to click anything. They are simultaneously the visitor you paid the most to acquire and the one your stack is structurally blind to.
What this looks like when you measure it
I put a stopwatch on a live consumer site this week, one running real paid traffic with a normal tag setup: a consent platform, a server side container, the usual analytics and ads tags behind it. I loaded a page and recorded when each thing actually happened.
- DOM ready at 1.6 seconds.
- Page fully loaded at 2.2 seconds. As far as the visitor is concerned, the page is done.
- Consent platform finished its own work around 1.9 seconds.
- Then an eight second gap where nothing happened.
- Server side container loaded at 10.1 seconds.
- The first identifying call fired at 10.9 seconds.
The page was usable at 2.2 seconds and the measurement did not exist until 10.9. That is a nine second window where a real person is reading a real page and no system has any idea they are there.
One honest caveat, because it matters and it cuts both ways: in that session nobody clicked the banner. A visitor who accepts immediately gets measured much faster. So 10.9 seconds is not the typical experience.
It is the experience of the visitor who ignores the banner and leaves, which is precisely the visitor the gap in your sheet is made of. The worst case and the relevant case are the same case. That is the part worth sitting with.
The two minute version you can run right now
You do not need a tool or a vendor for this. Open your own site in a browser, open developer tools, go to the Network tab, and reload. Sort by the time each request started. Then find the moment your analytics or ads tag actually fires and compare it to when the page finished loading.
If those two numbers are close together, this article is not about you and you can stop here. If your tags are landing five or ten times later than page load, you have found something, and it costs nothing to go look.
Do it twice: once accepting the banner, once ignoring it completely. The second run is the one that tells you the truth, because it is the one that matches how most people treat a cookie notice.
What to actually change
Two things, and the order matters.
Fire the moment consent is granted, not on a timer. If your consent platform resolves at two seconds but your tags do not run until ten, that gap is usually a trigger setting rather than a legal requirement. Tags waiting on a window load event, or a fixed delay someone added years ago to improve a page speed score, or a queue sitting behind three other containers. Firing immediately on the consent signal is free, changes nothing about compliance, and in the case above would have recovered eight seconds.
Shorten what sits in front of it. Every hop defers everything behind it. If your measurement tag is queued behind a container that is queued behind another container, it inherits all of that latency. Loading in parallel rather than in sequence is usually a configuration change, not a rebuild.
And one thing not to do, which I want to be direct about. Do not solve this by firing tags before consent is granted. That is not a performance optimization, it is a compliance decision with real exposure, and it is the wrong trade for a few seconds of data. The goal is to stop wasting the time between consent and firing, not to skip the consent.
Where we land on this
The pattern underneath all of it is that most measurement depends on a chain of things going right after someone arrives. Permission granted, container loaded, tag fired, cookie written, cookie surviving the week. Every link is a place to lose the visitor, and the links break in the order that costs you the most, starting with the people who left fastest.
The arrival itself does not break. Someone landed on your page. That happened whether or not they clicked your banner, whether or not your container was ready, whether or not the cookie lived until Friday. Working from who arrived rather than from what survived the chain is a different angle on the same question, and it does not ask you to change how you buy media or where your data goes afterward. You are already paying for the traffic. You already have the CRM and the email tool and the audiences.
Whether it is worth doing at your volume comes down to numbers you already have in front of you. Start with the subtraction at the top of this page. If the gap is small, you have better things to work on and we will tell you so.