GTM’de Consent (Onay)Ayarları

Yakın tarihli bir sürümde Google, yalnızca Google etiketlerinde değil, kapsayıcıda çalışan tüm etiketlerde consent (onay) belirlenmesine ve uygulanmasına yardımcı olacak gerçek bir yeni özellik yayınladı.

Yeni özellikler şunlardır:

• Yeni consent türleri (consent moduyla birlikte sunulan ad_storage ve analytics_storage’a ek olarak).
• Hem Built-in Consent (yerleşik onay kontrolleri davranışları consent durumu tarafından değiştirilirse) hem de bir etiketin genel olarak çalışmasına izin verilmesi için belirli consent türlerine ihtiyaç duyup duymadığını belirleyebileceğiniz ek consent kontrolleri içeren etikete özgü onay ayarları.
• Hangi etiketlerin ek onay ayarları için zaten yapılandırıldığını ve hangilerinin hala güncellenmeyi beklediğini hızlıca kontrol edebileceğiniz yeni bir Consent Overview ekranı.
• Hem Consent Initialization tetikleyicisi (kapsayıcıdaki diğer her şeyden önce ateşlenir) hem de İnitialization tetikleyicisi ile yeni tetikleyici türleri eklendi.
• Consent Manager platformu şablonlarını (ve neden diğerlerini de değil) onay farkındalığına sahip hale getirmek için yeni özel şablon sandbox API’leri.

Bu özellikler hem GTM 360’ta hem de normal (ücretsiz) GTM kapsayıcılarında mevcuttur.

Consent Türü	Açıklama
ad_storage	Reklamla ilgili depolamayı (çerezler gibi) etkinleştirir
analytics_storage	Ziyaret süresi gibi analizlerle ilgili depolamayı (çerezler gibi) etkinleştirir
functionality_storage	Web sitesinin veya uygulamanın işlevselliğini destekleyen depolamayı etkinleştirir, örneğin dil ayarları
personalization_storage	Video önerileri gibi kişiselleştirmeyle ilgili depolamayı etkinleştirir
security_storage	Kimlik doğrulama işlevi, dolandırıcılık önleme ve diğer kullanıcı koruması gibi güvenlikle ilgili depolamayı etkinleştirir

Not! Üç yeni onay türü yalnızca Google dışı etiketler içindir. Google etiketleri (örn. Analytics, Ads ve Floodlight) yalnızca ad_storage ve analytics_storage’a duyarlıdır. Burada functionality_storage ve security_storage’ı görmek biraz garip, çünkü en azından Avrupa Birliği’nde bunlar genellikle kesinlikle gerekli depolama olarak kabul edilir ve bu nedenle hiç onay gerektirmez. Öte yandan, daha fazla yapılandırma seçeneğine sahip olmak nadiren kötü bir şeydir. Aslında istediğiniz consent türlerini ilgili API çağrılarına ve etiket ayarlarına ekleyebilirsiniz. Bu üç yeni izin türü Google’ın tavsiyeleridir, ancak kapsamlı bir liste değildir.

Etiketlerdeki Consent Ayarları

Bir etiketi açıp Advanced Settings (Gelişmiş Ayarlar) bölümüne ilerlerseniz, Consent Settings başlıklı bir bölüm bulacaksınız.

Built-in Consent Checks ( Yerleşik Onay Kontrolleri)

Built-in Consent Checks (yerleşik onay kontrolleri), etiketin (veya daha doğrusu etiketi çalıştıran şablonun) onayın farkında olduğu anlamına gelir. Bu, ne olduğu tam olarak açıklanmasa da etiketin onay durumu ile bir şeyler yaptığı anlamına gelir. Örneğin yukarıdaki ekran görüntüsünde, Built-in Consent Checks bölümünde listelenen ad_storage ve analytics_storage öğelerini görebilirsiniz. Bu, söz konusu etiket şablonunun izinlerinde bu belirli onay türlerine okuma ve/veya yazma erişimine ihtiyaç duyduğunu tanımladığı anlamına gelir. Etiketin neden beklediğiniz gibi davranmadığını merak ediyorsanız, bunun farkında olmak iyi bir şeydir. Google etiketleri (Analytics, Ads ve Floodlight) analytics_storage ve ad_storage için yerleşik kontrollere sahiptir ve davranışları belgelenmiştir. Diğer etiketler burada başka onay türleri gösterebilir ve onay durumuna nasıl eriştiklerini açıklamak bu etiketlerin belgelerine bağlıdır. Not! Built-in Consent Checks yalnızca şablon kendi kodunda onay durumuna erişiyorsa görünür. Onay API’leri ile hiçbir ilgisi yoksa, bu ayarlar altında Built-in Consent Checks’i görmezsiniz.

Ek Consent Kontrolleri

Bu ayar sayesinde, etiketin tetikleyicilerine onay kontrolü koşulları uygulamak zorunda kalmadan onay kontrollerini gerçekleştirebilirsiniz! Burada üç seçenek vardır:

• Ayarlanmadı – varsayılan seçenek. Bunu, bu etiketin tetiklenmesinin izne bağlı olup olmaması açısından uygun şekilde incelenmediğini belirtmek için kullanın.
• Ek izin gerekmiyor – Etiketin tetiklenmesinin izne bağlı olarak sınırlandırılmaması gerekiyorsa bunu ayarlayın.
• Bu etiket için ek onay gerektir – Etiketin yalnızca bir veya daha fazla consnet türüne onay verilmişse tetiklenmesi gerekiyorsa bunu ayarlayın. Bu seçeneği işaretlediğinizde küçük bir tablo görünür ve tabloya beş consent türünden herhangi birini ekleyebilirsiniz. Etiket yalnızca listelenen tüm onay türleri granted durumuna sahipse çalışır.

Yukarıdaki ayarlara sahip etiket yalnızca security_storage, functionality_storage ve analytics_storage’a izin verilmişse etkinleşir.

Consent Genel Bakış

Consent Overview( Onaya Genel Bakış ) ekranını etkinleştirmek için önce Yönetici’ye (Admin) ve ardından Container Settings’e gidin. Consent Overview etkinleştir seçeneğinin yanındaki kutuyu işaretleyin.

Artık Etiketler’e gittiğinizde, eylem çubuğundaki Consent Overview simgesine tıklayabilirsiniz.

Consent Overview tüm etiketlerinizi iki bölümde listeler. Consent Not Configured, bu etiketler için Ek Onay Kontrolleri ayarının varsayılan Ayarlanmadı olduğu anlamına gelir. Consent Not Configured, etiketin ek onay kontrolleri için yapılandırıldığı anlamına gelir (Yok veya etiketin çalışması için verilmesi gereken bir veya daha fazla onay türü).

Etiketleri seçip ardından eylem çubuğundaki Edit Consent Settings düğmesine tıklayarak etiketler için onay kontrolü ayarlarını toplu olarak düzenleyebilirsiniz.

Özellikle Google Tag Manager’ı bir izin yönetimi platformuyla (CMP) entegre ediyorsanız, Consent Overview ekranını düzenli olarak kullanın. Etiketlerinizin CMP’niz tarafından belirlenen izin ayarlarıyla çalışacak şekilde nasıl yapılandırıldığını ve yapılandırılıp yapılandırılmadığını hızlı bir şekilde görmenin harika bir yoludur.

Yeni Tetikleyici Türleri

Google Tag Manager’da iki yeni tetikleyici türü vardır. Her ikisi de yerleşik tetikleyiciler olarak her container’a otomatik olarak eklenir ve her ikisi de Preview modunda yeni tetikleyici olaylar olarak görünür.

Not! Bu tetikleyiciler asenkron istekleri gerçekten işleyemez. Örneğin, onay durumunu almak için zaman uyumsuz bir çağrınız varsa, etiketi Consent Initialization tetikleyicisiyle ateşlerken bile, ancak diğer bazı etiketler daha sonraki tetikleyicilerde zaten ateşlenmeye başladıktan sonra tamamlanabilir.

Consent Initialization (Onay Başlatma)

Consent Initialization, kapsayıcıdaki diğer tüm tetikleyicilerden önce ateşlenen bir tetikleyicidir. Herhangi bir sayfada ateşlenebilecek ilk tetikleyici olacak şekilde programlı olarak oluşturulur. Bu, adından da anlaşılacağı gibi, örneğin yeni onay türlerinin varsayılan onay durumunu oluşturmak için iyi olduğu anlamına gelir (aşağıya bakın). Başka bir deyişle, bir onay yönetimi platformu kullanıyorsanız ve beş farklı onay türü için varsayılan onay durumunu belirleyen bazı kodları (belki de kendi özel şablonlarını) çalıştırmak istiyorsanız, kullanmanız gereken doğru tetikleyici türü budur. Tüm kapsayıcılarda otomatik olarak bulunan yerleşik tetikleyicinin adı Consent Initialization – All Pages’dır.

Bu tetikleyici türü için dataLayer olayı gtm.init_consent’tir (aslında bunu dataLayer dizisinde bulamazsınız) ve Preview  modunda Consent Initialization olarak görünür.

Initialization (Başlatma)

Diğer yeni tetikleyici türü ise Initialization’dur. Bu, Consent Initialization’dan sonra ancak dataLayer’a gerçekten itilen ilk tetikleyici olaylardan önce ateşlenir. Container geri kalanının kullanması için onay ile ilgili olmayan bağımlılıkları oluşturacağınız yerdir. dataLayer’a itilen diğer her şeyden önce ateşlendiğinden, gerçek dataLayer olaylarına dayanan herhangi bir tetikleyicinin ateşlenme şansı olmadan önce etiket yürütmesinin başlamasını garanti eder. Yukarıdaki asenkron etiketlerle ilgili uyarıya dikkat edin! Yerleşik tetikleyicinin adı Initialization – All Pages’tir. Bu tetikleyici türü için dataLayer olayı gtm.init’tir ve Preview modunda Initialization olarak görünür.

Yeni Şablon API’leri

Bir onay yönetimi platformu (veya onay durumunu tanımlaması gereken herhangi bir komut dosyası) için özel bir şablon oluşturuyorsanız, kullanabileceğiniz yeni şablon API’leri vardır. Şablonların sitedeki izin durumuna genel olarak duyarlı olmasını sağlayan bazı yeni API’ler de mevcuttur.

Varsayılan Consent Durumunu Ayarla

Varsayılan onay durumu, etiket ateşlenir ateşlenmez (tercihen Consent Initialization tetikleyicisinde) uygulanan bir şeydir. Bu, onay ayarları için bir temel oluşturur. Değerleri CMP’ye özgü çerezlerden veya örneğin dataLayer’daki bir şeyden türetilebilir. API setDefaultConsentState olarak adlandırılır ve her biri yukarıdaki tabloda listelenen bir onay türüne karşılık gelen beş özelliğe sahip bir nesne alır. API çağrısında belirlenen ayarların belirli bölgelerden gelen ziyaretçilere uygulanması için isteğe bağlı bir region parametresi de sağlayabilirsiniz. Bölgeler (ve alt bölgeler) ISO 3166-2 formatında sağlanır. Onay durumu güncellenene kadar varsayılan ayarlar uygulanır. Aşağıdaki örnekte, CMP şablonu, ad_storage hariç tümünün izin verilen duruma ayarlandığı ABD hariç, varsayılan olarak denied durumunu belirler.

const setDefaultConsentState = require(‘setDefaultConsentState’);  setDefaultConsentState({  ad_storage: ‘denied’,  analytics_storage: ‘denied’,  functionality_storage: ‘denied’,  personalization_storage: ‘denied’,  security_storage: ‘denied’  });  setDefaultConsentState({  analytics_storage: ‘granted’,  functionality_storage: ‘granted’,  personalization_storage: ‘granted’,  security_storage: ‘granted’,  region: [‘US’]  });

 

Doğal olarak değerleri, örneğin mevcut izin çerezlerine veya dataLayer’daki ayarlara göre dinamik hale getirmek isteyeceksiniz.

Consent Durumunu Güncelle

Kullanıcı daha sonra onay yönetimi platformuyla etkileşime girer ve tercihlerini değiştirirse, şablonun updateConsentState API’sini yukarıdaki gibi benzer bir yapıyla çağırmasını sağlayabilirsiniz. updateConsentState’de region mevcut olmadığını unutmayın. Bunun nedeni, bu API’yi çağırmanız gerektiğinde, kullanıcının nerede bulunduğundan bağımsız olarak onay çağrısının durumunun ne olması gerektiğini zaten biliyor olmanız gerektiğidir.

const updateConsentState = require(‘updateConsentState’);  updateConsentState({  ad_storage: data.ad_storage,  analytics_storage: data.analytics_storage,  functionality_storage: ‘granted’,  personalization_storage: data.personalization_storage,  security_storage: ‘granted’  });

Yukarıdaki örnekte, işlevsellik ve güvenlik depolaması sabit kodlu olarak verilmiştir ve diğer tüm onay durumları, büyük olasılıkla kullanıcı seçimine yanıt verecek şekilde yapılandırılmış şablon alanlarından çekilmiştir.

Consent Durumunu Kontrol Edin

Bir şablonun mevcut onay durumuna göre davranışını değiştirmesini istiyorsanız isConsentGranted API’sini kullanabilirsiniz. Bu, beş onay türünden biri olan tek bir parametre alır ve verilen onay türü için onay durumunun ne olduğuna bağlı olarak true veya false döndürür. Örneğin, yalnızca analytics_storageonayı verilmişse bir çerez ayarlamak için bu kodu çalıştırabilirsiniz:

const isConsentGranted = require(‘isConsentGranted’);  if (isConsentGranted(‘analytics_storage’)) {  // Custom method that handles setting the cookie  setCustomAnalyticsCookie();  }

  Consent Durumundaki Değişiklikleri Dinleme(Listen)

Bazen bir etikete tetikleyiciler ekleyerek, örneğin onay ayarlarına göre işlevselliğini yeniden değerlendirmesini sağlamak çok beceriksizce olabilir. Bu nedenle, herhangi bir onay türü için onay durumu değiştiğinde bir şablonda bir geri arama yürütmek için kullanılabilecek yeni bir API, addConsentListener var.

const addConsentListener = require(‘addConsentListener’);  const consentCallback = (consentType, granted) => {  if (consentType === ‘analytics_storage’ && granted) {  setCustomAnalyticsCookie();  }  };  addConsentListener(‘analytics_storage’, consentCallback);

Geri arama, onay türünü ve onayın verilip verilmediğini (true / false) argüman olarak iletir. Bu, gruplama ve gönderme mantığını etiketin kendisine bıraktığı için oldukça şık bir çözümdür. Consent durumundaki değişikliği tespit eden özel tetikleyicilerle etiketi aşırı mühendislikle donatmanıza gerek yoktur, şablon bunu sizin için halledecektir. Şablon sadece consent durumundaki değişiklikleri dinleyecek ve durum güncellemesinden önce onay eksikliği nedeniyle engellenen isabeti otomatik olarak gönderecektir.

Yeni İzin: Consent Durumuna Eriş

Şablonun hangi Consent durumlarını okumasına/yazmasına izin verildiğini kontrol eden yeni Accesses izin durumu izni de bulunmaktadır.

Yukarıda listelenen tüm API’lerin gerektirdiği izinler şunlardır:

API Adı	Okuma Gerektiren	Yazma Gerektiren
setDefaultConsentState	Hayır	Evet
updateConsentState	Hayır	Evet
isConsentGranted	Evet	Hayır
addConsentListener	Evet	Hayır

API’lerinizin okumak ve/veya yazmak istediği her izin türünün, izinler tablosunda ayrı ayrı listelenmesi gerekir (bu nedenle en fazla beş satıra sahip olabilir). Bu izin tablosuna eklediğiniz tüm izin türleri, etiketin Built-in Consent Checks bölümünde listelenecektir.

Consent Yönetimi Platformlarıyla Çalışmak

Bu yeni consent ayarlarının özellikle CMP’ler düşünülerek oluşturulduğu bir sır değil. Ancak, bu yeni ayarlarla bir CMP kullanmanın gerçek bir faydası olması için birkaç şeyin yerinde olması gerekir:

• CMP’nin yeni consent türlerini ve hem varsayılan hem de güncelleme consent durumu API’lerini kullanan özel bir şablon oluşturması gerekir.
• İdeal olarak, kapsayıcıda çalıştırdığınız etiketler davranışlarını consent durumuna göre değiştirecektir. Bunu, şablonların onay durumuna (ve değişikliklere) tepki vermesini sağlayan yeni şablon API’leri ile yapabilirler.
• En azından, kapsayıcıdaki her etiketi gözden geçirmeli ve onay durumunun verilmediği takdirde etiketi engellemesi gerekip gerekmediğini görmek için  Advanced Settings (Gelişmiş Ayarlarını) kontrol etmelisiniz.

Google tarafından sağlanan listeye bakılırsa, en popüler CMP’ler GTM veya consent (onay) modu ile entegre olma fırsatına tam olarak atlamıyor gibi görünüyor. Yeni özellikler (ve beta aşamasında) oluştukça, durumun yakında düzeleceğini umalım. Umarım, genel olarak etiket şablonları gerektiğinde onaya duyarlı olacak şekilde tasarlanır. Depolama olmadan çalışabilen şablonların, uygun onay mevcut değilse çerezlerin ayarlanmasını koşullu olarak engellemesi çok mantıklı. Benzer şekilde, “gizlilik dostu” veri toplama için ayrı bir uç noktaya sahip olan satıcılar (örneğin, üçüncü taraf çerezleri yok), hangi uç noktanın kullanılacağı kararını ilgili onayın durumuna bağlı olarak vermelidir. Daha önce olduğu gibi, onay yönetimini yapılandırmak çok fazla iş gerektirir. Kullanıcı seçiminin gerçekte ne olduğuna dair ayrıntıların göz ardı edilmesinin yasal sonuçları olduğundan, consent’in kasıtlı olarak entegre edilmesi ve tasarlanması gerekiyor ve bu tasarım gereğidir. GTM’deki bu yeni Consent ayarlarıyla, neyse ki artık işin büyük kısmını yapmak zorunda olan Google Tag Manager yöneticisi değil, satıcıların da katılması ve işbirliği yapması gerekiyor.

Özet

İzin yönetimi platformlarını Google Tag Manager ile entegre etmek geçmişte tam bir baş belasıydı. Yeni onay özellikleri tüm sorunları ortadan kaldırmıyor, ancak GTM konteynerinin consent seçeneklerine uygun olduğundan emin olmak için CMP’lerle birlikte çalışmayı daha yönetilebilir hale getiriyor. Benzer şekilde, hizmet sağlayıcıları da artık etiketlerine consent seçimine göre engelleme ve ateşlemeden daha fazla ayrıntı eklemelerine olanak tanıyan yeni şablon API’lerine sahip.  Yeni kullanıcı arayüzü özellikleri, bir konteyneri consent desteği açısından hızlı bir şekilde denetlemeyi kolaylaştırıyor, ancak daha fazla şeffaflık istemek yerinde bir talep olacaktır. Örneğin, yerleşik onay seçeneklerinin neler olduğunu bilmek güzel, ancak şablon kodunun kendisini araştırmak zorunda kalmadan etiketin gerçekte onaya nasıl dayandığını bilmek daha da yararlı olacaktır. Geliştirilmesi gereken diğer şeyler şunlardır:

• Yeni Consent Initialization ve Initialization tetikleyici türlerinin kullanımını teşvik edin. Bunların eşzamansız isteklerle de çalışmasını sağlayın (yani, bir başarı sinyali gönderilinceye kadar bir sonraki tetikleme olayına geçmeyin).
• Sunucu tarafı Google Tag Manager için de onay desteği ekleyin. İstek URL’sindeki (Google Tag) gcs parametresi, beş onay türünün tümünü iletmek için kullanılabilir ve sunucu tarafı etiketleme ortamı, şablonlardaki amaca yönelik API’leri kullanarak bu parametreden kullanıcı onayını deşifre edebilir.
• Satıcı bazında da onay vermeyi/reddetmeyi mümkün kılın.
• Şu anda mevcut olan beş onay türü yerine özel amaç türleri eklemeyi mümkün kılın (bu, eskiden sahip olduğumuz iki türden (ad_storage ve analytics_storage) çok daha iyi olsa da!)
• Tüm etiketlerin Google Tag Manager üzerinden çalışmıyor olması mümkün olduğundan, onay durumunu Google Tag Manager’ın dışına da gösterin.

Genel olarak consnet (izin, onay) şeffaflığa dayanmaktadır. GTM, consent durumunun ne olduğuna dair şeffaflığı ne kadar artırabilirse, ilgili tüm taraflar için o kadar iyi olur.