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:
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.
Publish your version of the Privacy Manager and copy the Privacy Manager tag script from the app’s Admin page in LiveRamp Console.
Implement the Privacy Manager script on your site(s)
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!
User Flow
If you prefer to link to your WireWheel opt-out, deletion, and access request portal from your privacy notice in the Privacy Manager UI, without capturing the Audit ID or metadata on the user, you will:
Show the Privacy Manager notice or Do Not Sell button to a California consumer
When the consumer clicks the link to submit a request in your Privacy Manager notice, they will be redirected to the WireWheel webform
Configuration
Configure your Privacy Manager app for your website following the steps in the How to setup CCPA Privacy Manager for Web guidelines.
In the Content page, go to Content Editor > Initial Notice Introduction Text or Content Editor > Privacy Information, depending on your preference of where you’d like to link.
Write up the content you would like to be displayed to the user, including the text you wish to turn into a hyperlink.
Once done, insert a <p> at the beginning of the text.
At the end of the text, insert:
<a href="PLACE_WIREWHEEL_LINK_HERE" target="_blank">link</a></p>
Be sure to include your hyperlink in the place of <PLACE_WIREWHEEL_LINK_HERE>
Save, and implement the Privacy Manager according to the guidelines in Step 2: Implement CCPA Privacy Manager for Web
Example text:
<p>We are committed to transparency and respect your privacy concerns. You may request a copy of your personal data, correct any inaccuracies, delete or transfer your data, or execute a permanent opt-out from this <a href="" target="_blank">link</a></p>
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