Last year when I was first reading over TCF 2.0 specs, I came across a new item: “Flexible Purpose.” It was defined as follows:
Flexible – A combination of both consent and legitimate interest to allow vendors to operate in different markets under different legal basis.
At the time, I didn’t quite understand what it meant, plus the phrase “under different legal basis” made me think that it probably didn’t apply to us. After doing more research and conferring with internal team members, not only did I realize that it did apply to us as an ad tech vendor, but that it also provided flexibility to our implementation of TCF 2.0, to publishers transacting on our exchange, and ultimately to their consumers; TCF 2.0 is truly flexible.
Let me explain…a legal team at an ad tech vendor may determine that they have legitimate interest to track purpose, say #7. That is, the ad tech company does not need to check for user consent when measuring ad performance, which happens to be purpose ID 7. This is fine, as long as the firm can back it up from a legal point of view. However, a publisher working with said vendor (in this case a 3rd party vendor) may want them to still check for consent for users browsing the publisher’s website, even though the 3rd party vendor’s policy states they have legal basis to use legitimate interest.
Clearly, there is a difference in policies which can jeopardize the relationship between the two entities. Either one of the entities forces the other to comply with them (which would translate into making policy changes and costly code changes to the technical implementation of TCF 2.0), or they both walk away from the relationship.
Enter Flexible Purposes.
Flexible Purposes act as a proxy for resolving these differences. When vendors implement purposes as “flexible” and default to legitimate interest, they are basically saying to the publisher, “for this particular request and for purpose ID 7, we’re not looking for consent unless you ask us to.” This allows vendors to check for consent (or not) based on publishers’ requirements in real-time for every single GDPR-applicable request received from the publisher. In other words, it prevents the vendor from having to make permanent code changes to always check for consent.
On the flip side, publishers also benefit from this because they may have different policies on different markets. For example, a publisher may be okay with a 3rd party vendor not checking for consent on their end in some geographical areas, but not in others. And this can only be possible via a flexible purpose.
In the end, this is all working toward better consumer choices as publishers can tailor TCF implementations to specific markets.
Although not perfect, I think this new version of TCF made some great improvements and I think it is here to stay. Consumers are getting more savvy about the value of the data they generate and are demanding more choices and transparency. We encourage all of our publishers and ad tech partners to embrace the framework and keep providing feedback in order to improve it even further.