Skip to main content

Article

How to Test Whether GTM and GA4 Respect Cookie Consent

10/02/2026

A consent banner appearing on a website doesn’t prove that Google Tag Manager, Google Analytics 4 or other marketing technology respects the visitor’s choices.

The banner collects preferences. The implementation must apply those preferences to the tags, scripts and services running on the website.

Here is a practical process for testing GTM and GA4 with your consent management platform. The main checks apply regardless of which platform you use. OneTrust-specific checks are included as optional steps.

Define the Expected Behavior First

Before testing, identify which services should run before consent, which require permission, and what should happen when permission is withdrawn.

If you use Google Consent Mode, distinguish between the two implementation models:

  • Basic Consent Mode: Google tags are blocked until the relevant consent is granted.
  • Advanced Consent Mode: Google tags can load with denied consent defaults and send cookieless pings before consent is granted.

This distinction matters when inspecting network activity. A Google request before consent does not automatically mean the implementation is incorrect. Its behavior must match the model you have intentionally configured.

Also identify any regional differences. Your website may display different choices or apply different defaults depending on the visitor’s location.

Start With a Clean Session

Existing cookies and saved preferences can make consent testing misleading.

Start with a new private/incognito browser session or clear the site’s cookies and storage before testing. Close existing private windows before starting a fresh session, because private windows can share session data.

Open your browser’s developer tools before loading the page so you can capture the initial network requests.

Then open the website without interacting with the consent banner.

Browser privacy settings and extensions can independently block tracking. Record those conditions so you don’t mistake browser blocking for working website consent controls.

Check the Initial Consent State

In Chrome or Edge developer tools, inspect:

Application → Cookies

and:

Network

Other browsers provide similar tools, although their names and locations may differ.

Check what loads before the visitor makes a choice:

  • Cookies and other browser storage
  • GA4 requests
  • Advertising requests
  • Other third-party scripts and embeds

If Google Consent Mode is configured, use Tag Assistant to inspect the consent state. Relevant consent types can include analytics_storage, ad_storage, ad_user_data and ad_personalization.

Confirm that the intended defaults are established before measurement tags run. A consent update arriving later does not correct requests that have already occurred.

Reject Optional Cookies

Choose the option that rejects optional categories, where your banner provides one.

Then check:

  • Cookies created in the browser
  • Network requests
  • GTM tags that fired
  • GA4 requests
  • Advertising requests
  • Other third-party scripts

Navigate to another page and repeat the checks. The rejection should remain effective as the visitor continues through the website.

Don’t test only for cookies. A third-party request can occur without leaving behind the cookie you expected to find.

Compare the observed requests and storage behavior with your configured consent model.

Accept Categories Separately

If your preference center supports separate categories, enable one optional category at a time.

For example, allow analytics while leaving advertising denied. Confirm that analytics behaves as expected without enabling unrelated advertising tags.

Then test the actions your website measures, such as a form submission or purchase. Confirm that the appropriate event is recorded once, with the expected information.

Changing a consent preference should not accidentally generate a duplicate page view or be recorded as a business conversion.

Inspect Your Consent Platform’s Signals

Your consent platform may communicate preferences through data layer values, browser events, cookies or a GTM template.

Check the integration your website actually uses. The platform’s recorded preferences should agree with the consent state and tag behavior visible in GTM.

Do not assume that installing a banner automatically connects its choices to every tag.

If You Use OneTrust: Inspect Active Categories

For OneTrust implementations using its active-group integration, inspect the GTM Data Layer Variable named:

OnetrustActiveGroups

In GTM Preview, select the relevant consent event and inspect the variable’s value. It may contain a comma-delimited list such as:

,C0001,C0002,

Confirm that the active category IDs correspond with the choices you made in the banner.

Verify the category mapping in your own OneTrust configuration. Do not assume that C0002 represents analytics on every website.

If Google Consent Mode is also used, check its consent states separately. An active OneTrust category does not by itself prove that the corresponding Google consent update was sent.

Test the Consent Change Event

Change your preferences without reloading the page. Verify that your consent platform communicates the change and that the relevant tags respond correctly.

If you use OneTrust’s event-based integration, look for:

OneTrustGroupsUpdated

If GTM tags rely on this event, confirm that it appears in Preview and that the active-category values are correct when the trigger is evaluated.

For example, if you have verified that analytics requires C0002, accepting that category should make it active and allow the configured analytics logic to proceed.

For other consent platforms, inspect their documented update event or consent integration instead.

Test Regional Consent Behavior

If the website uses regional consent rules, repeat the tests for the regions your implementation supports.

Check the banner, initial consent state, available choices and resulting tag behavior for each region.

If You Use OneTrust: Test With otgeo

OneTrust supports a geographic testing override through the otgeo URL parameter. Supply a two-letter ISO country code, such as US, GB, DE or FR:

https://example.com/?otgeo=DE

Replace example.com with your website address. This example tests the OneTrust rule selected for Germany.

If the URL already contains a query parameter, append &otgeo=DE instead:

https://example.com/?test=1&otgeo=DE

For US state rules, use a country and state code separated by a comma. For example, to test New Jersey:

https://example.com/?otgeo=us,nj

Start each regional test with cleared consent storage. Confirm that the intended rule loaded rather than judging only by the banner’s appearance.

With OneTrust loaded, run the following in the browser’s developer console to inspect its diagnostic information:

OneTrust.testLog();

Review the geolocation, rule and template information. Then repeat the rejection, acceptance and withdrawal tests for that region.

The override changes the location used by OneTrust for testing. It does not change your actual network location or automatically test other location-dependent website features.

If you use another consent platform, use its supported regional preview or geographic testing method.

Use GTM Preview During Testing

Google Tag Manager’s Preview mode connects your test session to Tag Assistant, helping you determine:

  • Which events occurred
  • Which tags fired
  • Which tags didn’t fire
  • Which trigger conditions succeeded or failed
  • Which variable values were available
  • Which consent states were recorded

Inspect the initial page events, consent updates and actual business events separately.

A tag firing in Preview does not necessarily mean the receiving service recorded the expected event. Check the corresponding network activity and, where appropriate, GA4 DebugView.

Repeat the main checks outside Preview after publishing. The live website should exhibit the expected behavior too.

Check Scripts Outside GTM

Consent testing must cover the whole website, including services loaded outside your GTM container.

Check for scripts installed through:

  • Theme templates
  • CMS plugins
  • Header/footer settings
  • Embedded forms
  • Videos and iframes
  • Custom JavaScript

A service loaded directly by a plugin does not automatically inherit the consent restrictions applied to a GTM tag.

Also check for duplicate installations. The same analytics service running through both GTM and a plugin can produce duplicate events and inconsistent consent behavior.

Test Consent Withdrawal Too

Testing shouldn’t stop at Accept.

Try this sequence:

  1. Start with optional consent denied.
  2. Enable an optional category.
  3. Confirm the expected behavior.
  4. Reopen cookie settings.
  5. Withdraw that consent.
  6. Inspect consent updates and subsequent requests on the current page.
  7. Navigate to another page.
  8. Confirm that the withdrawn preference remains effective.

Consent withdrawal is easy to overlook when QA focuses only on the initial banner.

Blocking future GTM tag executions does not automatically unload scripts that are already running or remove previously created cookies. Verify how each service and its integration handles withdrawal.

Repeat After Major Website Changes

Consent implementations can break when teams add:

  • New GTM tags
  • Plugins
  • Marketing platforms
  • Embedded forms
  • Videos
  • Iframes
  • Analytics products
  • Advertising scripts

Repeat testing after changes to consent categories, regional rules or Consent Mode settings as well.

Record the region, consent choices, expected behavior and observed results. This makes later comparisons easier and helps identify which change introduced a problem.

Consent testing should be part of ongoing website governance rather than a one-time launch task.

Need Help Testing Your Implementation?

AZTANDC works with Google Tag Manager, GA4, consent management platforms and web implementations to help identify scripts that are firing unexpectedly and determine where consent controls need to be applied. For websites using OneTrust, we can also review category mappings, consent updates and regional behavior.

References