In the first week of March 2024, marketing teams across Europe were doing something that looks, in retrospect, absurd. They were reading a regulation to figure out which JavaScript function to call.
The function was gtag('consent', 'update', {...}). The regulation was the Digital Markets Act. The connection between the two is not metaphorical. Alphabet was designated a gatekeeper under the DMA on 6 September 2023, with a compliance deadline of 7 March 2024, and Google’s answer to one specific DMA obligation was to require that advertisers pass it four named consent booleans, in a specific format, from a specific category of vendor, or lose access to European audiences. A competition-law deadline was translated into a tagging specification, shipped as a product requirement, and enforced through a tag.
This is the clearest example in the whole Google stack of regulation becoming an engineering artifact. It is worth being precise about the causal chain, because the industry shorthand gets it wrong.
The Deadline Was the DMA, Not the GDPR
The General Data Protection Regulation has been in force since May 2018 (Regulation (EU) 2016/679). Consent Mode v2 shipped in late 2023 and became mandatory for European Economic Area and UK traffic in March 2024. Six years separate the two. If GDPR alone had forced Google’s hand, the tag would have changed in 2018.
What changed in 2023 was the Digital Markets Act, which imposes obligations on designated gatekeepers rather than on data controllers generally. Alphabet was designated a gatekeeper for a list of core platform services including Google Search, YouTube, Google Maps, Google Play, Chrome, Google Shopping, and Google Ads (European Commission, DMA gatekeepers). Article 5(2) of the Regulation bars a gatekeeper from combining or cross-using personal data between its core platform services, or with third-party services, without specific end-user consent (Regulation (EU) 2022/1925). Compliance was due 7 March 2024.
Read that obligation against the chain traced in Join Keys and the engineering problem becomes obvious. Google’s advertising products work by joining data across services: a Search click to a YouTube view, a hashed email to a signed-in account, a Floodlight activity to a DV360 audience. Every one of those joins is a data combination between core platform services. Under Article 5(2), each one now needs demonstrable, specific consent. Google could either infer consent from whatever the advertiser’s cookie banner happened to do, which is legally indefensible for a gatekeeper facing a €20 billion-scale exposure, or it could require the advertiser to state the consent explicitly, in a format Google could log.
Google chose the second option. That choice is Consent Mode v2. The obligation is Google’s, and the implementation work was pushed onto several million advertisers.
Four Booleans
Consent Mode v1, introduced in 2020, carried two signals. Consent Mode v2 added two more, and the full set is four named parameters, each set to granted or denied (Google for Developers: consent mode).
| Signal | Controls | Practical effect when denied |
|---|---|---|
ad_storage | cookies and local identifiers used for advertising | no _gcl_* click-ID cookie, so no GCLID-based conversion join |
analytics_storage | cookies and identifiers used for analytics | no persistent GA4 client ID, so no returning-user recognition |
ad_user_data | sending user data to Google for advertising purposes | Enhanced Conversions and Customer Match uploads blocked for that user |
ad_personalization | using the data for personalised advertising | user excluded from remarketing and personalised targeting |
The first two are storage permissions. The second two are use permissions, and they are the v2 additions that map directly onto the DMA’s cross-use language. ad_user_data governs whether data may be transmitted to Google at all for ad purposes. ad_personalization governs whether Google may then use it to personalise. Splitting transmission from use is not a privacy nicety. It is what lets Google demonstrate, per user, that a specific consent existed for a specific combination of data.
The signals are set before any Google tag fires, using a default state, then updated when the visitor interacts with the banner. In practice the consent management platform writes the default, the visitor clicks, the CMP calls the update, and the tag manager gates every downstream tag on the result. Google Tag Manager exposes this as built-in consent checks on individual tags plus additional consent requirements the container enforces (Google Tag Manager Help: consent settings). The tag manager becomes the enforcement point for a competition-law obligation, which is a role nobody designing GTM in 2012 anticipated. The broader argument that the container is the real integration contract, not the tags inside it, is developed in The dataLayer Is a Message Bus.
Basic and Advanced Are Two Different Products
Google shipped two implementation modes, and the choice between them is the most consequential technical decision in a European measurement setup. The naming is unhelpfully bland. Treat them as different products.
In Basic mode, Google tags are blocked from loading until the user grants consent. No network request reaches Google before the click. If the user declines, Google receives nothing at all, not even the fact that a page was loaded.
In Advanced mode, tags load immediately with consent defaulted to denied. If the user declines, the tags do not write cookies or send identifiers, but they do send cookieless pings: a minimal, non-identifying signal that an event occurred (Google for Developers: consent mode). Those pings are the input to conversion modelling and to GA4’s behavioural modelling, which use consented traffic to estimate the shape of the unconsented traffic (Google Analytics Help: behavioural modelling).
| Basic | Advanced | |
|---|---|---|
| Tag load | after consent only | on page load, defaulted to denied |
| Signal on refusal | none | cookieless ping |
| Conversion modelling eligible | no | yes |
| Data volume Google receives | consented traffic only | consented traffic plus aggregate signals |
| Typical rationale | strictest legal reading, or a legal team that wants zero pre-consent requests | recover reporting completeness on declined traffic |
Practitioners tend to describe Advanced mode as the better option because the reporting is more complete. That framing skips the trade-off. Advanced mode sends a request to Google for users who explicitly declined. Google’s position is that these pings carry no identifiers and are therefore not personal data. Several European data protection authorities have taken a narrower view of what counts as processing, and the question of whether pre-consent cookieless pings are lawful under the ePrivacy Directive has not been settled uniformly across member states. A team choosing Advanced mode for modelling accuracy is making a legal judgment, and it should be the legal team making it, not the analytics team.
There is also a quieter asymmetry worth naming. Modelling turns a gap in Google’s data into a number Google produces. The advertiser cannot audit the model, cannot see the underlying pings, and cannot reproduce the estimate independently. Conversion modelling is a reasonable engineering response to consent-driven data loss. It also moves one more piece of measurement from something the advertiser observes to something the platform asserts.
The Enforcement Mechanism Is Commercial, Not Legal
The part of Consent Mode v2 that actually changed behaviour was not the specification. It was the consequence of ignoring it.
Google requires advertisers serving personalised ads to users in the EEA and UK to use a consent management platform certified under its own CMP partner programme, integrated with the IAB Europe Transparency and Consent Framework (Google CMP Partner Program). The underlying policy obligation sits in Google’s EU user consent policy, which requires advertisers to obtain and pass legally valid consent for the data Google receives (Google EU user consent policy). The TCF integration matters because it standardises how the consent string is encoded and passed, which is what makes Google’s per-user logging possible at scale (IAB Europe, Transparency and Consent Framework).
An advertiser without a certified CMP correctly wired does not get a warning letter. They get a silent degradation. New EEA users stop entering remarketing lists. GA4 audiences built on European traffic stop growing. Google Ads conversions for those users stop being recorded. Floodlight-based audience lists in CM360 and DV360 stop accumulating members. Existing campaigns keep spending. The lists that make them efficient quietly stop refilling.
That failure mode explains the shape of the March 2024 scramble better than any legal argument. The penalty was not a fine, it was audience attrition, invisible on a dashboard until performance sagged a quarter later. Teams that had treated the cookie banner as a legal artifact owned by counsel discovered it had become load-bearing infrastructure for their media buying.
Consent, at that point, stopped being a policy and became an interface. It has a name, a schema of four enumerated values, a default state, an update call, a transport format, a certification requirement for the vendors that implement it, and a documented degradation path for callers who get it wrong. Every property of an API, in other words. That is a genuinely new thing in advertising technology: a compliance obligation with a function signature.
It is also, so far, the mildest of the regulatory interventions aimed at this stack. Consent Mode v2 asked advertisers to change their tags. The cases covered in Remedies ask whether Google should be permitted to own both sides of the auction at all, and the answers being drafted in Virginia and Brussels would change considerably more than a JavaScript call. Consent Mode also has an unresolved future: DMA enforcement is active rather than finished, and the consent architecture described here may well be tightened again by the time you read this.
Key Sources
| Source | Author/Org | Year | Link | Why it matters |
|---|---|---|---|---|
| Regulation (EU) 2022/1925 (Digital Markets Act) | European Union | 2022 | EUR-Lex | Article 5(2) is the cross-service data-combination rule that produced Consent Mode v2 |
| DMA gatekeepers | European Commission | 2023 | digital-markets-act.ec.europa.eu | Records Alphabet’s 6 September 2023 designation and the 7 March 2024 compliance date |
| Regulation (EU) 2016/679 (GDPR) | European Union | 2016 | EUR-Lex | In force since 2018, which is why it cannot be the proximate cause of a 2024 tag change |
| Consent mode | Google for Developers | 2024 | developers.google.com | Canonical definition of the four signals and of Basic versus Advanced behaviour |
| Consent settings overview | Google Tag Manager Help | 2024 | support.google.com | Shows the container as the enforcement point for per-tag consent checks |
| Behavioural modelling for consent mode | Google Analytics Help | 2024 | support.google.com | Documents how cookieless pings become modelled conversions |
| EU user consent policy | 2024 | google.com | The contractual obligation advertisers are actually bound by | |
| CMP Partner Program | 2024 | cmppartnerprogram.withgoogle.com | Certification requirement that gates EEA personalised-ads delivery | |
| Transparency and Consent Framework | IAB Europe | 2024 | iabeurope.eu | The encoding standard that makes per-user consent logging practical at scale |
PM Lens
Papers referenced
- Regulation (EU) 2022/1925 on contestable and fair markets in the digital sector (Digital Markets Act) European Union · 2022
- Gatekeepers designated under the Digital Markets Act European Commission · 2023
- Regulation (EU) 2016/679 (General Data Protection Regulation) European Union · 2016
- Consent mode Google for Developers · 2024
- Consent settings overview Google Tag Manager Help · 2024
- Behavioural modelling for consent mode Google Analytics Help · 2024
- EU user consent policy Google · 2024
- CMP Partner Program Google · 2024
- Transparency and Consent Framework IAB Europe · 2024