Verify and Troubleshoot your Google Consent Mode Installation

Updated 8 days ago

Use this guide to confirm that Google Consent Mode (GCM) is correctly installed on your site and to diagnose common issues. Follow the steps in order: most problems can be traced to a sequencing or configuration issue caught in the early steps.

Step 1 : Verify GCM is Enabled in Osano

Before checking your site, confirm the setting is active in your configuration:

Log in to my.osano.com and navigate to Cookie Consent > Configurations.
Open your active configuration and go to Advanced Settings.
Confirm that the Google Consent Mode toggle is ON.
Check that the configuration has been published after this setting was enabled; unpublished changes have no effect on your live site.

Note: If GCM is enabled while Osano is running in Discovery or Listener mode, Osano will inject a denied-consent value even before a user sees the banner. Disable the GCM setting until you are running Osano in a live mode (Permissive or Strict) and the required dataLayer is present on your site.

Step 2 : Check the Installation Sequence

The order in which scripts load on your page determines whether consent signals reach Google tags in time. The correct order is:

Google Consent Mode default dataLayer — must load first, without async or defer
Osano script — loads second, manages consent changes
Google Tag Manager container (or other Google tags) — loads last

To check via Page Source:

Right-click your page and select View Page Source. Scan the <head> for the three script blocks and confirm they appear in the order above.

To check via Developer Tools:

Open your browser's Developer Tools, go to the Elements tab, and inspect the <head> to verify the same load order.

Important: If the default dataLayer script has async or defer attributes, remove them. It must execute synchronously so Google tags receive the default consent state before they fire.

Step 3 : Check the Data Layer

Open a fresh incognito or private window (this avoids cached consent from previous sessions) and navigate to your site.

Open Developer Tools and go to the Console tab.
Type dataLayer and press Enter to expand the data layer object.
Look for two entries:
- Consent default event — should appear immediately on page load, before any user interaction:
```
Arguments(3)
0: "consent"
1: "default"
2: {ad_storage: "denied", analytics_storage: "denied", ad_user_data: "denied", ad_personalization: "denied"}
```
- Consent update event — appears after the user grants consent. In regions like the EU where consent is not pre-granted, you will need to interact with the Osano banner to trigger this:
```
Arguments(3)
0: "consent"
1: "update"
2: {analytics_storage: "granted", ad_storage: "granted", ad_user_data: "granted", ad_personalization: "granted"}
```

Both entries must be present and in this order for GCM to function correctly. If the default entry is missing, the installation sequence is wrong (return to Step 2). If the update entry never appears after granting consent, the Osano GCM integration may not be active or the configuration may not be published.

Step 4 : Verify Google Tag Consent Status (GCS codes)

With Developer Tools open, go to the Network tab and select All. Search for "GCS" in the filter bar.

image (22).png

Inside each Google tag request, you should find a GCS=G1xx parameter. This reflects the current consent state Google has received:

Code	Meaning
`GCS=G100`	No consent granted
`GCS=G110`	Ads consent only
`GCS=G101`	Analytics consent only
`GCS=G111`	All consent granted

The code you see should match the consent state the user has given. If it does not — for example, you granted analytics consent but still see G100 — there is a problem with how the consent update is being passed to Google.

Step 5 : Use the Google Consent Mode Debugger

For a more detailed view of how consent is being handled tag by tag, use the Google Consent Mode Debugger. This tool shows the consent state each Google tag is operating under and can help identify tags that are not receiving the correct signal.

Step 6 : Check for Late Consent Signals

A late consent signal occurs when a Google tag fires before the consent default or update command has been sent to the data layer. This can cause inaccurate data collection or unexpected tag behavior.

How to identify a late consent signal:

In the Osano debugger or Google Consent Mode Debugger, look for any tag flagged as receiving a "late" consent event
In the data layer, check whether a config event for a Google tag (e.g., GT-, G-, AW-, DC-) appears in the data layer before the consent default entry

If you detect a late consent signal, follow the steps below.

What to do when a late consent signal is detected

First check whether the affected tag is enrolled in Google Tag Gateway (GTG).

GTG is a Google-managed infrastructure that can deliver tag scripts via CDN before your page scripts run. When a tag is enrolled in GTG through one-click CDN injection, the tag may load independently of the script order you have configured. This is the most common cause of late consent signals that cannot be resolved through reordering scripts alone.

To check for GTG enrollment:

Open Google Tag Manager and navigate to the container where the tag is configured.
Select the tag and look for a "Google tag settings" section.
Check whether automatic configuration or GTG-related options are enabled.
See Access your Google tag settings for the complete verification steps.
Also check at the Google Ads or GA4 account level, as GTG enrollment can be applied there independently of GTM.

For more background on GTG and its impact on tag load order, see Google's GTG documentation.

If the tag IS enrolled in GTG:

Reordering scripts on your page will not resolve the issue. The recommended solution is to switch to Advanced Consent Mode (also called U+C — unconsented and consented). Unlike Basic Consent Mode, Advanced Consent Mode does not rely on blocking the tag script from loading, instead it allows the tag to load in a cookie-less state and respond to consent signals via the data layer. This approach is fully compatible with GTG, including manual GTG configurations.

See Google Tag Gateway and Consent Mode for step-by-step guidance on enabling Advanced Consent Mode, configuring Data Transmission Controls and Global Consent Defaults, and alternative options such as migrating tags into GTM deployed via GTG.

If the tag is NOT enrolled in GTG:

The late consent signal is a page-level sequencing problem. Return to Step 2 and confirm the three scripts are loading in the correct order without async or defer on the default dataLayer script.

Step 7 : Verify Google Tag and Cookie Classification

Check how your Google content is classified within the Osano platform. Tags and cookies must be categorized consistently with the consent mode setup you are using:

Osano-Centric (Basic) setup: Google tags are classified by their actual function (e.g., Google Analytics = Analytics, Google Ads = Marketing). Osano controls whether they fire based on consent.
Google-Centric (Advanced) setup: Google tags are classified as Essential, allowing them to load before consent and operate in a cookieless state until the user consents.

Mismatched classification, for example classifying Google Analytics as Essential while using a Basic setup, can cause tags to fire unexpectedly or consent signals to be ignored. See Google Consent Mode v2 — Osano-Centric vs. Google-Centric Setup for guidance on which classification approach to use.

Still need help?

If you have completed all steps above and your data still does not look correct, contact Osano support. As a Google-certified CMP partner, we can review your setup, provide recommendations, and assist with any escalations to Google needed to resolve the issue.

Was this article helpful?

Subscribe to receive updates on this article

Help Center