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.
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
Certifierade CMP:er som stöder Ytterligare samtycke
Listan innehåller certifierade CMP:er som stöder Googles tekniska specifikation för Ytterligare samtycke samt den version av Ytterligare samtycke som de stöder.
Om du är en CMP som stöder Ytterligare samtycke och (1) inte finns med på den här listan eller (2) fel version av Ytterligare samtycke anges kan du fylla i intagningsformuläret för CMP och välja begäran Jag vill ställa en fråga eller uppdatera min status. Vi gör vårt bästa för att uppdatera uppgifterna så att de återspeglar din status i god tid.
Förklaring av informationen på listan
Listan innehåller följande information om varje certifierad CMP:
- Certifierad CMP: Namnet på den certifierade CMP:n.
- TCF CMP-id: Den unika identifierare som IAB har gett en TCF-validerad CMP.
- Ytterligare samtycke: Den version av Ytterligare samtycke som CMP:n stöder.
Lista över certifierade CMP:er som stöder Ytterligare samtycke
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