TCF v2: new features, constraints and… questions

Align all parties in the digital advertising industry with the same method for collecting and transmitting consent. Such is the objective of the Transparency Consent Framework. The new version of the “TCF” promises greater flexibility for professionals and more transparency for users. But has it kept its promises?

So here we are. After being repeatedly pushed back down the calendar, version 1 of the Transparency Consent Framework (TCF) will finally be replaced by version 2 on 30 September. Defined by the IAB, the TCF is designed to standardise the collection and transmission of consent information throughout the digital advertising supply chain. Everyone is concerned, whether publishers, advertisers or obviously ad tech professionals. When it comes to publishers, complying with the TCF (failing which they will be unable to declare their inventory) involves implementing a Consent Management Platform (CMP) that complies with version 2 of the TCF and is recognised as such by the IAB.

Why release version 2 of the TCF? The first part of the answer lies in the stated new features. At least three are worthy of a mention:

• 1) The number of purposes has been increased from 5 to 12 (without counting a few special features). The aim is to ensure greater flexibility and precision when defining the purpose for collecting data. Note that purposes can be stacked together when communicated to the user. Generally speaking, TCF v2 provides publishers with more granular control over their settings. For each purpose and each partner, publishers can restrict the authorised data processing operations.

• 2) This version of the TCF introduces the concept of legitimate interest. This means that a publisher can, by default and for certain purposes, define consent as being approved where its legitimate interest is the legal basis. If users object, that information is passed along the entire chain. The lack of consideration for legitimate interest was believed to be one of the main shortfalls in the first version of the TCF.

• 3) Since the TCF is designed to provide users with transparent management of their consent as well as global and fine-grained control of the authorisations given, it offers a highly precise specification for the consent process. Combined purposes (those famous stacks) can be displayed on the first screen, detailed purposes on the second, and the list of vendors on the third. Although there is no requirement to add a “Reject all” button on the first page, the IAB strongly recommends using a symmetrical set of options, such as a balance between “Accept all” and “Customise choices”. In this respect, the IAB intends to align with the recommendations issued by the national data protection authorities (CNIL in France).

The headline with TCF v2 is that it has been adopted by Google.

 Those are the main new features highlighted by the IAB. But we should not overlook the other big news with TCF v2, namely that it has been adopted by Google, which was involved in its development. This was not the case with the first version. In other words, TCF v1 looked like one of those acts that go unheeded when there are no regulations to implement them… It is hard to standardise a contract without support from the main party.

Would we now be right in thinking that the situation has changed for the better? That dialogue about consent between professionals in the digital advertising industry is now more streamlined? Not exactly, and there are several reasons why.

When it comes to implementing TCF v2, the devil is in the details

First of all, although Google has given TCF v2 its blessing, as is often the case, the devil is in the details. To work with Google, publishers not only have to use a CMP that conforms to the new TCF, but they also need to be mindful of several other points. For example, if consent is not granted for purpose 1 (data storage on the device), adverts may not be disseminated via Google. There are also potential contradictions between the restrictions applied by a publisher about the purposes and Google’s requirements. This is compounded by Google’s implementation of the TCF, which is generating errors and causing debate.

Publishers are far from celebrating. First of all, the deadlines associated with TCF 2.0 – which is not backwardly compatible with v1 – have put teams under pressure, especially during the summer season. These deadlines are sometimes considered to be ill-suited to a technical specification that is seen as overly complex. 

TCF v2: clearer consent for the general public?

Another source of complaints is the user experience. The IAB has gone very far indeed in its specifications, since even the texts that need to be displayed on the different levels of the interface have been authored in different languages. These texts may require iterations, which will need to be submitted to the IAB and may take time. Above all, the UX specified in the TCF is not always easy to reconcile with the work that publishers have been doing on their side. 

But THE question remains: if the digital advertising industry has everything to win by aligning with a single protocol for collecting and transmitting consent, despite the difficulties surrounding its implementation, how do users stand to benefit? In other words, does the experience gained from implementing TCF v2 – which can currently be seen at work with the renewed consent screens – make it easier for the general public to understand the choices on offer? Answers should start coming through in a few months when we see statistics on visitor numbers to the Preferences Centre…

To implement TCF v2, choose the TrustCommander CMP approved by the IAB.