After a two-year grace period to allow time for preparation, GDPR finally goes into effect this week. For most enterprises, mapping and remediation of private data storage has been the focus. But now it is time to focus on sustainable operational compliance starting on May 26th and continuing for years into the future.
If you monetize with programmatic ads, we’ll assume that your legal team has made the (very typical) decision that “consent” is the best legal basis for processing data under GDPR. Regardless of which basis you choose, data subjects must be given a clear and understandable explanation of what data you will use, how you’ll protect it, who you will share it with, and how long you’ll keep it. When the user gives his (now “informed”) consent, a transparent, trusting, ongoing relationship is formed – exactly what the authors of the GDPR intended.
Because it can be revoked at any time, and processing must stop when it is, consent must now be easily checkable by both internal company activities, and also by third parties (called “Data Processors” in GDPR lingo) that utilize the data (for example, ad networks). Clearly, “consent” has become a very important new corporate asset.
The Programmatic Problem
The AdTech industry has realized that under GDPR, lack of consent could quickly lead to the end of programmatic ads. Last November, the IAB trade group proposed the Transparency Consent Framework (TCF), an open source consent solution that it believes will allow the ads to keep flowing. Many observers, (including DCN) have criticized it for technical and functional shortcomings.
The purpose of this post is not to dissect the flaws of the IAB TCF. My goal is to make clear that even if it worked properly, the IAB’s solution could never be considered a complete consent solution for a publisher. Its only purpose is allowing programmatic ads to continue to flow.
As this point, you may think “So, what? It will keep my ads running. Why not use a free solution to manage the programmatic ad part of the GDPR consent puzzle?” I submit that consent needs to be handled centrally as a key corporate asset, just like accounting, HR, strategic, and other corporate data.
Here is a real-world example illustrating what will happen when consent is not handled centrally. A mid-sized publisher runs ads (of course) but also offers newsletters, email-based promotions with sign-ups, and an affinity / personalization program with a persistent login.
If the publisher chooses the IAB TCF solution to run ads, they still have no solution for storing or managing user consent to their internal GDPR uses. (This could include email newsletters and affinity programs, but potentially many more. Today’s digital marketing creates a lot of data ingress points).
The publisher chooses a “GDPR compliant” third party email provider that gathers consent and stores it internally (not accessible to publisher). For their affinity system, the publisher creates a basic consent flag system on their internal servers. In theory, the publisher is now covered for GPDR consent.
A Poor Patchwork
In actual practice, this “patchwork” solution is very unpleasant for users. They will be interrupted and asked for their consent for ads the first time they come to the site post-GDPR. They will again be interrupted and asked for consent (by a different vendor and with a different UX) when they join the email list. Then, they will again be interrupted and asked for their consent with a different UX when they join the affinity program.
Because of the disjointed consent strategy (known as “Consent Fragmentation,” the user has been interrupted 3 times for consent, shown 3 different notices, and given their consent using 3 different user interfaces. At a certain point, users will become frustrated with the continual interruptive requests for consent, something the GDPR authors envisioned and referred to as “Consent Fatigue”
It gets worse. Under this patchwork, when a user decides to revoke or modify their consent, their path to success is extremely arduous (the opposite of GDPR’s “easy as giving consent” wording in Article 7).
Since the IAB TCF does not provide any user interactivity, the publisher must use an IAB approved Consent Management Platform (CMP) to provide users with required rights management capability. To modify their ad consent, users must use the CMP dashboard that the publisher has chosen.
To revoke email permissions, the user would have to visit the “unsubscribe” page of the email vendor. Finally, for the loyalty program, they would need to use a “revoke my consent” function from the publisher’s in-house consent manager.
Consent fragmentation is the result of using different “Band-Aid” systems to hold user consent, and there is no positive aspect to it. This situation came about because the publisher did not understand the true importance of consent. No publisher would ever hold separate general accounting ledgers in multiple unconnected silos. It would be a certain recipe for disaster.
This disconnected experience is bad enough for a single site. Now imagine how users will feel if most sites ask their consent three or four times. This is the nightmare scenario that risks the failure of GDPR because users will simply stop giving consent.
I think you can see where this is going. Post GDPR, user consent is a vital corporate data asset, a key gating item for all user interactions. As such, consent must be gathered wherever needed. However, it must stored in a central repository, where is easily accessible to all internal activities, and to a curated group of external partners (email services, analytics, ad partners and downstream ad partners.)
With a single consent repository, users are presented with the experience they expect: one single sign-on dashboard. It will provide them with an accurate and easy to understand notice of the uses of their private data, easy access to exercise their rights, the ability to selectively opt-in or out of each of the services used by the publisher, and a secure point of access for SAR and breach notification. The solution must be an easy to use, single sign-on privacy management is evidence of “Privacy by Design,” as envisioned by the authors of GDPR.