In dit artikel
- Componenten van de Aanvullende toestemming
- De indeling voor de Aanvullende toestemming-tekenreeks (AT-tekenreeks)
- CMP's die Aanvullende toestemming ondersteunen
- Uitbreiding van de CMP API
- Hoe moet een AT-tekenreeks worden opgeslagen?
- De manier waarop de AT-tekenreeks moet worden doorgestuurd via de digitale advertentieketen
- Gerelateerde bronnen
Dit document definieert een technische specificatie ('Aanvullende toestemming' genoemd) die alleen bedoeld is voor gebruik in combinatie met het Transparency and Consent Framework (TCF) v2 van IAB Europe om transparantie- en/of toestemmingssignalen te sturen naar leveranciers die nog niet geregistreerd zijn op de Wereldwijde leverancierslijst van IAB Europe. (GVL). Met deze specificatie kunnen uitgevers, providers van toestemmingsbeheer (Consent Management Platforms, CMP's) en partners naast hun implementatie van TCF aanvullende toestemming verzamelen en gebruiken voor bedrijven die nog niet geregistreerd zijn op de Wereldwijde leverancierslijst van IAB Europe, maar die wel op de lijst met aanbieders van advertentietechnologie (Ad Tech Providers, ATP's) van Google staan.
Componenten van de Aanvullende toestemming
In Aanvullende toestemming bieden we ondersteuning voor het volgende:
- De Transparency and Consent-tekenreeks (TC-tekenreeks) zoals gedefinieerd door de IAB TCF v2.2-specificatie, die de transparantie en toestemming omvat die vastgesteld is voor leveranciers op de Wereldwijde leverancierslijst van IAB. En:
- Een lichtgewicht
addtl_consent-tekenreeks (AT-tekenreeks), die een lijst bevat van aanbieders van Google-advertentietechnologie (ATP's) waarvoor toestemming is gegeven en/of bekendgemaakt is en die niet geregistreerd zijn bij het IAB.
Deze specificatie biedt definities voor het volgende:
-
De indeling van de AT-tekenreeks
-
De uitbreiding voor de TCF v2.2 CMP API ter ondersteuning van de AT-tekenreeks en bedieningselementen voor wanneer zowel het TCF als de toestemmingsmodus voor adverteerders aanwezig zijn.
-
De manier waarop een AT-tekenreeks moet worden opgeslagen.
-
De manier waarop de AT-tekenreeks moet worden doorgestuurd via de digitale advertentieketen.
De indeling voor de Aanvullende toestemming-tekenreeks (AT-tekenreeks)
Welke informatie wordt opgeslagen in een AT-tekenreeks?
Een AT-tekenreeks bevat de volgende componenten:
-
Deel 1: Een versienummer van de specificatie, zoals
2 -
Deel 2: Het scheidingsteken
~ -
Deel 3: Een met punten gescheiden lijst van ID's van Google-aanbieders van advertentietechnologie (ATP, Ad Tech Providers) met gebruikerstoestemming. Bijvoorbeeld:
1.35.41.101 -
Deel 4: Het scheidingsteken
~ -
Deel 5: 'dv.' gevolgd door een met punten gescheiden lijst van vermelde ID's van Google-aanbieders van advertentietechnologie (ATP). Voorbeeld:
dv.9.21.81Leveranciers die opgenomen zijn in Deel 3, mogen niet worden opgenomen in Deel 5 om de tekenreekslengte te beperken.
Voorbeeld van een AT-tekenreeks
De AT-tekenreeks 2~1.35.41.101~dv.9.21.81 betekent dat de gebruiker toestemming heeft gegeven voor ATP's met ID's 1, 35, 41 en 101, dat ATP's met ID's 9, 21 en 81 bekendgemaakt zijn aan de gebruiker, en dat de tekenreeks gemaakt is met de indeling die gedefinieerd is in de v2-specificatie.
Wie moet een AT-tekenreeks maken?
Een AT-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 AT-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 AT-tekenreeks worden gemaakt?
In alle gevallen kan een AT-tekenreeks alleen worden gemaakt als de uitgever het Google-beleid voor toestemming van gebruikers in de EU naleeft.
Toegestane leveranciers mogen alleen worden opgenomen als de gebruiker juridisch geldige toestemming heeft gegeven om:
-
cookies of andere lokale opslag te gebruiken indien dat wettelijk vereist is, en
-
persoonsgegevens te verzamelen, te delen en te gebruiken voor de personalisatie van advertenties door een ATP en voldoen aan alle andere voorwaarden van het Google-beleid voor toestemming van gebruikers in de EU.
Bekendgemaakte leveranciers die geen toestemming hebben voor het volgende, mogen alleen worden opgenomen als gebruikers passende transparantie krijgen over de identiteit van elke ATP, inclusief een link naar het privacybeleid van de ATP dat vermeld wordt in de lijst met aanbieders van advertentietechnologie van Google:
-
cookies of andere lokale opslag te gebruiken indien dat wettelijk is vereist, en
-
persoonsgegevens te verzamelen, te delen en te gebruiken voor gepersonaliseerde advertenties.
Een AT-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 AT-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 AT-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 AT-tekenreeksen voor die leverancier genegeerd. In dit geval behoudt Google zich het recht voor om dergelijke 'dubbele' vermeldingen van de AT-tekenreeks te verwijderen en een gewijzigde AT-tekenreeks naast de TC-tekenreeks door te sturen. De AT-tekenreeks mag niet worden gewijzigd door leveranciers, behalve door Google.
Wijzigingen voor Aanvullende toestemming v2
Sinds december 2023 ondersteunt Google v2 van onze specificatie voor Aanvullende toestemming. De belangrijkste wijzigingen zijn:
- Update van de Aanvullende toestemming-tekenreeks (AT-tekenreeks) om leveranciers te ondersteunen die worden bekendgemaakt in het CMP.
- Update van de CMP API om interoperabiliteit mogelijk te maken voor CMP's die zowel het TCF als de toestemmingsmodus voor adverteerders ondersteunen.
Gecertificeerde CMP's die Aanvullende toestemming ondersteunen
Dit is een lijst van gecertificeerde CMP's die ondersteuning bieden voor de technische specificatie voor Aanvullende toestemming van Google, en de versie van Aanvullende toestemming die ze ondersteunen.
Als u een CMP heeft dat ondersteuning voor Aanvullende toestemming biedt en (1) u niet op deze lijst staat of (2) de verkeerde versie van Aanvullende toestemming wordt vermeld, gaat u naar het intakeformulier voor CMP's en selecteert u het verzoektype Ik wil een vraag stellen of mijn status updaten. We doen ons best om de vermelding tijdig te updaten met uw status.
Meer over de informatie op deze lijst
Deze lijst bevat de volgende informatie over elk gecertificeerd CMP:
- Gecertificeerd CMP: de naam van het gecertificeerde CMP.
- TCF CMP-ID: de unieke ID die het IAB heeft toegewezen aan een voor TCF gevalideerd CMP.
- Aanvullende toestemming: de versie van Aanvullende toestemming die door het CMP wordt ondersteund.
Lijst van gecertificeerde CMP's die Aanvullende toestemming ondersteunen
Uitbreiding van de CMP API
We stellen voor de bestaande TCF v2.2 CMP JavaScript API uit te breiden om de retournering van de AT-tekenreeks mogelijk te maken. Specifieker gezegd: we stellen 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 AT-tekenreeks worden opgeslagen?
Web
Het opslagmechanisme wordt door de CMP gekozen.
In-app
NSUserDefaults (iOS) of SharedPreferences (Android) wordt gebruikt om de AT-tekenreeks op te slaan via een CMP SDK. Hiermee is het volgende mogelijk:
-
Leveranciers hebben makkelijk toegang tot de AT-tekenreeks
-
De AT-tekenreeks blijft actief voor verschillende app-sessies
-
De AT-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 AT-tekenreeks niet blijven gebruiken.
| Storage en Lookup Key in NSUserDefaults en SharedPreferences | Waarde |
IABTCF_AddtlConsent |
Tekenreeks: AT-tekenreeks met specificatieversie en ID's van aanbieders van advertentietechnologie met toestemming |
De manier waarop de AT-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 AT-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 AT-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 AT-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 AT-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
