Conversion Tracking That Actually Works, Even With a Consent Banner

The symptom everyone knows

The tag is installed. Google says it is detected. The console is clean. And the reports show zero. This is not a rare bug or bad luck, it is what happens to almost every site that added a cookie banner after it added tracking. The problem is not the tag, and the fix is not to install it again.

This is not an installation guide. There are hundreds of those. This is about what happens after installation, when everything looks fine and nothing arrives.

Why a consent banner breaks measurement

A correct consent banner does one simple thing: it stops scripts from running until the visitor agrees. That sounds binary, but in practice there are three states, and only one of them is right.

• The script loads before consent. Measurement works beautifully, and you are violating your visitor's privacy. This is where most sites with a decorative banner end up.
• The script is blocked entirely. Privacy is respected, and you have no data at all. This is where most sites with a serious banner end up when nobody checked what it does.
• The correct state. The script loads, but it knows it must stay silent until permitted, and it starts reporting the moment consent is given. No tool does this by default.

Consent Mode, and what it actually does

Many people treat Consent Mode as one more checkbox. It is not. It is a change in the order of operations.

The page declares the consent state before the tag loads. The default is denied, so the tag comes up but stays quiet. When the visitor agrees, an update is sent, and the tag starts reporting from that moment. No data is collected without permission, and the script never has to be blocked outright.

The easiest part to miss: the declaration has to come first. If it arrives after the tag has loaded, it is worth nothing, and it will not raise a single error to tell you.

The mistake that burns weeks

There is one mistake that looks exactly like a network block, which is why people go looking for it in the wrong place.

The code that feeds Google's data layer has to pass its arguments in a very specific shape. Written in a cleaner, more modern style, it pushes a structure that Google silently ignores. No error, no warning, nothing. Everything loads, everything is "detected", and no event is ever sent.

The tell: you can see the tag in the diagnostic tool, but the real-time report has not a single entry. If that is your situation, check how your code pushes data before you blame an ad blocker or a firewall.

How to verify properly

Two popular verification methods will lie to you, and it helps to know that in advance.

• Fetching the page source and searching for a string. Tracking scripts load dynamically today. Finding nothing proves nothing.
• Trusting the browser network tab. Some tools and extensions hide or block requests to Google domains, which makes a working tag look broken.

What does work: check directly in the console what is sitting in the data layer and which measurement id actually registered. It is a two line check, and it gives you a definitive answer instead of a feeling.

Your numbers will drop, and that is intentional

Once everything is set up correctly, something surprising happens: the data looks lower than before. This is not a regression. From now on you are only counting visitors who agreed, not everyone.

It is worth internalising that before you open the first report, otherwise the instinctive reaction is "something is broken again". The lower number is the real one. What came before it was a number you were never supposed to collect.

The order to debug in

If you are in the middle of this right now, this order saves the most time:

1. Confirm the measurement id in your code is the one you are looking at in the reports. It sounds trivial and it happens.
2. Confirm the deployed build actually contains your change, and that the browser is not serving a cached older bundle.
3. Check the shape of what you push to the data layer.
4. Only then suspect a browser extension or a network block.

Step three before step four, always. A code bug is a perfect impersonation of a network block, and starting from the end costs days.