Consent Mode v2 in practice: why your conversions are modelled

On an online shop where we were running Google Ads, every conversion arrived modelled. That means Google was not seeing them, it was estimating them. The site had a cookie banner, Consent Mode was switched on through Site Kit, and visitors were clicking “Accept” as normal. Yet every request to Google went out as if nobody had ever given consent.

A few weeks later, on another shop, we found something stranger: a cookie banner showing up perfectly, while the plugin that was supposed to produce it had been deleted from the site. In both cases the banner worked for the visitor. It just did not tell Google correctly what the visitor had chosen.

What Consent Mode does, in one paragraph

Consent Mode is how a site tells Google’s tags what the visitor has accepted. According to Google’s developer guide, it takes two steps: a default (consent default) before any measurement is sent, and an update (consent update) at the moment the visitor clicks something in the banner. Version 2 adds two fields to the older ad_storage and analytics_storage: ad_user_data and ad_personalization.

There are two flavours. In basic mode, tags do not load at all until the visitor answers, and if they refuse, nothing is sent. In advanced mode, tags load with a default of “denied” and send cookieless pings until consent is given. Google says advanced gives an advertiser-specific model, while basic gives a generic one.

The most useful tool for seeing what is going on is the gcs parameter on the requests that go to Google. It carries the state of ad_storage and analytics_storage. In our own debugging, G100 meant both were denied and G111 meant both were granted. Google notes that the encoding may change, so we treat it as an indication, not a contract.

First shop: a banner that talked to nobody

Site Kit had Consent Mode on, with a default of “denied” for Greece and a 500 millisecond wait for an update. The cookie banner came from the theme (Blocksy). When the visitor clicked “Accept”, the banner wrote a cookie and closed. It did not call gtag(‘consent’, ‘update’), and it did not call the WP Consent API that Site Kit reads. The update never came, the “denied” default stayed forever, and every request went out with gcs=G100.

We had three options: install a proper consent management platform (CMP) wired to the WP Consent API, turn Consent Mode off, or build a bridge between the existing banner and Google. We chose the bridge. The site was already heavy and we did not want another plugin, the banner would not change visually, and rolling back meant deleting one file.

The bridge is a small mu-plugin. The points that kept us busy:

• Order. It prints at the end of the head, after Site Kit’s default, and before sending anything it checks that the default is already in the dataLayer. Google states explicitly that if the code runs in the wrong order, defaults do not work.
• A banner that loads later. The banner is injected asynchronously and emits no event. So the bridge listens to clicks at page level, not on the buttons.
• Cache. The decision is read from the cookie inside the browser, not on the server. The page is served from cache, identical for everyone, and has to behave correctly for each visitor.
• All or nothing. The banner has only “Accept” and “Reject”, with no categories, so the bridge grants or denies all fields together.

We tested it on a phone with the browser recording every request. After “Accept” and a new page, requests went out with gcs=G111 to google.com. After “Reject”, with gcs=G100 and through pagead2.googlesyndication.com, a domain without third-party cookies. Zero console errors, zero layout changes.

What we did not do. We did not push a fake conversion all the way through, because on a live account with automated bidding it would be recorded as real. We did not check whether the Meta pixel and Clarity, which also ran on the site, wait for consent. And the bridge makes the banner tell Google the truth, it does not make the site fully compliant: categories and a consent log are missing. Only a proper CMP solves those.

Second shop: the banner of a plugin that did not exist

Here we were looking for why GA4 recorded much less traffic than the orders suggested. The CookieYes banner showed up normally, with “denied” as the default for all countries, and its connection to Google Consent Mode was switched off in its settings. So it behaved like the basic mode: nothing before acceptance.

When we went to configure it, the plugin was not in the list. It had been deleted at some point, leaving its tables and settings behind in the database. The banner script, though, had once been pasted into an Insert Headers and Footers field, and that field is now served by WPCode. So the site had a banner nobody could configure from the admin, because as far as WordPress was concerned it did not exist. Anyone looking in Plugins would find nothing.

On the same site we found there was not even a GA4 tag waiting for consent, but that is another story. For the banner, our recommendation is reinstalling or replacing it with a proper CMP, in advanced mode. We do not delete the orphan script before the next one is in, because the banner is an obligation and we do not leave it empty even for a moment.

Earlier this year, on a third shop, the finding was simpler: Consent Mode was just switched off in Site Kit, while the WP Consent API plugin was installed. Two pieces in place, not talking to each other.

Basic or advanced

This is not only a technical choice. In advanced mode, tags send cookieless pings even before the visitor answers. For Google, that is how better modelling becomes possible. For compliance, it is a decision for whoever carries the legal responsibility for the site. We are not lawyers. What we do is make sure that whatever is decided is implemented correctly, and that the banner tells Google what the visitor actually clicked.

How to check your own site in ten minutes

• Open Developer Tools, the Network tab, filter “collect”. Load a page in a private window and look at gcs on the requests.
• Click “Accept” and go to another page. If gcs does not change, the banner is not sending an update.
• Do the same with “Reject”, in a clean window. It must stay denied.
• Look at the dataLayer in the console. The consent default must come before config, and the consent update must appear after the click.
• Find which plugin produces the banner and make sure it is in the plugin list. Also search the header/footer fields (WPCode, theme options) for scripts left behind.
• Check the other pixels. Meta, Clarity, TikTok: do they wait for consent too?
• After any change, do not test with a fake conversion on a live account. Wait for the first real one.

Conversion tracking is part of the Google Ads management we describe on Services. On sites we look after through Care, every admin change is logged: who changed what, and when. If you want us to look at what your banner actually sends, write to us.