Posts

Risks in IAB Europe’s proposed consent mechanism

This note examines the recently published IAB “transparency and consent” proposal. Major flaws render the system unworkable. The real issue is what should be done with the vast majority of the audience who will not give consent. 

Publishers would have no control (and are expected to blindly trust 2,000+ adtech companies)

The adtech companies[1] who drafted the IAB Europe proposal claim that “publishers have full control over who they partner with, who they disclose to their users and who they obtain consent for.”[2] But the IAB Europe documentation shows that adtech companies would remain entirely free to trade the personal data with their business partners if they wish. The proposed system would share a unique[3] consent record “throughout the online advertising ecosystem”, every time an ad is loaded on a website:[4]

“the OpenRTB request [from a website to an ad exchange] will contain the entire DaisyBit [a persistent cookie],[5] allowing a vendor to see which other vendors are an approved vendor or a publisher and whether they have obtained consent (and for which purposes) and which have not.”[6]

There would be no control over what happens to personal data once they enter the RTB system: “[adtech] vendors may choose not to pass bid requests containing personal data to other vendors who do not have consent”.[7] This is a critical problem, because the overriding commercial incentive for many of the companies involved is to share as many data with as many partners as possible, and to share it with parent companies that run data brokerages. In addition, publishers are expected to trust that JavaScript in “ad creatives” is not dropping trackers, even though no tools to police this are proposed here.
IAB Europe is asking publishers and brands to expose themselves to the legal risk of routinely sharing these personal data with several thousand adtech companies. What publishers and brands need is a “trust no one” approach. IAB Europe is proposing a “trust everyone” approach. Indeed, the proposed system looks like the GDPR’s description of a data breach:

“a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.[8]

Publishers have no control over personal data once they send them into the RTB system. All publishers have is liability.

“OK to everything” jeopardises the publisher’s own opt-ins

The proposed system would also jeopardise the chance of websites obtaining essential opt-ins for their own data processing purposes, such as commenting widgets, video players. IAB Europe proposes that websites bundle all consent under a single “OK”/”Accept all” button. Our wireframe below shows the text and buttons recommended by IAB Europe.[9]

Broadly speaking, websites might expect to receive consent from four out of every five of users for their own data processing.[10] Whereas the opt-in rate for ad tech tracking is tiny in comparison. Our research found that only 3% of people say they would opt in to 3rd parties tracking them across the web for the purposes of advertising.[11] IAB Europe’s commissioned research found that only 20% would do so.[12] The ad tech vendors who drafted the IAB Europe proposal have an incentive to ask publishers to take risk on their behalf: they must realize that there is no chance that Internet users will agree to the cascade of opt-ins that the GDPR requires.[13] A website would be ill advised to jeopardise its own consent requests in a vain effort to get consent for ad tech companies, particularly if those ad tech companies plan to use that same consent to work with the website’s competitors.

Conflation and other matters of presentation

The proposal appears to breach Article 5, Article 6, and Article 13 of the GDPR, for several reasons.
First, Article 5 requires that consent be requested in a granular manner for “specified, explicit” purposes.[14] Instead, IAB Europe’s proposed design bundles together a host of separate data processing purposes under a single opt-in. A user must click the “Manage use of your Data” button in order to view four slightly less general opt-ins, and the companies[15] requesting consent. These opt-ins also appear to breach Article 5, because they too conflate multiple data processing purposes into a very small number of ill defined consent requests. For example, a large array of separate ad tech consent requests[16] are bundled together in a single “advertising personalisation” opt-in.[17] European regulators explicitly warned against conflating purposes:

“If the controller has conflated several purposes for processing and has not attempted to seek separate consent for each purpose, there is a lack of freedom. This granularity is closely related to the need of consent to be specific …. When data processing is done in pursuit of several purposes, the solution to comply with the conditions for valid consent lies in granularity, i.e. the separation of these purposes and obtaining consent for each purpose.”[18]

Second, the text that IAB Europe proposes publishers display for the “advertising personalisation” opt-in appears to severely breach of Article 6[19] and Article 13[20] of the GDPR. In a single 49 word sentence, the text conflates several distinct purposes, and gives virtually no indication of what will be done with the reader’s personal data.

“Advertising personalisation allow processing of a user’s data to provide and inform personalised advertising (including delivery, measurement, and reporting) based on a user’s preferences or interests known or inferred from data collected across multiple sites, apps, or devices; and/or accessing or storing information on devices for that purpose.”[21]

This fails to disclose that hundreds, and perhaps thousands, of companies will be sent your personal data. Nor does it say that some of these companies will combine these with a profile they already have built about you. Nor are you told that this profile includes things like your income bracket, age and gender, habits, social media influence, ethnicity, sexual orientation, religion, political leaning, etc. Nor do you know whether or not some of these companies will sell their data about you to other companies, perhaps for online marketing, credit scoring, insurance companies, background checking services, and law enforcement.
Third, a person must say yes or no for all or none of the companies listed as data controllers.[22] Since one should not be expected to trust all controllers equally, and since it is unlikely that all controllers apply equal safeguards of personal data, we suspect that this “take it or leave it” choice will not satisfy regulatory authorities.
Fourth, there appears to be no way to easily refuse to opt-in to the consent request that IAB Europe proposes, which would also breach the GDPR.[23] It is possible that this last point is simply an accidental oversight in the drafting of IAB Europe’s documentation.

Conclusion: What about the people (80%-97%) who don’t opt-in?

The proposed system has no plan to make consent meaningful, by giving publishers and data subjects control over what happens to personal data. Nor does it have a plan for what happens when users do not give consent. It is time for the discussion to move on.
As the CEO of a Digital Content Next, a major publisher trade body, recent told members, “GDPR will create opportunity for audience selection based on cohorts and context”.[24] Non-personal data such as these are the only way for the industry to approach the GDPR.
PageFair has recently announced Perimeter, a regulatory firewall that enables websites (and apps) protect their ad business, running direct campaigns and use RTB without risk under the GDPR. It prevents unauthorized connections from 3rd parties, so that personal data can not leak through the RTB system, or anywhere else. (For extra peace of mind, PageFair’s SSP delivers guaranteed compliant programmatic display advertising). This is the consent-free approach.
We also believe that consent has a role. The next chapter for online advertising will be written by publishers who use consent-free RTB, and build up consenting audiences for premium advertising too.
Note: thanks to Andrew Shaw at PageFair. 


[x_alert heading=”Feedback Wanted” type=”success” close=”true”]Note: PageFair has just updated its online overview of Perimeter. Please review http://pagefair.com/perimeter and give us your feedback.[/x_alert]

Perimeter is a robust regulatory firewall. It preemptively blocks unauthorized requests from 3rd parties, and tightly controls personal data on your website and app. It protects you, your advertising business, and your users. Perimeter makes sure that consent means something.

[x_button shape=”rounded” size=”regular” float=”none” href=”https://pagefair.com/perimeter” info=”none” info_place=”top” info_trigger=”hover”]Learn more[/x_button]

Notes

[1] AppNexus Inc.; Conversant, LLC; DMG Media Limited; Index Exchange, Inc.; MediaMath, Inc.; Oath, Inc.; Quantcast Corp.; and, Sizmek, Inc. are named in the copyright notice of “Transparency & Consent Framework, Cookie and Vendor List Format, Draft for Public Comment, v1.a”, IAB Europe (URL: URL-shortened), p. 3.
Note: PageFair is a member of IAB TechLab, and IAB UK.
[2] “Transparency & Consent Framework FAQ”, IAB Europe, 8 March 2018 (URL: http://advertisingconsent.eu/wp-content/uploads/2018/03/Transparency_Consent_Framework_FAQ_Formatted_v1_8-March-2018.pdf), p. 8.
[3] Our statistical examination of the data in the cookie showed a very high degree of uniqueness. The proposed cookie is itself a tracking cookie. See the specification of the cookie in “Transparency & Consent Framework, Cookie and Vendor List Format, Draft for Public Comment, v1.a”, IAB Europe, pp 8 – 10.
[4] ibid., p. 3
[5] ibid., p. 8.
To see the content of the proposed consent cookie, see http://gdpr-demo.labs.quantcast.com/user-examples/cookie-workshop.html.
It is envisaged that the record may be server-based in the future, because this will work better. See p. 7.
[6] “Transparency & Consent Framework FAQ”, IAB Europe, 8 March 2018, p. 9.
[7] ibid., p. 10. And from the same page, when an adtech company gets personal data without consent, IAB Europe asks it “to only act upon that data if it has another applicable legal basis for doing so”.
[8] Regulation (EU) 2016/679 of The European Parliament and of The Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), Article 4, paragraph 12.
[9] “Transparency & Consent Framework FAQ”, IAB Europe, 8 March 2018, p. 13.
[10] 20% would accept first party tracking only. An additional 56% would accept tracking that is strictly necessary for services they have requested. 5% say they would accept all tracking.
See “Research result: what percentage will consent to tracking for advertising?”, PageFair Insider, 12 September 2017 (URL: https://pagefair.com/blog/2017/new-research-how-many-consent-to-tracking/).
[11] ibid.
[12] “Europe Online: an experience driven by advertising”, GFK, 2017, p. 7. (URL: https://www.iabeurope.eu/wp-content/uploads/2017/09/EuropeOnline_FINAL.pdf).
[13] “GDPR consent design: how granular must adtech opt-ins be?”, PageFair Insider, January 2018 (URL: https://pagefair.com/blog/2018/granular-gdpr-consent/).
[14] The GDPR, Article 5, paragraph 1, b, and note reference to the principle of “purpose limitation”. See also Recital 43. For more on the purpose limitation principle see “Opinion 03/2013 on purpose limitation”, Article 29 Working Party, 2 April 2013.
[15] Note that the Article 29 Working Party very recently warned that this alone might be enough to render consent invalid: “when the identity of the controller or the purpose of the processing is not apparent from the first information layer of the layered privacy notice (and are located in further sub-layers), it will be difficult for the data controller to demonstrate that the data subject has given informed consent, unless the data controller can show that the data subject in question accessed that information prior to giving consent”.
Quote from “Guidelines on consent under Regulation 2016/679”, WP259, Article 29 Working Party, 28 November 2017 (URL: https://pagefair.com/wp-content/uploads/2017/12/wp259_enpdf.pdf), p. 15, footnote 39.
[16] See discussion of data processing purposes in online behavioural advertising, and the degree of granularity required in consent, in “GDPR consent design: how granular must adtech opt-ins be?”, PageFair Insider, January 2018 (URL: https://pagefair.com/blog/2018/granular-gdpr-consent/).
[17] “Transparency & Consent Framework FAQ”, IAB Europe, 8 March 2018, p. 18.
[18] “Guidelines on consent under Regulation 2016/679”, WP259, Article 29 Working Party, 28 November 2017, p. 11.
[19] The GDPR, Article 6, paragraph 1, a.
[20] The GDPR, Article 13, paragraph 2, f, and Recital 60.
[21] “Transparency & Consent Framework FAQ”, IAB Europe, 8 March 2018, p. 18.
[22] “Transparency & Consent Framework, Cookie and Vendor List Format, Draft for Public Comment, v1.a”, IAB Europe, p. 5.
This is apparently “due to concerns of payload size and negatively impacting the consumer experience, a per-vendor AND per-purpose option is not available”, p. 22.
[23] The Regulation is clear that “consent should not be regarded as freely given if the data subject has no genuine or free choice”. The GDPR, Recital 42. See also, Article 4, paragraph 11.
[24] Jason Kint, “Why the IAB GDPR Transparency and Consent Framework is a non-starter for publishers”, Digital Content Next, 19 March 2018 (URL: https://digitalcontentnext.org/blog/2018/03/19/iab-gdpr-consent-framework-non-starter-publishers/)

PageFair writes to all EU Member States about the ePrivacy Regulation

This week PageFair wrote to the permanent representatives of all Member States of the European Union in support for the proposed ePrivacy Regulation.
Our remarks were tightly bounded by our expertise in online advertising technology. We do not have an opinion on how the proposed Regulation will impact other areas.
The letter addresses four issues:

  1. PageFair supports the ePrivacy Regulation as a positive contribution to online advertising, provided a minor amendment is made to paragraph 1 of Article 8.
  2. We propose an amendment to Article 8 to allow privacy-by-design advertising. This is because the current drafting of Article 8 will prevent websites from displaying privacy-by-design advertising.
  3. We particularly support the Parliament’s 96th and 99th amendments. These are essential to enable standard Internet Protocol connections to be made in many useful contexts that do not impact of privacy.
  4. We show that tracking is not necessary for the online advertising & media industry to thrive. As we note in the letter, behavioural online advertising currently accounts for only a quarter of European publishers’ gross revenue.

[x_button shape=”rounded” size=”regular” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/03/PageFair-letter-on-ePrivacy-to-perm-reps-13-March-2018.pdf” info=”none” info_place=”top” info_trigger=”hover”]Read the letter [/x_button]

The digital economy requires a foundation of trust to enable innovation and growth. The enormous growth of adblocking (to 615 million active devices) across the globe proves the terrible cost of not regulating. We are witnessing the collapse of the mechanism by which audiences support the majority of online news reports, entertainment videos, cartoons, blogs, and cat videos that make the Web so valuable and interesting. Self-regulation, lax data protection and enforcement have resulted in business practices that promise a bleak future for European digital publishers.
Therefore, we commend the Commission and Parliament’s work thus far, and wish the Council (of Ministers of the Member States) well in their deliberations.

Adtech must change to protect publishers under the GDPR (IAPP podcast)

The follow up to the International Association of Privacy Professionals’ most listened to podcast of 2017. 
Angelique Carson of the International Association of Privacy Professionals quizzes PageFair’s Dr Johnny Ryan on the crisis facing publishers, as they grapple with adtech vendors and attendant risks ahead of the GDPR. The podcast covers:

  • Why personal data can not be used without risk in the RTB/programmatic system under the GDPR.
  • Where consent falls short for publishers.
  • How vulnerable the online advertising system is, because of central points of legal failure.
  • The GDPR is part of a global trend. New privacy standards are on the way in other massive markets including China (and in important tech ecosystems such as Apple iOS, Firefox).

This is the follow up to an earlier IAPP and PageFair podcast discussion (which was the International Association of Privacy Professionals’ most listened to podcast of 2017).

[x_button shape=”rounded” size=”regular” float=”none” href=”https://iapp.org/news/a/the-privacy-advisor-podcast-johnny-ryan-on-the-continuing-crisis-ad-tech-faces/” info=”none” info_place=”top” info_trigger=”hover”]Listen at IAPP[/x_button]

[x_button shape=”rounded” size=”regular” float=”none” href=”https://itunes.apple.com/us/podcast/the-privacy-advisor-podcast/id1095382766?mt=2#” info=”none” info_place=”top” info_trigger=”hover”]Listen on iTunes[/x_button]

Click here to view PageFair’s explainers and official documents about the changes websites and apps must make under the new privacy rules. Elsewhere you can find details about Perimeter, PageFair’s GDPR solution for publishers.
[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]

PageFair Trusted Partners To Join GDPR Compliance Initiative

This note announces an initiative among adtech companies to keep online advertising operations outside the scope of the GDPR by using no personal data.
Dublin, Ireland (24 January, 2018) – PageFair has announced a joint initiative with eight other advertising companies to help equip website and app publishers with new ways of advertising  that fully comply with Europe’s new GDPR regulations.  Among the members are Adzerk, Bannerflow, Bydmath, Clearcode, Converge Digital, Digitize, SegmentIQ, and Velocidi.  The EU’s new privacy regulations will prohibit the kind of online tracking that has powered advertising up to now, unless every user gives explicit consent to the companies that track them. Publishers, advertisers and tech companies who ignore the regulation could face fines of up to €20 million or 4% of their global turnover.  According to PageFair, a growing number of ad tech companies are realising that tracking individual users is a convenience they can live without, and are preparing tracking-free versions of their products for the European market.
In December, PageFair announced a related product called “Perimeter”, which acts as a regulatory firewall for websites and apps, blocking potential tracking by default, while whitelisting approved “Trusted Partners”. PageFair CEO Sean Blanchfield said “This initial group is just a small sample of the companies who are committed to rewiring the advertising supply chain to work without personal data. Together, we have already designed alternative ways to provide advertisers with frequency capping, measurement and targeting, all without tracking individuals. We look forward to welcoming new members to our initiative, more privacy innovation, and to whitelisting all GDPR-compliant partners by default in the PageFair Perimeter platform”.
PageFair’s zero-tracking strategy contrasts with many other advertising technology companies, who are focusing on obtaining consent from each of Europe’s 512 million consumers, or who are hoping for leniency in how the law will be enforced. According to Blanchfield, “Consent has a role to play, but we already know that it will be hard-won and easily lost, and that the majority of online media revenue in Europe now depends on finding ways advertise without depending on personal data in the first place. Anyone who thinks that it’s business-as-usual this Summer will find that leniency is even harder to come by than consent.”
James Avery, CEO of Adzerk, said “What Adzerk is doing with PageFair means that advertisers will now be able to run digital ads safely, free from the large legals risks introduced by the GDPR”.
Nicholas Höglund, CEO of Bannerflow, said “At Bannerflow we’re committed to delivering a non-personal data solution for our clients and respecting the privacy of EU citizens. Serving millions of ads every week, this is core for us. We are working hard to develop a platform that can deliver valuable insight without any need to track individuals.”
Maciej Zawadziński, CEO of Clearcode, said “Clearcode views PageFair’s Perimeter as a  much-needed solution for publishers to comply with the GDPR and end to the out-of-control data collection processes in the current AdTech ecosystem. As a Perimeter Trusted Partner, Clearcode is committed to helping AdTech vendors and publishers become whitelisted by PageFair’s Perimeter and comply with other areas of the GDPR through our custom AdTech development services”.
David Dunne, CEO of Velocidi, said “GDPR is forcing brands, agencies and publishers to take greater control of their data. PageFair has created an ingenious way to facilitate GDPR compliance. Perimeter helps publishers manage data without leaving compliance entirely up to consumer consent”.
Publishers, advertisers and technology companies who want to find out more about Perimeter, or how to get involved can do so on http://pagefair.com/perimeter
https://adzerk.com
https://www.bannerflow.com
https://www.bydmath.com
https://clearcode.cc
http://converge-digital.com
http://www.digitize.ie
http://segmentiq.com
https://www.velocidi.com
 

Further detail

1. Perimeter integrates with websites and apps, and acts as a regulatory firewall. It blocks all 3rd party personal data access. No unique IDs are allowed, or any other personal data, unless adequate consent has been given. This puts the publisher and their advertisers in a zero risk position because they are processing no personal data.
2. Adtech partners can be automatically whitelisted by Perimeter, provided they use no unique IDs or any other personal data unless adequate consent has been given.
3. Perimeter Trusted Partners can include SSPs, ad servers, analytics, DMPs, DSPs, SDKs in mobile, etc., provided they do not expose the publisher and advertiser to risk under the GDPR by using unique IDs or any other personal data unless adequate consent has been given.
4. PageFair is sharing know how about to perform adtech functions without personal data. (For example, RTB bid requests based on non-personal segments, frequency capping using campaign IDs rather than unique IDs, etc.)
5. Avoiding the use of personal data means that there is no consent required for the processing of personal data. This is ultra privacy-by-design adtech places publishers, advertisers, and Perimeter Trusted Partners outside the scope of the GDPR.
6. If the publisher does seek and get appropriate consent, then Perimeter system will permit personal data to be processed.
7. What this means for publishers and buyers is that they can sell and buy online advertising in direct sold campaigns and in programmatic without any risk under the GDPR. This is the start of a clean data adtech stack.
 
***
 

Media Contact

Dr Johnny Ryan
press@pagefair.com
[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]

How to audit your adtech vendors' GDPR readiness (and a call to adtech vendors to get whitelisted as Trusted Partners)

This note describes how publishers can audit their adtech vendors’ readiness for the GDPR, and opens with a call for adtech vendors to collaborate with PageFair so that they can be whitelisted as Trusted Partners by PageFair Perimeter. 

How adtech and media will work under the GDPR

We anticipate that the GDPR will indeed be enforced, whether by national regulators or by NGOs or individuals in the courts. We also realise that consent is the only applicable legal basis for online behavioural advertising (See analysis). Personal data can not be processed for OBA in the absence of consent.

However, consent dialogues for adtech need a “next” button -or a very long scroll bar- because online behavioural advertising requires many different opt-ins to accommodate many distinct personal data processing purposes.  How many people will click OK 10+ times? (See analysis).

Even people do repeatedly opt-in for various adtech processing purposes, that consent will be inconsequential if there is continued widespread leakage of personal data through RTB bid requests, JavaScript in ads, mobile SDKs, and assets loaded from 3rd parties. Consent only has meaning if one prevents the personal data from falling into the hands of parties that do not have consent (See discussion).

Therefore, it is essential to plan for the eventuality that very few, if any, people will provide the ten or more opt-ins required to cover the diverse range of data processing purposes conducted by today’s online behavioral advertising ecosystem.

The only way to remove all risk of fines and legal suits for publishers, advertisers, and adtech vendors, is to use no personal data at all, unless one has consent. This would put routine advertising outside the scope of the GDPR, with no controllers, processors, nor personal data breaches.

PageFair Perimeter is working with a group of adtech vendors who can provide publishers with direct and programmatic adtech that uses only non-personal data (See footnote for a discussion of non-personal data).[1] Aside from non-personal cookie storage, there will be no need to seek consent because there will be no processing of personal data. 

In the minority of cases where valid consent is present, the corresponding vendors will be free to add incremental value by consensually using personal data.

Perimeter will block all 3rd parties that process personal data on its client publishers’ websites and apps, unless consent is present. Trusted Partner adtech vendors, who can operate programmatic and direct advertising without personal data, will be whitelisted (and promoted to publishers).

This note proceeds with two sections. The first describes Trusted Partner adtech vendors. The second outlines what questions publishers should ask their adtech vendors to audit their use of personal data and GDPR-readiness.

PageFair is calling for “Trusted Partner” Adtech vendors

PageFair is working with a group of adtech vendors who can provide publishers with direct and programmatic adtech that uses only non-personal data. (see footnote for a discussion of non-personal data). And of course, if appropriate consent is present, then these adtech vendors can process personal data.

Subject to verification that personal data is not processed without consent, PageFair Perimeter will whitelist Trusted Partners’ technology, while continuing to block all other 3rd parties.

We invite adtech vendors to work with us as Trusted Partners. Trusted Partners provide versions of their services that scrupulously prevent the collection or other processing of Personal Data, except where suitable consent has been obtained from the data subject and data protection requirements have been satisfied in a manner consistent with the GDPR.

[x_button shape=”rounded” size=”regular” float=”none” href=”https://goo.gl/forms/2RmmTbSiOy89Dx0l2″ info=”none” info_place=”top” info_trigger=”hover”]Become a Trusted Partner[/x_button]

PageFair will share methods for performing essential adtech functions (bid requests, frequency capping, measurement and reporting, etc.) with partners.[2]

How publishers can examine their adtech vendors’ personal data processing and GDPR-readiness.

The following section is a questionnaire for web and mobile publishers to use when exploring whether their adtech vendors are safe under the GDPR.

Questionnaire for adtech vendors

1. Unique identifiers

For each unique user identifier that you use, or introduce into the page, please list the primary purpose, the type, the duration of the identifier, what other companies might receive it, and what secondary purposes it might be used for.

Identifier name Primary purpose Secondary purposes Type
Example: 1st party cookie. 3rd party cookie. localStorage cookie. eTag supercookie. Flash supercookie. HSTS supercookie. device fingerprint / statistical ID. IP stack fingerprint. Other.
Lifetime of ID Other recipients

2. Other personal data

Do you use any other personal data (e.g., IP address, name, address, social security numbers, credit card numbers, email addresses or email address hashes)?

  1. What are their purpose?
  2. Where do you obtain this data from?
  3. Is there auditable consent from the user for the use of this personal data for this purpose?
  4. How do you match this data to unique user IDs?

3. Adtech server-to-server calls

What other advertising systems do you make server-to-server calls to that may communicate user IDs or other personal information, for example RTB bid requests, or automated transfer of RTB or ad call logs?

4. Cookie syncing / user matching

What other domains do you perform cookie syncing / user matching with?

5. Frequency capping

Do you perform frequency capping using unique user IDs? How?

6. Impression counting

Do you depend on any unique user identifiers when you perform impression counting? (for example, to count “unique impressions”)

7. Conversion counting

If you perform conversion counting, does this depend on unique user identifiers to track the user from click to post-conversion?

8. View through counting

If you perform view-through counting, does this depend on unique user identifiers to track the user from view to post-conversion?

9. Viewability measurement

If you perform viewability measurement, does this depend on any unique user identifiers?

10. Cross-device identification

If you perform any cross-device identification of users, what IDs do you use, and how do you match mobile device IDs with other IDs?

11. Fraud detection

If you perform fraud detection, do you use unique identifiers to track devices between websites, or perform other per-user analytics to detect the possibility of bot traffic?

Conclusion

It is inevitable that the audit above will find the processing of personal data is the norm among adtech vendors. This exposes the vendors, and their clients, under the GDPR.

PageFair invites all adtech vendors to provide versions of their service that operate outside the scope of the GDPR. We intend is to share insights on the tweaks required to take personal data out of adtech (where consent is absent) with Trusted Partners, and promote vendors who operate as Trusted Partners to publishers who use Perimeter.

Our objective is to minimize the number of vendors that publishers must block to protect themselves from GDPR liabilities.

[x_button shape=”rounded” size=”regular” float=”none” href=”https://goo.gl/forms/2RmmTbSiOy89Dx0l2″ info=”none” info_place=”top” info_trigger=”hover”]Become a Trusted Partner[/x_button]

[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]

Notes

[1] Non-personal data are any data that can not be related to an identifiable person. As Recital 26 of the GDPR observes, “the principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”. This recital reflects the finding of the European Court of Justice in 2016 that data are not personal “if the identification of the data subject was prohibited by law or practically impossible on account of the fact that it requires a disproportionate effort in terms of time, cost and manpower, so that the risk of identification appears in reality to be insignificant”. Judgment of the Court (Second Chamber) Patrick Breyer v Bundesrepublik Deutschland, Case C-582/14, 19 October 2016.

[2] For methods of performing frequency capping, impression counting, click counting, conversion counting, view through measurement, and viewability measurement see PageFair note at https://pagefair.com/blog/2017/gdpr-measurement1/.

GDPR consent design: how granular must adtech opt-ins be?

This note examines the range of distinct adtech data processing purposes that will require opt-in under the GDPR.[1]
In late 2017 the Article 29 Working Party cautioned that “data subjects should be free to choose which purpose they accept, rather than having to consent to a bundle of processing purposes”.[2] Consent requests for multiple purposes should “allow users to give specific consent for specific purposes”.[3]  Rather than conflate several purposes for processing, Europe’s regulators caution that “the solution to comply with the conditions for valid consent lies in granularity, i.e. the separation of these purposes and obtaining consent for each purpose”.[4] This draws upon GDPR, Recital 32.[5]
In short, consent requests must be granular, showing opt-ins for each distinct purpose.

How granular must consent opt-ins be?

In its 2013 opinion on “purpose limitation”, the Article 29 Working Party went some way toward defining the scope of a single purpose: a purpose must be “sufficiently defined to enable the implementation of any necessary data protection safeguards,” and must be “sufficiently unambiguous and clearly expressed.”[6]
The test is “If a purpose is sufficiently specific and clear, individuals will know what to expect: the way data are processed will be predictable.”[7] The objective is to prevent “unanticipated use of personal data by the controller or by third parties and in loss of data subject control [of these personal data]”.[8]
In short, a purpose must be specific, transparent and predictable.[9] It must be describable to the extent that the processing undertaken for it would not surprise the person who gave consent for it.
The process of showing an ad to a single person (in online behavioral advertising) involves the processing of personal data for several distinct purposes, by hundreds of different companies.
[accordion id=”video”] [accordion_item title=”Video: how personal data passes between companies in online behavioral advertising” parent_id=”video”]


[/accordion_item][/accordion]
Therefore, a broad, all-encompassing sentence such as “to show you relevant advertising” does not make it possible for one to grasp how one’s data will be used by a large number of companies. It would not be possible to understand from this sentence, for example, that inferences about one’s characteristics would be inferred, or what types of consequences may result.
The following table shows an indicative list of ten purposes for which personal data are currently processed in the online behavioral advertising system. In practice, there may be more purposes at play. The table also generalizes the types of company involved in the selection and display of an ad.
[x_button shape=”rounded” size=”small” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/01/purposes.pdf” info=”none” info_place=”top” info_trigger=”hover”]Download high resolution PDF [/x_button]
A spreadsheet version of this table is available here.
(Refer to footnote 10 to for a discussion the challenges presented by these purposes for all businesses involved.[10])

Pre-consent naming of each controller, and granular post-consent controller consent withdrawal

Recital 42 of the GDPR notes that “For consent to be informed, the data subject should be aware at least of the identity of the controller and the purposes of the processing”.[11] All controllers (including “joint controllers” that “jointly determine the purposes and means of processing”[12]) must be named.[13]
Each purpose must be very clear, and each opt-in requires a “clear affirmative action” that is both “specific”, and “unambiguous”.[14] There can be no pre-ticked boxes,[15] and “consent based on silence” is not permitted.[16]
Therefore, a consent request should be made with granular options for each of these purposes, and the names each controller that processes personal data for each of these purposes. For example:  

Specific purpose 1 | controllers A, B, C | options: Accept / Refuse 

There are two different scenarios for how consent for these purposes will be presented: the best case, and the more likely worst case.

The best scenario

At a minimum, then, assuming that all websites, SSPs, Ad Exchanges, DSPs, DMPs, and advertisers could align to pursue only these purposes, a consent request for this would include granular opt-in controls for a wide range of diverse purposes, the categories of processor pursuing each, and a very long list of controller names pursuing each.
The language and presentation of the request must be simple and clear, ideally the result of user testing.[17]
A consent request for a single purpose, on behalf of many controllers, might look like this.

Specific processing purpose consent, for multiple controllers,
with “next” button for multiple processing purpose opt-ins

[x_button shape=”rounded” size=”small” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/01/consent-dialogues.pdf” info=”none” info_place=”top” info_trigger=”hover”]Download wireframes [/x_button]

What is presented when?

The Article 29 Working Party suggests that consent notices should have layers of information so that they do not overload viewers with information, but make necessary details easily available.[18] This is adopted in the design above using “View details”, “Learn about your data rights here”, and similar buttons and links.
When a user clicks “view details” to see the next layer of information about a controller

[x_button shape=”rounded” size=”small” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/01/consent-dialogues.pdf” info=”none” info_place=”top” info_trigger=”hover”]Download wireframes [/x_button]

While some details, such as contact details for a company’s data protection officer, can be placed in a secondary layer, the primary layer must include “all basic details of the controller and the data processing activities envisaged”.[19]
Elements presented in this layer

[x_button shape=”rounded” size=”small” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/01/consent-dialogues.pdf” info=”none” info_place=”top” info_trigger=”hover”]Download wireframes [/x_button]

The likely scenario:

The scenario above assumes that all businesses in online behavioral advertising can agree to pursue tightly defined purposes without deviation. However, it is more likely that controllers will need granular opt-ins, because their purposes are unique.
Any individual controllers who intend to process data for their own unique purposes will need further granular opt-ins for these purposes. Since adtech companies tend to deviate from the common purposes outlined above, it is likely that most or all of them would ultimately require granular purpose consent for each controller.
However, even if all controllers pursued an identical set of purposes so that they could all receive consent via a single consent dialogue that contained a series of opt-ins, there would need to be a granular set of consent withdrawal controls that covered every single controller once consent had been given. The GDPR says that “the data subject may exercise his or her rights under this Regulation in respect of and against each of the controllers”.[20]

A higher bar: “explicit consent”

Processing of personal data in online behavioral advertising (for example, purposes 2, 3, 5, 8, and 10 in the table above) is highly likely to produce special categories of data by inference.[21] Where this occurs, these purposes require “explicit” consent.[22]
Special categories of data reveal “racial or ethnic origin, political opinions, religious or philosophical beliefs, or trade union membership, … [and] data concerning health or data concerning a natural person’s sex life or sexual orientation”.[23] 
To make consent explicit requires more confirmation. For example, the Article 29 Working Party suggests that two-stage verification is a suitable means of obtaining explicit consent.[24] One possible approach to this is suggested in PageFair’s design below.
Suggested mechanism for “explicit consent” 

[x_button shape=”rounded” size=”small” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/01/consent-dialogues.pdf” info=”none” info_place=”top” info_trigger=”hover”]Download wireframes [/x_button]

One can confirm one’s opt-in in a second movement of the finger, or cursor and click. It is unlikely that a person could confirm using this interface unless it was their intention.  

[x_button shape=”rounded” size=”small” float=”none” href=”https://pagefair.com/wp-content/uploads/2018/01/consent-dialogues.pdf” info=”none” info_place=”top” info_trigger=”hover”]Download wireframes [/x_button]

Note that even this high bar, however, may not be permitted in some Member States. The GDPR gives European Member States the latitude to enact national legislation that prohibits consent as a legal basis for processing of special categories of data.[25] Therefore, it may not be legal to process any special categories of personal data in some EU Member States.

Conclusion 

Consent for website and app publishers is certainly an important objective, but the personal data it provides must only be processed after data leakage has been stopped. Data leakage (through in RTB bid requests, cookie syncs, JavaScript ad units, and mobile SDKs) exposes publishers as the most obviously culpable parties that regulators and privacy NGOs can target. At the same time, it also exposes their adtech vendors, and advertisers, to large fines and legal actions too.[26]
Websites, apps, and adtech vendors, should switch from using personal data to monetize direct and RTB advertising to “non-personal data”.[27] Using non-personal, rather than personal, data neutralizes the risks of the GDPR for advertisers, publishers, and adtech vendors. And it enables them to address the majority (80%-97%) of the audience that will not give consent for 3rd party tracking across the web.[28]
We recently revealed PageFair Perimeter, a regulatory firewall that blocks party data leakage, and enables publishers and adtech partners to use non-personal data for direct and RTB monetization when consent is absent (and leverage personal data when adequate consent has been given). You can learn more about Perimeter here. Publishers using Perimeter do not need people’s personal data (nor the consent required to process it) to monetize websites and apps.

[x_button shape=”rounded” size=”regular” float=”none” href=”http://pagefair.com/perimeter/” info=”none” info_place=”top” info_trigger=”hover”]Learn about Perimeter[/x_button]

Postscript

A hiccup in the choreography of the European Commission’s legislative proposals means that non-tracking cookies will need storage consent, at least until the application of the forthcoming ePrivacy Regulation. These cookies, however, contain no personal data, and obtaining consent for their storage is significantly less burdensome than obtaining consent for to process personal data for multiple purposes and multiple controllers. Update: 16 January 2018: See PageFair Insider note on storage consent for non-tracking cookies.
[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]


Notes:

[1] See our discussion of why consent is the appropriate legal basis for online behavioral advertising in “Why the GDPR ‘legitimate interest’ provision will not save you” , PageFair Insider, 13 March 2017 (URL: https://pagefair.com/blog/2017/gdpr-legitimate-interest/).
[2] “Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 11.
[3] ibid., p. 13.
[4] ibid., p. 11.
[5] Regulation (EU) 2016/679 of The European Parliament and of The Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation), Recital 32. “…Consent should cover all processing activities carried out for the same purpose or purposes. When the processing has multiple purposes, consent should be given for all of them. …”
[6] “Opinion 03/2013 on purpose limitation”, Article 29 Working Party, 2 April 2013, p. 12.
Curiously, the Spanish Data Protection Authority has issued guidance that contains a sentence suggesting that continuing to browse a website might constitute consent, which is at odds with the Article 29 Working Party guidance on consent and appears to be entirely at odds with the text of the Regulation. See “Guía del Reglamento General de Protección de Datos para responsables de tratamiento”, Agencia Española de Protección de Datos, November 2017, p. 6.
[7] “Opinion 03/2013 on purpose limitation”, Article 29 Working Party, 2 April 2013, p. 13.
[8] “Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 12.
[9] “Opinion 03/2013 on purpose limitation”, Article 29 Working Party, 2 April 2013, p. 13.
[10] None of these purposes would be permissible unless data leakage were first addressed. See “Consent to use personal data has no value unless one prevents all data leakage”, PageFair Insider, October 2017 (URL: https://pagefair.com/blog/2017/understanding-data-leakage/). Furthermore,

  • Purpose 3 could not be permissible in any situation.
  • Purposes 2, 3, 5, 8, and 10 are highly likely to produce special categories of data by inference. See discussion of “explicit consent” in this note.
  • Regarding the purposes for which data have been sold, and to what category of customer, see “Data brokers: a call for transparency and accountability”, Federal Trade Commission, May 2014, pp 39-40, and B3-B

[11] The GDPR, Recital 42.
[12] The GDPR, Article 26, paragraph 1.
[13] “Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 14.
[14] The GDPR, Article 4, paragraph 11.
[15] ibid., Recital 32.
[16] “Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 16.
[17] “Guidelines on transparency under Regulation 216/679” Article 29 Working Party, November 2017, pp 8, 13.
[18] “Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 14.
[19] ibid., p. 15.
[20] The GDPR, Article 26, paragraph 3.
[21] “Informing data subjects is particularly important in the case of inferences about sensitive preferences and characteristics. The controller should make the data subject aware that not only do they process (non-special category) personal data collected from the data subject or other sources but also that they derive from such data other (and special) categories of personal data relating to them.” See “Guidelines on Automated individual decision-making and Profiling for the purposes of Regulation 2016/679”, Article 29 Working Party, 3 October 2017, p. 22.
[22] The GDPR, Article 9, paragraph 2, a.
[23] ibid., Article 9, paragraph 1.
[24] “Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 19.
[25] The GDPR, Article 9, paragraph 2, a.
[26] See “Consent to use personal data has no value unless one prevents all data leakage”, PageFair Insider, October 2017 (URL: https://pagefair.com/blog/2017/understanding-data-leakage/).
[27] Non-personal data are any data that can not be related to an identifiable person. As Recital 26 of the GDPR observes, “the principles of data protection should therefore not apply to anonymous information, namely information which does not relate to an identified or identifiable natural person or to personal data rendered anonymous in such a manner that the data subject is not or no longer identifiable”. This recital reflects the finding of the European Court of Justice in 2016 that data are not personal “if the identification of the data subject was prohibited by law or practically impossible on account of the fact that it requires a disproportionate effort in terms of time, cost and manpower, so that the risk of identification appears in reality to be insignificant”. Judgment of the Court (Second Chamber) Patrick Breyer v Bundesrepublik Deutschland, Case C-582/14, 19 October 2016.
Non-tracking cookies, which contain no personal data, are useful for privacy-friendly advertising, and for other functions where an individual does not need to be identified such as A/B testing.
[28] See “Research result: what percentage will consent to tracking for advertising?”, PageFair Insider, September 2017 (URL: https://pagefair.com/blog/2017/new-research-how-many-consent-to-tracking/).
The granularity of consent required for online behavioral advertising will make the consenting audience even smaller. Moreover, consent for adtech will not only be hard to get, it will also be easy to lose. Consent can be withdrawn with the same degree of ease as it was given, under The GDPR, Article 7, paragraph 3.
The Article 29 Working Party demonstrates what this means in practice: “When consent is obtained … through only one mouse-click, swipe, or keystroke, data subjects must … be able to withdraw that consent equally as easily”.
“Guidelines on consent under Regulation 2016/679”, Article 29 Working Party, 28 November 2017, p. 21.
The guidance also says that “Where consent is obtained through use of a service specific user interface (for example, via a website, an app, a log-on account, the interface of a IoT device or by e-mail), there is no doubt a data subject must be able to withdraw consent via the same electronic interface, as switching to another interface for the solve reason of withdrawing consent would require undue effort”.

The regulatory firewall for online media and adtech

This note announces Perimeter, a regulatory firewall to enable online advertising under the GDPR. It fixes data leakage from adtech and allows publishers to monetize RTB and direct ads, while respecting people’s data. 
PageFair takes a strict interpretation of the GDPR. To comply, all media owners need to protect their visitors’ personal data, or else find themselves liable for significant fines and court actions. In European Law, personal data includes not only personally identifiable information (PII), but also visitor IP addresses, unique IDs, and browsing history.[1] The problem is that today’s online ads operate by actively disseminating this kind of personal data to countless 3rd parties via header bidding, RTB bid requests, tracking pixels, cookie syncs, mobile SDKs, and javascript in ad creatives. This exposes everyone, from the publisher to the advertiser, to potential fines, litigation and brand damage.[2]
Perimeter fixes this. It enables publishers to securely protect and control the tracking activities of the entire advertising supply chain in their websites and apps, by strictly blocking all third parties unless both publisher and data subject have given their consent.

[x_button shape=”rounded” size=”large” float=”none” href=” https://pagefair.com/perimeter/” title=”perimeterblogbutton” info=”none” info_place=”top” info_trigger=”hover”]Learn more about Perimeter [/x_button]

Revenue with or without tracking and consent

Publishers using Perimeter do not need people’s personal data (nor the consent required to process it) to monetize websites and apps. This is critically important, because only a small minority of people online are expected to consent to third party tracking for online advertising.[3]
Even without personal data, Perimeter enables interoperation with GDPR-compliant ad tech vendors so that frequency capping, attribution, impression counting, click counting, view-through counting, conversion counting, and fraud mitigation, all work without personal data. The list of compliant adtech vendors that PageFair works with to do this is growing.
Perimeter will also re-enable audience targeting by using non-personal segments that can also interoperate with consent-bearing DMPs.
When adequate consent is present, publishers, adtech vendors and advertisers can use personal data, and Perimeter will interoperate with other compliant consent management platforms. Indeed, Perimeter is a necessary partner to make consent meaningful.[4] Adtech vendors are eager for publishers to collect consent on behalf of 3rd parties – but publishers must simultaneously block all parties who do not have consent, or else remain exposed to liabilities.

Take Control of Data Leakage in all your Digital Properties

Perimeter brings privacy and data protection to the RTB/programmatic advertising ecosystem in the following ways:

  • Automatic removal of data leaking scripts from ads before they are rendered.
  • Prevention of unauthorized 3rd parties from accessing personal data.
  • Enforcement of data protection in RTB bid requests.
  • Enforcement of data protection in mobile SDK.

[x_button shape=”rounded” size=”large” float=”none” href=” https://pagefair.com/perimeter/” title=”perimeterblogbutton” info=”none” info_place=”top” info_trigger=”hover”]Learn more about Perimeter [/x_button]

Four Components

Perimeter provides four components that protect website and app publishers, and all of their advertising partners.

  1. Server side ad rendering
    Controls data in bid requests and ad creatives
  2. Policy Manager
    Empowers publishers to decide what 3rd parties are permitted to run in their websites and apps.
  3. User Consent Manager
    Enables granular consent to be obtained, communicated, and withdrawn by users.
  4. Privacy-by-design adtech interoperation
    Perimeter is partnering with other adtech vendors who are innovating to be compatible with strict enforcement of privacy regulations. This re-enables all core campaign management, measurement and targeting features without depending on legally toxic tracking IDs or other personal data.

[x_alert heading=”Resource to check your adtech vendors’ compliance ” type=”success”]Here is a resource for publishers to check whether your adtech vendors are compliant.[/x_alert]

Ethical data

We built Perimeter to enable websites and apps to transition from the old adtech industry to a more ethical one. This is why we are openly sharing the measurement and capping techniques for non-personal data adtech.
Perimeter is the result of 24 months of intensive technical and policy research and development, and combines the feedback of many app developers, advertisers, adtech vendors, privacy NGOs, regulators, and lawmakers.
It enables publishers, and their advertising partners, to operate within a clean and ethical data/media industry.

[x_button shape=”rounded” size=”large” float=”none” href=” https://pagefair.com/perimeter/” title=”perimeterblogbutton” info=”none” info_place=”top” info_trigger=”hover”]Learn more about Perimeter [/x_button]

Are you an ad tech vendor?

Let us know if you would like to find out more about GDPR compliance requirements and getting whitelisted on the Perimeter partner program. You can read about non-personal data methods here.
 
[x_line]

Notes

[1] See the definition of personal data in Article 4, (1), Regulation (EU) 2016/679 of The European Parliament and of The Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).
[2] ibid., Article 4, paragraph 2.
[3] See “Europe Online: an experience driven by advertising”, GFK, 2017, p. 7 and “Research result: what percentage will consent to tracking for advertising?”, PageFair Insider, 12 September 2017.
[4] Because without Perimeter’s mitigation of data leakage, consent has no value. See “Consent to use personal data has no value unless one prevents all data leakage”, October 2017, PageFair Insider (URL: https://pagefair.com/blog/2017/understanding-data-leakage/)

How publishers verify their adtech partners' GDPR readiness

PageFair believes that the GDPR will be strictly enforced. This means all unique identifiers (such as user IDs) and IP addresses will be regarded as personal data under the Regulation, and therefore must not be used in a way that would distribute them in the programmatic advertising system without consent.[1] This is why we launched Perimeter, to protect publishers from risk under the GDPR.
When publishers install PageFair Perimeter on their sites or in their apps, Perimeter will block adtech that uses unique identifiers without consent. Adtech services that do not use personal data where consent is absent will be whitelisted.
Criteria for whitelisting in on sites/apps protected by Perimeter (where required consent is absent)

  • No use of unique IDs
  • No storage of IP addresses or user agent details

Adtech vendors can perform necessary campaign measurement, attribution, and frequency capping using non-personal data methods as we have outlined here.

How publishers verify their adtech’s GDPR readiness

Many publishers are uncertain of whether the adservers or other adtech services they use will be compliant with the GDPR. To remedy this situation, we present below a questionnaire that equips publishers to ask the right questions of their adtech vendors.
[alert type=”info” close=”false” heading=”Media owner’s questionnaire for adtech vendors”]
1. For each unique user identifier that you use, or introduce into the page, please list the primary purpose, the type, the duration of the identifier, what other companies might receive it, and what secondary purposes it might be used for.

Identifier table 

Identifier name Primary purpose Secondary purposes Type
Example: 1st party cookie. 3rd party cookie. localStorage cookie. eTag supercookie. Flash supercookie. HSTS supercookie. device fingerprint / statistical ID. IP stack fingerprint. Other.
Lifetime of ID Other recipients

2. Do you use any other personal data (e.g., IP address, name, address, social security numbers, credit card numbers, email addresses or email address hashes)?

a) What are their purpose?
b) Where do you obtain this data from?
c) Is there auditable consent from the user for the use of this personal data for this purpose?
d) How do you match this data to unique user IDs?

3. What other advertising systems do you make server-to-server calls to that may communicate user IDs or other personal information, for example RTB bid requests, or automated transfer of RTB or ad call logs?
4. What other domains do you perform cookie syncing / user matching with? 
5. How do you perform frequency capping using unique user IDs?
6. Do you depend on any unique user identifiers when you perform impression counting? (for example, to count “unique impressions”)
7. If you perform conversion counting, does this depend on unique user identifiers to track the user from click to post-conversion?
8. If you perform view-through counting, does this depend on unique user identifiers to track the user from view to post-conversion?
9. If you perform viewability measurement, does this depend on any unique user identifiers?
10. If you perform any cross-device identification of users, what IDs do you use, and how do you match mobile device IDs with other IDs?
11. If you perform fraud detection, do you use unique identifiers to track devices between websites, or perform other per-user analytics to detect the possibility of bot traffic?
[/alert]
 
 
You can read about Perimeter here.
[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]
 

Notes

[1] See Article 4 of Regulation (EU) 2016/679 of The European Parliament and of The Council of 27 April 2016 on the protection of natural persons with regard to the processing of personal data and on the free movement of such data, and repealing Directive 95/46/EC (General Data Protection Regulation).

Overview of how the GDPR impacts websites and adtech (IAPP podcast)

In this podcast, the International Association of Privacy Professionals interviews PageFair’s Dr Johnny Ryan about the challenges and opportunities of new European privacy rules for website operators and brands. 
Update: 3 January 2018: This podcast was the International Association of Privacy Professionals’ most listened to podcast of 2017. 

The conversation begins at 4m 14s, and covers the following issues.

  • Risks for website operators
  • How “consent” is an opportunity for publishers to take the upper hand in online media
  • Brands’ exposure to legal risk, and the agency / brand / insurer conundrum
  • Personal data leakage in RTB / programmatic adtech
  • How the adtech industry should adapt

As we told Wired some months ago, it’s not just that websites might expose yourself to litigation, it’s that you might expose your advertisers to litigation too. But this can be fixed.
Click here to view PageFair’s repository of explainers, analysis, and official documents about the new privacy rules.
Elsewhere you can find details about PageFair’s GDPR solutions for website operators.
Note: the IAPP published this podcast this month. The interview was conducted several months ago. 
[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]

Frequency capping and ad campaign measurement under GDPR

This note describes how ad campaigns can be measured and frequency capped without the use of personal data to comply with the GDPR. 
It is likely that most people will not give consent for their personal data to be used for ad targeting purposes by third parties (only a small minority [1] of people online are expected to consent to third party tracking for online advertising). Even so, sophisticated measurement and frequency capping are possible for this audience.
This note briefly outlines how to conduct essential measurement (frequency capping, impression counting, click counting, conversion counting, view through measurement, and viewability measurement) in compliance with the EU’s General Data Protection Regulation. This means that publishers and advertisers can continue to measure the delivery of the ads that sustain their businesses, while simultaneously respecting European citizens’ right to protection of their personal data.
Note that this discussion assumes that the final text of the EU’s ePrivacy Regulation will not incidentally illegalize non-tracking cookies (i.e., cookies that neither contain nor reveal any personal data, and therefore pose no privacy risks) [2].
Table: cleaner ad tech measurement [3]

 

Frequency capping, without personal data

Most of today’s ad servers implement frequency capping by using a server-side database to store the number of times an ad campaign has been shown to each user. Each user is tracked using a unique ID, which is stored both in the database and in a 3rd party cookie in the user’s browser [4]. Since this user ID could be used to track what websites the user is visiting, and could potentially be matched against other online trackers and offline data, this will be illegal under GDPR (unless the user has specifically consented to it).
A privacy-by-design alternative is to get rid of the user ID and move the counter directly into the cookie. The cookie it is stored in can have an expiry equal to the maximum amount of time the campaign should be capped for, and the name of the cookie can be set to the name of the ad campaign. Variations on this approach have been discussed for years – see Arvind Narayanan and Jonathan Mayer’s approach here. Since the counter does not contain any information specific to a particular user, it is not “personal data” under GDPR, and is not subject to consent.
Two inefficiencies of this approach, storage and bandwidth, are addressed below.
First, how much storage space will all those frequency capping cookies take up in the web browser? So long as the cookie expiry dates are reasonable, this data should be proportional to the number of ad campaigns delivered to a browser over a one- or two-week time window, and should not grow beyond that. Even if a user manages to view a hundred thousand different advertising campaigns in a two week period, that would still require no more than a few megabytes to store.
Second, how much bandwidth might be consumed by transmitting all these view counters along with every request to the ad server? This can be reduced by being efficient in the encoding of the cookie data. As shown in the inset below,  transmitting a frequency counter in the ad server cookie could take as little as 9 bytes of extra bandwidth, which means that thousands of counters could be transmitted without significantly impacting the weight of a modern web page.

Calculating potential bandwidth requirements
The name of the cookie might be used to store a campaign ID, efficiently encoded using all the characters available according to RFC 6265 (i.e., “A-Z”, “a-z”, “0-9” and “!#$%&’*+-.^_`|~”). That’s 77 characters, meaning that just four characters can be used to encode over 35 million (i.e. 774) different IDs, which is easily sufficient for all ad campaigns that an ad server might be managing in a given period. Meanwhile, the value portion of the cookie needs only contain a counter, which can be 2 characters long (to store a value up to 99 in decimal, or about 6,000 in base-77 encoding.With this system in place, a browser request to an ad server might consist of the following HTTP request:

GET /ad HTTP/1.1
Host: acmeadserver.com
Cookie: 2iP&=21; Rz%x=13

The “Cookie:” field concatenates all cookies previously stored by the ad server. We can see that the bandwidth consumed by each frequency counter is only 9 bytes in total: 4 characters for the campaign ID, 2 characters for the counter value, and 3 counters for the equals sign, the semi-colon delimiter and the space. It would only take 20 Kb to transmit over two thousand frequency counters in an ad call.

There is a further opportunity to optimize bandwidth, with the help of header bidding. Because header bidding sends multiple potential bids to the client, the client can do the work of deciding which ones have not reached a frequency cap and are therefore eligible for display. SSPs are currently moving from second-price auctions to first-price auctions to better support header bidding, and in time are likely to start returning multiple bids to header bidder wrappers, so that more bids can participate in the final auction. This will provide plenty of choice to a client-side frequency capping algorithm, and probably entirely eliminate the need for the frequency capping data to ever leave the browser.

Campaign Metrics

Campaign metrics allow advertisers and media owners to see how different advertising campaigns are performing, and to optimize campaigns if necessary. The typical metrics are impression counts, click counts, conversion counts, view-through measurement and viewability measurement.
Fortunately, none of these metrics concern individual people. Therefore, ad servers can avoid tracking information at an individual user level to ensure GDPR compliance. It is likely that many of today’s ad servers have not been so careful, and have implementations that currently depend on counting the same user ID that was used for frequency capping. These ad servers will need to consider providing alternative implementations when serving ads to EU users.
In the paragraphs below we review typical campaign metrics for likely GDPR compliance, and suggest alternative implementations where appropriate.

Impression Counting

Impression counting is normally implemented by incrementing a database counter pertaining to the ad campaign whenever a request is made to the ad server for that campaign, or when an impression pixel specific to that campaign is loaded from the ad server by the web browser. Basic impression counting should not pose a problem under GDPR, as no user-specific information is processed or stored [5].

Click Counting

Click measurement is normally performed by redirecting the browser to the ad server when the ad is clicked on, at which point it registers the click event, and then redirects the browser to the advertiser URL.
Like basic impression counting, click counting should not be problematic under GDPR, as all that is required is an overall counter of the number of times that an ad has been clicked on across all users, without the involvement of any user-specific information.
When the number of clicks is known, the click-through-rate is given by dividing the number of clicks by the number of impressions for any given campaign.

Conversion counting

Conversion counting is normally performed by obtaining a campaign-specific pixel from the ad server, and placing that pixel on a web page the user will be brought to when they complete a transaction with the advertiser (when they “convert”). When a user who has clicked on an ad “converts”, the conversion pixel will be loaded from the ad server, which will increase the conversion count for that campaign by one.
As with impression counting and click counting, there is no specific privacy concern here: only campaign-level data is used, and no user-specific information is processed.

View Through Measurement

Although click-through rates help an advertiser understand the immediate positive reaction of users who see their ad, many are also interested in the indirect response, e.g., how many people who saw the ad went on to buy the product during the subsequent weeks regardless of clicking on the ad?
It is possible that some ad servers currently perform view-through measurement using user-specific information. For example, the ad server might record that an ad was viewed by a particular user ID. When the conversion pixel loads on the advertiser’s post-conversion page, the ad server could look up the details of the last time that user ID viewed that campaign.
The above implementation would be incompatible with GDPR, as it involves tracking the behavior of unique users. Fortunately, there are alternative implementations that are equally effective.
The correct approach is to use a non-tracking cookie to store the fact that the user has viewed the ad campaign. This means that the cookie would contain the ID of the ad campaign, not an ID of the user (and consequently, every user who saw that campaign would have an identical cookie). This cookie should be set to expire automatically when a certain amount of time has passed, beyond which the advertiser is not interested in attributing the visit to the fact the ad was seen. In this system, when the user eventually converts for the advertiser, the cookie containing the campaign ID is transmitted to the advertiser’s ad server, which can then increment the relevant view-through counter.
It is possible that this approach could lead to a lot of cookie data being transmitted and consuming bandwidth. To mitigate this, the view-through pixel should be homed on a domain unique to each advertiser, rather than every advertiser sharing the domain of their ad server.

Viewability Measurement

Viewability measurement allows advertisers to understand how many of the ads they pay to serve on a web site are likely to scroll into view and be displayed for long enough for a user to potentially notice them.
Viewability measures a characteristic of websites, not users, and can therefore be implemented in a GDPR compatible fashion. Although some viewability systems today might store per-user information, there is no fundamental need to do so. All that is required is to detect when a view event has occurred for each ad space, and to send that to the server to be counted. The server will then aggregate these events and provide an overall count of the number of times each ad space has been viewable by any user in each time period.
[x_callout type=”center” title=”Perimeter: the regulatory firewall for online media and adtech. ” message=”Feature-rich adtech, even without personal data. Control user data and 3rd parties in websites + apps. Get robust consent.” button_text=”Learn more” href=”https://pagefair.com/perimeter”]

Notes

[1] See “Europe Online: an experience driven by advertising”, GFK, 2017, p. 7 and “Research result: what percentage will consent to tracking for advertising?”, PageFair Insider, 12 September 2017.
[2] For an overview of the issues see a previous PageFair Insider note, “The Privacy Case for Non-Tracking Cookies: PageFair writes to the European Parliament”, PageFair Insider, 10 August 2017 (URL:  https://pagefair.com/blog/2017/non-tracking-cookies/).
[3] Clearly, a campaign that targeted a single individual without a legal basis for doing so would be illegal. It is important that campaigns must target more than a small set of viewers.
[4] These data are automatically transmitted to the ad server along with every request.
[5] Ad servers may also support the counting of “unique impressions”, which means the number of unique users who saw the campaign. This mechanism generally relies on tagging each user with a unique identifier, and counting the number of unique identifiers. Therefore, while impression counting is practical, unique impressions may not be because a unique identifier could be misused.