GDPR & TCF v2 Setup and Configuration_Archived

This article has been replaced with a newer version. Please refer to the newest version to start your TCFv2 implementation. If you already implemented with the below setup we encourage you to review the updated documentation. However, your current implementation remains fully functional with the below configuration.


Implementing the Sourcepoint Consent Management Platform (CMP) for GDPR & TCF v2 follows a simple two step process that enables publishers and website owners to get up and running with minimal time and resource investment. This document is a guide on how to configure the Sourcepoint code snippet that enables the display of TCF v2 compliant user notifications as well as the syndication of consent signals to vendors through the TCF's v2 onsite API. This guide provides details on the technical implementation steps, however your Sourcepoint account dashboard needs to be enabled for TCF v2 before you can begin the implementation process. Please reach out to your account manager to learn more about this upcoming release and how to join the closed beta program.

1. Two step process to implement the GDPR & TCF v2 code snippet

  1. Implementing the Sourcepoint GDPR & TCF v2 page configuration.

  2. Setting up the message domain.

Below is the Sourcepoint’s GDPR & TCF v2 Javascript code-snippet which needs to be placed at the top of the HTML document and before any ad-tech related code snippets such as a header bidding script. It is strongly recommended to implement the Sourcepoint code snippet between the <head></head> tags of the HTML document to ensure the correct execution of vendor tags that depend on the timely availability of the consent signal.

<script type="text/javascript">
!function () { var e = function () { var e, t = "__tcfapiLocator", a = [], n = window; for (; n;) { try { if (n.frames[t]) { e = n; break } } catch (e) { } if (n === break; n = n.parent } e || (!function e() { var a = n.document, r = !!n.frames[t]; if (!r) if (a.body) { var i = a.createElement("iframe"); = "display:none", = t, a.body.appendChild(i) } else setTimeout(e, 5); return !r }(), n.__tcfapi = function () { for (var e, t = arguments.length, n = new Array(t), r = 0; r < t; r++)n[r] = arguments[r]; if (!n.length) return a; if ("setGdprApplies" === n[0]) n.length > 3 && 2 === parseInt(n[1], 10) && "boolean" == typeof n[3] && (e = n[3], "function" == typeof n[2] && n[2]("set", !0)); else if ("ping" === n[0]) { var i = { gdprApplies: e, cmpLoaded: !1, cmpStatus: "stub" }; "function" == typeof n[2] && n[2](i) } else a.push(n) }, n.addEventListener("message", (function (e) { var t = "string" == typeof, a = {}; try { a = t ? JSON.parse( : } catch (e) { } var n = a.__tcfapiCall; n && window.__tcfapi(n.command, n.version, (function (a, r) { var i = { __tcfapiReturn: { returnValue: a, success: r, callId: n.callId } }; t && (i = JSON.stringify(i)), e.source.postMessage(i, "*") }), n.parameter) }), !1)) }; "undefined" != typeof module ? module.exports = e : e() }();
window._sp_ = {
config: {
wrapperAPIOrigin: "",
mmsDomain: ""
<script src=""></script>

1. The first section of the snippet contains the so called IAB Stub file. The Stub file is defining the "__tcfapi" function to queue all calls into the CMP's onsite API to be released as soon as the consent information is available. It is important to have this script tag always at the top of the HTML document in the first position to avoid errors and failure of the service. To learn more about the IAB Stub file please refer to the IAB's TCF v2 Technical Specifications.

2. The second section of the snippet contains your account specific configuration parameters. This section sets up the parameters necessary for your website to communicate with the Sourcepoint messaging platform and establishes a communication channel with the Sourcepoint messaging and consent service libraries. In addition to the standard parameters in the example above, there are additional parameters that allow for Javascript callbacks to be triggered for different customization purposes. For GDPR & TCF v2 implementations there are currently three required paramameters to deliver a user notification successfully:

a. mmsDomain - For maintenance and optimization reasons the mmsDomain is account-specific. All mms Domains follow the pattern 'https://message{accountIdHere}' where {accountIdHere} needs to be replaced with your individual Sourcepoint account ID (see below). The mmsDomain can also be changed to a CNAMED 1st party subdomain in order to persist 1st party cookies on Safari web browser (due to Safari’s ITP) by setting cookies through the server with "set-cookie" rather than using "document.cookie" on the page. Changing the mmsDomain is optional! More information about setting up an mmsDomain below.

b. wrapperAPIOrigin - "" is the endpoint from where the GDPR & TCF v2 service is served. Keep as is.

c. accountId – This parameter needs to be used to set the account ID you received from your Sourcepoint account manager - The ID associates your data and website with the your account in the Sourcepoint dashboard.

In addition to the required parameters you can use following optional configuration parameters to tailor the implementation to your use case.

propertyHref – Maps the implementation to a specific URL as set up in the Sourcepoint account dashboard.

propertyId – Maps the message to a specific property (website, app, OTT) as set up in Sourcepoint account dashboard.

targetingParams –This parameter enables you to create key-value pairs that can be used for targeting in the scenario builder in the Sourcepoint dashboard. Key-value pairs can be created in the following format:

targetingParams: {
key1: valueA,
key2: valueB

events – An array of events that allow Javascript callbacks to be triggered. Please refer to the Optional Callback document to learn more about how to use events as part of your setup configuration.

2. Creating a 1st party subdomain CNAME for the mmsDomain

Creating a 1st party subdomain for the messaging domain (mmsDomain) and setting up a CNAME to the Sourcepoint endpoint is optional. The goal of creating a mmsDomain is for the Javascript library to communicate with the Sourcepoint messaging server through a 1st party subdomain. The benefit of this approach is to allow Sourcepoint cookies to be “first party” and thus, circumventing Safari’s Intelligent Tracking Prevention (ITP). This creates a discrete messaging channel between the publisher’s messaging subdomain and the Sourcepoint messaging server. Once you create the subdomain, you should create a DNS CNAME record to direct traffic to the Sourcepoint messaging endpoint message<account id> where the account ID refers to your account ID in the Sourcepoint user interface. If you are unsure of what your account ID is, please contact your Sourcepoint account manager.

Once you have created the CNAME record, please inform your Sourcepoint Account manager so that they can create an SSL certificate for the subdomain. This will ensure that both secure and non-secure traffic is handled properly.