GDPR'ye genel bakış ve rehberlik

Google'ın Ek İzin için teknik spesifikasyonu

Sonraki: IAB AB TCF 2.2 sürümünü uygulamayla ilgili sorunları giderme

TCF dışı reklam teknolojisi sağlayıcılarla (ATP'ler) çalışmak isteyen yayıncılar doğrudan CMP'leriyle çalışmalıdır.

Bu dokümanda, yalnızca IAB Avrupa Şeffaflık ve Kullanıcı Rızası Çerçevesi (TCF) v2 ile birlikte kullanılması amaçlanan, IAB Avrupa Küresel Katılımcı Listesi'ne (GVL) henüz kayıtlı olmayan sağlayıcılara şeffaflık ve/veya kullanıcı rızası sinyalleri göndermek amacıyla kullanılacak teknik bir spesifikasyon ("Ek İzin") açıklanmaktadır. Bu spesifikasyon; yayıncıların, Rıza Yönetimi Platformlarının (CMP'ler) ve iş ortaklarının henüz IAB Avrupa Küresel Katılımcı Listesi'ne kaydolmamış ancak Google'ın Reklam Teknolojisi Sağlayıcılar (ATP) listesinde bulunan şirketler için TCF uygulamasıyla birlikte ek izinleri alıp yaymasını sağlar.

Ek İzin v2 ile ilgili değişiklikler

Google, Aralık 2023'ten beri Ek İzin v2 spesifikasyonunu desteklemektedir. Başlıca değişiklikler şunlardır:

CMP'de açıklanan sağlayıcıları desteklemek için Ek İzin (Eİ) dizesinde yapılan güncelleme
Hem TCF hem de reklamveren izin modunu destekleyen CMP'lerin birlikte çalışabilmesi için CMP API'de yapılan güncelleme

v1 spesifikasyonuna göre oluşturulan Eİ dizeleri desteklenmeye devam edecek.

Ek İzin bileşenleri

"Ek İzin"de şu ikisini de destekliyoruz:

IAB TCF v2.2 spesifikasyonu ile tanımlanan ve IAB'nin Küresel Katılımcı Listesi'ndeki (GVL) sağlayıcılar için oluşturulan şeffaflık ve kullanıcı rızasını içeren Şeffaflık ve Kullanıcı Rızası Dizesi (TC dizesi) VE
IAB'ye kaydolmamış, kullanıcı rızası alan ve/veya açıklanan Google reklam teknolojisi sağlayıcıların (ATP'ler) listesini içeren basit bir addtl_consent dizesi (Eİ dizesi)

Bu spesifikasyonda aşağıdakiler tanımlanmıştır:

Eİ dizesinin biçimi
Eİ dizesini ve hem TCF hem de reklamveren izin modu mevcut olduğunda kontrolleri desteklemek için TCF v2.2 CMP API'de yapılan genişletme
Eİ dizesinin nasıl depolanması gerektiği
Eİ dizesinin dijital reklamcılık zinciri üzerinden nasıl iletileceği

"Ek İzin" (Eİ) dizesinin biçimi

Eİ dizesinde hangi bilgiler depolanır?

Eİ dizesi aşağıdaki bileşenleri içerir:

1. Bölüm: Spesifikasyon sürüm numarası (ör. "2")
2. Bölüm: Ayırıcı simgesi "~"
3. Bölüm: Kullanıcı rızası alan Google reklam teknolojisi sağlayıcıların (ATP) kimliklerinin noktayla ayrılmış listesi. Örnek: "1.35.41.101"
4. Bölüm: Ayırıcı simgesi "~"
5. Bölüm: "dv." ve ardından, açıklanan Google reklam teknolojisi sağlayıcı (ATP) kimliklerinin noktayla ayrılmış listesi. Örnek: "dv.9.21.81"

3. bölümde yer alan sağlayıcılar, dize uzunluğunu azaltmak için 5. bölüme dahil edilmemelidir.

Eİ dizesi örneği

2~1.35.41.101~dv.9.21.81 numaralı Eİ dizesi, kullanıcının 1, 35, 41 ve 101 kimliklerine sahip ATP'lere rıza gösterdiği, 9, 21 ve 81 kimliklerine sahip ATP'lerin açıklandığı ve dizenin 2 sürümlü spesifikasyonunda tanımlanan biçim kullanılarak oluşturulduğu anlamına gelir.

Eİ dizesini kim oluşturmalıdır?

Eİ dizesi yalnızca, IAB Politikalarına göre atanmış CMP kimliği kullanılarak, IAB Europe TCF'ye kayıtlı CMP'ler tarafından oluşturulabilir. Sağlayıcılar veya diğer üçüncü taraf hizmet sağlayıcılar Eİ dizeleri oluşturmamalıdır.

Google ATP'leri nerede yayınlanır?

Google, IAB'ye kaydolmamış reklam teknolojisi sağlayıcıların ve kimliklerinin listesini aşağıdaki konumda yayınlar:

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

Ne zaman bir Eİ dizesi oluşturulmalıdır?

Eİ dizesi her durumda yalnızca, yayıncı Google'ın AB Kullanıcı Rızası Politikası'na uygun hareket ettiğinde oluşturulabilir.

Kullanıcı rızası alan sağlayıcılar yalnızca kullanıcı aşağıdakiler için yasal olarak geçerli izin verdiğinde dahil edilmelidir:

Çerezlerin veya yasal olarak gerekli olan durumlarda yerel olarak depolanan diğer teknolojilerin kullanımı.
Reklamların bir ATP tarafından kişiselleştirilmesi için kişisel verilerin toplanması, paylaşılması ve kullanılmasının yanı sıra Google'ın AB kullanıcı rızası politikasının diğer tüm şartlarına uyulması.

Aşağıdakiler için kullanıcı rızası bulunmayan açıklanmış sağlayıcılar yalnızca, kullanıcılara her ATP'nin kimliği konusunda uygun şeffaflık sunulduğunda (Google'ın ATP listesinde sağlanan ATP gizlilik politikasına bağlantı vermek de dahil) dahil edilmelidir:

Çerezlerin veya yasal olarak gerekli olan durumlarda yerel olarak depolanan diğer teknolojilerin kullanımı.
Reklamların kişiselleştirilmesi için kişisel verilerin toplanması, paylaşılması ve kullanılması.

Eİ dizesi, yalnızca TC dizesine ek olarak oluşturulabilir, TC dizesinin yerine oluşturulamaz. Google, bir istek için TC dizesi kullanılamıyorsa aldığı isteği işlemeyecek ve istekteki Eİ dizesini silecektir.

Bu spesifikasyonu uygulayan CMP'ler, oluşturdukları Eİ dizesinin yalnızca yayınlanan Google ATP dosyasındaki kimlikleri (yani GVL dışındaki sağlayıcıları) içerdiğinden emin olmalıdır. Google bir TC dizesi aldığında, TC dizesinde listelenen GVL'nin sürümünü kontrol eder. Bu GVL sürümü bir sağlayıcının kaydını içeriyorsa TC dizesi bu sağlayıcıyı kontrol eder ve bu sağlayıcıya ait tüm Eİ dizesi girişleri yoksayılır. Bu durumda Google, söz konusu "kopya" girişleri Eİ dizesinden kaldırma ve bu değiştirilmiş Eİ dizesini TC dizesiyle birlikte aktarma hakkını saklı tutar. Google dışındaki sağlayıcılar Eİ dizesini değiştiremez.

İlgili kaynaklar

CMP API için genişletme

Mevcut TCF v2.2 CMP JavaScript API'nin, Eİ dizesinin döndürülmesine olanak tanıyacak şekilde genişletilmesini öneriyoruz. Daha açık olmak gerekirse bu verilerin döndürülmesi için TCData ve InAppTCData JSON nesnelerinin genişletilmesini öneriyoruz.

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’
}

Eİ dizeleri nasıl depolanmalıdır?

Web'de

Depolama mekanizmasına CMP karar verir.

Uygulamada

Eİ dizesinin CMP SDK tarafından depolanması için NSUserDefaults (iOS) veya SharedPreferences (Android) kullanılmalıdır. Bunu yapmak, aşağıdakilere olanak tanır:

Sağlayıcıların Eİ dizesine kolayca erişmesi
Eİ dizesinin uygulama oturumları arasında kalıcı olması
Yayıncıya bir CMP SDK'yı diğeriyle değiştirme esnekliği sunmak için Eİ dizesinin CMP'ler arasında taşınabilir olması

CMP SDK'yı uygulamasından kaldırmayı seçen bir yayıncı, sağlayıcıların eklenen Eİ dizesini kullanmaya devam etmemesini sağlamak amacıyla kullanıcılar için AddtlConsent değerlerini temizlemekten sorumlu olur.

NSUserDefaults ve SharedPreferences Nesnelerindeki Storage ve Lookup Anahtarı	Değer
`IABTCF_AddtlConsent`	Dize: Spesifikasyon sürümünü ve kullanıcı rızası alan reklam teknolojisi sağlayıcıların kimliklerini içeren Eİ dizesi

Eİ dizesinin dijital reklamcılık zinciri üzerinden nasıl iletileceği

Teklif isteği

Sürecin ilerleyen aşamalarında GVL dışındaki sağlayıcılar için ek izinleri yaymak üzere ConsentedProvidersSettings'i yeniden kullanacağız.

OpenRTB uzantılar protokolünde
Eski Protokol Arabelleği sürümü

message ConsentedProvidersSettings { // Set of IDs corresponding to providers for whom the publisher has told // Google that its EEA users have given legally valid consent to: 1) the use of cookies or other local // storage where legally required; and 2) the collection, sharing, and use of personal data for // personalization of ads by an ATP in accordance with Google’s EU User Consent Policy. // A mapping of provider ID to provider name is posted at providers.csv. repeated int64 consented_providers = 2 [packed = true]; }

// Information about the providers for whom the publisher has told Google // that its EEA users have consented to the use of their personal data for // ads personalization in accordance with Google's EU User Consent Policy. // This field will only be populated when regs_gdpr is true. optional ConsentedProvidersSettings consented_providers_settings = 42;

URL tabanlı hizmetler

Oluşturulan bir reklam öğesi, <img> etiketlerinin altında birkaç piksel içerebilir. Örneğin <img src="http://vendor-a.com/key1=val1&key2=val2">, tarayıcıdan sağlayıcının alan adına bir HTTP GET isteği gönderir.

Piksel, JavaScript yürütme imkanı olmayan bir <img> etiketinde bulunduğundan, TC dizesini edinmek için CMP API kullanılamaz. TC dizesi için verdiğimiz desteğe benzer şekilde, standart bir URL parametresinin yanı sıra, Eİ dizesinin eklenmesi gereken piksel URL'lerinde bir makro sağlıyoruz.

URL parametresi	İlgili makro	URL'de gösterimi
`addtl_consent`	`ADDTL_CONSENT`	`&addtl_consent=${ADDTL_CONSENT}`

1. Örnek

Sağlayıcı A'nın Eİ dizesini alabilmesi için, görüntü URL'sinin &addtl_consent=${ADDTL_CONSENT} URL parametresi ve makrosuna sahip bir anahtar/değer çifti içermesi gerekir. Elde edilen URL şöyle olur:

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

2. Örnek

Belirli bir istekte Eİ dizesinin şöyle olduğunu varsayalım: 1~1.35.41.101

Reklam öğesini çağıran veya oluşturan kullanıcı, URL'deki makroyu gerçek Eİ dizesiyle değiştirir. Böylece başlangıçta yerleştirilen ve makroyu içeren piksel, belirtilen sunucuya çağrı yapılırken aşağıdaki gibi değiştirilir:

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

Bu size yardımcı oldu mu?

Bunu nasıl iyileştirebiliriz?