Consent Mode v2 Is Configured—but Google Still Says It Is Not

Google Ads can keep warning that Consent Mode is missing or incomplete even when a cookie banner is visible and every Google tag appears green in Google Tag Manager Preview. This guide separates the consent chain into its real components and shows how to diagnose the point where the banner, consent state, tag behavior, network request, account-level detection, or Google policy review breaks.

Practical default: do not treat a green tag in GTM as proof that Consent Mode v2 is correct. Test a fresh visit, rejection, granular choice, acceptance, and withdrawal from the relevant regions; verify the earliest consent default and the later update; inspect live network requests and storage; then check every landing-page template and Google tag destination. Only after that should you wait for Google Ads to refresh its diagnostics or respond to a policy audit.

Executive summary

Consent Mode is not a cookie banner, and a cookie banner is not Consent Mode. The banner collects a visitor’s choice. A consent management platform, or CMP, may store and route that choice. Consent Mode communicates the resulting states to Google tags. The tags then change how they use storage and what they send. Finally, Google Ads has to receive enough correctly labelled traffic to recognize the implementation. A break at any one of these layers can leave the site looking correct in a single browser test while Google still reports missing or incomplete consent.

The most important diagnostic mistake is to equate tag execution with correct consent behavior. In Advanced Consent Mode, a Google tag can legitimately fire while consent is denied and send measurements without cookies. In Basic Consent Mode, the same tag may be intentionally blocked until consent is granted. A green “fired” status therefore proves only that the tag executed in that test session; it does not prove that the four Consent Mode v2 signals were initialized early enough, updated from the user’s choice, attached to the outgoing request, applied on every page, or recognized by Google Ads.

A second common mistake is to treat CMP certification as the deciding factor. Google explicitly says that advertisers are not required to use a CMP from its partner program, and that adopting a partner CMP does not by itself guarantee compliance with the EU User Consent Policy. A partner integration can make implementation easier, but a non-partner CMP or a custom banner can still work if it presents the required choice, sends valid signals, and correctly controls the tags. The separate Google-certified CMP requirement primarily concerns publishers using Google’s publisher products; an organization that is both an advertiser and a publisher may have to evaluate both regimes.

Google’s own troubleshooting materials identify the same recurring technical failures: no default consent state, a default set after another tag has already run, no consent update after the visitor chooses, regional defaults that do not match the visitor’s location, Google tags blocked despite an intended Advanced setup, missing Consent Mode v2 parameters, incomplete page coverage, and a consent rate that remains at zero because every visitor is permanently labelled as denied. These are chain failures, not banner-design problems.

There is also a reporting delay. Google says the active Consent Mode status normally takes up to 48 hours to appear in Google Ads and can take as long as two weeks in some cases. Conversion modelling has separate volume thresholds and timing rules, so the absence of a modelling uplift report does not prove that Consent Mode is absent. Google currently documents a threshold of 700 ad clicks over seven days for a domain-and-country grouping before Ads conversion modelling can become eligible.

Finally, a general account banner or widely distributed reminder is not the same thing as an actual EU User Consent Policy audit. A real audit can review the visible consent mechanism, first-layer wording, affirmative action, disclosures about Google and other recipients, the ability to revoke consent, cookies set before consent, and the technical consent signal. It may require remediation and a re-audit. Technical diagnostics and policy audits overlap, but they are not interchangeable.

As of 2 August 2026, this distinction matters even more because Google has made Consent Mode the principal control for Google Ads data flowing from linked Google Analytics setups. For the wider 2026 data-control context, see metricfixer’s review of GA4 consent changes and server-side GTM.

The full consent chain: seven separate layers

The chain explains why apparently contradictory observations can all be true. A banner can be present while no Consent Mode command is sent. Consent Mode can be correct on the home page but missing on advertising landing pages. Tag Assistant can show a correct draft container while the live site still runs an older published version. A GA4 request can carry consent information while a separate Google Ads destination or ecommerce subdomain does not.

What you see	What it proves	What it does not prove
A cookie banner appears	A consent interface was loaded for this visitor.	That the four Google consent signals exist, that the choice is stored, or that Google tags respect it.
The CMP dashboard says Google Consent Mode is enabled	A platform setting was switched on.	That the live template, category mapping, geolocation rule, published version, or update callback works.
A Google tag is green in GTM Preview	The tag executed in that preview event.	That consent was granted, that storage was allowed, that the request contained correct signals, or that every live page behaves the same way.
Tag Assistant shows an On-page Default	A default consent call was detected on that page.	That it happened before every tag, that the values are correct for the visitor’s region, or that a later update occurs.
Tag Assistant shows an On-page Update	The tested interaction changed consent on that page.	That reject, granular, withdrawal, subsequent-page, subdomain, or SPA flows also work.
A request contains gcd	The Google request carries a consent-related field.	That Consent Mode is correctly configured: Google says gcd is sent even when Consent Mode is not activated.
Google Ads shows “Consent mode is implemented”	Google detected eligible labelled traffic for the relevant setup.	That the banner wording, pre-consent cookies, withdrawal flow, every domain, or every third-party tag meets policy and legal requirements.
Google sends an EU User Consent Policy audit notice	A policy review identified one or more user-facing or technical issues.	That changing one GTM trigger alone will resolve the audit.

Cookie banner presence is only the first layer

What the banner must do technically

For Consent Mode, the banner’s job is not merely to appear. It must produce a machine-readable decision that can be mapped to the site’s consent categories and then to Google’s consent types. The implementation should support at least these user paths:

• first visit before any choice;
• accept all;
• reject all;
• a granular selection, such as analytics allowed but advertising denied;
• a returning visit with a stored choice;
• withdrawal or revision of a previous choice.

Google’s developer documentation notes that Consent Mode itself does not save the visitor’s choice. The CMP or site must persist it and apply the appropriate state on later pages and future visits. A banner that updates consent only on the first page but fails to read the stored choice after navigation can create alternating granted, denied, and unset requests within one user journey.

Testing should begin with cleared cookies and storage, or a new browser profile. Incognito mode is useful, but it is not always enough if extensions, browser privacy features, preview tooling, or server-side geolocation affect the result. Run separate sessions for each consent path rather than clicking “Accept all” once and assuming the other branches are symmetric.

Certified, partner, integrated, and custom CMPs

Google uses several related labels that are easy to conflate. A CMP may be listed as an integrated partner for a simplified setup, participate in Google’s advertiser CMP Partner Program, provide a GTM Community Template, or be certified for publisher use. These labels describe integration and program status; they do not turn the CMP into a compliance guarantee.

For advertisers, Google’s own EU User Consent Policy help page says the partner list is not exhaustive and that advertisers are not required to choose a partner CMP. It also says adopting one does not guarantee compliance because the result depends on the implementation and the message shown to users. A custom consent banner is therefore technically possible, but the organization assumes more responsibility for defaults, updates, storage, regional rules, records, and testing.

The publisher rule is different. Google requires certain publisher partners serving ads in the EEA, the UK, and Switzerland to use a Google-certified CMP. A company that runs Google Ads to acquire customers and also monetizes pages through AdSense or Google Ad Manager should not apply the advertiser rule to its publisher activity or vice versa.

Certification also does not prevent configuration mistakes. Common examples include leaving the CMP’s Google integration disabled, deploying an old template version, mapping “Marketing” to ad_storage but not to ad_user_data and ad_personalization, using auto-blocking that converts an intended Advanced implementation into Basic, or showing a banner only in part of the policy region.

The four Consent Mode v2 signals are not interchangeable

Consent Mode v2 added ad_user_data and ad_personalization to the earlier ad_storage and analytics_storage model. A site that still sends only the two original storage signals can look partly functional while Google Ads reports that EEA consent or ads-personalization consent is missing.

Consent type	What it controls	Common mistaken assumption	Practical verification
ad_storage	Whether Google advertising tags may use advertising-related cookies or device identifiers.	“If this is granted, every advertising use is allowed.” It does not replace ad_user_data or ad_personalization.	Check storage behavior, advertising-cookie access, and the value shown in the earliest default and later update.
analytics_storage	Whether analytics-related cookies or app identifiers may be used.	“Denied means no Analytics request exists.” In Advanced mode, GA4 can still send measurements without analytics cookies.	Inspect GA4 requests and the browser’s cookies/storage separately.
ad_user_data	Consent for sending user data to Google for online advertising purposes, including relevant user-provided-data and measurement use cases.	“It inherits automatically from ad_storage forever.” A current v2 implementation should send it explicitly.	Verify the field in both default and update events and test the exact Ads or enhanced-conversion workflow that uses it.
ad_personalization	Consent for personalized advertising, including remarketing-related uses.	“Turning off a remarketing tag is equivalent.” Google expects the consent signal to describe the user’s choice.	Confirm the value changes with the advertising/personalization choice and review the Google Ads personalization diagnostic.

The additional GTM storage types—such as functionality_storage, personalization_storage, and security_storage—can be useful for non-Google tags and site functions, but they are not substitutes for the four v2 signals Google asks Tag Assistant to verify.

Since 15 June 2026, Google’s documented data-control changes make ad_storage the central control for Google Ads cookies and identifiers collected through linked Google Analytics tags and SDKs. That does not make the other signals optional: ad_user_data still governs advertising use of user data, and ad_personalization still governs personalized advertising.

The default consent state must exist before measurement

Google says that, by default, no Consent Mode values are set. A robust implementation therefore sends an explicit default before commands or tags that transmit measurement data. In GTM, the CMP or consent template should normally run on Consent Initialization – All Pages, before ordinary Initialization or Page View tags. In a direct gtag.js implementation, the default command belongs before config and event commands.

A default set to denied after a Google Ads tag has already written or read a cookie is not retroactive. Tag Assistant may show both the tag and the later consent event, but the ordering is already wrong. Google has a specific “Default consent set too late” diagnostic for this sequence.

The following is a minimal page-level example for illustrating the order. It is not a universal policy recommendation, and GTM users should not paste it into a Custom HTML tag. Google recommends a consent template that uses the GTM consent APIs for container-based implementations.

// Example only: align values and regional logic with your approved policy.
window.dataLayer = window.dataLayer || [];

function gtag() {
  dataLayer.push(arguments);
}

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

// Load the Google tag only after the default command has been queued.

// Call this after the visitor confirms the relevant choices.
function updateGoogleConsent(choice) {
  gtag('consent', 'update', {
    ad_storage: choice.ads ? 'granted' : 'denied',
    analytics_storage: choice.analytics ? 'granted' : 'denied',
    ad_user_data: choice.ads ? 'granted' : 'denied',
    ad_personalization: choice.personalizedAds ? 'granted' : 'denied'
  });
}

The optional wait_for_update value can give an asynchronously loaded CMP a short period to provide an update before data is sent. It is not a substitute for an early default, and an excessively long wait can create its own measurement gaps. If the CMP is installed through GTM, use its template and documented GTM consent APIs rather than a Custom HTML implementation of gtag('consent', ...).

Regional defaults must match the regions you actually serve

Google supports region-specific defaults using ISO 3166-2 region codes. More-specific rules take precedence over broader ones. This is useful when an organization has different approved consent models by geography, but it creates several ways to fail:

• the banner is shown in the EEA but the default rule covers only a smaller country list;
• the policy applies to the EEA, the UK, and Switzerland, but the test covers only EU member states;
• a global denied fallback is never updated outside Europe, producing a zero-percent advertising-consent rate in regions where the organization intended another model;
• the CMP’s geolocation and Google’s traffic classification do not produce the same regional path;
• a more-specific subregion rule overrides the expected country-level default;
• the home page and checkout use different CMP configurations or region lists.

Google’s current Tag Diagnostics explicitly includes warnings for a zero-percent consent rate and for zero percent in some non-EEA regions. Region scoping is therefore not merely a legal-policy setting; it also affects whether Google can recognize a plausible live consent pattern.

Test regional behavior from several real or simulated locations, including at least one EEA country, the UK, Switzerland, and a non-European control region if those audiences are in scope. Keep the browser state clean between tests. A single successful test from the agency office does not validate a geo-targeted implementation.

The update after the visitor’s choice is a separate requirement

The default answers “what may happen before the visitor chooses?” The update answers “what did this visitor choose?” Both are required for a normal Advanced implementation. A common broken setup sends a denied default correctly, displays the banner, and then never sends an update. Every Google request remains denied, Google Ads sees a zero-percent consent rate, and the CMP dashboard still reports that the banner collected acceptances.

Every choice path needs an update. Do not test only “Accept all.” A granular choice should produce different values, and “Reject all” should explicitly preserve or update the denied state. Withdrawal should send a new update as soon as the visitor confirms the change.

Timing matters. Google recommends sending the update on the page where the choice occurs and before a page transition. If the banner’s accept button immediately reloads the page or submits a form, the browser can cancel the measurement requests triggered by the update. The next page may then start without the initial page’s full measurement context. In single-page applications, route changes must not replace or bypass the current consent state.

Test state	Expected consent behavior	Advanced mode expectation	Basic mode expectation
Fresh visit, no choice	An explicit default is available before measurement for the applicable region.	Google tags may load and send measurements without cookies under denied states.	Google tags remain blocked; no Google request is sent before a grant.
Reject all	All relevant values remain or become denied.	Consent-aware Google tags may continue cookieless measurement.	Google tags remain blocked and send no data.
Analytics only	analytics_storage may be granted while advertising-related values remain denied, if that matches the choice model.	Analytics can use permitted storage; Ads personalization and user-data uses remain restricted.	Only tags allowed by the selected categories should load.
Accept all	All four relevant values update to granted.	Google tags can use permitted storage and send full measurement data.	Google tags load after the grant and send the default followed by the update.
Withdraw consent	A new update changes the relevant values from granted to denied.	Future tag behavior changes immediately; separate cookie-removal handling may still be needed.	Future tag execution should again be blocked where required.

Basic and Advanced Consent Mode produce different “correct” tag behavior

Dimension	Basic Consent Mode	Advanced Consent Mode
Before a decision	Google tags are blocked.	Google tags load with explicit defaults, normally denied where prior consent is required.
When consent is denied	No Google data is sent, including no consent-status ping.	Google tags can send consent-labelled measurements without cookies.
When consent is granted	Google tags load and send measurement data.	Existing tags adapt and can use permitted storage and full measurement data.
Modelling	Google describes a more general model.	Google describes advertiser-specific modelling when eligibility thresholds are met.
Typical GTM symptom	Google tags appear under “Tags Not Fired” before consent.	Google tags can appear under “Tags Fired” even while the consent state is denied.

This difference is why “the tag fired before consent” is not, by itself, a diagnosis. In Advanced mode, firing is expected; the question is whether the tag avoided disallowed storage and sent the correct consent-labelled request. In Basic mode, firing before consent would be a configuration error.

The reverse mistake is also common. Teams intend to use Advanced mode but add exception triggers or “Require additional consent” checks to Google Analytics, Google Ads, Floodlight, or Conversion Linker tags. Google tags already contain built-in consent checks. Google’s unblock Google tags guidance says additional checks can block those tags completely and remove the cookieless signals needed for advertiser-specific modelling. If the organization intentionally chose Basic mode, blocking can be correct; if it intended Advanced mode, the same configuration is a silent architecture change.

Advanced mode is a technical measurement choice, not a declaration that every pre-consent request is legally appropriate in every jurisdiction. The organization’s privacy and legal owners should approve the mode, the defaults, the data included in events, and the disclosures. Consent Mode adapts Google tags to a decision; it does not create valid consent or replace the consent notice.

What GTM Preview and Tag Assistant should show

Google’s current verification workflow asks you to inspect the earliest Consent event and the most recent Consent event separately. In the earliest event, all four v2 fields should appear in the API Call or the On-page Default column. After the user interacts with the banner, the most recent Consent event should show the corresponding values in On-page Update.

A proper test session should answer five questions:

1. Did a consent event occur before ordinary measurement tags?
2. Were ad_storage, analytics_storage, ad_user_data, and ad_personalization all present?
3. Did the visitor’s exact choice create a later update?
4. Did each tag behave according to the intentionally selected Basic or Advanced mode?
5. Did the same behavior persist after navigation, reload, route change, and return visit?

Do not stop when the tag row turns green. Open the tag and inspect its built-in consent checks, required additional consent, firing event, and outgoing request. A Google tag that fires at Consent Initialization for the wrong reason can still be too early; a tag that fires at Page View can still have read an unset default if the CMP loaded asynchronously.

Also distinguish Preview from live. GTM Preview normally evaluates the current workspace version. Google Ads diagnoses traffic generated by the published live container and other live integrations. Confirm the container version, publication timestamp, environment, and exact container ID on the production page. A correct unpublished fix is one of the simplest reasons for a persistent warning.

Verify the requests that actually leave the browser

Tag Assistant is the primary Google-supported debugger, but browser network inspection answers a different question: what did the browser actually send? In Chrome DevTools, preserve the network log, clear site storage, reload, and test the fresh, reject, granular, accept, and withdrawal paths. Filter for Google Analytics collection requests, Google Ads conversion or remarketing endpoints, and consent-related parameters such as gcs and gcd.

Google’s current Consent Mode overview explains that:

• gcs communicates the ad_storage and analytics_storage choices;
• gcd carries more detailed consent information and is always sent to Google services, even when Consent Mode is not active;
• dma and dma_cps may communicate related consent configuration and Google-service consent;
• the encoding can change as Google’s services evolve.

Two practical conclusions follow. First, the mere presence of gcd is not proof that Consent Mode v2 is working. Second, community decoders for gcd and gcs can be useful clues, but they should not replace Tag Assistant because Google does not promise a permanent public encoding format.

The network pattern should match the intended mode:

• in Basic mode, there should be no Google tag requests before consent and no Google requests after rejection;
• in Advanced mode, denied-state requests may exist, but advertising and analytics storage should not be read or written where the corresponding storage consent is denied;
• after a grant, requests should reflect the updated state and permitted cookies or identifiers may appear;
• after withdrawal, later requests should reflect denied states again.

Check the browser’s Application panel at the same time. Network parameters and stored cookies answer different questions. A request can carry denied consent while a non-Google script still sets a marketing cookie, and a banner audit can fail because of that unrelated tag. Likewise, an old cookie left from a previous granted session can confuse a test unless storage is cleared first.

For Google Ads, inspect the exact advertising destination used in production. A correct GA4 request is not proof that a separate AW- destination, Floodlight configuration, Google tag connected destination, CMS plugin, or ecommerce integration receives the same consent state.

Google Ads has several diagnostics that answer different questions

Surface	What it evaluates	How to interpret it
Google tag > Tag quality > Diagnostics	Tag coverage, ordering, domain behavior, and consent labelling detected across live traffic.	Useful for page- or domain-level gaps; not the same as a policy audit.
Goals > Conversions > conversion action > Diagnostics	Consent Mode status and, where eligible, modelling activation for the selected conversion setup.	Can lag after implementation; check the exact conversion action and tag destination.
Consent Mode impact results	Reported modelling uplift for eligible domain-and-country slices.	Absence can mean low volume, a small uplift, an expired reporting window, or an implementation issue.
Account notification, setup card, or general email	May communicate a broad requirement, recommendation, or detected account-level risk.	Classify the message before changing production: look for a named domain, diagnostic, deadline, and remediation path.
EU User Consent Policy audit notice	A policy review of the user-facing consent experience and technical behavior.	Requires policy-specific remediation and often a re-audit, not only a GTM change.

Google’s current Tag Diagnostics documentation lists several consent-specific findings that are more precise than a generic “not configured” message:

• Some pages missing consent for EEA users: some live pages send data without recognizable consent labelling.
• Website/App missing EEA consent for ads personalization: ad_personalization is missing or an older v1 setup is still in use.
• Consent mode installation out of order: consent commands and tags are running in the wrong sequence.
• Verify consent mode setup as 0% consent rate detected: ad_user_data remains denied for all detected traffic.
• 0% consent rate detected in some regions: a regional rule may have been applied globally or never updated.
• Consent missing for EEA users: Google receives EEA data without recognized consent labels and cannot establish that tags were blocked.
• Update your consent settings: Google believes tags are blocked across the site but cannot verify the consent states being sent.

These diagnostics should be treated as evidence about live traffic coverage, not as a line-by-line verdict on the one page you tested. Google may have detected an old landing page, a language version, a checkout domain, a campaign URL, a CMS template, or a second Google tag that your manual session did not visit.

Allow for detection delay—but only after verifying the live chain

Google states that the active Consent Mode status can take 48 hours to appear and may take up to two weeks. Waiting is reasonable only after the live implementation has been verified. Do not use the delay as an explanation when the production container is unpublished, the default is late, the update is absent, or only one template was tested.

Consent Mode status and conversion modelling eligibility are also separate. Google may show “Consent mode is implemented” before the domain-country slice has enough data for modelling. The current documented Ads threshold is 700 ad clicks over seven days for a domain-and-country grouping. Uplift results are subject to additional minimums and are displayed for a limited period. A small advertiser can therefore have a valid implementation with no visible uplift table.

A general warning is not the same as a real EU User Consent Policy audit

Google has sent broad product communications about consent requirements, and account interfaces can display generalized setup prompts. The message itself should be classified before it is treated as evidence of a site-specific failure.

General reminder or broad warning	Likely policy audit or account-specific enforcement notice
Uses generic language about implementing Consent Mode or maintaining measurement.	Names the affected site, app, account, or property.
Links mainly to standard setup documentation.	Identifies a specific failure category or observable behavior.
Provides no page, domain, deadline, case reference, or re-audit process.	Provides remediation instructions, a response path, deadline, case thread, or re-audit step.
May arrive even when the recipient manages several accounts or linked properties.	Usually concerns the account or properties explicitly in scope.
Should trigger verification, not an emergency redesign.	Should trigger a documented technical and policy remediation workflow.

A real audit is broader than Consent Mode syntax. Google says its reviewers visit the site or app as a user would and examine the information and consents presented. Current audit guidance covers issues such as:

• a missing consent mechanism or a banner not shown across the policy region;
• missing or incomplete disclosure of personal-data use and ads personalization;
• no clear affirmative action to provide consent;
• missing disclosure of data sharing with Google and other recipients;
• no link to Google’s Business Data Responsibility information;
• invalid, missing, or mismatched consent signals;
• cookies set before consent where consent is required;
• a CMP or consent mechanism configured incorrectly.

That means a site can pass a narrow Tag Assistant test and still fail a policy audit because the banner wording is incomplete, rejection or withdrawal is ineffective, a third-party script sets cookies before consent, or the notice does not explain data sharing. It can also fail technically even when the visible wording is strong.

Do not turn this distinction into a legal conclusion. Google’s policy reflects its contractual requirements and interpretation of applicable rules; the organization remains responsible for its own legal analysis. For the contractual allocation of roles, consent obligations, customer-data use, and agency responsibility, see metricfixer’s Google Ads Data Processing Terms guide for advertisers and agencies.

Why Google can still be right when your test is right

Failure pattern	Why Preview can look correct	What to check
Workspace fix was never published	Preview runs the draft workspace.	Production container version, publish timestamp, environment, and live source.
Only the home page has the CMP	The tester starts on the home page.	Paid landing pages, direct-entry pages, blog templates, checkout, account area, and 404 pages.
A second Google tag or destination bypasses consent	The tested GA4 tag is correct.	Every G-, AW-, DC-, Google tag destination, CMS plugin, and hard-coded snippet.
Consent Mode v1 remains on part of the site	ad_storage and analytics_storage appear normal.	Explicit ad_user_data and ad_personalization on every template.
The update fires only for “Accept all”	The most convenient test path succeeds.	Reject, granular choice, close/dismiss, withdrawal, and returning-visitor paths.
The update is followed by an immediate reload	Tag Assistant records the call.	Network completion before navigation and the state on the next page.
The CMP and Google tags race	A fast office connection loads in the expected order.	Slow network/CPU tests, asynchronous loader order, early default, and appropriate wait_for_update.
Additional consent checks block Google tags	The consent template itself is green.	Exceptions, consent-based triggers, and “Required Additional Consent” on Google tags.
Regional rules are incomplete	The tester is in one covered country.	EEA countries, UK, Switzerland, relevant subregions, and a non-European control location.
The consent choice is not persisted	The first page updates correctly.	Reload, second page, subdomain, cross-domain checkout, and a return visit.
Duplicate consent implementations conflict	The final visible state looks plausible.	Page source, GTM templates, CMS plugins, hard-coded commands, and order of multiple defaults/updates.
Google has not refreshed the status	The live implementation is genuinely fixed.	Document the verification, then allow 48 hours to two weeks before escalating.

A production diagnostic workflow

1. Classify Google’s message. Record the exact wording, surface, affected account, conversion action, tag ID, domain, date, severity, deadline, and whether a re-audit is offered. Do not summarize it as “Google says Consent Mode is missing.”
2. Inventory the live tagging paths. List every GTM container, Google tag, GA4 stream, Google Ads destination, Floodlight tag, CMS plugin, ecommerce integration, hard-coded snippet, server-side endpoint, subdomain, checkout, and app surface.
3. Confirm the intended architecture. Decide whether the implementation is Basic or Advanced and document the approved default and category mapping by region. Do not diagnose an Advanced implementation with Basic expectations.
4. Start with a clean regional session. Clear cookies and storage, disable ad blockers for the test, use a fresh browser profile, and test from the relevant geography. Capture the banner before interacting with it.
5. Verify the earliest default. In Tag Assistant, select the earliest Consent event and confirm all four v2 signals, their values, and their order relative to Google tags.
6. Verify every update path. Run separate sessions for reject, granular selection, accept, returning visitor, and withdrawal. Confirm that updates occur before reloads or route transitions.
7. Review tag behavior. Check which tags fired or were blocked and whether that matches the intended mode. Remove unintended exceptions or additional consent checks from consent-aware Google tags when Advanced mode is intended.
8. Inspect network and storage. Compare requests and cookies before a choice, after rejection, after granular choice, after acceptance, and after withdrawal. Verify the exact Google Ads and Analytics destinations, not only one request.
9. Repeat across the real site. Test paid landing pages, alternative languages, checkout, subdomains, SPAs, logged-in areas, and high-traffic templates. Confirm the live published container rather than only the workspace preview.
10. Check Google Ads again. Review Tag Diagnostics and the selected conversion action’s Diagnostics. If the live evidence is clean, allow the documented 48-hour to two-week refresh period.
11. Handle an audit as an audit. Review the first-layer notice, affirmative action, disclosures, Google link, consent records, withdrawal path, pre-consent cookies, and technical signals. Respond through the case or re-audit process with evidence.

Build an evidence pack before escalating

A useful escalation to a CMP vendor, developer, Google Ads support, or a policy-review team should contain reproducible evidence rather than a statement that “GTM is green.” Include:

• the exact warning or audit notice and where it appeared;
• the affected customer ID, conversion action, domain, and Google tag IDs;
• the CMP name, version, template version, deployment method, and regional rule set;
• the GTM container ID, live version number, and publication timestamp;
• screenshots or a screen recording of the fresh banner, rejection, granular choice, acceptance, and withdrawal;
• Tag Assistant evidence for the earliest default and most recent update;
• a HAR or equivalent network capture for denied and granted sessions;
• a cookie and storage inventory before and after consent;
• the tested URLs, templates, countries, devices, and browser conditions;
• the date of the fix and the date on which Google Ads was checked again.

This evidence also helps separate platform delay from an incomplete fix. If one page, region, or destination behaves differently, the comparison normally reveals it faster than repeated edits to the main GTM container.

Final implementation checklist

• [ ] A banner is shown to the intended users in every applicable region.
• [ ] The user can accept, reject, make a granular choice, and later change that choice.
• [ ] Consent choices are stored and restored on later pages and visits.
• [ ] The default state is set before Google tags or measurement commands.
• [ ] ad_storage, analytics_storage, ad_user_data, and ad_personalization are all present.
• [ ] Every banner path sends the correct consent update.
• [ ] The selected Basic or Advanced mode is documented and intentional.
• [ ] Google tags are not accidentally blocked by exceptions or additional consent checks when Advanced mode is intended.
• [ ] Tag Assistant results match browser network and storage behavior.
• [ ] The live published container matches the tested workspace.
• [ ] Every landing-page template, subdomain, checkout, language version, and Google tag destination has been tested.
• [ ] Regional rules cover the EEA, the UK, Switzerland, and any other locations in the organization’s approved consent model.
• [ ] Google Ads Tag Diagnostics and conversion diagnostics were checked separately.
• [ ] The team distinguished implementation status from modelling eligibility and allowed for the documented diagnostic delay.
• [ ] Any EU User Consent Policy audit was reviewed for notice, disclosure, affirmative-action, revocation, data-sharing, and pre-consent-cookie issues—not only GTM configuration.

Conclusion

When Consent Mode v2 is “configured” but Google still says it is not, the disagreement is usually about scope or evidence. The team has confirmed one visible layer or one successful browser path; Google is evaluating live requests across pages, domains, regions, tag destinations, and time. Or the message is not a technical diagnostic at all, but a broader policy reminder or audit.

The reliable approach is to stop asking whether Consent Mode is installed and ask whether the entire chain works. A valid banner choice must become an early default and a timely update; Google tags must behave according to the intentionally selected mode; outgoing requests and storage must reflect the choice; every production surface must carry the same logic; and Google Ads must have time and enough real traffic to detect it. A green tag is useful evidence, but it is only one link in that chain.

Methodology and sources

This article reflects documentation available on 2 August 2026. It is based primarily on Google’s current Consent Mode overview and implementation guides, Tag Assistant troubleshooting instructions, Google Ads and Google Tag diagnostics, the EU User Consent Policy and audit guidance, and Google’s 2026 Analytics data-control update. Practical recommendations were developed by translating the documented failure categories into a production audit sequence covering clean-browser tests, regional variants, live-versus-preview differences, network requests, storage, page coverage, duplicate tag paths, and escalation evidence. Simo Ahava’s technical analysis and implementation template, CMP-vendor instructions from Cookiebot and OneTrust, and the Loves Data troubleshooting workflow were reviewed to cross-check field issues such as stale templates, category mapping, state persistence, duplicate banner loaders, and additional-consent checks.

• Google Tag Platform: Consent Mode overview
• Google Tag Platform: Set up Consent Mode on websites
• Google Tag Platform: Troubleshoot Consent Mode with Tag Assistant
• Google Tag Manager: Consent Mode support
• Google Tag Manager: Unblock Google tags when using Consent Mode
• Google Tag Manager: Set up a consent banner with a CMP or CMS
• Google Ads: Consent Mode reference
• Google Ads: Verify Consent Mode implementation
• Google Ads: Troubleshoot Consent Mode
• Google Ads: Troubleshoot tag issues with Tag Diagnostics
• Google Ads: Consent Mode impact results
• Google Ads: Consent Mode updates for EEA traffic
• Google EU User Consent Policy
• Google: Help with the EU User Consent Policy
• Google Ads: Fix issues with an EU User Consent Policy audit
• Google Analytics: 2026 updates to data controls
• Simo Ahava: Consent Mode v2 for Google tags
• Simo Ahava: Consent Mode custom tag template
• Cookiebot: Implementing Google Consent Mode
• OneTrust: Using Google Consent Mode
• Loves Data: Troubleshooting Consent Mode in Google Tag Manager

This article is for technical and operational information only and is not legal advice. Consent requirements, valid consent standards, regional rules, contractual obligations, and acceptable tag behavior depend on the jurisdiction, the organization’s role, the Google products used, and the exact data collected. Google, CMP interfaces, diagnostics, modelling thresholds, policy-review processes, and documentation may change after publication. metricfixer is not affiliated with Google, Google Ads, Google Analytics, Google Tag Manager, or the third-party author mentioned in the sources.