This consent management module is designed to support the Global Privacy Platform (GPP)
This module works with supported Consent Management Platforms (CMPs) to fetch an encoded string representing the user’s consent choices (for their repsective region) and make it available for adapters to consume and process.
Prebid functionality created to address regulatory requirements does not replace each party’s responsibility to determine its own legal obligations and comply with all applicable laws. We recommend consulting with your legal counsel before determining how to utilize these features in support of your overall privacy approach. This module is not yet intended to replace other consent modules; it supplements them.
Below is a summary of the actions performed by the GPP consent management module:
In the case of a new user, CMPs will generally respond only after there is consent information available (i.e., the user has made their consent choices). Making these selections can take some time for the average user, so the module provides timeout settings.
If the timeout period expires or an error from the CMP is thrown, one of these actions occurs:
To utilize this module, a Consent Management Platform (CMP) compatible with the IAB GPP CMP spec needs to be implemented on the site to interact with the user and obtain their consent choices. It’s important to understand the details of how the CMP works before integrating it with Prebid.js.
In general, implementation details for CMPs are not covered by Prebid.org, but we do recommend that you place the CMP code before the Prebid.js code in the head of the page in order to ensure the CMP’s framework is loaded before the Prebid code executes. In addition, the community is collecting a set of CMP best practices.
Once the CMP is implemented, simply include this module into your build and add a
consentManagement object in the
setConfig() call. Adapters that support this feature will then be able to retrieve the consent information and incorporate it in their requests.
Here are the parameters supported in the
consentManagement object specific for the GPP consent module:
||The CMP interface that is in use. Supported values are ‘iab’ or ‘static’. Static allows integrations where IAB-formatted consent strings are provided in a non-standard way. Default is
||Length of time (in milliseconds) to allow the CMP to obtain the GPP consent information. Default is
||An object representing the IAB GPP consent data being passed directly; only used when cmpApi is ‘static’. Default is
||Indicates the header section of the GPP consent string, recommended to be
||The version number parsed from the header of the GPP consent string.|
||The sections contained within the encoded GPP string as parsed from the header.|
||Section ID considered to be in force for this transaction. In most cases, this field should have a single section ID. In rare occasions where such a single section ID can not be determined, the field may contain up to 2 values. The value can be 0 or a Section ID specified by the Publisher / Advertiser, during stub / load. When no section is applicable, the value will be -1.|
||The complete encoded GPP string.|
||An object representing the current status of the CMP at the time consent data was fetched. See PingReturn in IAB’s CMP API doc for further information.|
In addition to the static approach described above, there is another means to pass already known GPP consent data of a user via the Prebid.js First Party Data feature. The values for
applicableSections can be passed via the
ortb2.regs.gpp_sid fields respectively; other fields in the GPP data object listed above are not available via the
ortb2 structure. If the GPP consent module is present and successfully obtains the consent information from the CMP, it will override the GPP values set originally in the
ortb2 object (as we assume the CMP’s values will be more up-to-date). Please visit the First Party Data page for more overall information and examples.
Example 1: IAB CMP using a custom timeout
Example 2: Static CMP using custom data passing.
Follow the basic build instructions in the GitHub Prebid.js repo’s main README. To include the consent management module, an additional option must be added to the gulp build command:
You can also use the Prebid.js Download page.
If you are submitting changes to an adapter to support GPP, please also submit a PR to the docs repo to add the
gpp_supported: true variable to your respective page in the bidders directory. This will ensure that your adapter’s name will automatically appear on the list of adapters supporting GPP.
To find the GPP consent information to pass along to your system, adapters should look for the
bidderRequest.gppConsent field in their
buildRequests() method; this field includes a copy of the full GPPData object from the CMP, in case additional information (beyond the gppString and applicableSections values) is needed. Alternatively if only the consent string and/or the applicableSections values are needed, these two values can also be found in the
bidderRequest.ortb2.regs field under the OpenRTB 2.6 field names (
Here is a sample of how the data is structured in the
gppConsent object is also available when registering
The object can be accessed by including it as an argument in the
Depending on your needs, you could include the consent information in a query of your pixel and/or, given the consent choices, determine if you should drop the pixels at all.
Bidders on this list have self-declared their GPP support in their https://github.com/prebid/prebid.github.io/tree/master/dev-docs/bidders md file by adding “gpp_supported: true”.