Oversikt over og veiledning om europeiske forordninger

Googles tekniske spesifikasjon for ekstra samtykke

Neste: Feilsøking av implementering av TCF versjon 2.2 for EU fra IAB

Publisister som vil samarbeide med leverandører av annonseteknologi (AT-leverandører) som ikke er TCF-registrert (rammeverket for åpenhet og samtykke), må samarbeide direkte med CMP-ene sine.

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

ES-strenger som er generert basert på v1-spesifikasjonen, støttes fortsatt.

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

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

Var dette nyttig for deg?

Hvordan kan vi forbedre den?