Dette dokumentet definerer en teknisk spesifikasjon (kalles «ekstra samtykke») som bare skal brukes sammen med versjon 2 av rammeverket for åpenhet og samtykke (TCF) fra IAB Europe. Den skal sende signaler om åpenhet og/eller samtykke til leverandører som ennå ikke er registrert i listen over globale leverandører (GVL) fra IAB Europe. Med denne spesifikasjonen kan publisister, plattformer for samtykkestyring (CMP-er) og partnere samle inn og overføre ekstra samtykke – i tillegg til TCF-implementeringen – for bedrifter som ennå ikke er registrert i IAB Europes liste over globale leverandører, men som er på Googles liste over leverandører av annonseteknologi (AT-leverandører).
Endringer i versjon 2 av ekstra samtykke
Siden desember 2023 har Google støttet versjon 2 av spesifikasjonen for ekstra samtykke. De viktigste endringene er at vi
- oppdaterer ES-strengen (ekstra samtykke) for å støtte leverandører som tilkjennegis på CMP-en
- oppdaterer til CMP API for å sikre interoperabilitet for CMP-er som støtter både TCF og samtykkemodus for annonsører
Komponentene i ekstra samtykke
I ekstra samtykke støtter vi både
- ÅS-strengen (åpenhet og samtykke) som definert i spesifikasjonen for versjon 2.2 av TCF fra IAB, som omfatter kravene til åpenhet og samtykke etablert for leverandører oppført i IABs liste over globale leverandører (GVL)
- en enkel versjon av
addtl_consent
-strengen (ES-strengen), som inneholder en liste over Google-leverandører av annonseteknologi brukere har samtykket til bruk av, og/eller blitt opplyst om, men som ikke er IAB-registrert
Denne spesifikasjonen definerer også
-
formatet til ES-strengen
-
utvidelsen av CMP API for versjon 2.2 av TCF som trengs for å støtte ES-strengen, samt kontroller for tilfeller der både TCF og samtykkemodus for annonsører foreligger
-
hvordan ES-strengen skal lagres
-
hvordan ES-strengen skal sendes via den digitale annonseringskjeden
Formatet til ES-strengen (ekstra samtykke)
Hva slags informasjon lagres i ES-strenger?
ES-strenger består av følgende komponenter:
-
Del 1: et versjonsnummer for spesifikasjonen, for eksempel «
2
» -
Del 2: skilletegnet «
~
» -
Del 3: en punktumdelt liste over ID-er for Google-leverandører av annonseteknologi som brukere har samtykket til bruk av – for eksempel «
1.35.41.101
» -
Del 4: skilletegnet «
~
» -
Del 5: «dv.» etterfulgt av en punktumdelt liste over oppgitte ID-er for Google-leverandører av annonseteknologi (AT-leverandører) – for eksempel «
dv.9.21.81
»For at strengens lengde skal bli mer håndterbar, skal ikke leverandører som er tatt med i del 3, inkluderes i del 5.
Eksempel på ES-streng
ES-strengen 2~1.35.41.101~dv.9.21.81
betyr at brukeren har samtykket til AT-leverandørene med ID-ene 1
, 35
, 41
og 101
. AT-leverandørene med ID-ene 9
, 21
og 81
er tilkjennegitt overfor brukeren, og strengen har formatet definert i v2-spesifikasjonen.
Hvem skal opprette ES-strenger?
ES-strenger kan bare opprettes av CMP-er som er registrert i TCF (rammeverket for åpenhet og samtykke) fra IAB Europe, og CMP-ene skal være registrert med CMP-ID-nummeret de er tilordnet i tråd med retningslinjene for IAB. Leverandører og andre tredjeparts tjenesteleverandører kan ikke opprette ES-strenger selv.
Hvor publiseres listen over Google-leverandører av annonseteknologi?
Her publiserer Google listen over leverandører av annonseteknologi som ikke er registrert med IAB, og ID-ene de er tilordnet:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Når skal ES-strenger opprettes?
Uansett hva som er årsaken til at ES-strengen opprettes, må den aktuelle publisisten overholde Googles retningslinjer for brukersamtykke i EU.
Leverandører som brukeren har samtykket til bruk av, skal kun tas med hvis brukeren har gitt juridisk gyldig samtykke i:
-
bruken av informasjonskapsler eller annen lokal lagring der dette er lovpålagt; og
-
at en AT-leverandør kan samle inn, dele og bruke personopplysninger til personlig tilpasning av annonser – i tillegg skal alle vilkår i Googles retningslinjer for brukersamtykke i EU overholdes.
Tilkjennegitte leverandører som ikke har fått samtykke til
-
bruken av informasjonskapsler eller annen lokal lagring der dette er lovpålagt; eller
-
innsamling, deling og bruk av personopplysninger til å gjøre annonser personlig tilpassede, skal kun tas med hvis de gir brukerne tilstrekkelig informasjon om identiteten til de enkelte AT-leverandørene, deriblant ved å ta med en link til den aktuelle AT-leverandørens personvernregler, som oppgitt i Googles liste over AT-leverandører.
ES-strengen skal bare brukes som et supplement til ÅS-strengen, aldri i stedet for ÅS-strengen. Forespørsler uten ÅS-strengen blir ikke behandlet av Google, som også forkaster forespørsler som bare inneholder ES-strengen og ikke ÅS-strengen.
CMP-er som implementerer denne spesifikasjonen, må påse at ES-strengen de oppretter, bare inneholder ID-er fra listen over leverandører av annonseteknologi som Google har publisert (altså leverandører som ikke er oppført i GVL). Når Google mottar en ÅS-streng, sjekker vi GVL-versjonen oppført i ÅS-strengen. Hvis en angitt leverandør er registrert i den aktuelle GVL-versjonen, ser ÅS-strengen etter oppføringer av denne leverandøren, og eventuelle oppføringer ignoreres. I slike tilfeller forbeholder Google seg retten til å fjerne slike «dupliserte» oppføringer fra ES-strengen og overføre den redigerte ES-strengen sammen med ÅS-strengen. Andre leverandører enn Google skal ikke redigere ES-strengen.
Relaterte ressurser
-
Åpenhet og samtykke-streng i formatet for versjon 2.2 av listen over globale leverandører
-
Retningslinjer for rammeverket for åpenhet og samtykke fra IAB Europe
Sertifiserte CMP-er som støtter ekstra samtykke
I denne listen finner du sertifiserte CMP-er som støtter Googles tekniske spesifikasjon for ekstra samtykke, samt hvilken versjon av ekstra samtykke CMP-ene støtter.
Hvis du representerer en CMP som støtter ekstra samtykke, men (1) ikke er oppført på denne listen, eller hvis (2) feil versjon av ekstra samtykke er oppført, kan du gå til registreringsskjemaet for CMP-er og velge «Jeg ønsker å stille et spørsmål eller oppdatere statusen min» som type forespørsel. Vi skal gjøre vårt beste for å oppdatere oppføringen med den aktuelle statusen så snart som mulig.
Veiledning om informasjonen i denne listen
Informasjon i denne listen om hver sertifiserte CMP:
- Sertifisert CMP: navnet på den sertifiserte CMP-en.
- CMP-ID for TCF: den unike identifikatoren tilordnet en CMP som er godkjent av IAB i henhold til rammeverket for åpenhet og samtykke (TCF).
- Ekstra samtykke: versjonen av ekstra samtykke som CMP-en støtter.
Liste over sertifiserte CMP-er som støtter ekstra samtykke
Utvidelse til CMP API
Vi foreslår at du utvider CMP JavaScript API for versjon 2.2 av TCF, slik at ES-strengen kan returneres. Mer spesifikt foreslår vi at du utvider JSON-objektene TCData og InAppTCData slik at de kan returnere disse dataene.
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’
}
Hvordan skal ES-strenger lagres?
Nett
Hvilken lagringsmekanisme som brukes, er opp til den aktuelle CMP-en.
I app
I SDK-er som benyttes av CMP-er, skal NSUserDefaults (iOS) eller SharedPreferences (Android) brukes til å lagre ES-strengen. Dette bidrar til at
-
leverandører har enkel tilgang til ES-strengen
-
ES-strengen er konsekvent i alle appøkter
-
ES-strengen kan flyttes mellom ulike CMP-er, slik at publisister kan bytte mellom CMP-SDK-er
Hvis en publisist velger å fjerne et CMP-SDK fra appen sin, er hen selv ansvarlig for å slette AddtlConsent
-verdiene for brukere, slik at leverandører ikke fortsetter å bruke den inkluderte ES-strengen.
Lagrings- og oppslagsnøkkel i NSUserDefaults og SharedPreferences | Verdi |
IABTCF_AddtlConsent |
Streng: ES-streng med spesifikasjonsversjon og ID-er for leverandører av annonseteknologi det er samtykket til bruk av |
hvordan ES-strengen skal overføres via den digitale annonseringskjeden
Budforespørsel
Vi gjenbruker ConsentedProvidersSettings
til å overføre listen over leverandører som ikke er GVL-oppført, senere i prosessen:
- i protokollen for åpen RTB-utvidelser
- eldre versjon av protokollbuffer
message ConsentedProvidersSettings {
// Et sett av ID-er for leverandører som publisisten har fortalt Google at
// EØS-brukerne sine har gitt juridisk gyldig samtykke til: 1) at kan bruke informasjonskapsler eller
// annen lokal lagring der dette er lovpålagt; og 2) at en leverandør av annonseteknologi kan samle inn, dele og bruke personopplysninger
// til personlig tilpasning av annonser i samsvar med Googles retningslinjer for brukersamtykke i EU.
// På providers.csv har vi publisert en oversikt over tilordningen mellom leverandør-ID-er og leverandørnavn.
repeated int64 consented_providers = 2 [packed = true];
}
// Informasjon om leverandørene som publisisten har fortalt Google
// at EØS-brukerne sine har samtykket til at kan bruke personopplysningene deres
// til personlig tilpasning av annonser i samsvar med Googles retningslinjer for brukersamtykke i EU.
// Dette feltet fylles bare ut dersom regs_gdpr er «true» sann.
optional ConsentedProvidersSettings consented_providers_settings = 42;
Nettadressebaserte tjenester
Når en reklame gjengis, kan den ha en rekke piksler oppført under <img>
-tagger. Et eksempel kan være <img src="http://vendor-a.com/key1=val1&key2=val2">
, som sender en HTTP GET
-forespørsel fra nettleseren til leverandørens domene.
Siden pikselen er plassert i en <img>
-tag som ikke kan kjøre JavaScript, kan ikke ÅS-strengen hentes via API-et for CMP-en. På samme måte som vi støtter ÅS-strengen, tilbyr vi en standard nettadresseparameter og en makro i pikselnettadressene der ES-strengen skal settes inn.
Nettadresseparameter | Tilsvarende makro | Gjengivelse i nettadressen |
addtl_consent |
ADDTL_CONSENT |
&addtl_consent=${ADDTL_CONSENT} |
Eksempel 1
For at leverandør A skal motta en ES-streng, må den aktuelle bildenettadressen inneholdet et nøkkelverdi-par med nettadresseparameteren og makroen &addtl_consent=${ADDTL_CONSENT}
. Den resulterende nettadressen er
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}
Eksempel 2
Hvis ES-strengen er 1~1.35.41.101
i en gitt forespørsel:
Den som ber om eller gjengir reklamen, erstatter makroen i nettadressen med den faktiske ES-strengen, slik den opprinnelig innsatte pikselen som inneholder makroen, blir endret som angitt nedenfor, når forespørselen går til den bestemte tjeneren:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101