In this article and video, IAB Europe's Matthias Matthiesen discusses how brands and publishers can first gain, then manage GDPR-compliant consent for digital advertising.
Filmed live at Conversant's GDPR Summit, Privacy By Design, Matthias' succinctly breaks down the complexities of consent under the GDPR. Watch all eight on-demand live talks from Conversant's GDPR summit to
Click for sound
0:00
0:53
Firstly, let’s get something straight: consent is not king. There are six co-equal legal bases for processing personal data, of which consent is just one.
Sometimes, consent is not even needed – if you find a more appropriate legal ground for processing, then that is fine. If you are attempting to save the life of the legal subject, for instance, then that would be acceptable.
However, in many cases consent is required – it is not optional – and this particularly holds true when considering the ePrivacy Directive (ePD), popularly known as the ‘Cookie Law’.
Now, the ePD says that for the storing or accessing of information already stored on the terminal equipment of an end user, you require consent – unless it is strictly technically necessary to carry out a communication.
For examples of technically necessary communications, think of client server communications or where it’s strictly necessary for the service that you're providing to the user, and that the user has requested to function - a web shop for example, which requires a cookie to remember what you put in the shopping basket, so you can buy it later.
Consent is required for advertising
Unfortunate as it may be for us as an industry, advertising is very unlikely to be necessary for the service that the user is requesting to function.
You are physically able to use an app, or read the news without ads, for example. Therefore, cookies or other identifiers that fall under the scope of this will have to be used on the basis of consent.
It’s important to note that while the ePD exists today, it currently relies upon each country’s individual legal definition for collecting consent. While there has been some harmonisation so far, implementation has been quite different between countries – in some, a user can give consent by failing to say no, while in others you need a prior affirmative act.
In short, depending on which country you’re looking at, to apply the ePD you have very different qualities of consent. But, come May 25th, the GDPR replaces all of these different data protection laws and the definitions of consent embedded within them.
But the GDPR and the ePD are not one and the same – the ePD will point to the GDPR to define what type of consent is needed, but it has a somewhat different scope. Collection of data from a user device generally requires consent under the ePD, while the processing of personal data requires a legal basis – consent, or legitimate interest for example – under the GDPR.
To summarise, consent is not always necessary. But for advertising, it’s required.
The three key obligations to consent
Transparency is a key principle under the GDPR, and it’s very important in what it changes under consent. Instead of informing a user that we’re sharing data with vaguely defined categories of controllers, we’ll actually have to say who we’re sharing that data with, or who is relying on the consent to process that data so that the data subject can know where to exercise their rights.
In the advertising industry, that’s a pretty big challenge when often we don’t know who’s going to be transacting on some data. For example, who’s going to win the programmatic bid, and who do you disclose ahead of time?
Where I am not the entity requesting and obtaining consent, how could I prove that the user on whose consent I am relying to do something, has actually given that consent?
That’s a challenge where we need to create communication channels that haven’t existed before.
Firstly, where a publisher, advertiser or any other entity that obtains consent on behalf of a third party can tell their third-party partners that they have disclosed them – that the third party can be sure that the transparency has been provided.
Secondly, the consent-obtaining entity needs to be able to tell their third-party partners: “I have obtained consent, and I am letting you know of that fact.”
The quality of consent can vary because of the action required. For example, currently the majority of ‘cookie banners’ assume consent if a user ignores them.
In the future, to prove consent will require an affirmative act. Moreover, you need to make it as easy to withdraw that consent as it was to originally give it.
The Transparency and Consent Framework
Putting all three of these obligations together creates a difficult cocktail to deal with.
Before we process anything on the basis of consent, we need to know the user is okay with it, rather than assume that the user is okay with it. You need a signal coming from whoever obtains consent going to the third-party, so that the third-party knows what to do.
We also need to be able to provide ways for the consent obtaining entity to make disclosures about the third-party partners. But that presents further complications – what happens when a privacy policy is updated, for instance? All disclosures for that third party would need updating.
Introducing the Transparency and Consent Framework.
Key within the Transparency and Consent Framework is the Global Vendor List – it’s really the cornerstone of the entire framework, and it directly solves the transparency requirement, while leading into the remaining two requirements, accountability and control.
It allows publishers or advertisers to look at the entire pool of third-parties that have signed up to the framework, find the most up-to-date disclosures, and display those to their users. If the privacy policy URL changes, the disclosure will update as well.
When an ad-tech vendor joins the Transparency and Consent Framework, they receive an ID. This ID is the key to understand the technical signals needed for the framework to operate.
When a publisher or advertisers obtains consent – or doesn’t obtain consent – they need to let their downstream third-party partners know. This is achieved through the ID, which maps to a technical signal that can be passed on through the entire ecosystem. That signal can then be unpacked and understood before a third-party partner makes a decision to process data.
What does this look like to the user?
So far, I’ve discussed how the framework collects and processes consent between the different parties that, come May 25th will need consent from end users. But how will this look and operate for the end user?
The Transparency and Consent Framework will operate behind the scenes, while IAB EU approved Consent Management Providers (CMPs) will handle displaying to a user the relevant disclosures and making use of the Global Vendor List to inform users about the purpose of the processing, based on standardised language and purposes.
Importantly, the CMPs will record the consent choices of the user, before sending that on via the framework.