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.
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.
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 (Ad Tech Providers, ATP) 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 en andere derde serviceproviders mogen zelf geen AT-tekenreeksen maken.
Waar worden de Google-ATP's gepubliceerd?
Google publiceert de lijst met aanbieders van advertentietechnologie die niet bij IAB geregistreerd zijn, 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 om
-
cookies of andere lokale opslag te gebruiken indien dat wettelijk vereist is, en
-
persoonsgegevens te verzamelen, delen en gebruiken voor de personalisatie van advertenties, 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.
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 krijgt waarvoor geen TC-tekenreeks beschikbaar is.
CPM's die deze specificatie implementeren, moeten ervoor zorgen dat de door deze platforms 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 krijgt, wordt de versie gecheckt 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. Leveranciers mogen de AT-tekenreeks niet wijzigen. Alleen Google mag dit doen.
Gerelateerde bronnen
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 het 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 de ene CMP SDK voor de andere kan verwisselen.
Als een uitgever besluit 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.
| Opslag- en zoeksleutel 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 gebruiken de ConsentedProvidersSettings opnieuw om de leveranciers die niet op de GVL staan, later in het proces door te verwijzen.
- In OpenRTB-extensies proto
- Verouderde Protobuf-versie
message ConsentedProvidersSettings {
// Reeks ID's van providers voor wie de uitgever Google heeft laten weten
// dat hun gebruikers in de EER juridisch geldende toestemming hebben gegeven voor: 1) het gebruik van cookies of andere lokale
// opslag waar dit wettelijk is vereist, en 2) het verzamelen, delen en gebruiken van persoonsgegevens voor
// de personalisatie van advertenties door een ATP in overeenstemming met het Google-beleid voor toestemming van gebruikers in de EU.
// Een toewijzing van provider-ID aan een providernaam wordt gepost op providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Informatie over de providers voor wie de uitgever Google heeft laten weten
// dat hun gebruikers in de EER toestemming hebben gegeven voor het gebruik van hun persoonsgegevens voor
// de personalisatie van advertenties in overeenstemming met het Google-beleid voor toestemming van gebruikers in de EU.
// Dit veld wordt alleen ingevuld als regs_gdpr waar is.
optional ConsentedProvidersSettings consented_providers_settings = 42;
URL-gebaseerde services
Als advertentiemateriaal wordt getoond, 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 een macro in de pixel-URL's als 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 krijgen, 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 is de AT-tekenreeks: 1~1.35.41.101
De caller of het weergaveprogramma van het advertentiemateriaal vervangt de macro in de URL door de daadwerkelijke AT-tekenreeks. Hierdoor wordt de oorspronkelijk geplaatste pixel met de macro zo gewijzigd als de aanroep naar de aangegeven server wordt uitgevoerd:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101