Bu makalede ele alınan konular:
- Ek İzin bileşenleri
- "Ek İzin" (Eİ) dizesinin biçimi
- Ek İzin'i destekleyen CMP'ler
- CMP API için genişletme
- Eİ dizeleri nasıl depolanmalıdır?
- Eİ dizesinin dijital reklamcılık zinciri üzerinden nasıl iletileceği
- İlgili kaynaklar
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, Kullanıcı Rızası Yönetim 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 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_consentdizesi (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çıklanan 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. İzin verilen tedarikçi firma listesine dahil edilen tedarikçi firmaların, açıklanan tedarikçi firma listesine de dahil edilmesi gerekmez.
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.
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
Ek İzin'i destekleyen sertifikalı CMP'ler
Bu listede, Google Ek İzin teknik özelliği için destek sağlayan sertifikalı CMP'ler ve destekledikleri Ek İzin sürümü yer almaktadır.
Ek İzin desteği sağlayan bir CMP olmanız halinde, (1) bu listeye dahil değilseniz ya da (2) yanlış Ek İzin sürümü listelenmişse lütfen CMP kabul formuna gidip "Soru sormak veya durumumu güncellemek istiyorum" istek türünü seçin. Girişinizi durumunuzu yansıtacak şekilde zamanında güncellemek için elimizden geleni yapacağız.
Bu listedeki bilgilerle ilgili kılavuz
Bu listede, sertifikalı CMP'lerin her biriyle ilgili aşağıdaki bilgiler yer alır:
- Sertifikalı CMP: Sertifikalı CMP'nin adı.
- TCF CMP Kimliği: IAB'nin, TCF tarafından doğrulanmış CMP'ye atadığı benzersiz tanımlayıcı.
- Ek İzin: CMP tarafından desteklenen Ek İzin sürümü.
Ek İzin'i destekleyen sertifikalı CMP'lerin listesi
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
