Skip to main content

Supported Integrations

Privacy Manager supports a number of different integrations for delivery of data or deeper integration with your other business processes. Don’t see an integration you’d like here? Reach out to our support team, who may be able to help!

LiveRamp and WireWheel offer a joint solution to help you enable a CCPA-compliant, seamless user experience in collecting Do Not Sell, opt-out, deletion, and access requests from California consumers. Please see the attached one-pager for more information, and do not hesitate to reach out to your Customer Success rep if you are interested in learning more.

If you’ve already signed up to integrate with WireWheel, please see the below instructions for how to set up your Privacy Manager for CCPA instance(s) such that you can easily redirect Do Not Sell requests for fulfillment downstream by WireWheel.

User Flow

This implementation of the joint solution allows you to automatically:

  • Show the Privacy Manager notice or Do Not Sell button to a California consumer

  • When the consumer clicks the Do Not Sell button, they are redirected to your WireWheel webform setup

  • The Privacy Manager distributes the Do Not Sell IAB flag to your configured vendors

  • The Privacy Manager passes the Do Not Sell flag, the user’s Audit ID, the domain, and (optionally) some additional metadata about the request to WireWheel to aid in fulfillment

  • The consumer fills out the webform to submit a request

Configuration

In order to implement the Privacy Manager + WireWheel redirect in this manner, please follow these steps:

  1. Configure your Privacy Manager app for your website following the steps in the How to setup CCPA Privacy Manager for Web guidelines. Note: The below instructions can also be applied to alternative user experience flows you may wish to implement if you would not like to display the full Privacy Manager UI.

  2. Publish your version of the Privacy Manager and copy the Privacy Manager tag script from the app’s Admin page in LiveRamp Console.

  3. Implement the Privacy Manager script on your site(s)

  4. Copy the script below to enable the redirect to WireWheel to be triggered:

<script>
    var url = "<// WW WEBFORM LINK PASTE HERE>"
    var auditId
    var domain
    window.__ccpa('addEventListener', 'doNotSellMyDataButtonClicked', 1, function () {
        __ccpa('getConsent', null, 1, function (data) {
        auditId = data.auditId
        domain = window.location.hostname
    });
    var uri = url+"?auditID=" + auditId + "&domain=" + domain;
    var res = encodeURI(uri);
    window.location = uri
    });
</script>

5. Paste the above script underneath your configured Privacy Manager tag script.

6. Be sure to replace the <// WW WEBFORM LINK PASTE HERE> text with the link to your real WireWheel-powered webform.

7. Test you have implemented correctly prior to publishing on your site, and you’re done!

For publishers who are using Prebid as their header bidding solution can implement the Prebid GDPR module to ensure that the consent of the user is passed downstream.

Please see the documentation of Prebid below to understand and integrate the GDPR module with our CMP:

http://docs.prebid.org/dev-docs/modules/consentManagement.html

After the CMP implementation you’ll probably start wondering how you can utilise the CMP functionalities to its full potential. One of the features that you can do with the CMP is the Audit ID interoperability, or in other words, connecting the Audit ID to any data silo available.

For our example we’re going to connect the Audit ID to the login ID, which enable the client to track consent across multiple devices and create a complete 360° view of the end-users consent.

The CMP has an API available that allows to fetch the Audit ID of the end-user.

By calling this API at the right moment we can then send the Audit ID, together with the persistent ID, to any available end-point for storage.

Our example

As said before, for our example we’ll use the workflow of connecting the Audit ID together with a login ID.

Ideally we create a script that contains the Audit API, store the value and pushes the ID to an end-point where we can store the ID in the database.

The best moment for us to connect the Audit ID together with the login ID is right after the user went through the login module.

So right after the login module is done and the end-user has logged in, the Audit API script is called and execute the following API:

__tcfapi('getAuditId', 2, (result) => {console.log(result)});

And store the Audit ID in a variable, ready to send it to any desired end-point together with the already available login ID from the end-user, which will be the second part of the script execution.

The Audit ID that we send to the database of the login module need to be stored as an array, with only new entries and no deletion of previous Audit IDs.

Doing so will ensure that you’ve the complete history of the end-user from their consent point of view, which will help you with auditability once the end-user asks for their consent history.

Note

The logic of connecting the Audit ID to any other persistent ID available will regardless stay the same. By swapping the login system for any other data-silo you’ll achieve the same results