Add the Consent Object to Event Payloads

Pass the consent category IDs as contextual information in events for server-side SDKs and other sources.

This guide explains how to add the consent data to event payloads to implement the consent-based filtering logic (allow or block) on downstream destinations.

Overview

Irrespective of the source or destination, RudderStack honors the consent ID values included in the consentManagement object in the context of event payloads. Several RudderStack SDKs provide native integrations with popular consent management providers and automatically add this data for you.

You can also add the consent data to the event payloads manually to apply the filtering logic (allow or block) for downstream destinations. You can use this approach for:

  • Server-side SDKs
  • SDKs that do not integrate natively with the consent management providers, for example, using Ketch with iOS SDK.

Note that RudderStack supports this approach only for cloud mode destinations.

Prerequisites

  1. Set up the source in the RudderStack dashboard.
  2. Connect the source to the required destination.
  3. Specify the consent category IDs in the consent settings for that destination.
  4. For a Custom consent management provider, you must also select the consent logic to be applied on the category IDs while resolving them against user consent data:
  • AND: Allows the events to go through to the destination only if the end user consents to all the categories corresponding to the category IDs specified in the dashboard.
  • OR: Allows the events to go to the destination if the end user consents to at least one of the categories corresponding to the category IDs specified in the dashboard.

Implementation

Pass the consent data in your event’s context object.

The following snippets highlight some sample instrumentations to send the consent management data to OneTrust via various RudderStack sources:

Note that:

  • RudderStack requires the allowedConsentIds and deniedConsentIds fields to successfully filter events based on user’s consent.
  • You must first configure the consent categories in the consent manager’s platform, then provide the category IDs in the allowedConsentIds and deniedConsentIds fields.
  • The consent IDs specified in the allowedConsentIds and deniedConsentIds must be the union of all the consent settings specified for the destination in the dashboard. Otherwise, the consent setup will not work and RudderStack may not filter your events as expected.
  • The resolutionStrategy parameter refers to the consent logic applied on the category IDs while resolving them against user-specified consent. It is a required field if you set provider to oneTrust, ketch, or iubenda. The below table highlights the resolutionStrategy value that you must set for the specific consent management providers:
Consent management providerresolutionStrategy value
OneTrustand
Ketchor
iubendaor
warning
The event filtering will not work correctly if you set a different consent logic for these providers.
  • resolutionStrategy is not required if you set provider to custom. RudderStack fetches the value for this parameter directly from the consent logic specified in the RudderStack dashboard.


Questions? Contact us by email or on Slack