The Consent Preferences Manager helps you deploy a tracking preferences option to your website. The consent decision provided by the Consent Manager is automatically enforced by select server-side products. 

However, there are a few restrictions to the automatic enforcement of server-side consent management. This article describes the current per-product behaviors and restrictions, and how to effectively disable automatic enforcement if desired.

In this article: 

How It Works

The consent preferences manager groups tags in categories based on their function and purpose. These categories are presented to the visitor and displayed as toggle buttons to allow or disallow that tracking to occur. 

The following consent categories are currently available:

  • Analytics
  • Affiliates
  • Display Ads
  • Search
  • Email
  • Personalization
  • Social
  • Big Data
  • Misc
  • Cookiematch
  • CDP
  • Mobile
  • Engagement
  • Monitoring
  • CRM

The Tealium Collect tag adds the consent_categories array to incoming payloads on its i.gif call. If the consent_categories array is defined on an incoming event, that array will be respected as detailed below. If that array is not present, it is assumed that no consent policies apply and as such, all server-side products are enabled.

EventStream Connector Actions

Consent preferences are also honored by Tealium EventStream connectors. The consent category of a connector action is displayed on the action configuration screen in the Details:


EventStream Connector Actions Consent Categories

Each connector action in EventStream has at least one consent category assigned. Those cannot currently be changed or reassigned. When the consent_categories array is defined, an action will only fire if all of the relevant categories are present.

Example 1

The Facebook Connector is governed by the Analytics, Display Ads and Social consent categories. Facebook connector actions will only fire when the visitor has opted in to all three categories.

Example 2

You have two connectors configured, one for "Analytics" and one for "Personalization". A visitor grants partial consent in the preference form by allowing "Analytics" tracking but not allowing "Personalization".consent-server-side-categories-example.png

Only connector actions in the "Analytics'' category are triggered. Any connector action in the "Personalization" category is suppressed.

AudienceStream Processing

Tealium AudienceStream is categorized in the CDP consent category. In order for attributes and connectors to be processed in AudienceStream, the visitor must opt in to the CDP category. 

It's not currently possible to change that category.

AudienceStream Connector Actions

There is currently no per-Action enforcement of consent categories in AudienceStream. To have consent built into your AudienceStream workflows requires building any consent-based requirements into the Audience membership conditions.


DataAccess products only log events and profiles with Big Data consent in the consent_categories  array (when that array is present). EventDB is categorized in the Big Data consent category. In order for event data to be stored in EventDB, the visitor must opt in to the Big Data category.

However, there are exceptions for Event Logging:

  • Consent Change events ( grant_full_consent does not require an exception, by definition).

  • Events used by the Data Governance Package

  • AudienceDB stores AudienceStream profiles. Since AudienceStream requires a  CDP consent, in order for AudienceStream profiles to be stored in AudienceDB, the visitor must opt into the CDP category.

Disabling Automatic Enforcement

The built-in consent_categories enforcement described above can sometimes cause unwanted blocking of consented data. To override that logic, follow these steps:

  1. Use a JavaScript Code extension scoped to the Tealium Collect tag to copy the opt-in categories to a new array, such as consent_categories_granted:

    // copy the consent information into a more flexible array for manual use
    b.consent_categories_granted = b.consent_categories
    // remove the inflexible array to avoid server-side limitations
    delete b.consent_categories
  2. Remove the consent_categories array to allow server-side products to operate unrestricted.

  3. Manually add conditions based on consent_categories_granted to each event feed and audience (see Manual Enforcement.)

This will disable all automatic enforcement and consent-based blocking. To avoid tracking without end-user permission, ensure you are extremely cautious with your configuration when using this workaround.

Manual Enforcement Instructions

This section describes server-side consent management after disabling automatic enforcement.

Step 1: EventStream Connectors, Functions, and EventStore

  1. Identify event-level consent attributes.

    • If you're using the Tealium Consent Manager and have disabled automatic enforcement following the instructions above, you'll have an array of strings called  consent_categories_granted  on your web events that include the categories of user consent that have been granted. 

    • If you're using a third-party consent manager, the consent attributes could be different in number, name, or type, but each event should have the relevant consent information exposed. 

    • You can create a simplified version to reference downstream, depending on the complexity of the logic needed to parse the consent decision from the event.

    • We recommend labeling these attributes.

  2. Include the appropriate event-level consent attributes in each event feed, to ensure only consented data is activated.


Step 2: AudienceStream Connectors, Functions, and AudienceStore

  1. Create visitor-level consent attributes to reconcile the consent for the visitor profile:

    • These will be based on your event-level consent attributes, and should clearly reflect the most recent state of the visitor's reconciled cross-device consent.

    • We recommend labeling these attributes.

  2. Include the appropriate visitor-level consent attributes in each audience, to ensure only consented data is activated.


Step 3: AudienceStream Profiling and AudienceDB

Audience-level conditions won't prevent AudienceStream profiles from being built or written to AudienceDB. 

If your policies require the profile itself to be blocked in some cases, you can set a separate string attribute for use in the AudienceStream Event Filter. For instance, you could set a new event string attribute called has_audiencestream_consent that defaults to false and is enriched to true when the visitor has consented appropriately (based on your event-level consent attributes ).