Clarity'yi GTM ile Consent'e Uygun Kurmak

Clarity consent tarafı çoğu kurulumda GTM (Google Tag Manager) etiketine izin koşulu konunca kapanmış sayılıyor. 31 Ekim 2025’ten beri bu yeterli değil ve yetersizliğin belirtisi de sessiz: Clarity kapanmıyor, oturumları parçalıyor. Raporda oturum sayısı artıyor, funnel’lar her adımda tam düşüş gösteriyor ve bunun kurulumla ilgili olduğunu anlamak uzun bir zaman alabiliyor.

Bu yazı bir örnek üzerinden elde edilen bulguları anlatıyor: enforcement’ın kapsamı, sinyal gelmediğinde raporda ne olduğu, GTM tarafında gate ile sinyalin farkı, eski consent çağrısının açtığı reklam izni ve dokümandaki Google Consent Mode (GCM) vaadinin canlı sitede neden karşılık bulmadığı. Dokümanda cevabı olmayan iki soru da ölçümle yanıtlanıyor: parçalanan oturumu sitenin kendi oturum kimliğini vererek geri kurup kuramayacağı ve iki consent kategorisi ayrı ayrı gönderildiğinde reklam izninin gerçekten kapalı kalıp kalmadığı. Aynı sorunun Umami tarafındaki karşılığı Umami’yi GTM ile consent’e uygun kurma yazısında; consent’in Clarity verisine analiz düzeyindeki etkisi de frustrated buyer analizi yazısında duruyor. Parçalanmış oturumun heatmap okumasına ne yaptığını ise heatmap okuma ve yorumlama rehberi anlatıyor.

31 Ekim 2025’ten Beri Ne Değişti

Clarity, EEA (Avrupa Ekonomik Alanı), Birleşik Krallık ve İsviçre kaynaklı sayfa ziyaretleri için geçerli bir consent sinyali bekliyor. Bölge, ziyaretçinin IP adresinden belirleniyor; sitenin nerede barındığı veya şirketin nerede olduğu kapsamı değiştirmiyor.¹ Doküman, bunun yeni bir consent şartı getirmediğini, var olan mekanizmaların sinyali Clarity’ye gerçekten iletmesini zorunlu kıldığını söylüyor.²

Üç detay kurulumu belirliyor. Sinyal proje bazında işleniyor, birden çok Clarity projesi olan her domain sinyali ayrı geçiriyor. Consent en fazla 9 ay geçerli sayılıyor. Consent Mode ise bu üç bölgeden gelen ziyaretçiler için varsayılan olarak açık; diğer ziyaretçiler için projenin Settings > Setup > Advanced settings > Cookies ayarı kapatılmadıkça Clarity ilk yüklemede cookie yazıyor.³

Ayarın kendi açıklaması da sonucu doğruluyor: kapatıldığında kayıtlar çok sayfalı oturumlar halinde birleştirilmiyor.³ Yani bu anahtar bir cookie tercihi gibi görünse de asıl belirlediği şey oturum bütünlüğü.

Üçüncü madde Türkiye’deki kurulumlar için önemli. Clarity Türkiye trafiğinde enforcement uygulamıyor, dolayısıyla Cookies ayarı açık bir proje banner’dan bağımsız çalışmaya devam ediyor. Bu boşluk, KVKK (Kişisel Verilerin Korunması Kanunu) tarafında analitik cookie’nin rızasız yazılabildiğini göstermez. Teknik kısıt ile hukuki yükümlülük ayrı şeyler; Clarity yalnızca birincisini uyguluyor, ikincisi sende kalıyor.

Sinyal Yoksa Ne Oluyor

Cookie olmadan Clarity oturumu birleştiremiyor ve her sayfa görüntülemesine ayrı bir kimlik veriyor. Dokümandaki bozulma tablosu 23 satır; kök neden tek cümle ve gerisi ondan türüyor.⁴

Alan	Sinyalsiz durum
Oturum sayısı	Her sayfa görüntülemesi ayrı oturum
Pages per session	1
Dönen kullanıcı	Yok, herkes yeni
Funnel	Çok adımlı funnel’lar her adımda tam düşüş
Giriş ve çıkış sayfası	Her sayfa hem giriş hem çıkış
Kanal ve kaynak	Other ve Direct payı artıyor, referrer sitenin kendi domain’i görünüyor
User intent	Daha çok Low intent, daha az Medium ve High
Quickback	0 olarak kaydediliyor

Tablo dokümandan geliyor, ama aynı bozulma test edilen canlı kurulumda da benzer şekilde ölçüldü. Ölçümler sandbox’ta değil, gerçek bir consent yönetim platformu ve yayındaki bir GTM container’ı üzerinde alındı; yazı boyunca “test kurulumu” bu kurulumu işaret ediyor. 12 Eylül 2026’da, Clarity 0.8.69 ile, aynı tarayıcıdan üç durum ayrı ayrı kaydedildi ve Clarity’nin sunucuya gönderdiği paketler açıldı. Paketin başındaki başlık alanı, o isteğin hangi kullanıcıya, hangi oturuma ve oturumun kaçıncı sayfasına ait olduğunu taşıyor.

Durum	Clarity kullanıcı	Clarity oturum	Sayfa sayacı
Kabul, giriş yapılmış	133syj	1u5cj1m	10
Kabul, anonim	1rdxwqw	14v2qa4	9
Ret, giriş yapılmış	u34bme	100s0zd	1
Ret, anonim	e0he7c	1qg0t8d	1
Karar verilmemiş	3jklv0	15ttqy3	1

Kabul edilen ziyaretlerde tek oturum 9 ve 10 sayfa taşımış. Reddedilen ziyaretlerde sayaç 1’de kalıyor. Son satır ayrıca bir şeyi daha söylüyor: banner’a hiç cevap vermemiş ziyaretçi, reddetmiş ziyaretçiyle birebir aynı davranıyor. Clarity tarafında kararsızlar reddedenlerle birlikte sayılmalı, bu aracın ölçümünde üçüncü bir durum yok. Banner gösterimi ve karar değişimi üzerinden kurulan consent oranı hesabı ise kararsızı ayrı bir kategori olarak tutabiliyor; o hesabın kurulumu consent oranı ölçümü yazısında.

Yukarıdaki tablo beş ayrı gezinti, dolayısıyla beş ayrı kayıt. Ertesi gün aynı geçişleri tek bir kesintisiz izde, 16 saniyeye sıkıştırılmış bir tıklama dizisiyle tekrarladım ve davranış tam olarak görünür hale geldi:

Saniye	Kimlik	Sayfa sayacı	Consent olayı
0	s33qsm / oo4qu1	1	varsayılan, ikisi denied
+7	s33qsm / oo4qu1	2	analytics granted
+10	s33qsm / oo4qu1	3	analytics granted
+13	1vgvob2 / 15i7659	1	ret
+16	ng5bui / 1i2neeh	1	varsayılan, ikisi denied

Kabul geldiği anda aynı kimlik korunuyor ve sayaç 1’den 3’e ilerliyor. Ret anında kimlik tamamen yenileniyor. Retten sonraki sayfa yüklemesi ise cookie silindiği için varsayılan duruma dönüyor, yani hiç karar verilmemiş ziyaretçiyle aynı yere düşüyor.⁵

Bu tablonun sahadaki görünümü Microsoft Q&A’daki bir soruda duruyor: Şubat 2026’dan itibaren oturum sayısında yüzde 165 artış, aynı oran bir önceki yılın şubatına göre de geçerli. Kabul edilen yanıt tanı olarak cookie’siz modu, teşhis yolu olarak da pages per session’ın 1’e inmesini gösteriyor.⁶ Doküman da aynı listeyi veriyor, yani soru soranın karşılaştığı şey bir hata değil, tasarım sonucu.

Bu tablo GA4 ile karşılaştırma yaparken de devreye giriyor. GA4, consent reddedildiğinde cookie’siz ping gönderip modelleme yapıyor; Clarity ise oturumu parçalıyor. Aynı ziyaretçi grubunu iki araç iki farklı şekilde sayıyor, fark reddetme oranıyla büyüyor.

Kendi Oturum Kimliğini Vermek Kurtarmıyor

Buraya kadarki tablo şu soruyu davet ediyor: oturumu Clarity birleştiremiyorsa, site kendi oturum kimliğini verip bu boşluğu kapatabilir mi? Clarity’nin Identify API’si (Application Programming Interface) buna açık görünüyor, çünkü çağrı dört değer alıyor ve ikincisi tam olarak oturum kimliği:⁷

window.clarity(
  "identify",
  "custom-id",
  "custom-session-id",
  "custom-page-id",
  "friendly-name",
);

Dördüncü değer panelde gösterilecek okunabilir ad. Verilmediğinde Clarity birinci değerden kendisi bir maske üretiyor ve dokümandaki örnekte bu maske Mo****************** şeklinde dönüyor: ilk iki karakter açık kalıyor. Yani friendly-name göndermemek kimliği tamamen gizlemiyor.

Dokümanın hiçbir yeri, cookie yokken bu ikinci değerin sayfa görüntülemelerini tek oturumda toplayıp toplamadığını söylemiyor. Soru sorulmamış, dolayısıyla cevaplanmamış.

Ölçüm şöyle kuruldu. Sunucu tarafında üretilen, oturum çerezinden türetilen ve cihazda yeni hiçbir şey saklamayan bir oturum kimliği, consent kararından bağımsız olarak Clarity’ye geçirildi. Sonra consent reddedilip site içinde gezildi.

Değer Clarity’ye ulaştı. Gönderilen pakette, sayfa etiketlerinin yanında duruyor:

"auth_state", ["anon"]
"userId",     ["06d19d84f49cded90d193b59e529d9b4dd5598a8caebbd8cc852c4565d0caa2a"]
"sessionId",  ["0760684e4d2f05a25dc9e869a6a04372"]

Ama oturum yine birleşmedi. Site içinden gelinen bir sayfada, yani gezinmenin ilk adımı olmayan bir istekte, Clarity yeni bir kullanıcı ve yeni bir oturum açtı, sayfa sayacı 1 olarak gitti.

Aynı pakette auth_state değerinin anon olması hata değil, kurulumun kendisinden geliyor: sitenin kimlik etiketleri consent’e bağlı, identify çağrısı ise bağlı değil. Clarity’nin identify komutu izin durumunu hiç sormuyor, cookie’siz modda da gönderiliyor. Giriş yapmış ama consent vermemiş bir ziyaretçi bu yüzden Clarity’de anonim görünürken kimliği yine de taşınıyor.

Sebep paketin yapısında. Sitenin verdiği oturum kimliği, page_type veya auth_state gibi bir boyut olarak taşınıyor. Clarity’nin oturumu kurduğu kimlik ise paketin başlık alanında, boyutlardan ayrı bir yerde tutuluyor ve _clsk cookie’si yokken her sayfa görüntülemesinde yeniden üretiliyor. İkisi aynı paket içinde yan yana gidiyor ama farklı işler yapıyor.

Pratik karşılığı şu: custom-session-id bir etiket, oturum anahtarı değil. Doküman da bu değerleri zaten “informational data values” diye tanımlıyor ve işlevlerini oturum bulmak ve filtrelemek olarak tarif ediyor.⁷ Filtre olarak işe yarıyor, oturum sürekliliğine katkısı yok. Cookie’siz modda parçalanan oturumu uygulama tarafından geri kurmanın bir yolu yok, çünkü birleştirme kararını veren taraf tarayıcıdaki kod değil, Clarity’nin kendi kimlik alanı.

Bu, kimlik geçirmenin tamamen boş olduğu anlamına gelmiyor. Kimlik, kaydı sonradan bulmak için işe yarıyor; oturumu onarmak için yaramıyor. İkisini karıştırmamak gerekiyor.

Gate mi, Sinyal mi

GTM’de Clarity’yi consent’e bağlamanın iki yolu var ve ikisi farklı şeyler vaat ediyor.

Gate modeli. Clarity etiketi GTM’de analytics_storage iznine bağlanıyor. Ayarın adı Advanced Settings altında Require additional consent for tag to fire; seçilen izin tiplerinin hepsi granted değilse etiket hiç çalışmıyor.⁸ İzin gelmeden etiket tetiklenmiyor, Clarity hiç yüklenmiyor, cookie de sinyal sorunu da olmuyor. Bedeli, reddeden ziyaretçiden cookie’siz veri de gelmemesi. Bu modelde Clarity’ye ayrıca sinyal geçmenin tek nedeni, etiketin yalnızca izin sonrası yüklendiğini Clarity’ye de söylemek; aksi halde Clarity izin durumunu bilmeden, projenin varsayılanıyla çalışıyor.

Sinyal modeli. Etiket herkes için yükleniyor, projenin Cookies ayarı kapalı, cookie kararı sinyalle veriliyor. Reddeden ziyaretçiden sayfa düzeyinde heatmap ve click verisi geliyor, ama o segmentte oturum parçalanıyor. Clarity’nin kendi dokümanı bu modeli anlatıyor.³

İki modelin karışımı en kötü sonucu veriyor: etiket gate’e bağlı, içinde de eski consent çağrısı var. Reddedenden veri gelmiyor, kabul edende ise reklam izni yanlışlıkla açılıyor. Test edilen kurulumun başlangıç hali buydu; aşağıdaki örnek setinde de sekiz siteden birinde aynı karışım duruyordu.

Eski Çağrı Reklam İznini de Açıyor

Clarity’nin window.clarity('consent') çağrısı hâlâ çalışıyor ve doküman onu deprecated olarak işaretliyor.⁹ Neden değiştirilmesi gerektiği yayınlanan koddan okunuyor. clarity.js sürüm 0.8.69’da consent komutu tek boolean alıyor ve her iki kategoriyi birden aynı değere çekiyor:

consent: function (t) {
  void 0 === t && (t = !0),
  Kr(t
    ? { source: 4, ad_Storage: "granted", analytics_Storage: "granted" }
    : { source: 4, ad_Storage: "denied", analytics_Storage: "denied" });
}

Yükleyici script de bu değeri okuyor. clarity.ms/tag/<proje> altındaki 878 byte’lık yükleyici, ad_Storage granted olduğunda c.clarity.ms/c.gif adresine bir görsel isteği gönderiyor; bu istek MUID senkronu, yani Microsoft’un reklam tarafındaki tarayıcı kimliği.¹⁰ Reklam vermeyen, banner’ında “reklam çerezi yok” yazan bir site, eski çağrıyla Clarity’ye reklam izni vermiş ve senkronu tetiklemiş oluyor.

consentv2 iki kategoriyi ayrı alıyor:

window.clarity("consentv2", {
  ad_Storage: "denied",
  analytics_Storage: "granted",
});

Doküman kategorilerin ne yaptığını da ayırıyor: analytics_storage cookie’yi ve özellikleri yönetiyor, ad_storage yalnızca Microsoft Ads ile veri paylaşımını.² ad_storage hiç kullanmayan bir sitede bu alanı her zaman denied göndermek doğru davranış, Clarity’nin çalışmasını etkilemiyor.

Ayrımı doğru göndermek yetmiyor, çünkü Clarity ikinci sayfada izni CMP’den (Consent Management Platform) değil kendi cookie’sinden okuyor. _clck içindeki consent flag’i tek bir bit ve reklam ile analitik iznini ayırmıyor; yalnızca analitik kabul etmiş bir ziyaretçide de 1 yazılıyor. Dönen ziyaretçinin ilk anında Clarity bu tek bitten iki kategoriyi birden türetiyor:

Ze = {
  source: i.consent ? 6 : 0,
  ad_Storage: xn.track ? "granted" : "denied",
  analytics_Storage: xn.track ? "granted" : "denied",
};

xn.track değeri cookie’deki flag’ten geliyor. Yani ziyaretçi reklam iznini hiç vermemiş olsa bile, ikinci sayfanın başlangıcında Clarity’nin iç durumunda ad_Storage granted oluyor.

Bunun test kurulumunda gerçekleştiğini dolaylı ama kesin bir izden gördüm. Clarity’nin yükleyici ayarındaki cookie listesini (["_uetmsclkid","_uetvid","_clck"]) okuyan fonksiyon, kaynak kodda iki kategorinin de granted olmasını şart koşuyor. Ölçümde ikinci ve üçüncü sayfanın paketlerinde _clck değeri okunmuş halde duruyor. O fonksiyonun çalışabilmesi için ad_Storage granted olmalıydı; oysa banner’dan çıkan her consent olayında reklam alanı denied gidiyor. İki kategoriyi ayrı ayrı göndermek, cookie’den gelen bu örtük granted’ı engellemiyor.

MUID senkronu da aynı alana bakıyor ve bu, bir yarış durumu yaratıyor. Yükleyicinin metadata callback’i, çağrıldığı andaki Ze değerini okuyor. consentv2 o ana kadar kuyruğa girmişse callback reddedilmiş reklam iznini görüyor; girmemişse cookie’den türetilmiş granted’ı görüyor ve senkronu başlatıyor.

Bunu izole etmek için aynı origin’de sentetik bir sayfa kurdum: eski bir _clck cookie’si consent flag’i 1 ile yerleştirildi, veri gönderimi engellendi ve yalnızca c.gif isteği izlendi.¹¹ Dört varyant:

Varyant	MUID senkronu
Hiç consent çağrısı yok	Tetiklendi, source: 6, iki kategori granted
consentv2 yükleyiciden önce kuyrukta	Tetiklenmedi
consentv2 başlangıçtan 3 saniye sonra	Tetiklendi, izin sonradan düzeltilse bile
Cookie yok	Tetiklenmedi

Üçüncü satır kritik: senkron bir kez gittikten sonra consentv2’nin arkadan gelip reklam iznini denied yapması isteği geri almıyor. Yani bu, yavaş açılan ya da geç karar veren bir CMP’de kaybedilen bir yarış.

Test kurulumunda senkron hiç tetiklenmedi. Sebebi izin değil, sıralama: GTM’deki consentv2 etiketi consent_restored event’iyle yükleyicinin callback’inden önce kuyruğa giriyor. Görsel isteklerini de kapsayan iki ayrı kayıtta, cookie’si consent flag’i taşıyan 9 ardışık sayfa yüklemesi boyunca c.clarity.ms adresine tek istek gitmedi.

Sıralama doğru olsa bile cookie okuması duruyor. Reklam iznini hiç vermemiş dönen ziyaretçide Clarity kendini Microsoft’un reklam tarafındaki cookie’lerini okumaya yetkili sayıyor ve okuduğunu bir boyut olarak yüklüyor. Test edilen kurulumda sonuç zararsız kaldı, çünkü UET hiç kurulu değil ve okunacak _uetvid ile _uetmsclkid yok. Aynı anda Microsoft Ads çalıştıran bir sitede ise ilk sayfadan sonraki her sayfada bu iki değer, reklam izni verilmemişken Clarity’ye gider.⁵

Google Consent Mode Vaadi ve Canlı Sitede Olan

Doküman, GCM (Google Consent Mode) kullanan sitelerde ek değişiklik gerekmediğini yazıyor.¹² Test kurulumunda GCM v2 zaten çalıştığı için ilk deneme buydu: eski çağrı kaldırıldı, etiketin gate’i açıldı, Cookies ayarı kapatıldı, sinyal Google’a bırakıldı.

Sonuç: banner açıkken denied, kabul sonrası yine denied. dataLayer’da consent update ve sitenin kendi consent_restored event’i gtm.js’den önce duruyordu, yani Clarity yüklendiğinde sinyal oradaydı; sayfa yenilense de değişmedi.

Nedeni yayınlanan kodda görünüyor. Clarity, GCM’yi window.google_tag_data.ics nesnesinden okuyor. Modül başlarken bu nesne varsa addListener(["ad_storage","analytics_storage"], Ur) ile dinleyici kuruyor; Ur fonksiyonu getConsentState("analytics_storage") ile durumu okuyup uyguluyor. Bir de tek seferlik yedek yol var: Cookies kapalıysa ve ics.usedUpdate doğruysa ilk yükleme döngüsünde Ur bir kez çalışıyor.

function Ur() {
  var a = window.google_tag_data && window.google_tag_data.ics;
  if (a && a.getConsentState)
    try {
      e = a.getConsentState("analytics_storage");
      Kr({
        source: 2,
        ad_Storage:
          1 === a.getConsentState("ad_storage") ? "granted" : "denied",
        analytics_Storage: 1 === e ? "granted" : "denied",
      });
    } catch (t) {
      return;
    }
}

Bu kodun iki zayıf noktası var. Birincisi, dinleyici yalnızca Clarity’nin başladığı anda ics varsa kuruluyor ve sonradan kontrol edilmiyor. İkincisi, getConsentState çağrısı tek argümanla yapılıyor ve güncel Google tag kütüphanesi, henüz update gelmemişken bu çağrıda Cannot read properties of undefined (reading 'usedContainerScopedDefaults') hatası veriyor. Hata catch ile yutuluyor, yedek yol sessizce çıkıyor.

Kanıt, kabul öncesi kaydedilen bir metadata callback’inden geldi. Clarity, consent her uygulandığında bu callback’i çağırıyor ve source alanı hangi yolun yazdığını söylüyor: 0 örtük başlangıç, 2 GCM, 4 eski çağrı, 5 consentv2, 6 önceki ziyaretten kalan cookie, 7 argümansız consentv2.

clarity(
  "metadata",
  (d, u, c) => console.log("consent apply", JSON.stringify(c)),
  false,
  true,
  true,
);
// banner açıkken: consent apply {"source":0,"ad_Storage":"denied","analytics_Storage":"denied"}
// kabul sonrası:  consent apply {"source":5,"ad_Storage":"denied","analytics_Storage":"granted"}

source: 2 hiç gelmedi. Aynı sayfada konsoldan elle kaydedilen bir ics.addListener ise kabul anında iki kez tetiklendi ve 1 okudu; Google tarafı güncellemeyi iletiyor, Clarity’nin kendi kaydı bu kurulumda bağlanmıyor. Neden bağlanmadığını kesin olarak söyleyemiyorum; en tutarlı açıklama, Google tag kütüphanesinin ics nesnesini Clarity’nin başlangıcından sonra oluşturması. Ama sonuç kesin: GTM ile yüklenen bir Clarity’de GCM yolu varsayılmamalı; metadata çıktısında source: 2 görülmedikçe o yolun çalıştığı kabul edilmemeli.

Çalışan Kurulum: Kendi Event’inden consentv2

Test kurulumunda consent banner’ı kararı dataLayer’a iki event ile yazıyor: kabul veya ret anında consent_update, dönen ziyaretçide sayfa yüklenirken consent_restored. İkisi de consent_analytics alanında granted veya denied taşıyor. Sinyal bu iki event’ten Clarity’ye geçiyor.

GTM tarafında üç parça var. consent_analytics için bir dataLayer Variable, ^consent_(update|restored)$ regex’iyle bir Custom Event tetikleyici ve şu Custom HTML etiketi:

<script>
  (function (w) {
    w.clarity =
      w.clarity ||
      function () {
        (w.clarity.q = w.clarity.q || []).push(arguments);
      };
    var a = "{{dlv - consent_analytics}}";
    w.clarity("consentv2", {
      ad_Storage: "denied",
      analytics_Storage: a === "granted" ? "granted" : "denied",
    });
  })(window);
</script>

İlk üç satır sırayı önemsiz kılıyor. Clarity’nin kendi yükleyicisi window.clarity zaten tanımlıysa onu koruyup kuyruğunu boşaltıyor; dolayısıyla consent_restored GTM yüklenmeden önce push edilse bile çağrı kuyruğa giriyor ve Clarity gelince işleniyor. Etiket consent koşulu taşımıyor, çünkü ret kararının da Clarity’ye ulaşması gerekiyor: consentv2 denied aldığında var olan cookie’leri siliyor, oturumu bitiriyor ve cookie’siz modda yeniden başlıyor.⁹

Aynı stub kalıbı diğer Clarity çağrıları için de geçerli. Kurulumda auth_state gibi custom tag’leri Clarity’ye yazan etiket, kullanıcı kimliği çözüldüğünde düşen user_identity event’ine bağlı olmalı, aksi durumda hatalı bir değer iletilebilir.

GA4 Entegrasyonu Consent Altında

Clarity’nin GA4 entegrasyonu tek yönlü. Clarity, OAuth ile GA4 verisini çekip kendi içinde bir GA dashboard gösteriyor; GA4’e oturum kaydının adresini göndermiyor, çünkü GA4 yüksek kardinaliteli satır kabul etmiyor. GA4 segmentlerini de desteklemiyor ve proje başına tek property bağlanabiliyor.¹³

Consent bağlamında bunun anlamı şu: entegrasyon Clarity’nin sinyal sorununu GA4’e taşımıyor, GA4’ün sayımını da Clarity’ye taşımıyor. Aynı ekranda iki farklı consent modeliyle üretilmiş iki sayı duruyor. GA4 tarafı reddedenleri modelleme ile kapatırken Clarity tarafı parçalanmış oturumları olduğu gibi gösteriyor. Sinyal wiring’i tamamlanmadan bu iki sayıyı karşılaştırmak, sinyal eksikliğini trafik değişimi olarak okumak demek.

Sahadan Bir Örnek Seti

Yazıyı hazırlarken aynı iki konsol kontrolünü Clarity kullanan başka sitelerde de çalıştırdım: banner açıkken cookie ve consent durumu, kabul sonrası aynı ölçümler. 8 site 5 sınıfa ayrıldı.

Sınıf	Gözlem
Clarity kaldırılmış, CMP kabulü ancak yenilemede işliyor	3 site. Kabul anında hiçbir araç açılmıyor, usedUpdate false; sayfa yenilenince GA4 açılıyor, Clarity yok
Varsayılan açık	2 site. Cookies ayarı açık, banner yok veya bağlı değil, _clck ilk yüklemede, source: 0 ile iki kategori granted
Bölgesel açık	1 site. CMP AB dışına örtük rıza uyguluyor, banner açıkken tüm cookie’ler yazılı, sinyal UET köprüsü üzerinden granted geliyor
Doğru gate, eski çağrı	1 site. Banner öncesi temiz, kabulde clarity('consent') ile source: 4 ve ad_Storage: granted; Google tarafına update hiç gitmiyor
Açık sinyal	Test kurulumu. Kendi event’inden consentv2, banner öncesi denied

Doğrulama

İki adım, ikisi farklı şeyi kanıtlıyor.

Banner açıkken. Site cookie’lerini sil, sayfayı yükle, konsolda şu çağrıyı çalıştır. İki kategori denied, Application sekmesinde _clck ve _clsk yok olmalı. _clck varsa Cookies ayarı açık demek.

clarity("metadata", (d, u, c) => console.log(c), false, true, true);

Kabul sonrası, yenilemeden. Aynı çağrı analytics_Storage: granted dönmeli, _clck ve _clsk oluşmuş olmalı, ad_Storage sitenin gerçek durumunu yansıtmalı. Sayfa yenilemeden görmek önemli; yenilemeyle düzelen bir kurulum, kabul eden ziyaretçinin ilk sayfasını kaybediyor.

Sınırlar

Ölçümler tek bir kurulumdan geliyor. Kurulum canlı, ama tek örnek; başka bir CMP, başka bir tetikleyici sırası ya da başka bir yükleyici ayarı farklı sonuç verebilir. Kod okumaları clarity.js 0.8.69 ve 12 Eylül 2026 tarihli dokümantasyon üzerinden yapıldı. Clarity yükleyicisi sürümü kendisi güncelliyor, dolayısıyla source değerleri ve ics okuma mantığı sonraki sürümde değişebilir.

GCM yolunun neden bağlanmadığına dair açıklama gözleme dayalı bir çıkarım, kanıtlanmış bir kök neden değil. Kanıtlanan kısım, kabul öncesi kaydedilen callback’te source: 2’nin hiç görünmemesi.

Cookie’den gelen örtük reklam iznini iki aşamada doğruladım. Önce canlı kurulumda senkronun hiç gitmediğini gördüm ve mekanizmanın da çalışmadığı sonucunu çıkardım; bu çıkarım yanlıştı. Sentetik sayfa mekanizmanın çalıştığını, canlı kurulumu kurtaran şeyin yalnızca çağrı sıralaması olduğunu gösterdi. Sentetik testte veri gönderimi engelli olduğu için ölçülen şey isteğin kendisi, panelde oluşan kayıt değil.

Bu yazı ne yapıldığını anlatıyor, hukuki görüş vermiyor. Clarity’nin kullanım şartları toplanan veriyi AI model eğitimi ve reklam profilleme için kullanma hakkını saklı tutuyor ve yurt dışı veri aktarımı KVKK tarafında ayrı bir başlık; bunlar davranışsal analiz rehberinde duruyor. Consent Mode’un GA4 tarafındaki kurulumu ise Consent Mode v2 kurulum yazısında.

Footnotes

1. Microsoft Learn, Frequently asked questions, Cookie consent: “Clarity uses IP address-based geolocation to determine user location. Consent should be obtained for users in the EEA, UK, and Switzerland.” Ayrıca: “Your location is not relevant. The impact depends on where your users originate.” ↩
2. Microsoft Learn, Consent Management: enforcement tarihi, 9 aylık geçerlilik, analytics_storage ve ad_storage davranış tablosu. “It is important to note that this update does not introduce new consent requirements but rather emphasizes the need for existing consent mechanisms to be properly implemented.” ↩ ↩²
3. Microsoft Learn, Consent Mode: “Consent Mode is enabled by default for all users originating from the European Economic Area (EEA), United Kingdom (UK), and Switzerland (CH).” Diğer ziyaretçiler için Settings > Setup > Advanced settings altında Cookies ayarının kapatılması gerekiyor. Ayarın panelde kendi açıklaması da aynı sonucu veriyor: “Clarity uses cookies to gather session data. Recordings will not be linked together into multi-page sessions if this is turned off.” (proje ayarları ekranı, 14 Eylül 2026). ↩ ↩² ↩³
4. Microsoft Learn, Changes to Clarity Reporting Without Cookie Consent: sinyalsiz durumda 23 rapor alanının nasıl değiştiğini listeleyen tablo. ↩
5. HAR kayıtları, 13 Eylül 2026, Chrome 152, test edilen canlı kurulum. Üç ayrı kayıt: biri kabul, ret ve yeniden kabul geçişleri için, ikisi görsel istekleri dahil tam kayıt olarak (607 ve 686 istek, 27 ve 30 görsel). Kabul sonrası kayıtta tek oturum 10 sayfaya ulaştı ve 2’den 10’a kadar her sayfanın paketinde _clck değeri okunmuş halde geldi; aynı kayıtta c.clarity.ms adresine istek yok. Reddedilen kayıtta 9 ayrı sayfa yüklemesinin hepsi ayrı kullanıcı ve pageNum 1. Yükleyici ayarı: {"projectId":"<proje>","cookies":["_uetmsclkid","_uetvid","_clck"],"track":false}. Cookie okuma koşulu ve örtük consent bloğu clarity.js 0.8.69 içinde. ↩ ↩²
6. Microsoft Q&A, I’ve noticed since February 2026, the amount of sessions recorded in Microsoft Clarity has increased dramatically, 7 Mayıs 2026. Soru sahibi Ocak 2026’dan Şubat 2026’ya yüzde 165 artış bildiriyor; kabul edilen yanıt AI üretimi olarak işaretli. ↩
7. Microsoft Learn, Identify API: imza window.clarity("identify", "custom-id", "custom-session-id", "custom-page-id", "friendly-name") ve yalnızca custom-id zorunlu. Sayfa bu değerleri “informational data values about site visitors” diye tanımlıyor ve işlevlerini “can help you filter and find clarity sessions based on your own internal way of representing user, session or page” diye açıklıyor. friendly-name verilmeyen örnekte dönen userHint değeri "Mo******************". Ayrıca: “Clarity securely hashes the custom-id on the client before being sent to Clarity servers.” Sayfanın son güncellenme tarihi 13 Ocak 2025. ↩ ↩²
8. Google Tag Manager Help, Tag Manager consent mode support: “Require additional consent for tag to fire: This tag will only fire if the status of all specified consent types are ‘granted’ when the tag is triggered.” Ayar Advanced Settings > Consent Settings > Additional Consent Checks altında, varsayılanı Not set. Aynı sayfa Consent Initialization tetikleyicisini ve Consent Overview ekranını da anlatıyor. ↩
9. Microsoft Learn, Clarity Cookie Consent API, ConsentV2: “consentv2 is the latest and recommended method … It replaces the older Consent API, which is planned for deprecation.” Ret durumunda: “Clarity deletes any existing cookie for the website, ends the current session, and restarts tracking in no-consent mode.” ↩ ↩²
10. Yükleyici script https://www.clarity.ms/tag/<projectId> ve çekirdek https://scripts.clarity.ms/0.8.69/clarity.js, 12 Eylül 2026’da indirilip okundu. Yükleyicideki handleConsentEvent fonksiyonu ad_Storage granted olduğunda muidsync() çağırıyor. Kaynak kod ayrıca microsoft/clarity deposunda yayınlanıyor. ↩
11. Playwright ile iki koşu, 13 Eylül 2026. Birincisi canlı sitede gerçek akış (karar yok, aynı sayfada kabul, yeniden yükleme, ikinci sayfa). İkincisi aynı origin’de sentetik bir sayfa: eski bir _clck cookie’si consent flag’i 1 ile yerleştirildi, collect istekleri engellendi ve yalnızca c.gif izlendi. Sentetik koşuda veri Clarity’ye gitmedi. Headless tarayıcıda banner bot tespiti nedeniyle hiç açılmadığı için gerçek kullanıcı arayüzü dizisi UA değişikliğiyle kuruldu. ↩
12. Microsoft Learn, Support for Google Consent Mode (GCM) in Clarity: “If your website already uses GCM, no additional changes are required.” ↩
13. Microsoft Learn, Google Analytics4 Integration with Clarity: “Currently, Clarity doesn’t support segments in GA4. Clarity doesn’t send playback URL to GA4 as it cannot accept High Cardinality rows.” Tek property sınırı Getting started with GA Integration sayfasında. ↩

Önemli Noktalar

• 01 Enforcement 31 Ekim 2025'ten beri EEA, Birleşik Krallık ve İsviçre kaynaklı ziyaretler için geçerli. Bölge IP ile belirleniyor, sitenin nerede olduğu değil ziyaretçinin nereden geldiği önemli.
• 02 Sinyal yoksa Clarity durmuyor, parçalanıyor. Her sayfa görüntülemesi ayrı oturum sayılıyor, pages per session 1'de kalıyor, dönen kullanıcı sıfırlanıyor ve çok adımlı funnel'lar her adımda tam düşüş gösteriyor.
• 03 Parçalanan oturumu site kendi custom-session-id değerini vererek geri kuramıyor. Değer Clarity'ye ulaşıyor ama bir boyut olarak taşınıyor; oturumu kuran kimlik paketin ayrı bir alanında tutuluyor ve cookie yokken her sayfada yeniden üretiliyor.
• 04 Banner'a hiç cevap vermemiş ziyaretçi, Clarity tarafında reddetmiş ziyaretçiyle aynı davranıyor. Clarity raporlarını okurken kararsızlar reddedenlerle birlikte sayılmalı.
• 05 GTM'de consent gate'i ile Clarity'ye sinyal geçmek iki farklı model. Gate modelinde reddeden ziyaretçi hiç ölçülmüyor. Sinyal modelinde cookie'siz de olsa ölçülüyor, ama raporu okurken oturumun parçalandığını hesaba katmak gerekiyor.
• 06 Eski window.clarity('consent') çağrısı tek argümanla iki kategoriyi birden granted yapıyor. Reklam izni hiç verilmemişken Clarity'ye o izin gitmiş oluyor ve yükleyici MUID (Microsoft User ID) senkronunu tetikliyor.
• 07 consentv2 ile iki kategoriyi ayrı göndermek ikinci sayfada yetmiyor. Clarity dönen ziyaretçide izni _clck cookie'sindeki tek bir bitten okuyor ve o bitten hem analitik hem reklam iznini birden türetiyor; reklam izni hiç verilmemiş ziyaretçide bile iç durum granted oluyor ve Clarity, Microsoft Ads cookie'lerini okuyup boyut olarak yüklüyor.
• 08 MUID senkronu bir yarış durumu. consentv2 yükleyicinin metadata callback'inden önce kuyruğa girerse senkron gitmiyor, geç kalırsa CMP reddetmiş olsa bile gidiyor ve sonradan düzeltmek isteği geri almıyor. Sentetik sayfada dört varyantla izole edildi.
• 09 Dokümandaki 'Google Consent Mode varsa ek iş gerekmez' cümlesinin yazılmamış bir ön koşulu var: google_tag_data.ics Clarity başlamadan önce var olmalı. Metadata çıktısındaki source alanı hangi yolun çalıştığını söylüyor; 2 dönmüyorsa GCM yolu çalışmıyor.
• 10 Clarity'nin GA4 entegrasyonu tek yönlü. Clarity GA4 verisini çekip kendi panelinde gösteriyor, GA4'e playback URL göndermiyor. İki araç aynı ekranda iki farklı consent modeliyle sayıyor.

Sık Sorulan Sorular (FAQ)

+ Türkiye'den gelen trafik için Clarity consent sinyali zorunlu mu?

Clarity tarafında değil. Enforcement yalnızca EEA, Birleşik Krallık ve İsviçre kaynaklı ziyaretler için uygulanıyor ve bölge IP ile belirleniyor. Ama bu, KVKK tarafında analitik cookie'nin açık rıza olmadan yazılabileceği anlamına gelmiyor. Clarity'nin enforce etmemesi ile sitenin uyumlu olması iki ayrı konu. Cookies ayarı açık bırakılan bir projede _clck ilk yüklemede yazılıyor ve banner'ın vaadiyle çelişiyor.

+ Clarity etiketini GTM'de `analytics_storage` iznine bağlamak yeterli değil mi?

Tek başına yeterli değil, ama nedeni çoğu kurulumun beklediği yerde değil. Gate reddeden ziyaretçide Clarity'yi hiç yüklemiyor, orası temiz. Sorun kabul eden ziyaretçide: etiket tetikleniyor, Clarity yükleniyor ve izin durumunu bilmiyor. EEA, Birleşik Krallık ve İsviçre trafiğinde Consent Mode varsayılan olarak açık olduğu için sinyal gelmedikçe cookie yazılmıyor, yani kabul etmiş ziyaretçi de cookie'siz modda ölçülüyor ve oturumu parçalanıyor. Gate modelinde de Clarity'ye ayrıca consentv2 geçmek gerekiyor. Bir de sık görülen karışım var: etiket gate'e bağlı, içinde eski consent çağrısı duruyor. O zaman hem reddedenden veri gelmiyor hem kabul edende reklam izni yanlışlıkla açılıyor.

+ Google Consent Mode v2 çalışıyorsa Clarity bunu otomatik okumuyor mu?

Dokümana göre okuyor, ancak istisnai bir durum var. Clarity'nin yayınlanan kodu sinyali window.google_tag_data.ics üzerinden alıyor ve dinleyiciyi yalnızca kendi başlangıcında bu nesne varsa kuruyor. Test edilen canlı bir kurulumda, kabul öncesi kaydedilen bir metadata callback'inde yalnızca source: 0 ve açık çağrıdan gelen source: 5 görüldü, GCM'ye ait source: 2 hiç gelmedi. Otomatik yolu varsaymak yerine metadata çıktısında source değerini kontrol etmek gerekiyor.

+ Eski `clarity('consent')` çağrısı hâlâ çalışıyorsa neden değiştirmeli?

Çalışıyor ama fazla izin veriyor. Kaynak kodda bu çağrı ad_Storage ve analytics_Storage alanlarının ikisini birden granted yapıyor. Ziyaretçi yalnızca analitik kabul etmiş olsa bile Clarity, Microsoft Ads ile veri paylaşımını açıyor ve yükleyici script c.clarity.ms üzerinden MUID senkron isteği gönderiyor. consentv2 iki kategoriyi ayrı alıyor; reklam kullanmayan sitede ad_Storage her zaman denied gönderilmeli.

+ Sinyal gelmediğinde Clarity raporlarında ne değişiyor?

Cookie olmadığı için oturum birleştirilemiyor. Her sayfa görüntülemesi ayrı oturum oluyor, pages per session 1'de kalıyor, her sayfa hem giriş hem çıkış sayfası görünüyor, dönen kullanıcı sıfır, funnel'lar her adımda tam düşüş gösteriyor, kanal raporunda Other ve Direct payı artıyor. Microsoft Q&A'da Mayıs 2026'da sorulan bir soruda Şubat 2026'dan itibaren oturum sayısında yüzde 165 artış bildirilmişti; tanı aynı.

+ Kurulumun doğru çalıştığını nasıl doğrularım?

İki adım. Site cookie'lerini silip banner açıkken clarity('metadata', cb, false, true, true) ile consent durumunu okumak, iki kategori de denied ve _clck cookie'si oluşmamış olmalı. Kabul edip sayfayı yenilemeden aynı çağrıyı tekrarlamak, analytics_Storage: granted ve _clck, _clsk cookie'leri oluşmuş olmalı. Bunların yanında yayınlanmış GTM container dosyasını okuyup consentv2 çağrısının gerçekten yayında olduğunu görmek gerekiyor; workspace'te kalan değişiklik canlıda görünmüyor.