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İ dizesi dijital reklamcılık zinciri üzerinden nasıl iletilir?
- İ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, henüz IAB Avrupa Küresel Katılımcı Listesi'ne (GVL) kaydolmamış sağlayıcılara şeffaflık ve/veya kullanıcı rızası sinyalleri göndermek için kullanılacak Google Ek İzin teknik spesifikasyonu 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 İzin'i alıp yaymasını sağlar.
Ek İzin bileşenleri
Ek İzin, IAB'nin Küresel Katılımcı Listesi'ne (GVL) 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 dizesinden (Eİ dizesi) oluşur.
"Ek İzin" 2. sürüm (ACv2) dizesi oluşturma
Eİ dizesinde hangi bilgiler depolanır?
Eİ dizesi aşağıdaki bileşenleri içerir:
-
1. Bölüm: Spesifikasyon sürüm numarası. Mevcut sürüm "
2"dir. -
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 örnekleri
1, 2, 3, 4 ve 10 kimliklerine sahip ATP sağlayıcıları kullanıcıya açıklanırsa:
- …ve kullanıcı, bu sağlayıcıları açıklayan CMP mesajını görmüş ancak henüz izin verip vermeyeceğine karar vermemişse ilgili ACv2 dizesi
2~~dv.1.2.3.4.10olur. -
…ve kullanıcı tüm sağlayıcılara izin verdiyse karşılık gelen ACv2 dizesi
2~1.2.3.4.10~dv.olur. Yalnızca bu durumda dv'den sonraki "." isteğe bağlıdır. Bu nedenle2~1.2.3.4.10~dvde kabul edilen bir ACv2 dizesidir. - …ve kullanıcı tüm sağlayıcılar için izni reddettiyse karşılık gelen ACv2 dizesi, tüm sağlayıcıların açıklandığını ancak hiçbirine izin verilmediğini belirtmelidir. Karşılık gelen ACv2 dizesi
2~~dv.1.2.3.4.10olur. - …ve kullanıcı,
1ve10numaralı sağlayıcılar için izin vermiş ancak diğer tüm sağlayıcılar için izni reddetmişse karşılık gelen ACv2 dizesi2~1.10~dv.2.3.4olur.
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 tutar:
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 sağlayıcı listesine dahil edilen sağlayıcıların, açıklanan sağlayıcı 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 (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 v1 dizeleri hâlâ destekleniyor mu?
Ek İzin v2, Aralık 2023'ten bu yana standart Ek İzin sürümüdür. v1 spesifikasyonuna göre oluşturulan Ek İzin dizeleri desteklenmeye devam edecek. Ancak bu tür dizeler, bir ATP için şeffaflığın sağlanıp sağlanmadığını gösteremez. İzin gerektirmeyen kullanım alanlarını desteklemek için CMP'lerin v2 spesifikasyonuna taşınması gerekir.
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
Ek İzin'i destekleyen CMP'ler Ek İzin dizesini, biri TCData, diğeri ise InAppTCData olan mevcut TCF v2 CMP JavaScript API JSON nesnelerinin bir parçası olarak döndürmelidir.
TCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
InAppTCData = {
tcString: 'base64url-encoded TC string with segments',
...
addtlConsent: ‘AC string with spec version and consented/disclosed Ad Tech Provider IDs’
}
Eİ dizeleri nasıl depolanmalıdır?
Web'de
Depolama mekanizmasına CMP karar verir.
Uygulamada
TCFv2 için uygulama içi API'ye benzer şekilde, bir CMP SDK tarafından oluşturulan Eİ dizesini depolamak için NSUserDefaults (iOS) ya da SharedPreferences (Android) kullanılır. Bu mekanizma şunlara olanak tanır:
-
Sağlayıcıların Eİ dizesine kolayca erişmesi
-
Eİ dizesinin uygulama oturumları arasında kalıcı olması
-
Yayıncıların CMP'lerini değiştirmesi durumunda Eİ dizesinin taşınabilir olması
Not: 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İ dizesi dijital reklamcılık zinciri üzerinden nasıl iletilir?
Teklif istekleri
Teklif istekleri, sürecin ilerleyen aşamalarında GVL dışındaki sağlayıcılar için Ek İzin'i yaymak üzere ConsentedProvidersSettings'i kullanır.
- 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: 2~1.35.41.101~dv.
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=2~1.35.41.101~dv.