I denne artikkelen
- Komponentene i ekstra samtykke
- Formatet til ES-strengen (ekstra samtykke)
- CMP-er som støtter ekstra samtykke
- Utvidelse til CMP API
- Hvordan skal ES-strenger lagres?
- Slik overføres ES-strengen gjennom den digitale annonseringskjeden
- Relaterte ressurser
Dette dokumentet beskriver Googles tekniske spesifikasjon for ekstra samtykke, som bare skal brukes sammen med versjon 2 av rammeverket for åpenhet og samtykke (TCF) fra IAB Europe for å sende signaler om åpenhet og/eller samtykke til leverandører som ennå ikke er registrert på 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 på IAB Europes liste over globale leverandører, men som er på Googles liste over leverandører av annonseteknologi (AT-leverandører).
Komponentene i ekstra samtykke
Ekstra samtykke består av en enkel versjon av addl_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 registrert på listen over globale leverandører (GVL) fra IAB Europe.
Slik genererer du en streng for versjon 2 av ekstra samtykke (ESv2)
Hvilken informasjon lagres i ES-strenger?
ES-strenger består av disse komponentene:
-
Del 1: versjonsnummeret for spesifikasjonen. Den gjeldende versjonen er «
2». -
Del 2: skilletegnet «
~» -
Del 3: en punktumdelt liste over ID-er for Google-leverandører av annonseteknologi (annonseteknologi-partnere) som brukere har samtykket i 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 (annonseteknologi-partnere) – for eksempel «
dv.9.21.81»For å begrense strengens lengde skal ikke leverandører som er med i del 3, tas med i del 5.
Eksempler på ES-strenger
Hvis annonseteknologi-partnere med ID-ene 1, 2, 3, 4 og 10 er vist til brukeren,
- og brukeren har sett CMP-meldingen som opplyser om disse leverandørene, men ikke har tatt en avgjørelse om samtykke ennå, blir ESv2-strengen
2~~dv.1.2.3.4.10 -
og brukeren har gitt samtykke til alle leverandører, blir ESv2-strengen
2~1.2.3.4.10~dv.(punktumet «.» etter dv er valgfritt bare i dette tilfellet, så2~1.2.3.4.10~dver også en godkjent ESv2-streng) - og brukeren har avvist samtykke for alle leverandører, skal ESv2-strengen vise at alle leverandører er oppgitt, men at det ikke er gitt samtykke til noen av dem, så ESv2-strengen blir
2~~dv.1.2.3.4.10 - og brukeren har gitt samtykke til leverandør
1og10, men avvist samtykke til alle andre leverandører, blir ESv2-strengen2~1.10~dv.2.3.4
Hvem skal lage ES-strenger?
ES-strenger kan bare lages 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 lage ES-strenger selv.
Hvor publiseres listen over Googles annonseteknologi-partnere?
Her har Google en liste over leverandører av annonseteknologi som ikke er registrert hos IAB, og ID-ene deres:
https://storage.googleapis.com/tcfac/additional-consent-providers.csv
Når skal ES-strenger lages?
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 i bruk av, skal kun tas med hvis brukeren har gitt juridisk gyldig samtykke til
-
bruk av informasjonskapsler eller annen lokal lagring der dette er lovpålagt, og
-
innsamling, deling og bruk av personopplysninger til personlig tilpasning av annonser via en annonseteknologi-partner samt overholdelse av alle andre vilkår i Googles retningslinjer for brukersamtykke i EU
Oppgitte leverandører skal kun tas med hvis de gir brukerne nok informasjon om identiteten til hver annonseteknologi-partner, blant annet ved å ta med en link til den aktuelle annonseteknologi-partnerens personvernregler i henhold til Googles liste over annonseteknologi-partnere. Leverandører på listen over leverandører en bruker har samtykket i bruk av, trenger ikke også å være på listen over leverandører brukeren er informert om.
ES-strengen skal bare brukes som et supplement til ÅS-strengen, aldri i stedet for ÅS-strengen. Hvis Google mottar en forespørsel med ES-streng, men uten ÅS-streng, blir forespørselen ikke behandlet, og ES-strengen blir forkastet.
CMP-er som implementerer denne spesifikasjonen, må sørge for at ES-strengen de lager, bare inneholder ID-er fra listen over annonseteknologi-partnere som Google har publisert (som ikke er i GVL). Når Google mottar en ÅS-streng, sjekker vi GVL-versjonen som er oppført i ÅS-strengen. Hvis en leverandør er registrert i denne GVL-versjonen, ser ÅS-strengen etter oppføringer av denne leverandøren, og eventuelle oppføringer av leverandøren i ES-strengen blir ignorert. 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.
Støttes fortsatt versjon 1 av strenger for ekstra samtykke?
Versjon 2 av ekstra samtykke har vært standardversjonen siden desember 2023. Strenger for ekstra samtykke som er generert basert på spesifikasjonen i versjon 1, støttes fortsatt. Men slike strenger kan ikke indikere om det er fastslått åpenhet for en annonseteknologi-partner. For å støtte bruksmønstre som ikke krever samtykke, bør CMP-er bruke versjon 2 av spesifikasjonen.
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
CMP-er som støtter ekstra samtykke, skal returnere strengen for ekstra samtykke som en del av de eksisterende JSON-objektene for CMP JavaScript API for versjon 2 av TCF, TCData og InAppTCData.
TCData = {
tcString: 'base64url-kodet ÅS-streng med segmenter',
...
addtlConsent: ‘ES-streng med spesifikasjonsversjon og ID-er for samtykkede/oppgitte leverandører av annonseteknologi’
}
InAppTCData = {
tcString: 'base64url-kodet ÅS-streng med segmenter',
...
addtlConsent: ‘ES-streng med spesifikasjonsversjon og ID-er for samtykkede/oppgitte leverandører av annonseteknologi’
}
Hvordan skal ES-strenger lagres?
Nett
Hvilken lagringsmekanisme som brukes, er opp til den aktuelle CMP-en.
I app
NSUserDefaults (iOS) eller SharedPreferences (Android) brukes til å lagre ES-strengen som genereres av en CMP-SDK, på samme måte som API-et i appen for TCF versjon 2. Denne mekanismen gjør følgende mulig:
-
Leverandører har enkel tilgang til ES-strengen.
-
ES-strengen er konsekvent i alle appøkter.
-
ES-strengen kan flyttes hvis publisisten bytter CMP.
Merk: 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 med samtykke |
Slik overføres ES-strengen gjennom den digitale annonseringskjeden
Budforespørsler
Budforespørsler bruker ConsentedProvidersSettings til å overføre listen over leverandører som ikke er GVL-oppført, senere i prosessen
- i utvidelser for OpenRTB-protokollen
- i en eldre versjon av Protobuf
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) bruk av informasjonskapsler eller annen lokal
// lagring der dette er lovpålagt; og 2) innsamling, deling og bruk av personopplysninger
// via en annonseteknologi-partner til personlig tilpasning av annonser i samsvar med Googles retningslinjer for brukersamtykke i EU.
// Vi har publisert en oversikt over tilordningen mellom leverandør-ID-er og leverandørnavn i providers.csv.
repeated int64 consented_providers = 2 [packed = true];
}
// Informasjon om leverandørene som publisisten har fortalt Google
// at EØS-brukerne sine har samtykket i bruk av personopplysningene deres
// til personlig tilpasning av annonser i samsvar med Googles retningslinjer for brukersamtykke i EU.
// Dette feltet fylles bare ut hvis regs_gdpr er «true».
optional ConsentedProvidersSettings consented_providers_settings = 42;
Nettadressebaserte tjenester
Når en reklame vises, kan den ha flere 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 i en <img>-tag som ikke kan kjøre JavaScript, kan ikke CMP-API-et brukes til å hente ÅS-strengen. 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 | Korresponderende makro | Plassering 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 inneholde et nøkkel/verdi-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 2~1.35.41.101~dv. i en gitt forespørsel:
Den som ber om eller viser reklamen, erstatter makroen i nettadressen med den faktiske ES-strengen, slik at den opprinnelig innsatte pikselen som inneholder makroen, blir endret som angitt nedenfor, i forespørselen til den spesifiserte tjeneren:
http://vendor-a.com/key1=val1&key2=val2&addtl_consent=2~1.35.41.101~dv.