Programové zásady AdMob a AdSense

Technické specifikace režimu dalšího souhlasu společnosti Google

Tento dokument definuje technickou specifikaci („režim dalšího souhlasu“), která se má používat společně se systémem Transparency & Consent Framework (TCF) 2.0 organizace IAB Europe jako spojovací článek pro dodavatele, kteří ještě nejsou registrováni v globálním seznamu dodavatelů (GVL) IAB Europe. Tato specifikace majitelům stránek, poskytovatelům správy souhlasů (CMP) a partnerům umožňuje shromažďovat a propagovat další souhlas — souběžně s implementací systému TCF verze 2.0 — pro společnosti, které dosud nejsou zaregistrovány v globálním seznamu dodavatelů organizace IAB Europe, ale jsou v seznamu poskytovatelů reklamních technologií (ATP) společnosti Google.

Související zdroje

Součásti režimu dalšího souhlasu

V režimu dalšího souhlasu podporujeme oba následující řetězce:

řetězec transparentnosti a souhlasu (řetězec TC) definovaný ve specifikaci IAB TCF 2.0, který obsahuje informace o transparentnosti a souhlasu získaném pro dodavatele na globálním seznamu dodavatelů (GVL) organizace IAB,
stručný řetězec addtl_consent (řetězec AC), který obsahuje seznam poskytovatelů reklamních technologií Google, pro které byl udělen souhlas a kteří nejsou zaregistrováni u organizace IAB.

Tato specifikace definuje:

formát řetězce AC,
rozšíření rozhraní TCF v2.0 CMP API pro podporu řetězce AC,
požadovaný způsob uložení řetězce AC,
způsob předávání řetězce AC v řetězci digitální inzerce.

Formát řetězce dalšího souhlasu (AC)

Jaké informace řetězec AC obsahuje?

Řetězec AC obsahuje následující tři části:

část 1: číslo verze specifikace, například „1“,
část 2: oddělovač „~“,
část 3: seznam tečkami oddělených identifikátorů poskytovatelů reklamních technologií (ATP) Google, pro které uživatel udělil souhlas. Příklad: „1.35.41.101“

Řetězec AC 1~1.35.41.101 například znamená, že uživatel udělil souhlas s použitím poskytovatelů reklamních technologií s ID 1, 35, 41 a 101 a že řetězec odpovídá formátu definovanému ve verzi 1.0 specifikace.

Kdo by měl řetězec AC vytvořit?

Řetězec AC může vytvořit pouze platforma CMP zaregistrovaná do systému TCF organizace IAB Europe, která musí použít svoje přiřazené identifikační číslo platformy CMP v souladu se zásadami organizace IAB. Dodavatelé ani žádní jiní externí poskytovatelé služeb řetězce AC sami vytvářet nesmějí.

Kde budou poskytovatelé reklamních technologií Google publikováni?

Seznam poskytovatelů reklamních technologií, kteří nejsou zaregistrováni u organizace IAB, a jejich identifikátorů publikuje společnost Google v následujícím umístění:

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

Kdy se má řetězec AC vytvářet?

Řetězec AC je povoleno vytvořit pouze v případě, že majitel obsahu splňuje zásady společnosti Google pro souhlas uživatele z EU. Řetězec AC konkrétně není dovoleno vytvořit předtím, než uživatel udělí právně platný souhlas k: 1) používání souborů cookie či jiného místního úložiště, pokud to je právně vyžadováno, a 2) shromažďování, sdílení a používání osobních údajů k personalizaci reklam ze strany poskytovatele reklamních technologií v souladu se zásadami společnosti Google pro souhlas uživatele z EU.

Řetězec AC musí být vytvářen pouze jako doplňující řetězec k řetězci TC, nikoliv namísto řetězce TC. Pokud Google obdrží žádost, pro kterou není k dispozici řetězec TC, nezpracuje ji a její řetězec AC nepoužije.

Platformy CM, které implementují tuto specifikaci, musejí zajistit, aby vytvořený řetězec AC obsahoval pouze ID ze seznamu poskytovatelů reklamních technologií publikovaného společností Google (tj. dodavatele, kteří nejsou na seznamu GVL). Když Google obdrží řetězec TC, zkontroluje verzi seznamu GVL, která je v něm uvedena. Pokud daná verze seznamu GVL obsahuje registraci dodavatele, možnosti pro daného dodavatele v řetězci TC a záznamy pro daného dodavatele v řetězci AC budou ignorovány. Za těchto okolností si společnost Google vyhrazuje právo takové „duplicitní“ položky z řetězce AC odstranit a předat s řetězcem TC takto upravený řetězec AC. Jiní dodavatelé než Google řetězec AC upravovat nesmějí.

Rozšíření rozhraní CMP API

Navrhujeme rozšířit existující javascriptové rozhraní API řešení CMP TCF 2.0, aby umožňovalo vrácení řetězce AC. Konkrétně navrhujeme rozšířit objekty JSON TCData a InAppTCData tak, aby vracely tato 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’,
}

Jak se má řetězec AC ukládat?

Web

Způsob ukládání si platforma CMP může zvolit.

V aplikaci

Sada SDK platformy CMP by k uložení řetězce AC měla použít rozhraní NSUserDefaults (iOS) nebo SharedPreferences (Android). Přináší to následující výhody:

Řetězec AC je snadno přístupný dodavatelům.
Řetězec AC zůstává zachován mezi relacemi aplikace.
Řetězec AC lze přenášet mezi platformami CMP, což majitelům stránek umožňuje flexibilně vyměnit sadu SDK platformy CMP za jinou.

Pokud majitel obsahu sadu SDK platformy CMP z aplikace odstraní, má povinnost smazat u uživatelů hodnoty AddtlConsent, aby dodavatelé zahrnutý řetězec AC již nadále nepoužívali.

Úložiště a vyhledávací klíč v objektech NSUserDefaults a SharedPreferences	Hodnota
`IABTCF_AddtlConsent`	Textový řetězec: řetězec AC s verzí specifikace a ID poskytovatelů reklamních technologií, pro které byl udělen souhlas

způsob předávání řetězce AC v řetězci digitální inzerce.

Žádost o nabídku

Na základě nastavení ConsentedProvidersSettings budeme dodavatele neuvedené na seznamu GVL používat pro další zpracování.

V souboru protokolu rozšíření OpenRTB
Starší verze dat ve formátu protocol buffer (Protobuf)

message ConsentedProvidersSettings { // soubor ID odpovídající poskytovatelům, pro které majitel obsahu sdělil // Googlu, že jeho uživatelé z EHP udělili zákonně platný souhlas 1) s používáním souborů cookie nebo jiného místního // ukládání dat tam, kde to vyžaduje zákon, a 2) se sběrem, sdílením a využíváním osobních údajů za účelem // personalizace reklam ze strany ATP v souladu se zásadami pro souhlas uživatele z EU. // ID poskytovatele je přiřazeno k názvu poskytovatele v souboru providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// údaje o poskytovateli, o kterém majitel obsahu sdělil Googlu, // že jeho uživatelé z EHP udělili souhlas s využíváním svých osobních údajů pro účely // personalizace reklam v souladu se zásadami pro souhlas uživatele z EU. // Toto pole se vyplnění pouze pokud má proměnná regs_gdpr hodnotu true (pravda). optional ConsentedProvidersSettings consented_providers_settings = 42;

Služby založené na adresách URL

Vykreslená kreativa může zahrnovat několik pixelů ve značkách <img>. Může obsahovat například značku <img src="http://vendor-a.com/key1=val1&key2=val2">, která z prohlížeče odešle požadavek HTTP GET do domény dodavatele.

Protože se pixel nachází ve značce <img> a nelze v něm tedy spustit JavaScript, k získání řetězce TC nelze použít rozhraní CMP API. Podobně jako u podpory řetězce TC poskytujeme v adresách URL pixelů standardní parametr adresy URL a makro, do kterého je řetězec AC potřeba vložit.

Parametr adresy URL	Odpovídající makro	Podoba v adrese URL
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

Příklad 1

Aby dodavatel A obdržel řetězec AC, musí adresa URL obrázku zahrnovat pár klíč–hodnota s parametrem adresy URL a makrem &addtl_consent=${ADDTL_CONSENT}. Výsledná adresa URL:

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

Příklad 2

Pokud je u žádosti řetězec AC 1~1.35.41.101:

Subjekt, který volá nebo vykresluje kreativu, nahradí makro v adrese URL skutečným řetězcem AC tak, aby byl původní pixel s makrem při volání zadaného serveru upraven takto:

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

Pomohly vám tyto informace?

Jak bychom článek mohli vylepšit?