Programmabeleid van AdMob en AdSense

Technische specificatie voor de 'Stand voor aanvullende toestemming' van Google

Dit document definieert een tijdelijke technische specificatie (de Stand voor aanvullende toestemming) die alleen is bedoeld voor gebruik in combinatie met het Transparency and Consent Framework (TCF) v2.0 van IAB Europe als overbrugging voor leveranciers die nog niet zijn geregistreerd op de Wereldwijde leverancierslijst (Global Vendor List, GVL) van IAB Europe. Met deze specificatie kunnen uitgevers, providers van toestemmingsbeheer (Consent Management Providers, CMP's) en partners naast hun implementatie van TCF v2.0 aanvullende toestemming verzamelen en gebruiken voor bedrijven die nog niet zijn geregistreerd op de GVL van IAB Europe, maar die wel op de lijst met aanbieders van advertentietechnologie (Ad Tech Providers, ATP's) van Google staan.

Gerelateerde bronnen

Componenten van de Stand voor aanvullende toestemming

We bieden in de 'Stand voor aanvullende toestemming' ondersteuning voor:

  • De Transparency and Consent-tekenreeks (TC-tekenreeks) zoals gedefinieerd door de IAB TCF v2.0-specificatie, die de transparantie en toestemming omvat die is vastgesteld voor leveranciers op de Wereldwijde leverancierslijst van IAB. EN
  • Een lichtgewicht addtl_consent-tekenreeks (AC-tekenreeks), die een lijst van Google-aanbieders van advertentietechnologie met toestemming bevat die niet zijn geregistreerd bij IAB.

Deze specificatie biedt definities voor het volgende:

  1. De indeling van de AC-tekenreeks
  2. De uitbreiding voor de TCF v2.0 CMP API ter ondersteuning van de AC-tekenreeks
  3. De manier waarop een AC-tekenreeks moet worden opgeslagen
  4. De manier waarop de AC-tekenreeks moet worden doorgestuurd via de digitale advertentieketen

De indeling voor de Additional Consent-tekenreeks (AC-tekenreeks)

Welke informatie wordt opgeslagen in een AC-tekenreeks?

Een AC-tekenreeks bevat de volgende 3 componenten:

  • Deel 1: Een versienummer van de specificatie, zoals 1
  • Deel 2: Een scheidingsteken '~'
  • Deel 3: Een met punten gescheiden lijst van ID's van Google-aanbieders van advertentietechnologie (ATP, Ad Tech Providers) met gebruikerstoestemming. Voorbeeld: '1.35.41.101'

De AC-tekenreeks 1~1.35.41.101 houdt bijvoorbeeld in dat de gebruiker toestemming heeft gegevens voor ATP's met de ID's 1, 35, 41 en 101, en dat de tekenreeks is gemaakt met de indeling die is gedefinieerd in de specificatie van v1.0.

Wie moet een AC-tekenreeks maken?

Een AC-tekenreeks kan alleen worden gemaakt door een voor IAB Europe TCF geregistreerd CMP dat gebruikmaakt van de toegewezen CMP-ID in overeenstemming met het IAB-beleid. Leveranciers of andere externe serviceproviders moeten zelf geen AC-tekenreeksen maken.

Waar worden de Google-ATP's gepubliceerd?

Google publiceert de lijst met aanbieders van advertentietechnologie die niet bij IAB zijn geregistreerd samen met de bijbehorende ID's op de volgende locatie:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

Wanneer moet een AC-tekenreeks worden gemaakt?

In alle gevallen kan een AC-tekenreeks alleen worden gemaakt als de uitgever het Google-beleid ten aanzien van toestemming van gebruikers in de Europese Unie naleeft. Nog specifieker: Een AC-tekenreeks moet niet worden gemaakt voordat de gebruiker juridisch geldende toestemming heeft gegeven voor: 1) het gebruik van cookies of andere lokale opslag waar dit wettelijk is vereist; en 2) het verzamelen, delen en gebruiken van persoonlijke gegevens voor de personalisatie van advertenties door een ATP in overeenstemming met het Google-beleid ten aanzien van toestemming van gebruikers in de Europese Unie.

Een AC-tekenreeks moet alleen worden gemaakt als aanvullende tekenreeks voor de TC-tekenreeks en niet als vervanging van de TC-tekenreeks. Google verwerkt het verzoek niet en verwijdert de AC-tekenreeks als Google een verzoek ontvangt waarvoor geen TC-tekenreeks beschikbaar is.

CPM's die deze specificatie implementeren, moeten ervoor zorgen dat de door hen gemaakte AC-tekenreeks alleen de ID's bevat van het gepubliceerde Google ATP-bestand (de leveranciers die niet op de GVL staan). Als Google een TC-tekenreeks ontvangt, wordt er gecontroleerd op de versie van de GVL die in de betreffende TC-tekenreeks wordt vermeld. Als die versie van de GVL een registratie bevat voor een leverancier, worden de beheeropties van de TC-tekenreeks voor die leverancier en alle AC-tekenreeksen voor die leverancier genegeerd. In dit geval behoudt Google zich het recht voor om dergelijke 'dubbele' vermeldingen van de AC-tekenreeks te verwijderen en een gewijzigde AC-tekenreeks naast de TC-tekenreeks door te sturen. De AC-tekenreeks mag niet worden gewijzigd door leveranciers, behalve door Google.

Uitbreiding van de CMP API

We stellen voor de bestaande TCF v2.0 CMP JavaScript API uit te breiden om de retournering van de AC-tekenreeks mogelijk te maken. Specifieker gezegd, stellen we voor de JSON-objecten TCData en InAppTCData uit te breiden om deze gegevens te retourneren.

TCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}

InAppTCData = {
  tcString: 'base64url-encoded TC string with segments',
  ...
  addtlConsent: ‘AC string with spec version and consented Ad Tech Provider IDs’,
}

Hoe moet een AC-tekenreeks worden opgeslagen?

Web

Het opslagmechanisme wordt door de CMP gekozen.

In-app

NSUserDefaults (iOS) of SharedPreferences (Android) wordt gebruikt om de AC-tekenreeks op te slaan via een CMP SDK. Hiermee is het volgende mogelijk:

  • Leveranciers hebben makkelijk toegang tot de AC-tekenreeks
  • De AC-tekenreeks blijft actief voor verschillende app-sessies
  • De AC-tekenreeks is overdraagbaar tussen CMP's zodat een uitgever flexibeler kan wisselen van de ene CMP SDK naar de andere

Als een uitgever ervoor kiest een CMP SDK te verwijderen uit een app, is de uitgever ervoor verantwoordelijk de AddtlConsent-waarden voor gebruikers te wissen, zodat leveranciers de opgenomen AC-tekenreeks niet blijven gebruiken.

Storage en Lookup Key in NSUserDefaults en SharedPreferences Waarde
IABTCF_AddtlConsent

Tekenreeks: AC-tekenreeks met specificatieversie en ID's van aanbieders van advertentietechnologie met toestemming

De manier waarop de AC-tekenreeks moet worden doorgestuurd via de digitale advertentieketen

Biedingsverzoek

We hergebruiken de ConsentedProvidersSettings om de leveranciers die niet op de GVL staan downstream door te verwijzen.

  • In OpenRTB-extensies proto
  • Verouderde Protobuf-versie

message ConsentedProvidersSettings {
 // Set of IDs corresponding to providers for whom the publisher has told
 // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local  
 // storage where legally required; and 2) the collection, sharing, and use of personal data for 
 // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy.
 // A mapping of provider ID to provider name is posted at providers.csv.
 repeated int64 consented_providers = 2 [packed = true];
}

 // Information about the providers for whom the publisher has told Google
 // that its EEA users have consented to the use of their personal data for
 // ads personalization in accordance with Google's EU User Consent Policy.
 // This field will only be populated when regs_gdpr is true.
 optional ConsentedProvidersSettings consented_providers_settings = 42;

URL-gebaseerde services

Als advertentiemateriaal wordt weergegeven, kan dit een aantal pixels bevatten onder <img>-tags. Voorbeeld: <img src="http://vendor-a.com/key1=val1&key2=val2">, waarmee een HTTP GET-verzoek van de browser naar het domein van de leverancier wordt gestuurd.

Aangezien de pixel in een <img>-tag staat zonder de mogelijkheid om JavaScript uit te voeren, kan de CMP API niet worden gebruikt om de TC-tekenreeks op te halen. Net als bij de support voor TC-tekenreeksen bieden we een standaard URL-parameter en macro in de pixel-URL's in gevallen waar de AC-tekenreeks moet worden ingevoegd.

URL-parameter Bijbehorende macro Vertegenwoordiging in URL
addtl_consent ADDTL_CONSENT &addtl_consent=${ADDTL_CONSENT}

Voorbeeld 1

Als Leverancier A een AC-tekenreeks moet ontvangen, moet een afbeeldings-URL een sleutel/waarde-paar bevatten met de URL-parameter en macro &addtl_consent=${ADDTL_CONSENT}. De resulterende URL is:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

 

Voorbeeld 2

In een bepaald verzoek, als de AC-tekenreeks het volgende is: 1~1.35.41.101

De caller of de renderer van het advertentiemateriaal vervangt de macro in de URL door de daadwerkelijke AC-tekenreeks, zodat de oorspronkelijk geplaatste pixel met de macro als volgt wordt gewijzigd als de aanroep naar de opgegeven server wordt uitgevoerd:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

Was dit nuttig?
Hoe kunnen we dit verbeteren?

Meer hulp nodig?

Log in voor extra supportopties om uw probleem snel op te lossen