Oversigt over og vejledning vedrørende europæiske forordninger

Googles tekniske specifikation for Yderligere samtykke

Næste: Fejlfinding i forbindelse med implementeringen af IAB's TCF version 2.2 i EU

Udgivere, der vil arbejde med ikke-TCF-leverandører af annonceteknologi (ATP'er, Ad Technology Providers), bør arbejde direkte med deres CMP'er.

I dette dokument defineres en teknisk specifikation (som betegnes "Yderligere samtykke"), til at sende gennemsigtigheds- og/eller samtykkesignaler til leverandører, som endnu ikke er med på IAB Europes liste over globale leverandører, sammen med IAB Europes forskrifter for gennemsigtighed og samtykke (TCF, Transparency & Consent Framework) version 2. Denne specifikation giver udgivere, partnere og administrationsplatforme for samtykke (CMPs, Consent Management Platforms) mulighed for at indsamle og overføre yderligere samtykke (ud over deres implementering af TCF) for virksomheder, der endnu ikke er med på IAB Europes liste over globale leverandører, men med på Googles liste over leverandører af annonceteknologi (ATP).

Ændringer vedrørende version 2 af Yderligere samtykke

Siden december 2023 har Google understøttet version 2 af vores specifikation for Yderligere samtykke. De primære ændringer er:

Opdatering til strengen Yderligere samtykke (AC-strengen) med henblik på understøttelse af leverandører, der er offentliggjort i CMP'en.
Opdatering af CMP API med henblik på at muliggøre interoperabilitet for CMP'er, der understøtter både TCF og tilstanden Samtykke for annoncører.

AC-strenge, der er genereret på baggrund af v1-specifikationen, understøttes fortsat.

Komponenter i Yderligere samtykke

I "Yderligere samtykke" understøtter vi både:

Strengen for gennemsigtighed og samtykke (TC-streng) (TC, Transparency & Consent), som den er defineret i specifikationen IAB TCF v2.2, som indeholder gennemsigtighed og samtykke, som er fastsat for leverandører på IAB's liste over globale leverandører (GVL, Global Vendor List). OG
En let addtl_consent-streng (AC-streng), som indeholder en liste over Googles leverandører af annonceteknologi (ATP'er, Ad Technology Provider), som har givet samtykke og/eller er offentliggjort, men som ikke er registreret hos IAB.

Denne specifikation definerer følgende:

AC-strengformatet.
Udvidelsen til TCF v2.2 CMP API, der understøtter AC-strengen og kontrollerer for, hvornår både TCF og tilstanden Samtykke for annoncører er til stede.
Sådan gemmes en AC-streng.
Hvordan AC-strengen passerer gennem kæden for digital annoncering.

AC-strengformatet ("Yderligere samtykke")

Hvilke oplysninger gemmes i en AC-streng?

En AC-streng indeholder følgende tre komponenter:

Del 1: Et specifikationsversionsnummer, f.eks. "2"
Del 2: Et separatorsymbol "~"
Del 3: En liste adskilt med punktummer over id'er for Googles leverandører af annonceteknologi (ATP, ad technology provider), hvor brugerne har givet deres samtykke. Eksempel: "1.35.41.101"
Del 4: Et separatorsymbol "~"
Del 5: "dv." efterfulgt af en liste adskilt med punktummer over id'er for Googles offentliggjorte leverandører af annonceteknologi (ATP, Ad Technology Provider). Eksempel: "dv.9.21.81"

For at reducere strenglængden bør leverandører, der er inkluderet i Del 3, ikke være inkluderet i Del 5.

Eksempel på AC-streng

AC-streng 2~1.35.41.101~dv.9.21.81 betyder, at brugeren har givet samtykke til ATP'er (leverandører af annonceteknologi) med id'erne 1, 35, 41 og 101. ATP'er med id'erne 9, 21 og 81 er blevet videregivet til brugeren, og strengen er oprettet ved hjælp af det format, der er defineret i v2-specifikation.

Hvem skal oprette en AC-streng?

En AC-streng må kun oprettes af en CMP, der er TCF-registreret af IAB Europe, og som bruger sit tildelte CMP-id-nummer i overensstemmelse med IAB's forskrifter. Leverandører eller andre udbydere af tredjepartstjenester må ikke selv oprette AC-strenge.

Hvor bliver Google ATP'er udgivet?

Google udgiver listen over leverandører af annonceteknologi, som ikke er registreret hos IAB, samt deres id'er på følgende placering:

https://storage.googleapis.com/tcfac/additional-consent-providers.csv

Hvornår skal der oprettes en AC-streng?

Der må i alle tilfælde kun oprettes en AC-streng, hvis udgiverne overholder Googles samtykkepolitik for brugere i EU.

Leverandører, der har modtaget samtykke, må kun inkluderes, hvis brugeren har givet juridisk gyldigt samtykke til følgende:

Brugen af cookies eller anden lokal lagring, hvor det er juridisk påkrævet, og
Indsamling, deling og brug af personoplysninger med henblik på personlig tilpasning af annoncer fra en udbyder af annonceteknologi samt overholdelse af alle andre vilkår i Googles samtykkepolitik for brugere i EU.

Offentliggjorte leverandører, der ikke har samtykke til

brugen af cookies eller anden lokal lagring, hvor det er juridisk påkrævet, og
indsamling, deling og brug af personoplysninger til en ATP's personlige tilpasning af annoncer, bør kun inkluderes, når brugerne har fået passende gennemsigtighed vedrørende identiteten af hver enkelt leverandør af annonceteknologi (ATP, Ad Technology Provider), herunder link til ATP'ens privatlivspolitik, som den er angivet i Googles liste over ATP'er.

En AC-streng må kun oprettes som en supplerende streng til TC-strengen og ikke som en erstatning for TC-strengen. Google vil ikke behandle anmodningen og vil kassere AC-strengen efter en anmodning modtaget af Google, hvis der ikke er en tilgængelig TC-streng for den pågældende anmodning.

CMP'er, der implementerer denne specifikation, skal sørge for, at den AC-streng, de opretter, kun indeholder id'erne fra den udgivne Google ATP-fil (dvs. ikke-GVL-leverandører). Når Google modtager en TC-streng, tjekker vi den version af listen over globale leverandører, der er angivet i den pågældende TC-streng. Hvis denne version af listen over globale leverandører har en registrering for en leverandør, kontrollerer TC-strengen for denne leverandør, og eventuelle AC-strengposter for den pågældende leverandør vil blive ignoreret. I dette tilfælde forbeholder Google sig retten til at fjerne sådanne "dubletter" af poster og angive en sådan ændret AC-streng sammen med TC-strengen. Andre leverandører end Google ændrer muligvis ikke AC-strengen.

Relaterede ressourcer

Udvidelse til CMP-API'en

Vi foreslår, at du udvider den eksisterende TCF v2.2 CMP JavaScript API for at muliggøre returnering af AC-strengen. Mere specifikt foreslår vi, at du udvider JSON-objekterne TCData og InAppTCData, så de returnerer disse data.

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 en AC-streng opbevares?

Web

Lagringsmetoden afhænger af CMP'ens valg.

I appen

NSUserDefaults (iOS) eller SharedPreferences (Android) skal bruges til at gemme AC-strengen via en CMP-SDK. Det giver mulighed for følgende:

Leverandører kan nemt få adgang til AC-strengen
AC-strengen kan bevares på tværs af appsessioner
AC-strengen kan flyttes mellem CMP'er, hvilket giver en udbyder fleksibilitet til at udskifte én CMP-SDK med en anden

Hvis en udgiver vælger at fjerne en CMP-SDK fra sin app, er udgiveren ansvarlig for at rense AddtlConsent-værdier for brugere, så leverandører ikke fortsætter med at bruge den inkluderede AC-streng.

Lager- og opslagsnøgle i NSUserDefaults og SharedPreferences	Værdi
`IABTCF_AddtlConsent`	Streng: AC-streng med specifikationsversion og id'er for udbydere af annonceteknologi, der er givet samtykke til

Sådan passerer AC-strengen gennem kæden for digitale annoncer

Budanmodning

Vi genbruger ConsentedProvidersSettings til at udfylde leverandører, der ikke er på listen over globale leverandører efterfølgende.

I OpenRTB-udvidelsesprotokol
Tidligere Protobuf-version

message ConsentedProvidersSettings { // Sæt af id'er, der stemmer overens med de udbydere, for hvem udgiveren har meddelt // Google, at deres EØS-brugere har givet juridisk gældende samtykke til: 1) brug af cookies eller anden lokal // lagerplads, hvor det er juridisk påkrævet, og 2) indsamling, deling og brug af personoplysninger til // en ATP's tilpasning af annoncer i overensstemmelse med Googles Samtykkepolitik for brugere i EU. // En tilknytning af udbyder-id til udbydernavn er slået op på providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Oplysninger om de udbydere, for hvem udgiveren har meddelt Google, // at deres EØS-brugere har givet samtykke til brug af deres personoplysninger til // annoncetilpasning i overensstemmelse med Googles samtykkepolitik for brugere i EU. // Dette felt udfyldes kun, når regs_gdpr er sand. valgfrit ConsentedProvidersSettings consented_providers_settings = 42;

Webadressebaserede tjenester

Når annoncemateriale gengives, kan det indeholde et antal pixels under <img>-tags. F.eks. <img src="http://vendor-a.com/key1=val1&key2=val2">, som sender en HTTP GET-anmodning fra browseren til leverandørens domæne.

Da pixelen er et <img>-tag uden mulighed for at eksekvere JavaScript, kan CMP-API'en ikke bruges, uden at TC-strengen skaffes. I lighed med understøttelse af TC-streng leverer vi en standardwebadresseparameter og en makro i de pixelwebadresser, hvor AC-strengen skal indsættes.

Webadresseparameter	Tilsvarende makro	Gengivelse i webadresse
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

Eksempel 1

For at Leverandør A skal modtage en AC-streng, skal en billedwebadresse indeholde et nøgleværdipar med webadresseparameteren og makroen &addtl_consent=${ADDTL_CONSENT}. Den resulterende webadresse er:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=${ADDTL_CONSENT}

Eksempel 2

Hvis AC-strengen for en given anmodning er: 1~1.35.41.101

Opkaldet eller gengiveren af annoncematerialet erstatter makroen i webadressen med den faktiske AC-streng, så den oprindeligt anbragte pixel, der indeholdt makroen, ændres på følgende måde, når opkaldet foretages til den angivne server:

http://vendor-a.com/key1=val1&key2=val2&addtl_consent=1~1.35.41.101

Var disse oplysninger nyttige?

Hvordan kan vi forbedre siden?