IAB Europe | IAB Tech Lab
Final v1.1 | April 2018
- Introduction
- About the Transparency & Consent Framework
- About the Transparency & Consent Standard
- License
- Disclaimer
- About IAB Tech Lab
- About IAB Europe
- Consent String and Vendor List Format v1.1
- Version History
- In the GDPR Global DaisyBit consent solution, what purpose does the consent string serve?
- What information is stored in the consent string?
- What is not being supported in the consent string format?
- What is contained in the vendor list JSON?
- What are the URLs for the vendor (and standard purposes lists?
- What is the process of getting on the global vendor list?
- What is the format of the global vendor (and standard purposes) list?
- What are the purposes and features being supported?
- What are the fields of the global vendor consent cookie?
- Vendor Consent String Format
- Example Vendor Consent String
- How is publisher-specific consent stored?
- Publisher Purposes Consent String Format
- Major changes
In February 2017, the IAB Europe assembled parties representing both the supply and demand sides of the digital advertising ecosystem, to work collectively on guidance and solutions to the requirements of the General Data Protection Regulation (GDPR). That working group is known as the GDPR Implementation Working Group (GIG). One of the sub-groups within the GIG was tasked with developing guidance on consent as a legal basis for processing personal data. Out of that effort, an additional working group was formed to develop a technical solution to the challenge of obtaining and disseminating consumer consent to the various parties relying on it as a legal basis of processing personal data.
The scope of the technical working group's initiative increased to include a technical industry solution to allow website operators to:
- Control the vendors they wish to allow to access their users' browsers (for setting and reading cookies) and process their personal data and disclose these choices to other parties in the online advertising ecosystem
- Seek user consent under the ePrivacy Directive (for setting cookies or similar technical applications that access information on a device) and/or the GDPR in line with applicable legal requirements and signal the consent status through the online advertising ecosystem
In summary, have one place to go to:
-
Understand privacy-related disclosures about those vendors
-
Use those disclosures to make privacy-related disclosures to its users
-
Disseminate the disclosure status through the online advertising ecosystem.
The various pieces of the Framework are the following:
-
A Global Vendor and CMP List (commonly referred to as the List)
-
The technical specification for capturing, storing and retrieving user consent in the context of digital advertising
-
Policy underlying the:
-
Disclosures to be made by vendors included on the List
-
Use of the List and the reference architecture
-
Resources including policy FAQ, Global Vendor List Registration, and CMP registration can be found at advertisingconsent.eu.
For purposes of this documentation, the following terms have the following definitions:
-
"CMP" means a company that can read the vendors chosen by a website operator and the consent status of an end user (either service specific (through a first-party cookie) or global (through a third-party cookie). A CMP is not synonymous with a company that surfaces the user interface to a user (although it can be the same).
-
"Purposes" mean the purposes for which a Controller enabled by a website operator is using personal data collected from (or received by a third party) about an end user.
-
"Daisybit" means information compressed into a binary value and passed throughout the online advertising ecosystem through the OpenRTB specification.
-
"Vendor" means a third party that a website operator is using in connection with surfacing content to its end users that either (1) accesses an end user's device or browser; and/or (2) collects or receives personal data about the website operator's end users. As such, a vendor need not be a Controller.
Copyright 2018 IAB Technology Laboratory
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
THE STANDARDS, THE SPECIFICATIONS, THE MEASUREMENT GUIDELINES, AND ANY OTHER MATERIALS OR SERVICES PROVIDED TO OR USED BY YOU HEREUNDER (THE "PRODUCTS AND SERVICES") ARE PROVIDED "AS IS" AND "AS AVAILABLE," AND IAB TECHNOLOGY LABORATORY, INC. ("TECH LAB") MAKES NO WARRANTY WITH RESPECT TO THE SAME AND HEREBY DISCLAIMS ANY AND ALL EXPRESS, IMPLIED, OR STATUTORY WARRANTIES, INCLUDING, WITHOUT LIMITATION, ANY WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AVAILABILITY, ERROR-FREE OR UNINTERRUPTED OPERATION, AND ANY WARRANTIES ARISING FROM A COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE. TO THE EXTENT THAT TECH LAB MAY NOT AS A MATTER OF APPLICABLE LAW DISCLAIM ANY IMPLIED WARRANTY, THE SCOPE AND DURATION OF SUCH WARRANTY WILL BE THE MINIMUM PERMITTED UNDER SUCH LAW. THE PRODUCTS AND SERVICES DO NOT CONSTITUTE BUSINESS OR LEGAL ADVICE. TECH LAB DOES NOT WARRANT THAT THE PRODUCTS AND SERVICES PROVIDED TO OR USED BY YOU HEREUNDER SHALL CAUSE YOU AND/OR YOUR PRODUCTS OR SERVICES TO BE IN COMPLIANCE WITH ANY APPLICABLE LAWS, REGULATIONS, OR SELF-REGULATORY FRAMEWORKS, AND YOU ARE SOLELY RESPONSIBLE FOR COMPLIANCE WITH THE SAME.
The IAB Technology Laboratory ("Tech Lab") is a non-profit research and development consortium that produces and provides standards, software, and services to drive growth of an effective and sustainable global digital media ecosystem. Comprised of digital publishers and ad technology firms, as well as marketers, agencies, and other companies with interests in the interactive marketing arena, IAB Tech Lab aims to enable brand and media growth via a transparent, safe, effective supply chain, simpler and more consistent measurement, and better advertising experiences for consumers, with a focus on mobile and "TV"/digital video channel enablement. The IAB Tech Lab portfolio includes the DigiTrust real-time standardized identity service designed to improve the digital experience for consumers, publishers, advertisers, and third-party platforms. Board members include AppNexus, ExtremeReach, Google, GroupM, Hearst Digital Media, Integral Ad Science, Index Exchange, LinkedIn, MediaMath, Microsoft, Moat, Pandora, PubMatic, Quantcast, Telaria, The Trade Desk, and Yahoo! Japan. Established in 2014, the IAB Tech Lab is headquartered in New York City with an office in San Francisco and representation in Seattle and London.
Learn more about IAB Tech Lab here: https://www.iabtechlab.com/
IAB Europe is the voice of digital business and the leading European-level industry association for the interactive advertising ecosystem. Its mission is to promote the development of this innovative sector by shaping the regulatory environment, investing in research and education, and developing and facilitating the uptake of business standards.
Learn more about IAB Europe here: https://www.iabeurope.eu/
2019/12/06 - Version 1.1 Updated with global cookie support notes
2018/04/24 - Version 1.1 final publication
2018/03/08 - Version 1.1 published for 30-day public comment
2017/12/19 - Initial version v1.0 created
After the interaction between an end user and the Consent Manager Provider (CMP) UI, the consent info is stored (for example, as a third-party cookie) in the user's browser. The data in the consent string answers the question: "Which vendors and purposes did the user give consent for?"
The data stored in the consent string is divided into 3 parts:
-
Metadata of the consent info, e.g. consent string version, when updated, vendor list version, what compression scheme applied on the data.
-
What standard purposes (not per-vendor) the user has given consent for (See Policy FAQ).
-
What vendors the user gave consent to.
-
Multiple vendor lists support (or regional lists)
-
Intelligent handling of deleted vendors
-
Distinct recording of "Consent Revoked" (as opposed to "No Consent")
-
"Not yet consented" state per vendor (it's either "Consent" or "No Consent", or string-not-present).
-
Legal audit trail within the consent string. However, the following details are stored for consent logging and audit record: LastUpdated, CmpId, CmpVersion, ConsentScreen, ConsentLanguage, and VendorListVersion.
-
A vendor list version
-
A list of standard purposes (identifies PurposesAllowed and StandardPurposesAllowed consent bits) (See Policy FAQ for definitions.)
-
A list of standard features. Vendors can indicate that they use features. Since they span data purposes, they are not individually consentable-to by the user, but should be shown in the vendor details in the UI.
-
A list of vendors with assigned VendorIds, the standard purposes they are requesting consent for, the standard purposes they will be using legitimate interest for, and the URL of their GDPR policy page. VendorIds are incrementally-assigned and never reused; deleted vendors are just marked as deleted.
The vendor list will be in JSON and hosted at https://vendorlist.consensu.org/vendorlist.json . Previous and the current version are available at https://vendorlist.consensu.org/v-versionnum/vendorlist.json , where versionnum is a decimal number from 0 to 4095 as indicated in the VendorListVersion field.
Translations of the standard purposes' names and descriptions to non-English languages will be contained in a JSON file including only the 'purposes', 'features', 'vendorListVersion', and 'lastUpdated' keys, and hosted at https://vendorlist.consensu.org/purposes-language.json with older versions at https://vendorlist.consensu.org/v-*versionnum*/purposes-language.json where language is the two-letter lowercase ISO 639-1 language code.
The Vendor Info file will be in JSON and hosted at https://vendorlist.consensu.org/vendorinfo.json.
In this file, the use of the term "AdServers" is representative of the type of domains associated with a vendor that would be used in delivery of assets or script on page, including (but not limited to) ad serving domains.
{
"vendorListVersion": 36,
"lastUpdated": "2018-05-30T16:10:05Z",
"vendors": [
{
"id": 1,
"name": "Example Company",
"AdServers": ["example.company.com (Description, Ad server and tracker)",
}
.... and so on for each vendor included in the Global Vendor List
}
Access iabeurope.eu/join-the-tcf/ to register on the global vendor list. Registration guidelines are available on this website as well.
Purposes, features, and vendors will be sorted by "id".
The JSON format is:
{
"vendorListVersion": 0, // will be incremented each change*
"lastUpdated": "2018-05-28T00:00:00Z",
"purposes": [
{
"id": 1,
"name": "Storage and access of information",
"description": "The storage of information, or access to information that is already stored, on user device such as accessing advertising identifiers and/or other device identifiers, and/or using cookies or similar technologies.."
},
// ... more purposes from id=2 to currently, id=5 (max, id=24)
],
"features" : [
{
"id": 1
"name": "Matching Data to Offline Sources",
"description": "combining data from offline sources that were initially collected in other contexts"
},
// ... more purposes from id=2 up to no higher than id=64. Currently there are 3 planned features*
],
"vendors": [
{
"id": 1,
"name": "Vendor Name",
"purposeIds": [1], // list of consentable data purposes
"legIntPurposeIds": [2, 3], // list of (non-consentable) data purposes that will be used under legitimate interest
"featureIds": [1, 2], // list of features
"policyUrl": "[https://vendorname.com/gdpr.html](https://vendorname.com/gdpr.html)",
"deletedDate": "2018-05-28T00:00:00Z", // if present, vendor should be considered deleted after this date/time
},
// ... more vendors, expecting several hundred vendors in the initial Global Vendor List*
]
}
The entries below are valid for the v1.1 release. Purposes and features are subject to change, so are included in the Global Vendor List. For most up-to-date policy defined purposes, please refer to iabeurope.eu/tcf/.
Purposes are individually-consentable data uses. Due to space constraints in the consent string, they are not consentable on a per-vendor basis, but which vendors utilize which purpose should be shown in the UI for each vendor. Consent for a purpose applies only to vendors that have declared (via the Global Vendor List) that they use that purpose.
Features are informational and should be shown on the UI as a data use by that vendor for transparency purposes, but since they can span multiple (consentable) purposes, they are not individually consentable.
| purpose number | purpose name | purpose description |
| 1 | Information storage and access | The storage of information, or access to information that is already stored, on your device such as advertising identifiers, device identifiers, cookies, and similar technologies. |
| 2 | Personalisation | The collection and processing of information about your use of this service to subsequently personalise advertising and/or content for you in other contexts, such as on other websites or apps, over time. Typically, the content of the site or app is used to make inferences about your interests, which inform future selection of advertising and/or content. |
| 3 | Ad selection, delivery, reporting | The collection of information, and combination with previously collected information, to select and deliver advertisements for you, and to measure the delivery and effectiveness of such advertisements. This includes using previously collected information about your interests to select ads, processing data about what advertisements were shown, how often they were shown, when and where they were shown, and whether you took any action related to the advertisement, including for example clicking an ad or making a purchase. This does not include personalisation, which is the collection and processing of information about your use of this service to subsequently personalise advertising and/or content for you in other contexts, such as websites or apps, over time. |
| 4 | Content selection, delivery, reporting | The collection of information, and combination with previously collected information, to select and deliver content for you, and to measure the delivery and effectiveness of such content. This includes using previously collected information about your interests to select content, processing data about what content was shown, how often or how long it was shown, when and where it was shown, and whether the you took any action related to the content, including for example clicking on content. This does not include personalisation, which is the collection and processing of information about your use of this service to subsequently personalise content and/or advertising for you in other contexts, such as websites or apps, over time. |
| 5 | Measurement | The collection of information about your use of the content, and combination with previously collected information, used to measure, understand, and report on your usage of the service. This does not include personalisation, the collection of information about your use of this service to subsequently personalise content and/or advertising for you in other contexts, i.e. on other service, such as websites or apps, over time. |
| feature number | feature name | feature description |
| 1 | Matching Data to Offline Sources | Combining data from offline sources that were initially collected in other contexts. |
| 2 | Linking Devices | Allow processing of a user's data to connect such user across multiple devices. |
| 3 | Precise Geographic Location Data | Allow processing of a user's precise geographic location data in support of a purpose for which that certain third party has consent. |
| Cookie Directive | Value(s) | Notes |
| Name | euconsent | |
| Host | .consensu.org | The DNS resolution for the name cmp-name.mgr.consensu.org will be delegated by the standardizing authority (IAB) to each CMP. CMPs will host their code, APIs, and CDN at this domain or subdomains. |
| Path | / | |
| Max-Age | 33696000 | This represents thirteen 30-day months. |
| Value | base64url-encoding of the concatenated Cookie Value Fields bits described below. Padding '=' characters should be omitted. | The binary bits should be padded at the end with zeroes to the nearest multiple of 8 bits, packed into a string of bytes, and have base64url-encoding performed. |
- All requests that read from or write to the global cookie in the consensu.org domain must be secured by HTTPS
- Additionally, browser cookie policies may require the support of certain attributes (e.g. sameSite, Secure)
The following fields are stored in big-endian format. Example values are provided below, and bit numberings are left-to-right.
| Vendor Consent String Field Name | Number of bits (bit offsets) | Value(s) | Notes |
| Version | 6 bits (0-5) | "1" for this version | Incremented when consent string format changes |
| Created | 36 bits (6-41) | Epoch deciseconds when consent string was first created | Deciseconds fits into 36 bits with enough precision to record a user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) |
| LastUpdated | 36 bits (42-77) | Epoch deciseconds when consent string was last updated | |
| CmpId | 12 bits (78-89) | Consent Manager Provider ID that last updated the consent string | A unique ID will be assigned to each Consent Manager Provider |
| CmpVersion | 12 bits (90-101) | Consent Manager Provider version | Each change to the CMP should receive a new version number, for logging proof of consent |
| ConsentScreen | 6 bits (102-107) | Screen number in the CMP where consent was given | The screen number is CMP and CmpVersion specific, and is for logging proof of consent |
| ConsentLanguage | 12 bits (108-119) | Two-letter ISO639-1 language code that CMP asked for consent in | Each letter should be encoded as 6 bits, A=0..Z=25 . This will result in the base64url-encoded bytes spelling out the language code (in uppercase). |
| VendorListVersion | 12 bits (120-131) | Version of vendor list used in most recent consent string update. | Vendor list versions will be released periodically. 12 bits allows for 78 years of weekly updates. |
| PurposesAllowed | 24 bits (132-155) | For each Purpose, one bit: 0=No Consent 1=Consent | Purposes are listed in the global Vendor List. Resultant consent value is the "AND" of the applicable bit(s) from this field and a vendor's specific consent bit. Purpose #1 maps to the first (most significant) bit, purpose #24 maps to the last (least significant) bit. |
| Above fields are multiples of 6 bits to fit into base64url-encoded bytes. | |||
| MaxVendorId | 16 bits (156-171) | The maximum VendorId for which consent values are given. | VendorIds are numbered 1 to MaxVendorId. Allows the consent string to be interpreted without waiting for the vendor list fetch. |
| EncodingType | 1 bit (172) | 0=BitField 1=Range | The consent encoding used. Either a BitFieldSection or RangeSection follows. Consent string encoding logic should choose the encoding that results in the smaller output. |
| BitFieldSection | Encodes one consent bit per VendorId | ||
| BitField | MaxVendorId bits (173-...) | For each Vendor, one bit: 0=No Consent 1=Consent | The consent value for each VendorId from 1 to MaxVendorId |
| RangeSection | Encodes a default consent value and any number of single or range override entries | ||
| DefaultConsent | 1 bit (173) | 0=No Consent 1=Consent | Default consent for VendorIds not covered by a RangeEntry. VendorIds covered by a RangeEntry have a consent value the opposite of DefaultConsent. |
| NumEntries | 12 bits (174-185) | Number of entries to follow | NumEntries instances of RangeEntry follow. |
| RangeEntry (repeated NumEntries times, indicated by [idx]) | A single or range of VendorIds, whose consent value is the opposite of DefaultConsent. All VendorIds must be between 1 and MaxVendorId. | ||
| SingleOrRange[idx] | 1 bit | 0=Single VendorId 1=VendorId range | Whether a single VendorId or a start/end range of VendorIds is given |
| SingleVendorId[idx] | 16 bits | A single VendorId. | Exclusive with Start/EndVendorId. |
| StartVendorId[idx] | 16 bits | The start of an inclusive range of VendorIds | Exclusive with SingleVendorId. Must be paired with a EndVendorId |
| EndVendorId[idx] | 16 bits | The end of an inclusive range of VendorIds | Exclusive with SingleVendorId. Must be paired with a StartVendorId. |
Example consent string field values for the case:
-
all VendorId consents given, except VendorId=9
-
for VendorListVersion=8 which has 2011 VendorIds defined
-
by Consent Manager Provider Id #7
| Field | Decimal Value | Meaning | Binary Value |
| Version | 1 | Consent String Format Version #1 | 000001 |
| Created | 15100821554 | 2017-11-07T19:15:55.4Z | 001110000100000101000100000000110010 |
| LastUpdated | 15100821554 | 2017-11-07T19:15:55.4Z | 001110000100000101000100000000110010 |
| CmpId | 7 | The ID assigned to the CMP | 000000000111 |
| CmpVersion | 1 | Consent Manager Provider version for logging | 000000000001 |
| ConsentScreen | 3 | Screen number in the CMP where consent was given | 000011 |
| ConsentLanguage | "EN" (E=4, N=13) | Two-letter ISO639-1 language code that CMP asked for consent in | 000100 001101 |
| VendorListVersion | 8 | The vendor list version at the time this consent string value was set | 000000001000 |
| PurposesAllowed | 14680064 | Purposes #1, 2, and 3 are allowed | 111000000000000000000000 |
| MaxVendorId | 2011 | Number of VendorIds in that vendor list | 0000011111011011 |
| EncodingType | 1 | Range encoding (not bitfield) | 1 |
| DefaultConsent | 1 | Default is "Consent" | 1 |
| NumEntries | 1 | One "range or single" entry | 000000000001 |
| SingleOrRange[0] | 0 | A single VendorId (which is "No Consent") | 0 |
| SingleVendorId[0] | 9 | VendorId=9 has No Consent (opposite of Default Consent) | 0000000000001001 |
| fillbits | The binary bits should be padded at the end with zeroes to the nearest multiple of 8 bits | 00000 |
The complete byte-oriented consent string representation for the previously shown example is:
00000100 11100001 00000101 00010000 00001100 10001110
00010000 01010001 00000000 11001000 00000001 11000000
00000100 00110001 00001101 00000000 10001110 00000000
00000000 00000000 01111101 10111100 00000000 01000000
00000001 00100000 00000000
This string is built using the base64url-encoded representation of the concatenated Cookie Value Fields bits described earlier. Attention: Padding '=' characters should be omitted.
The calculated value for this example is:
BOEFEAyOEFEAyAHABDENAI4AAAB9vABAASA
Under this proposal, there are two types of publisher-specific consent: service-specific vendor consent, and a publisher's purposes consent for its own data use (if needed). For example, a publisher that wants to set a frequency-capping first-party cookie should request Publisher Purposes Consent for Purpose #1 "Accessing a Device".
Service-specific vendor consent can be implemented (optionally) by a CMP using the same Vendor Consent String Format (as detailed above) with the Host, Path, and/or Cookie Name referencing a first-party cookie (or service-shared 3rd-party cookie). If a CMP allows a subset of vendors to be configured by a publisher, storage of consent in a service-specific cookie is necessary to avoid clearing previously-given consent (on non-included vendors) on the global cookie.
The following table indicates which fields are used by which cookie:
| Consent String Format Type | Cookie Location | Purpose |
| Vendor Consent | 3rd-party global location (.consensu.org). Required cookie name: euconsent | global vendor consent |
| Vendor Consent | 1st-party publisher-configured name & location. Could instead be a 3rd-party shared location, for a service-specific cookie that spans publisher sites. Recommended default cookie name: euconsent | service-specific vendor consent |
| Publisher Purposes Consent | 1st-party publisher-configured name & location (again, could be a shared 3rd-party location as well). Recommended default cookie name: eupubconsent | publisher's own data usages consent (not looked at by vendors) |
A publisher's purposes consent string stores the publisher's own consent. This is different than the consent string used to collect consumer consent for vendors. The publisher can configure the CMP to request consent for any of the standard list of purposes (which utilizes the StandardPurposesAllowed bitfield and the standard list of purposes from the Vendor List) and/or custom purposes (initialized by the publisher).
Differences from the Vendor Consent String Format are:
-
"PublisherPurposesVersion" augments "VendorListVersion" and is incremented each time the publisher modifies the requested purposes.
-
"NumCustomPurposes" replaces "MaxVendorId" and is reduced to 6 bits.
-
"BitField" encoding is always used and is indexed by CustomPurposeId's.
-
Host, Path, and Cookie Name are configured in the CMP by the publisher, and the consent string data is stored as a first-party cookie by the CMP javascript.
The following fields are stored in big-endian format, the binary bits padded at the end with zeroes to the nearest multiple of 8 bits, packed into a string of bytes, and base64url-encoding performed (with '=' padding omitted).
| Publisher Purposes Consent String Field Name | Number of bits (bit offsets) | Value(s) | Notes |
| Version | 6 bits (0-5) | "1" for this version | Incremented when consent string format changes |
| Created | 36 bits (6-41) | Epoch deciseconds when consent string value was first created | Deciseconds fits into 36 bits with enough precision to record a user's consent action timing. Javascript: Math.round((new Date()).getTime()/100) |
| LastUpdated | 36 bits (42-77) | Epoch deciseconds when consent string value was last updated | |
| CmpId | 12 bits (78-89) | Consent Manager Provider ID that last updated the consent string value | A unique ID will be assigned to each Consent Manager Provider |
| CmpVersion | 12 bits (90-101) | Consent Manager Provider version | Each change to the CMP should receive a new version number, for logging proof of consent |
| ConsentScreen | 6 bits (102-107) | Screen number in the CMP where consent was given | The screen number is CMP and CmpVersion specific, and is for logging proof of consent |
| ConsentLanguage | 12 bits (108-119) | Two-letter ISO639-1 language code that CMP asked for consent in | Each letter should be encoded as 6 bits, a=0..z=25 . This will result in the base64url-encoded bytes spelling out the language code (in uppercase). |
| VendorListVersion | 12 bits (120-131) | Version of vendor list used in most recent consent string value update. | The vendor list provides the list of standard purposes, so the version of the vendor list used is recorded. |
| PublisherPurposesVersion | 12 bits (132-143) | Version of publisher purposes list used in most recent consent string value update. | Publishers initialize the CMP with this version, and should increment it for any changes to the list of requested purposes so that consent can be re-obtained. |
| StandardPurposesAllowed | 24 bits (144-167) | For each standard purpose, one bit: 0=No Consent 1=Consent | Standard purposes are listed in the global Vendor List. |
| NumberCustomPurposes | 6 bits (168-173) | The number of custom purposes consent bits. | CustomPurposeIds are numbered 1 to NumberCustomPurposes. Custom purposes will be initialized in the CMP by the publisher. |
| Above fields are multiples of 6 bits to fit into base64url-encoded bytes. | |||
| CustomPurposesBitField | NumberCustomPurposes bits (174-...) | For each custom purpose, one bit: 0=No Consent 1=Consent | The consent value for each CustomPurposeId from 1 to NumberCustomPurposes |
-
2018-03-20 Features added to vendorlist
-
2018-03-22 "Consent Cookie" wording and title changed to "Consent String" in all places not specifically referring to a cookie
-
2018-03-22 legitimate interest purposes supported (per vendor) with legIntPurposeIds
-
2018-03-27 added recommended cookie names for publisher-local cookies
-
2018-04-02 change purposes[].purpose to purposes[].name for consistency
-
2018-04-09 Changed CmpVersion from 6 to 12 bits