Översikt och vägledning om EU-förordningar

Googles tekniska specifikation för ytterligare samtycke

Nästa: Felsöka implementering av IAB EU TCF v2.2

Utgivare som vill arbeta med annonsteknikleverantörer som inte använder TCF bör samarbeta direkt med sina CMP:er.

Detta dokument definierar en teknisk specifikation (kallad Ytterligare samtycke) som endast är avsedd att användas tillsammans med IAB Europes Transparency & Consent Framework (TCF) v2 för att skicka signaler om insyn och/eller samtycke till leverantörer som ännu inte har registrerats på IAB Europes globala leverantörslista (GVL). Enligt denna specifikation kan utgivare, plattformar för samtyckeshantering (CMP) och partner samla in och sprida ytterligare samtycke, utöver sin implementering av TCF, för företag som ännu inte har registrerats på IAB Europes globala leverantörslista men som finns med på Googles lista över leverantörer av annonsteknik (ATP).

Ändringar för ytterligare samtycke v2

Sedan december 2023 stöder Google stöd version 2 av vår specifikation för Ytterligare samtycke. De primära ändringarna är dessa:

Uppdatering av strängen för ytterligare samtycke (AC) för att stödja leverantörer som anges i CMP.
Uppdatering av CMP-API:et för att möjliggöra kompatibilitet för CMP:er som har stöd för både TCF och samtyckesläge för annonsör.

AC-strängar som genereras baserat på v1-specifikationen fortsätter att stödjas.

Komponenter i Ytterligare samtycke

Ytterligare samtycke ger stöd för både

Transparency & Consent-strängen (TC-strängen) enligt definitionen i specifikationen för IAB TCF v2.2, som beskriver den transparens- och samtyckesmekanism som har upprättats för leverantörer på IAB:s globala leverantörslista (GVL). och
en begränsad addtl_consent-sträng (AC-sträng), som innehåller en lista över Googles annonsteknikleverantörer (ATP) som användaren har gett sitt samtycke till eller informerats om och som inte har registrerats hos IAB.

Specifikationen definierar följande:

AC-strängformatet
tillägget till TCF v2.2 CMP-API:et för att stödja AC-strängen samt kontroller för när det finns både TCF och samtyckesläge för annonsör
hur AC-strängen ska lagras
hur AC-strängen skickas med i kedjan för digital annonsering

AC-strängformatet

Vilken information lagras i AC-strängen?

AC-strängen innehåller följande tre komponenter:

del 1: specifikationens versionsnummer, till exempel ”2”
del 2: avgränsaren ”~”
del 3: en punktavgränsad lista över id:n för Googles leverantörer av annonsteknik som användaren har gett sitt samtycke till Exempel: ”1.35.41.101”
del 4: avgränsaren ”~”
del 5: ”dv.” följt av en punktavgränsad lista med id:n för Googles leverantörer av annonsteknik. Exempel: ”dv.9.21.81”

Leverantörer som ingår i del 3 ska inte inkluderas i del 5 för att minska stränglängden.

Exempel på AC-sträng

AC-strängen 2~1.35.41.101~dv.9.21.81 innebär att användaren har samtyckt till ATP:er med id:na 1, 35, 41 och 101, ATP:er med id:n 9, 21 och 81 har angetts för användaren, och strängen skapas enligt det format som definieras i v2-specifikationen.

Vem ska skapa en AC-sträng?

AC-strängen kan endast skapas av en IAB Europe TCF-registrerad CMP med dess tilldelade CMP-id i enlighet med IAB:s policyer. Leverantörer eller andra tredje parts tjänsteleverantörer får inte själva skapa AC-strängar.

Var publiceras Googles annonsteknikleverantörer?

Google publicerar listan över annonsteknikleverantörer (ATP:er) som inte har registrerats hos IAB och deras id:n på följande plats:

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

När ska AC-strängen skapas?

AC-strängen kan endast skapas om utgivaren följer Googles policy för användares medgivande inom EU.

Leverantörer som har gett sitt samtycke ska endast inkluderas när användaren har gett sitt juridiskt giltiga samtycke till att

använda cookies eller annan lokalt lagrad data om det krävs enligt lag
samla in, lämna ut och använda personuppgifter i syfte att anpassa annonser av en ATP samt följa alla andra villkor i Googles policy för användares medgivande inom EU.

Leverantörer som har meddelats men inte har inhämtat samtycke till att

använda cookies eller annan lokalt lagrad data om det krävs enligt lag
samla in, lämna ut och använda personuppgifter i syfte att anpassa annonser ska endast inkluderas när lämplig insyn har getts till användarna om varje ATP:s identitet, inklusive länkning till ATP:ns integritetspolicy enligt Googles lista över annonsteknikleverantörer.

AC-strängen får endast skapas som en kompletterande sträng till TC-strängen och får inte ersätta TC-strängen. Google ignorerar AC-strängen och behandlar inte mottagna förfrågningar om de inte inkluderar en TC-sträng.

CMP:er som implementerar denna specifikation måste säkerställa att AC-strängen endast innehåller id:n från den publicerade Google ATP-filen (det vill säga leverantörer som inte finns med på GVL). När Google tar emot en TC-sträng kontrollerar vi vilken version av GVL som ingår i TC-strängen. Om GVL innehåller en registrerad leverantör ignoreras TC-strängkontrollerna och eventuella leverantörsposter i AC-strängen. Google förbehåller sig rätten att ta bort sådana ”dubbletter” av poster från AC-strängen och att skicka med sådana modifierade AC-strängar tillsammans med TC-strängen. AC-strängen får inte modifieras av andra leverantörer än Google.

Relaterade resurser

Tillägg till CMP-API:et

Vi rekommenderar att du utökar det befintliga TCF v2.2 CMP JavaScript-API:et för att tillåta returnering av AC-strängen. Specifikt rekommenderar vi att du utökar JSON-objekten TCData och InAppTCData för att returnera denna data.

TCData = {
tcString: 'base64url-kodad TC-sträng med segment',
...
addtlConsent: ‘AC-sträng med specifikationsversion och id:n för leverantörer av annonsteknik som användaren har gett sitt samtycke till’
}

InAppTCData = {
tcString: 'base64url-kodad TC-sträng med segment',
...
addtlConsent: ‘AC -sträng med specifikationsversion och id:n för leverantörer av annonsteknik som användaren har gett sitt samtycke till’
}

Så ska AC-strängen lagras

Webben

CMP:n väljer själv vilken lagringsmekanism som ska användas.

I appen

NSUserDefaults (iOS) eller SharedPreferences (Android) ska användas för att lagra AC-strängen från ett CMP-SDK. Detta resulterar i att

leverantörer får enkel åtkomst till AC-strängen
AC-strängen sparas mellan appsessioner
AC-strängen kan flyttas över mellan olika CMP:er för att ge utgivarna flexibilitet att ersätta ett CMP-SDK med ett annat.

Om en utgivare väljer att ta bort ett CMP-SDK från sin app ansvarar han eller hon för att rensa AddtlConsent-värden för användare så att leverantörerna inte fortsätter använda den inkluderade AC-strängen.

Nyckel för lagring och sökning i NSUserDefaults och SharedPreferences	Värde
`IABTCF_AddtlConsent`	Sträng: AC-sträng med specifikationsversion och id:n för leverantörer av annonsteknik som användaren har gett sitt samtycke till

Så ska AC-strängen skickas med i kedjan för digital annonsering

Budbegäran

Vi återanvänder ConsentedProvidersSettings för att skicka vidare leverantörerna som inte finns med på GVL nedströms.

i protokollet för OpenRTB-tillägg
äldre Protobuf-version

message ConsentedProvidersSettings { // Uppsättning id:n för leverantörer för vilka utgivaren har meddelat Google // att dess användare i EES har gett juridiskt giltigt samtycke till 1) användning av cookies eller andra lokala // lagringsmekanismer där detta krävs enligt lag och 2) insamling, delning och användning av personuppgifter i syfte att // anpassa annonser av en ATP i enlighet med Googles policy för användares medgivande inom EU. // En mappning av leverantörs-id:n och leverantörsnamn publiceras i providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information om leverantörer för vilka utgivaren har meddelat Google // att dess användare i EES har gett samtycke till att deras personuppgifter används för // annonsanpassning i enlighet med Googles policy för användares medgivande inom EU. // Detta fält fylls bara när regs_gdpr är sant. optional ConsentedProvidersSettings consented_providers_settings = 42;

Webbadressbaserade tjänster

När en annons renderas kan den innehålla ett antal pixlar under <img>-taggar. Exempel: <img src="http://vendor-a.com/key1=val1&key2=val2">, som skickar en HTTP GET-begäran från webbläsaren till leverantörens domän.

Eftersom pixeln finns i en <img>-tagg utan möjlighet att köra JavaScript går det inte att använda CMP-API:et för att hämta TC-strängen. Precis som när det gäller stöd för TC-strängen tillhandahåller vi en standardinställd webbadressparameter och ett makro i pixelwebbadresserna där AC-strängen ska infogas.

Webbadressparameter	Motsvarande makro	Komponent i webbadressen
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

Exempel 1

För att leverantör A ska ta emot en AC-sträng måste bildwebbadressen innehålla ett nyckel-värdepar med webbadressparametern och makrot &addtl_consent=${ADDTL_CONSENT}. Den resulterande webbadressen är:

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

Exempel 2

AC-strängen i en given begäran är: 1~1.35.41.101

Servern som anropar eller renderar annonsen ersätter makrot i webbadressen med den faktiska AC-strängen. Den ursprungliga pixeln som innehåller makrot modifieras enligt följande när anropet sker till den angivna servern:

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

Var det här till hjälp?

Hur kan vi förbättra den?