The Consent Banner Said Yes. The Tags Heard No.

The Setup

A made-to-order home brand on WooCommerce, with Google Ads as its biggest paid channel. The site ran a consent banner, visitors were accepting it, and on the surface everything about the tracking looked compliant and normal.

I was on the account for a different reason: consolidating a redundant tracking stack that had accumulated six overlapping tracker installs across the stack, with four separate Google tag libraries loading on a single page. The consent finding came out of that audit, and it outranked everything else on the list.

What Was Broken

I measured a normal returning-visitor page load with consent verified as granted. The consent cookie said yes on every category. The consent platform’s own API said yes. And every consent-scoped Google beacon on the load still went out carrying gcs=G1--, which is Consent Mode’s code for ad storage and analytics storage both denied.

Google Ads, the biggest spend on the account, fired its conversion and remarketing beacons in denied mode, which means modeled conversions and degraded remarketing instead of observed data. Merchant Center fired denied on the same load.

The root cause had two layers:

1. The consent platform’s free tier never pushes the update. It sets Consent Mode’s default state to denied, as it should. But for a returning visitor who already accepted, it never sent the follow-up granted signal. That feature is behind the paid tier. Nothing on the page ever told Google about the yes.
2. An earlier bridge script fired too late. A tag that pushed the granted signal existed, but it ran on DOM-ready and read the consent platform’s JavaScript API, which loads late. By the time it fired, the page-view and conversion beacons were already gone, denied.

The brand was paying for consent management and losing the data of exactly the users who had consented. Nobody had looked at the beacons.

What I Did

The fix reads the consent cookie directly, server-side, and prints the granted signal into the top of the page before any tag can fire. A small PHP snippet hooked at head priority 1. It does not wait on the consent platform’s JavaScript, so the race condition is gone by construction.

Verified across repeat loads the same day: the Google Ads and Merchant Center beacons flipped from gcs=G1-- to gcs=G111 and stayed there. Storefront healthy, consent choices still respected. Rollback is deactivating one snippet.

What I Did Not Claim

This fix restores observed data going forward for consented visitors. It does not backfill the modeled months, and it does not change data for visitors who decline, which is exactly as it should be. I also chased a suspicion to a dead end on purpose: the suspected GA4 double-counting on this stack turned out to be false once tested properly, and saying so saved the client a pointless migration.

The Takeaway

Consent Mode has a failure state nobody watches for: default-denied with no update. Your banner can be legally perfect and your data pipeline still starving, because the two are separate systems and only one of them has a dashboard.

The test takes five minutes. Accept your own banner, reload, open the network tab, and read the gcs parameter on your Google beacons. If it says G1-- after you said yes, your ad platform is guessing at conversions you paid to observe.

Want the beacons on your site read properly? Start with a tracking audit.