Consent Management Platform from a developer’s perspective

Since the GDPR legislation on 25th May 2018, website owners are obliged to capture user consent before showing personalised adverts. This consent is captured in the form of a Consent Management Platform (CMP).

A CMP has two parts:

• UI banner — consisting of toggles that allows users to opt-in/out of GDPR Purpose Consents and GDPR Vendor Consents.
• JavaScript API — allowing in-page adverts to determine whether a vendor (or purpose) is in the consented list.

The vast majority of documentation on the web talk about the UI part, e.g. econsultancy, clearcode, and headerbidding.co. But there is hardly any resources on the JavaScript API.

The JavaScript API needs to satisfy three criteria:

• have a __cmp function on the window object
• have a CMP stub
• have a __cmpLocator

__cmp

The __cmp() function has three uses:

1. getVendorConsents — check if vendor(s) or purposes(s) are consented.
2. getConsentData — retrieve the GDPR consent string.
3. ping — check to see if the CMP implementation has loaded.

CMP stub

The purpose of the CMP stub is to queue commands sent to __cmp before __cmp has a chance to, asynchronously, load its full implementation.

__cmpLocator

When code within an iframe wants to access the __cmp() it would do it via a specially-named iframe called __cmpLocator.

In-frame callers can check for the presence of a function named __cmp. For callers in iframes, the CMP can be determined by the presence of a specially-named child frame named “__cmpLocator” in the parent (or above) frame. The CMP tag creates an iframe named “__cmpLocator” on its frame to indicate its presence. Publishers should load the CMP in a parent (or ancestor) of all iframes that may need to request consent. (IAB GDPR Transparency and Consent Framework)