Cookie consent for AdSense: what Google's EU policy actually requires

Google's EU user consent policy requires publishers to obtain a visitor's consent before using cookies or other local storage for personalised advertising, and before collecting or sharing data for that purpose, wherever the visitor is protected by an EU law that requires consent — in practice this means the European Economic Area, plus the UK and Switzerland. Google requires this consent to be gathered in a way that meets the GDPR's standard: specific, informed, freely given and unambiguous.

This is a contractual requirement Google places on everyone who serves its ads, sitting alongside — not replacing — your own legal obligations under GDPR and the UK's equivalent regime. Google can suspend ad serving or your account for breaching it even if a regulator never gets involved.

The policy applies per visitor, not per publisher location. A site based outside Europe with no European business presence still has to apply it to any visitor arriving from the EEA, the UK or Switzerland. There is no size or traffic threshold — a small hobby blog with a handful of European visitors a month is covered on exactly the same terms as a large publisher.

You cannot opt out by claiming your audience is elsewhere. If your analytics show any EEA, UK or Swiss traffic at all, the consent mechanism needs to be live and correctly configured for those requests, and geotargeting it away from the rest of the world is a technical convenience, not a way of avoiding the requirement.

For ad serving in the EEA and the UK, Google requires publishers to use a Google-certified Consent Management Platform (CMP) that supports the IAB Europe Transparency and Consent Framework (TCF). The CMP presents the banner, records the choice, and passes a standardised consent signal — the TC string — to every ad vendor in the chain, so each one knows exactly what it is and is not allowed to do.

Google publishes a list of CMPs it has reviewed and certified. Using an uncertified banner, a bespoke cookie notice you built yourself, or a CMP that has not registered with the IAB TCF, means AdSense cannot reliably read the consent signal — which functionally means you are not compliant even if your banner looks correct to a human visitor.

TCF applies to the EEA and the UK. Switzerland is covered by the same Google policy but sits outside the IAB TCF's formal jurisdiction, so check your CMP's Swiss handling separately rather than assuming it is automatic.

Consent Mode is Google's mechanism for adjusting how its own tags — AdSense, Ads, Analytics, Tag Manager — behave based on the visitor's choice, without you having to block the tags from loading at all. Consent Mode v2 introduced two additional signals specifically for advertising, on top of the original two:

• ad_storage — whether cookies or storage related to advertising may be set.
• ad_user_data — whether user data may be sent to Google for advertising purposes.
• ad_personalization — whether data may be used to personalise ads, including remarketing.
• analytics_storage — whether cookies or storage related to measurement may be set.

Each signal is either granted or denied. The two newer signals, ad_user_data and ad_personalization, are what Google now treats as a baseline requirement for advertisers and, in practice, publishers running AdSense with a CMP in the EEA — without them, Google cannot confirm what the visitor has actually agreed to.

The critical implementation detail is default state: all four signals must default to denied before the banner has been interacted with, and must only flip to granted after the visitor actively agrees. A page that sets defaults to granted, or that never sets defaults at all before tags fire, defeats the point of the entire mechanism regardless of what the banner text says.

AdSense does not stop serving ads to a visitor who declines. It falls back to non-personalised ads for that impression instead, using contextual signals from the page rather than the visitor's profile. Non-personalised ads earn less on average because they cannot target as precisely, so a site with a high EEA refusal rate will typically see lower RPMs from that traffic than an equivalent audience elsewhere.

This is expected and not a sign anything is broken. It is not a reason to make the banner harder to decline, hide the reject option, or pre-tick consent — those tactics are exactly what the policy and GDPR are designed to prevent, and Google treats them as violations rather than optimisation.

Your privacy policy has to name the categories of data collected, the purposes (including advertising and measurement), and the third parties involved, in language that matches what the consent banner actually offers. If the banner presents granular choices — advertising, analytics, personalisation as separate toggles — the policy needs to describe each of those uses distinctly rather than folding everything into one vague 'cookies' paragraph.

A mismatch is a common and easy-to-spot problem in review: a banner that mentions only 'cookies for analytics' while the site actually serves personalised ads, or a policy that lists a CMP or vendor list that no longer matches what is deployed. Update both together whenever you change ad setup, add a network, or switch CMP.

Consent has to be revisable, not a one-time gate. Visitors need an ongoing, easy-to-find way to change their mind — typically a persistent 'Cookie settings' or 'Privacy choices' link in the footer that reopens the CMP's preference panel with the visitor's current choices shown, not a fresh blank banner.

Most certified CMPs provide this control automatically; the mistake is disabling it, burying it deep in a settings page, or removing the footer link during a redesign. Test it after any theme or template change — footer links are exactly the kind of thing that quietly disappears.

• A banner with only an 'OK' or 'Got it' button and no genuine way to refuse — this is not valid consent under GDPR or under Google's policy, regardless of how prominent the banner is.
• Consent recorded as granted before the visitor has made any choice, often because a plugin default was left on 'accept' rather than 'deny'.
• Ad and analytics scripts loading before Consent Mode defaults are set — the tags fire on page load with no consent signal attached at all, which is worse than an explicit denial.
• A reject button that is visually present but functionally does nothing, still setting ad_storage or ad_user_data to granted regardless of the click.
• Using an uncertified or homemade banner instead of a Google-certified, TCF-compliant CMP.
• Treating consent as a one-off pop-up rather than an ongoing state — no footer link, no way to change the choice later.
• Privacy policy still listing an old CMP, a removed ad network, or purposes the current banner no longer covers.

During both initial approval review and ongoing account monitoring, Google can and does check sites with European traffic for a working consent setup. A missing banner, a non-functional reject option, or a policy that contradicts what the banner actually does can contribute to a policy violation notice or, in serious or repeated cases, ad serving restrictions on the account.

For a site still working toward approval, absent EEA/UK/Swiss traffic this is not usually a blocker — but if your analytics show any European visitors, set the CMP up correctly before you apply rather than after. Fixing it retroactively after a violation notice is slower and more disruptive than getting it right from the start.

You do not need a bespoke consent system. Pick a CMP from Google's certified list, use its default TCF and Consent Mode v2 integration rather than customising the underlying logic, and check three things after installation: defaults deny all four signals before any interaction, the reject button actually flips them to denied, and a footer link reopens the preference panel. Then make sure the privacy policy text matches what the banner says, word for word on the categories and purposes.

Revisit the setup whenever you add an ad network, change CMP, or redesign the site — each of those is a common point where the banner, the tag firing order, or the policy wording quietly drift out of sync with each other.