Přehled informací a pokyny pro nařízení GDPR

Technická specifikace Dalšího souhlasu společnosti Google

Majitelé obsahu, kteří chtějí spolupracovat s poskytovateli reklamních technologií mimo rámec TCF, by měli spolupracovat přímo se svými platformami pro správu souhlasu.

Tento dokument definuje technickou specifikaci („Další souhlas“), která se má používat společně se systémem Transparency & Consent Framework (TCF) v2 organizace IAB Europe k odesílání signálů transparentnosti a souhlasu dodavatelům, kteří ještě nejsou registrováni v globálním seznamu dodavatelů (GVL) IAB Europe. Tato specifikace majitelům stránek, platformám pro správu souhlasu (CMP) a partnerům umožňuje shromažďovat a propagovat další souhlas — souběžně s implementací systému TCF — 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.

Změny týkající se Dalšího souhlasu verze 2

Od prosince 2023 Google podporuje verzi 2 specifikace Dalšího souhlasu. Tady jsou nejdůležitější změny:

Aktualizujte řetězec Dalšího souhlasu (AC), aby podporoval dodavatele uvedené na platformě pro správu souhlasu.
Aktualizujte na rozhraní CMP API, abyste umožnili interoperabilitu platforem pro správu souhlasu, které podporují TCF i režim souhlasu inzerenta.

Řetězce AC vygenerované na základě specifikace verze 1 budou podporovány i nadále.

Komponenty dalšího souhlasu

V dalším souhlasu podporujeme oba následující řetězce:

řetězec transparentnosti a souhlasu (řetězec TC) definovaný ve specifikaci IAB TCF v2.2, 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/nebo byli zveřejněni a kteří nejsou zaregistrováni u organizace IAB.

Tato specifikace definuje:

formát řetězce AC,
rozšíření rozhraní TCF v2.2 CMP API pro podporu řetězce AC a ovládací prvky pro případy, kdy je k dispozici jak systém TCF, tak režim souhlasu inzerenta,
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í části:

část 1: číslo verze specifikace, například „2“,
čá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“,
část 4: oddělovač „~“,
část 5: řetězec „dv.“ následovaný tečkami odděleným seznamem zveřejněných ID poskytovatelů reklamních technologií (ATP), příklad: „dv.9.21.81“.

Kvůli zkrácení délky řetězce by dodavatelé uvedení v části 3 neměli být zahrnuti v části 5.

Příklad řetězce AC

Řetězec AC 2~1.35.41.101~dv.9.21.81 znamená, že uživatel udělil souhlas s poskytovateli reklamních technologií s ID 1, 35, 41 a 101, poskytovatelé reklamních technologií s ID 9, 21 a 81 byli uživateli zveřejněni a řetězec se vytvoří ve formátu definovaném ve specifikaci v2.

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.

Dodavatelé se souhlasem by měli být zahrnuti pouze v případě, že uživatel udělil právně platný souhlas s:

používáním souborů cookie nebo jiných lokálně ukládaných informací v případech, kdy to právní předpisy vyžadují,
shromažďováním, sdílením a používáním osobních údajů k personalizaci reklam ze strany poskytovatele reklamních technologií a dodržováním všech ostatních podmínek daných zásadami společnosti Google pro souhlas uživatele z EU.

Zveřejnění dodavatelé, kteří nemají souhlas s

používáním souborů cookie nebo jiných lokálně ukládaných informací v případech, kdy to právní předpisy vyžadují,
shromažďováním, sdílením a používáním osobních údajů k personalizaci reklam, by měli být zahrnuti pouze v případě, že je uživatelům poskytnuta patřičná transparentnost ohledně identity jednotlivých poskytovatelů reklamních technologií, včetně odkazu na zásady ochrany soukromí těchto poskytovatelů tak, jak je uvedeno v seznamu poskytovatelů reklamních technologií společnosti Google.

Ř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í.

Související zdroje

Rozšíření rozhraní CMP API

Navrhujeme rozšířit existující javascriptové rozhraní API řešení CMP TCF v2.2, aby umožňovalo vracení ř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?