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.
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.
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:
- Display Ads
- Big Data
The Tealium Collect tag sets the
consent_categories array to events. If the
consent_categories array is defined on an incoming event, the categories in the array will be enforced as detailed below. If that array is not set, then a consent policy cannot be enforced and all server-side products are enabled.
EventStream connector actions
Consent preferences are enforced by 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. This consent category cannot be changed. When the
consent_categories array is defined, an action will only fire if all of the relevant categories are present.
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.
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.
Only connector actions in the Analytics category are triggered. Any connector action in the Personalization category is suppressed.
AudienceStream is categorized in the CDP consent category. To allow attributes and connectors to be processed in AudienceStream, the visitor must opt in to the CDP category.
The consent category assigned to AudienceStream cannot be changed.
AudienceStream connector actions
Audience connectors do not support consent category enforcement at the connector action level. To customize consent enforcement in your AudienceStream connectors you must add consent conditions to the audience rules.
DataAccess products only log events and profiles with Big Data consent in the
consent_categories array. EventDB is categorized in the Big Data consent category. To allow 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.
- Events used by the Data Governance Package
To allow visitor profiles to be stored in AudienceDB, the visitor must opt in to the CDP category.
Disabling automatic enforcement
The built-in enforcement based on
consent_categories can sometimes cause unwanted blocking of consented data. To override that logic, follow these steps:
b.consent_categories_granted = b.consent_categories delete b.consent_categories
- Remove the
consent_categoriesarray to allow server-side products to operate unrestricted.
- Manually add conditions based on
consent_categories_grantedto each event feed and audience.
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
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_grantedon 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 attributescould 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.
Include the appropriate event-level
consent attributesin each event feed, to ensure only consented data is activated.
Step 2: AudienceStream connectors, functions, and AudienceStore
consent attributesto 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.
- These will be based on your event-level
Include the appropriate visitor-level
consent attributesin each audience, to ensure only consented data is activated.
Step 3: AudienceStream profiling and AudienceDB
Audience rules won’t prevent visitor 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 ).
Thank you for your feedback!
This page was last updated: January 7, 2023