What should a store do when Google Ads reports Consent Mode setup issues?

Treat the diagnostics panel as a triage list, not a grade. The common flags are a missing or late default state, updates that fire after tags already ran, TCF strings that do not map to consent state, and tag timing races introduced by apps or theme changes. Work through them in that order.

Start with the exact flag, not the general worry

Google Ads diagnostics point at specific problems: consent state missing on a share of traffic, default state arriving late, or updates not detected. Each flag has a different fix. Screenshot the flagged issue with its date range before touching anything, because the flag may clear and reappear as you test, and you want the original wording. Then reproduce on the live store in a fresh browser profile so you are diagnosing the real setup, not a cached one.

Fix the default state first

The most common flag is a missing or late default consent state. Google tags must see a default state, typically denied, before they fire. If the consent script loads asynchronously after the tags, or only fires on pages where the banner component is present, some pageviews carry no consent state at all. The fix is ordering: the default state script must run synchronously in the head, before the tag manager container or gtag snippet, on every page. Verify in the console that the default fires before any tag, on the homepage, a product page, the cart, and checkout-adjacent pages.

Check that updates actually update

The second common flag is updates not detected: the visitor chose, but the tags never heard it. This happens when the banner writes its own cookie but never calls the consent update command, or calls it with the wrong storage keys. Accept the banner as a fresh visitor and watch for the update event in the console, then confirm the tag behavior changes: granted tags fire, denied tags do not. A preference center that updates a cookie but not the live consent state will trip this flag on every visitor who changes their mind.

Verify the TCF mapping if you use a TCF banner

Stores using a TCF 2.2 consent framework can hit a subtler flag: the TCF string exists but does not translate into the consent state Google expects. Purposes and vendor consents in the TCF string must map to the right storage signals. If the banner grants a purpose the store's mapping ignores, or denies something the tags treat as granted, diagnostics flag the mismatch. Walk the TCF string through the mapping for the accept-all, reject-all, and custom paths. This is tedious once and then it is documented forever.

Look for tag timing races from apps and themes

Some flags appear only on certain pages or devices. That usually means something loads tags in a different order there: an app that injects its own gtag snippet, a theme variant that loads the tag manager in the body on mobile, or a checkout extension with its own timing. Compare a clean page against the flagged page and diff the tag load order. The fix is usually to route all Google tags through one container with one consent gate, instead of letting apps fire their own copies outside it.

Confirm the fix in the panel, then watch for regressions

After fixing, the diagnostics panel needs fresh traffic to update, usually a day or two of real pageviews. Do not declare victory from a single test click. Watch the flag clear across the flagged traffic share, then keep monitoring: theme updates, app installs, and banner vendor changes are the usual reasons a cleared flag comes back. A setup that was verified once is verified until the next deploy, and the diagnostics panel is the early warning that the next deploy broke the ordering.