Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Interact 2018 - IAB Europe’s GDPR Transparency & Consent Framework


Published on

Held in Milan on 23-24 May, IAB Europe’s annual 2-day conference Interact 2018 featured a training by Wilfried Schobeiri, Chief Technology Officer, MediaMath and Matthias Matthiesen, Director Public Policy & Privacy IAB Europe
Following up on the plenary session from DAY 1 on IAB Europe’s GDPR Transparency & Consent Framework this training session presented by IAB Europe will offer the opportunity to ask any questions you may still have regarding the implementation of the Framework from the Global Vendor List to ensuring the best possible User Experience.

Published in: Marketing
  • Snaptits big-breasted girls snaps only. View pics... ▲▲▲
    Are you sure you want to  Yes  No
    Your message goes here
  • Your opinions matter! get paid for them! click here for more info...◆◆◆
    Are you sure you want to  Yes  No
    Your message goes here
  • Discover a WEIRD trick I use to make over $3500 per month taking paid surveys online. read more... ●●●
    Are you sure you want to  Yes  No
    Your message goes here

Interact 2018 - IAB Europe’s GDPR Transparency & Consent Framework

  1. 1. DIGITAL ADVERTISING TRANSPARENCY, CONTROL, CONSENT Interact 2018 May 24th Technical standard in development and subject to change. 1 Presented by: Wil Schobeiri, CTO, MediaMath Matthias Matthiesen, Director, Privacy & Public Policy at IAB Europe
  2. 2. Agenda •Issue: EU Regulatory Challenges •Solutions •Closed Ecosystem •Open Framework within an independent and flexible ecosystem •Standard Framework •Goals •Framework •Technology •Pubvendors.json 2
  3. 3. AdTech Data Flows… Sell-side 3 DATA SUBJECT PERSONAL DATA • IDFA • advertising ID • cookies/unique identifier • lat/long • IP Address • segments S2S SERVER Cookie Synching On Page Header Bidding Partners Third parties and advertisers collecting data re: ad delivery, conversion and attribution Header Bidding Demand Partners External Bidders Real Time Data Providers Subcontractors PUBLISHERS ADVERTISER *Data flows are an example for illustrative purposes only, certain data flows may be missing or different for different parties SSP
  4. 4. AdTech Data Flows… Buy-side 4 DATA SUBJECT DIRECT RETAILER ADVERTISER LANDING PAGE CRM Onboarder ADVERTISER AD SERVER ADVERTISER DSP *Data flows are an example for illustrative purposes only, certain data flows may be missing or different for different parties SSP
  5. 5. It’s not all about Consent • Under GDPR, consent is only one of six “legal grounds” for processing personal data, and therefore not always needed • For the purposes of access and storage of information on devices ePrivacy Directive consent requirements currently apply • The Framework is designed to be flexible and accommodate different publisher and vendor needs centering on transparency, control and choice 5
  6. 6. Data leakage Lack of Control and Transparency over partners and demand sources on page (and their partners) No single privacy policy ePrivacy GDPR requirements Continued monetization Current Challenges 6
  7. 7. Benefits • Control data leakage • Single privacy policy • Easier consent • Easier GDPR compliance Closed Ecosystem Challenges • Control of data and reporting • Control of third party partners • Control of demand 7
  8. 8. Standard Framework Transparency for Consumers and Publishers into partners that help monetize sites and apps Control for Publishers over partners operating on sites and apps and processing their users’ data Control for Consumers over how their personal data is used and by which partners Consent as a potential legal basis Standardization allowing publishers and partners to operate and communicate efficiently using a single, open source standard Flexibility for publishers and demand sources to build or work with various consent management providers Minimize Disruption of the Internet, benefiting consumers, publishers & supporting companies 8
  9. 9. Transparency & Consent Framework
  10. 10. Technical Context Industry Vendor List Vendor and Consent Storage and Transmission Publisher Header Tag Exchanges DSP DSP DSP CProposal Publisher Ad Server DSP / DMP Dynamic Creative Server Fully Customizable Consent UI 10
  11. 11. The Technology 1. Industry-wide list of vendors bound to standard protocols and policies (Publisher choice over which vendors to activate) 2. Standardized mechanism for requesting, storing, and optionally sharing approved vendors and consent • Standard JS API • Standard vendor/consent storage format (currently 1st/3rd party cookies) • Standardized data structure for transmitting vendor/consent state 3. Open source specification, complete with reference implementations 11
  12. 12. Global Vendor List • A centralized, dynamic list of vendors, their purposes, their privacy policy URL, et al • Versioned to allow for audit trail • Publishers will use the global vendor list as basis for disclosure and consent requests • Both vendors and publishers will need to adhere to baseline principles and minimum standards ID Company Privacy Policy Purposes … 1 SSP1 1, 2, 3 … 2 ANW2 2, 3 … 3 ANA5 4 … … … … … … ID Purpose Description … … 1 Purpose 1 … … 2 Purpose 2 … … 3 Purpose 3 … … … … … … … 12
  13. 13. Providing Transparency and Requesting Consent • A JavaScript library/API which enables publishers to customize the experience of providing transparency disclosures and requesting consent • Abstracts the complexities of consent checking and storage • Implements standardized minimum disclosure language • Ensures the vendor list and disclosure language stays updated to latest version • Integrates with consent identification mechanism • Makes approved vendor and consent data available for downstream usage via daisy chain 13
  14. 14. Example of custom UI NB: Graphics are for illustration purposes only. 14 Level 1: Simple consent collection for all selected vendors and purposes
  15. 15. Example of custom UI NB: Graphics are for illustration purposes only. 15 Level 2: Purpose-level consent options for consumers
  16. 16. Example of custom UI NB: Graphics are for illustration purposes only. 16 Level 3: Vendor-level consent options for consumers
  17. 17. Storing Vendor and Consent Signals • Approved Vendor and Consent storage requires two mechanisms: a user identification method and persistence method. • Identification method • The identification needed for global consent to be made possible could be done via multiple mechanisms (e.g., id syncing). • Implementation to be determined by the publisher and vendor. API will standardize interaction, not implementation. • Persistence method • Multiple storage options possible: cookie, mobile app SDK, login alliances, centralized registries, etc. • Javascript library gives vendors the flexibility to implement storage in whatever mechanism they see fit, supporting both desktop and mobile 17
  18. 18. Transmitting Approved Vendors and Consent • Consent value to be binary • Consent values to be compressed into as small of a data structure possible. • Consent data structure is flexible • Policy requirements and technical feasibility will determine final implementation. • Consent transmitted via a Daisy Chain • every upstream member will append a consent payload to all downstream requests. • OpenRTB to directly support consent transmission 18
  19. 19. 1. ✓ SSP1 2. ✓ SSP2 3. ✓ Exchange1 4. X Exchange2 5. ✓ Exchange3 6. ✓ DMP1 7. ✓ DMP2 8. ✓ DMP3 9. ✓ DMP4 10. X DMP5 11. X DMP6 12. ✓ DPM7 13. X DMP8 14. ✓ DMP9 15. X DSP1 16. X DSP2 17. ✓ DSP3 18. ✓ DSP4 19. X DSP5 20. X DSP6 1. ✓ PURP1 2. ✓ PURP2 3. ✓ PURP3 4. ✓ PURP4 5. ✓ PURP5 11111 1110111110010100110011011111001010110 Purpose Choices String Vendor Choices String Purpose Choices Vendor Choices P U R P 1 P U R P 5 D M P 2 D S P 7 3FDF299BE572 21. ✓ DSP7 22. ✓ DSP8 23. X DSP9 24. ✓ DCO1 25. ✓ DCO2 26. ✓ DCO3 27. ✓ DCO4 28. ✓ DCO5 29. X DCO6 30. X DCO7 31. ✓ DCO8 32 X DCO9 33. ✓ Viewability1 34. X Viewability2 35. ✓ Viewability3 36. ✓ Viewability4 37. ✓ Viewability5 38. X Viewability6 39. X Viewability7 40. ✓ Viewability8 41. X Viewability9 Compressed Value Encoding Choices for Storage & Transmission 19
  20. 20. 3FDF299BE572 Consent Payload: “3FDF299BE572” appended to every request Transmitting Approved Vendors and Consent PublisherPublisher Publisher Ad Server DMP1 SSP1 SSP2 Exchange1 Exchange2 Exchange3 DSP5 DSP1 Advertiser Ad Server DCO1 Viewability 1 Advertiser Ad Server DCO5 Viewability 5 DSP9 Advertiser Ad Server DCO9 Viewability 9 DSP8 Advertiser Ad Server DCO8 Viewability 8 DSP7 Advertiser Ad Server DCO7 Viewability 7 DSP6 Advertiser Ad Server DCO6 Viewability 6 DSP3 DSP4 DSP2 Advertiser Ad Server DCO2 Viewability 2 Advertiser Ad Server DCO3 Viewability 3 Advertiser Ad Server DCO4 Viewability 4 DMP 2 DMP 3 DMP 5 DMP 4 DMP 8 DMP 9 DMP 7 DMP 6 3FDF299BE572 3FDF299BE572 3FDF299BE572 Has consent Doesn’t have consent 20
  21. 21. Combined, they enable... • Control over the vendors enabled by publishers. • Transparency into the supply chain for consumers & publishers. • An auditable consent trail that gives all supply chain members confidence by providing a more efficient disclosure mechanism, enabling companies to ”know” rather than “assume” their consent status with a user. • A better user experience than if every publisher were to try to solve the challenge on their own. 21
  22. 22. Problem: Publisher’s Liability • Publishers have approached the IAB for a solution that will allow them to protect themselves and their customers from exposure to vendors that the publisher doesn’t do business with. • They also asked for a way to configure purposes per vendors and have a control of the vendors listed in the consent UI. 22
  23. 23. Goal • Provide a standard for publishers to publicly declare the vendors that they are working with and their permissions/configuration • Allow vendors to verify publisher GDPR settings and verify and audit CMP consent string • Provide a standard way for publishers to whitelist vendors • Enable publishers to limit purposes on a per vendor basis • Enable publishers to limit features on a per vendor basis This configuration is an optional feature to the IAB’s T&C framework. 23
  24. 24. Solution: pubvendors.json • Out of band signal ("pubvendors.json") to signal to vendors and CMPs: • Limitations that a publisher places on specific vendors by purpose • Disclosures made by the publisher on behalf of the vendor • Vendor crawl for the pubvendors.json periodically 24
  25. 25. Integration: • Publisher • place a pubvendors.json file at the ".well-known path" of their domain: • CMP • Check for pubvendors.json file on the publisher “.well-known path” and uses this to filter the list of vendors to present to the user. • SSP/DSP: • Can use "pubvendors.json" as an out of band solution to augment the Consent String by crawling the publisher’s site. 25
  26. 26. Pubvendors.json v1.0 • Can be used immediately by Publishers to signal to the CMP which vendors to present to the user. • Enabling vendors to rely on legitimate interest 26 { "publisherVendorsVersion": 1, // [Required] Version of the pubvendors.json specification "version": 1, // [Required] Increment on each update of this file "globalVendorListVersion": 1, // [Required] The version of the GVL this was created from "updatedAt": "2018-05-28T00:00:00Z", // [Required] Updated for every modification "vendors": [ // [Required] Whitelist vendors { "id": 1 // [Required] ID of vendor from GVL }, { "id": 2 } ] }
  27. 27. Pubvendors.json v1.1(proposal) • disableUpstreamVendors disables to pull in additional vendors from the global vendor list. • vendors.purposes allows restrict purposes by vendors 27 { "publisherVendorsVersion": 1, // [Required] Version of the pubvendors.json specification "version": 1, // [Required] Increment on each update of this file "globalVendorListVersion": 1, // [Required] The version of the GVL this was created from "updatedAt": "2018-05-28T00:00:00Z", // [Required] Updated for every modification "disableUpstreamVendors": true, // [Optional] dont pull additional vendors from the GVL "vendors": [ // [Required] Whitelist vendors { "id": 1 // [Required] ID of vendor from GVL "purposes": [1, 2, 3], // [Optional] Publishers can restrict purposes by vendor }, { "id": 2 } ] }
  28. 28. Pubvendors.json v1.1(proposal) • Update to the GVL to expand purpose control • - The id of the purpose from the GVL. • vendors.purposes.legalBasis - The legal basis for which the vendor uses the purposes. (either "consent" or “legitimateInterest”) • vendors.purposes.required - An optional field that signals to external parties if a specific purpose is required for a vendor to operate. 28 "purposes": [ { "id": 1, // [Required] ID of purpose "legalBasis": "consent|legitimateInterest", // [Required] legal basis for usage of purpose "required": boolean, // [Optional] Is this purpose a requirement for the // vendor to operate } ]
  29. 29. Pubvendors.json v1.1(proposal) • Change to Consent String protocol • The Consent String should be modified to pass the version of the pubvendors.json used when sending the request. 0 = that pubvendors.json was not present. • The file version can be used by downstream parties to determine if they have an up to date version of the file when processing requests. 29
  30. 30. Timeline • pubvendors.json v1.0 is available for immediate use by CMPs • pubvendors.json v1.1 spec is under review and open for public comments. Review cycle end June 1st. Link to spec: Transparency-and-Consent- Framework/blob/master/pubvendors.json%20v1.0%20Draft%20f 30
  31. 31. Stay informed 31