This is how the Transparency & Consent String (TC String) of the IAB Transparency and Consent Framework works

GDPR regulations have created an extra administrative burden for digital publishers, advertisers and technology providers. To support the digital advertising ecosystem and to comply with guidelines such as the GDPR and the planned ePrivacy Ordinance, the Interactive Advertising Bureau (IAB) launched the Transparency and Consent Framework in 2018 – a consent interface for consumers, publishers and advertisers.

In the field of digital advertising, many technologies are interwoven – of both advertisers and publishers. Many of the interlinked platforms use the collected data of website visitors to customize the advertising experience. Yet in order to do so, user consent must be collected. After user consent has been requested by a Consent Management Platform (CMP), it is necessary to ensure that publishers, advertisers and each of the connected technology platforms respect the user’s wishes. Therefore, the IAB TC String, which is a coded character string containing all relevant information about the user’s consent, is used for this reason and is passed on to all parties. In this way it serves as a means of communication within the IAB Framework.

• Metadata concerning the consent (version of the TC String, last update, version of the provider list, etc.)
• The purpose for which the providers may use the data.
• Which providers have received the user’s consent.

The last two points are especially relevant for the shopping chain.

• Storage of information
• Personalization
• Measurement
• Selection, delivery and report of advertising media
• Content selection, delivery and reporting

The IAB functions through a list of all global technology providers in digital marketing who are registered in the Transparency and Consent Framework. The TC String contains the providers involved in the respective purchasing chain and indicates whether they are allowed to use the user’s data. This information is stored in binary-code: “1” stands for existing Consent, “0” stands for rejection.

Decoded, all information is hidden behind a sequence of ones and zeros, which show for which purposes and which providers the user has given his or her consent. All of this information is then encoded in a character string by the Consent Management Platform. For example, the result looks like this:

BOSSotLOSSotLAPABAENBc-AAAAgR7

Through the help of the CMP, the TC String is forwarded from the publisher’s side to all technology providers in the value chain up to the demand side platform. Thereby the respective consent-status is openly visible for all participants of the chain. However, the data usage of the other participants cannot be viewed.

The information stored in the Consent String is locally stored in a first-party cookie on the user’s device after the Consent query. 

When the user re-enters the website, a Java script installed by the CMP reads the cookie and passes on the information to the technology providers in the value chain. However, if the user or the browser involved deleted the cookies since the last website visit, then the consent request must be repeated. 

In order to ensure that a content string is legitimate and that publishers do not pass on modified consent information to their technology providers, the consent string is also stored in the form of a cookie on a domain of the CMP

Each and every CMP registered with the IAB receives its own subdomain under mgr.consensu.org, e.g. usercentrics.mgr.consensu.org. The CMP sets a cookie here as soon as a Consent String has been created. This allows tech vendors to check at any time whether a particular Consent String can be found in a cookie in the CMP subdomain making it valid. 

However, despite this safeguarding, fraudulent methods still exist in Consent Management. 

These usually take place where the Consent String is created: on the publisher’s side. You can’t necessarily blame the CMP for this, because the publisher is able to modify the user consent banners of each CMP provider.

Whether intentionally or due to technical errors, what can happen is that the Consent String is already falsified during the consent request. For example, a recent study has found that 12 percent of the more than 1,400 websites examined, have already created the data usage purposes in the content string before the user has made a selection. On 7.5 percent of the 508 websites examined, purposes of use were even permitted via Consent String, even though the user had clearly given his opt-out.

The IAB has taken an important step towards greater autonomy over users’ personal data with the Transparency and Consent Framework. However, there are still gaps in the Framework that make fraud possible. This does not exclude the TC String. However, the TC String does provide the possibility of a central “point of proof” for consent management along the entire value chain. 

Key takeaways:

• The TC String is a coded character string that contains all relevant information concerning the user’s consent decision.
• The TC String receives information regarding which providers have received the User Consent and for what purpose they are allowed to use the User’s data.
• It is generated by the CMP and forwarded to all providers in the advertising value chain. The information in TC String is stored locally on the computer as a cookie. At the same time, a cookie is then created on an exclusive domain of the CMP at the IAB, enabling parties to verify the authenticity of the Consent String. 
• However, the system is not safe from fraud. It is already possible  during the production of the string, to make changes that do not correspond to the will of the user.