Skip to main content

Article

OneTrust + Google Tag Manager: How Cookie Categories Control Tags

10/03/2026

Installing a OneTrust banner doesn’t automatically mean every script on a website respects the visitor’s consent selection.

The banner collects preferences. Your website must then apply those preferences to analytics, advertising, embeds and other optional technology.

If you use Google Tag Manager (GTM), the tags inside your container need appropriate consent controls too.

Why Use Google Tag Manager?

A website may use several services: Google Analytics, advertising pixels, conversion tracking, customer-support tools and more. Each service can require a script or tracking tag.

Without a central approach, those scripts can become scattered across theme files, plugins and header settings. That makes it harder to understand what loads, when it loads and which consent category should control it.

GTM provides a central place to manage tags and their firing rules. Once the container is installed, many tag changes can be managed there without editing the website’s templates for every change. Some implementations still require development work to supply the events and information those tags need.

For consent management, the practical advantage is visibility: you can review the tags in the container, identify their purpose, and check the conditions that allow each one to run.

GTM is optional. OneTrust can also be integrated with scripts loaded directly by a website. GTM is useful when you want to manage multiple tracking services and their rules in one place.

How OneTrust and GTM Work Together

Think of the integration as a sequence:

  1. OneTrust establishes the visitor’s current consent preferences.
  2. The integration makes those preferences available to GTM.
  3. GTM evaluates the relevant consent controls when a tag is triggered.
  4. The tag is allowed to run, blocked, or adjusts its behavior according to its configuration.

For example, a visitor might allow analytics but reject advertising. The implementation should apply those choices separately rather than treating acceptance of any optional category as permission for every tag.

The sections below explain a category-based trigger approach. Google tags that support Consent Mode also have consent features that need to be considered separately.

What Is OnetrustActiveGroups?

OneTrust can provide a data layer value named OnetrustActiveGroups. It represents the currently active category IDs, based on the visitor’s preferences or your configured defaults.

A data layer is a way for the website and its integrations to make information available to GTM. A GTM Data Layer Variable reads a particular value from it.

An example value is:

,C0001,C0002,C0003,

The category IDs are identifiers, not descriptive names. Before writing a firing rule, confirm which ID corresponds to the category that should control the tag.

Verify the category IDs in your own OneTrust configuration. Do not assume every implementation uses an identical mapping.

Create the Variable in GTM

To make the active categories available in your trigger conditions:

  1. Open your GTM container and select Variables.
  2. Create a new user-defined variable.
  3. Select Data Layer Variable as its type.
  4. Set the Data Layer Variable Name to OnetrustActiveGroups, preserving its capitalization.
  5. Give the GTM variable a recognizable name, such as OnetrustActiveGroups, and save it.

Use GTM Preview to confirm that the variable receives the expected value when OneTrust updates consent.

Use the Category to Control a Tag

Suppose you have verified that C0002 is the category required for a particular optional tag.

A condition can check for the complete category token:

Variable: OnetrustActiveGroups
Operator: matches RegEx
Value: ,C0002,

These lines describe fields in the GTM interface. They are not JavaScript to paste into your website.

The surrounding commas delimit the category ID. This makes the condition more precise than searching for an unbounded fragment of the value.

What Happens When Consent Changes?

OneTrust provides a data layer event named OneTrustGroupsUpdated. A GTM Custom Event trigger can listen for it and evaluate the category condition.

For a tag that should start when the category becomes active, configure:

Trigger type: Custom Event
Event name: OneTrustGroupsUpdated
Fire on: Some Custom Events
Condition: OnetrustActiveGroups matches RegEx ,C0002,

This is useful when a visitor grants consent without reloading the page.

However, consent updates are not business events. Do not use this event as a substitute for a purchase, form submission or another action you actually want to measure.

Also check repeated updates and consent withdrawal. A trigger cannot automatically undo JavaScript that has already loaded.

Match the Trigger to the Tag’s Purpose

Before applying a consent trigger, decide what the tag is supposed to do.

  • Load an optional service: The service may need to initialize when its required consent becomes available.
  • Record a form submission: The tag should respond to a real submission and check the required consent at that time.
  • Record a purchase: The tag should respond to the purchase event, with the correct transaction details and consent controls.

Attaching every tag to a consent-update event can produce incorrect measurements. Accepting cookies should not be recorded as a purchase or a form submission.

Multiple GTM Triggers Can Cause Problems

An easy mistake is adding a consent firing trigger alongside an existing firing trigger and assuming both conditions must be true.

Separate firing triggers on a tag can allow either trigger to fire it. An existing All Pages trigger can therefore undermine the intended consent restriction.

A Trigger Group waits until all of its member triggers have fired at least once on the page. This can combine event requirements, but it is not a continuous check that consent remains granted.

For a tag that measures a specific action, design the configuration so the required consent is checked when that action occurs. Depending on the tag, this may involve GTM’s consent settings, conditions on the action trigger, or an exception evaluated on the same event.

Test the sequence you intend to support, including consent being granted, withdrawn, and granted again. Do not assume a Trigger Group alone handles every consent change.

How This Relates to Google Consent Mode

OneTrust category IDs and Google’s consent types are different systems. Seeing C0002 in the active groups does not, by itself, prove that Google has received an analytics_storage consent update.

If you use Google Consent Mode, verify the integration that maps your preferences to Google’s consent states.

Google tags that support Consent Mode have built-in consent checks. Other tags may need additional consent requirements or category-based blocking.

The expected behavior also depends on your implementation:

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

Consequently, a network request before consent does not automatically prove a faulty implementation. Compare the observed behavior with the consent model you have intentionally configured.

Consent defaults must be established before measurement tags run, then updated when the visitor’s preferences are known. GTM provides a Consent Initialization trigger for integrations that establish those defaults.

Don’t Forget the Scripts Outside GTM

GTM is only part of the audit.

A website may also load analytics, advertising, embeds or other third-party JavaScript directly through:

  • Theme templates
  • CMS plugins
  • Header/footer injection
  • Custom JavaScript
  • Embedded forms
  • Iframes

Those scripts don’t automatically become consent-aware because GTM has been configured correctly.

For example, a marketing platform might be loaded once through a WordPress plugin and again through GTM. Controlling the GTM copy would leave the plugin’s copy unaffected and could also create duplicate tracking.

Review where each service is installed and make sure its consent controls cover every loading path.

Test the Result

After implementing consent controls, test the website from a clean browser session. Use GTM Preview alongside the browser’s Network and storage tools.

  1. Before interacting with the banner: Check the initial consent state and which services load.
  2. Reject optional categories: Confirm that behavior matches your configured consent model.
  3. Allow one category: Check that the corresponding functionality becomes available without enabling unrelated services.
  4. Perform a real action: Test a form submission, purchase or other event and confirm that the correct tag fires once with the expected information.
  5. Withdraw consent: Check the updated state, subsequent events and behavior after navigating to another page.
  6. Return to the website: Confirm that saved preferences are applied before optional services run.

For each relevant event, inspect the consent state, variable values, tags that fired, tags that were blocked, and actual network activity.

Consent withdrawal deserves particular attention. Blocking future tag executions does not necessarily stop an already loaded service or remove cookies it previously created. Check what the service and your integration require to handle withdrawal.

Consent management should be treated as an implementation that needs testing—not simply a banner installed on top of a website.

Consent and Analytics Implementation

AZTANDC helps organizations implement and troubleshoot consent management, Google Tag Manager, analytics and the web technology surrounding them. We can review how tags load, how consent choices reach those tags, and whether the resulting behavior matches the intended configuration.

References