The Consent Gap

Three suspects came up first, and each one was a reasonable place to start.

A broken GA4 tag. A gap that large looks like something simply isn't firing. But the tag was configured correctly and fired cleanly when I forced it in isolation, so it wasn't broken in the ordinary sense.

A misconfigured GA4 property. The next thought was that events were arriving and a filter was dropping them, or that they were landing somewhere I wasn't looking. That didn't hold either, because the collect endpoint never received the traffic in the first place. Nothing arrived to be misfiled.

The server-side pipeline dropping data. With server-side GTM in the mix, a parameter getting dropped downstream was plausible. But the loss was happening before the server ever saw a request. The GA4 tag never loaded in the browser at all.

What connected all three guesses is that each one assumed the fault lived inside a single system. It didn't live inside any of them.

Before I get to the real cause, there's a part I got wrong early, and it changed how I ran everything afterward.

My first round of testing ran through a VPN that had a built-in DNS tracker blocker I'd forgotten was switched on. It was quietly resolving googletagmanager.com to NXDOMAIN, which killed the entire analytics stack at the network layer before a single tag had a chance to load.

That meant every observation I'd made through that connection was worthless. The tag looked broken because my own test setup was breaking it. I discarded those conclusions and re-ran the whole investigation on a clean connection.

On a clean connection I started over. On the surface the consent banner (a CMP) worked. I clicked Accept, Consent Mode flipped to granted in the dataLayer, and the Ads pings fired. By every visible signal, consent was being honored.

But GA4's collect endpoint still received zero traffic and the GA4 tag still never loaded. Consent was reading as granted while GA4 behaved as though the visitor had never answered the banner at all. That gap between the two pointed at a handoff between systems rather than a problem with any one tag.

To see the handoff directly, I proxied Shopify's customerPrivacy.setTrackingConsent in the console before clicking Accept, so that anything the CMP told Shopify would be logged. Then I clicked.

Nothing logged. The CMP never called setTrackingConsent. It updated its own dataLayer state and fired the Ads pings, but it never passed the consent signal to Shopify. Shopify's Customer Privacy API therefore stayed at no_interaction, and Shopify's native Google channel, which waits on that signal before loading GA4, held GA4 back.

Both systems were behaving correctly by their own logic. The CMP treated its work as finished once it had updated the dataLayer, while Shopify was waiting on a function call that the CMP was never going to make.

Knowing the handshake was missing wasn't enough on its own. I wanted to understand why it was missing, so that the fix addressed the cause rather than papering over the symptom. I fetched the CMP's runtime chunks and read through them, and found two separate bugs that compounded each other.

The first was a name mismatch. The banner dispatched an event called cf_consent_updated, while the bridge script that was supposed to relay consent to Shopify was listening for cf_consent. The two names are similar enough that the mistake is easy to miss in review, but different enough that the listener never once fired.

The second was that even when the names lined up, the bridge crashed on its first line. It referenced window.Shopify at a point in the theme where that object had not yet been defined, so it threw an error before it could do anything useful.

There was a useful control sitting right next to the problem. The retailer's US store ran the same bridge script, placed correctly in its theme, and there it worked. The script itself was sound. What differed was where it had been placed in the EU theme, which told me the fix was about placement and ordering rather than logic.

The fix itself was deliberately small: a two-line placement change so that window.Shopify existed before the bridge ran, plus a hardened version of the bridge that listened for the correct event and failed safely instead of throwing.

Even a small change on a live store needs to be proven before it ships. Because this was an EU consent path, I verified it from where the affected visitors actually are, running a live proof of concept from a German VPN exit and testing both the fresh-consent and returning-visitor paths.

setTrackingConsent fired within a millisecond of Accept on both paths, confirmed from an EU exit before the change went out.

Once the change was live, I compared matched weekdays 48 hours later rather than raw day-over-day numbers, so the comparison actually meant something.

Traffic was actually down 8% on the matched comparison, and GA4 tracked revenue was up 152%. The store did not suddenly sell more product over those two days. The increase was the gap closing: revenue that had been happening all along, now recorded where it should have been. As Consent Mode modeling calibrated, the capture rate moved from roughly 9% toward a projected 85 to 95%.

The failure lived between two systems rather than inside either one. The CMP was doing its job, Shopify was doing its job, and both of their dashboards read as healthy because each was reporting accurately on itself. The fault was only visible in the handoff between them, and the only way to find it was to instrument that handshake directly and watch it fail to happen.