Custom Consent Management Beta

This guide takes you through the detailed steps to configure the custom consent setup and pass the consent data to SDK.

You can use this feature only with the JavaScript SDK v3.

Configure consent settings

While setting up a destination in the RudderStack dashboard, the Consent settings section lets you configure the consent management provider settings for each source type you want to connect with your destination.

You can choose OneTrust, Ketch, or Custom provider using the dropdown and enter all the categories relevant to the destination in the Enter consent category ID’s field.

For Custom consent management provider, you must select the consent logic between the category IDs depending on the use case:

• AND - Blocks the events from going to the destination if all the categories are not consented to by the end user.
• OR - Allows the events to go to the destination if any one of the categories is consented to by the end user.

Additionally, you can add multiple consent management providers for each source type by clicking Add group condition. Note that only one of them will be active at any given point, based on the options passed in consentManagement API.

Pass custom consent data

While using HTTP source

To filter events based on user consent to the cloud mode destinations connected to your HTTP source, pass the consent data in the event’s context object as shown:

{
  context: {
    consentManagement: {
      allowedConsentIds: [...],
      deniedConsentIds: [...], // optional
      provider: "custom", // "ketch" or "oneTrust"
      // This is mandatory when the "provider" value is "custom"
      resolutionStrategy: "and", // or "or"
    },
    ...
}

The resolutionStrategy option lets you define the consent logic between the category IDs:

• and: Blocks the events from going to the destination if all the categories are not consented to by the end user.
• or: Allows the events to go to the destination if any one of the categories is consented to by the end user.

While using client-side SDK

While using a custom consent provider, pass the consent data to SDK based on the following scenarios:

SDK initialized after capturing user consent

Use the consentManagement load API object and ensure that the category IDs in the allowedConsentIds or deniedConsentIdes match exactly (case-sensitive) with the values on the destination configuration page:

<script type="text/javascript">
  // First ensure the user has provided the consents
  // Insert the rest of the RS loading snippet here
  rudderanalytics.load(WRITE_KEY, DATA_PLANE_URL, {
    consentManagement: {
      enabled: true,
      provider: "custom", // important to use the keyword "custom" here
      allowedConsentIds: ['id1', 'id2'],
      deniedConsentIds: ['id3']
    },
    //other options
  });
</script>

SDK initialized before capturing user consent

Pass the consent management platform’s information in the load call while loading the SDK:

<script type="text/javascript">
  // Insert the rest of the RS loading snippet here

  rudderanalytics.load(WRITE_KEY, DATA_PLANE_URL, {
	// allowedConsentIds and deniedConsentIds arrays are not required here
    consentManagement: {
      enabled: true,
      provider: "custom"
    },
    //other options
  });
</script>

Use the SDK’s consent API to pass the end-user consent at a later stage:

<script type = "text/javascript">
  // consent provider callback
  function ConsentManagerWrapper() { /// pseudo name
    if (window.isConsented()) { // pseudo name
      // pass the allowed and denied categoryIds
      rudderanalytics.consent({
        consentManagement: {
          allowedConsentIds: ['id1', 'id2'],
          deniedConsentIds: ['id3']
        }
      });
    }
  } 
</script>

Pre-consent user tracking

You can configure the SDK behavior even before the user provides consent on the site. You can choose to track users as fully anonymous, track their sessions only, or track with anonymousId as the user identifier. This minimizes any data loss related to attribution, acquisition, and the overall user journey.

In this mode, you need to add a new preConsent object to the load API options:

rudderanalytics.load(WRITE_KEY, DATA_PLANE_URL, {
  consentManagement: { // optional
    enabled: true,
    provider: oneTrust/ketch/custom
  },
  preConsent: { // optional
    enabled: true/false, // optional. false by default
    storage: { // optional
      strategy: none/session/anonymousId, // optional; default is "none"
    },
    events: { // optional
      delivery: immediate/buffer, // optional; default is "immediate"
    },
  },
  //Other options
});

If preConsent.enabled is set to true, RudderStack does the following changes while loading the SDK:

• Does not load the device mode integrations but the SDK reaches the ready state.

• Stores information based on the following values:

  Value	Description
  none	Fully anonymous tracking where RudderStack does not store any cookies.
  session	Fully anonymous tracking where RudderStack stores only the session tracking cookie.
  anonymousId	RudderStack only persists the anonymous ID (anonymousId).

• Delivers events based on the following values:

  Value	Description
  immediate	RudderStack sends the events immediately as they occur.
  buffer	RudderStack queues the events in the local storage until the consent API is invoked (or in memory, if local storage is unavailable). This option is applicable only for the none and session cookie storage strategies.

  RudderStack decides the event delivery for preload, ad-block detection, and Query string API based on the above mentioned options (immediate/buffer).

Questions? Contact us by email or on Slack