KVKK Uyumlu Web Ölçümlemesi Nasıl Yapılır?

Web sitelerine analitik aracı kurarken yaşanan klasik bir sahne var:

Pazarlama & ölçümleme ekibi “her şeyi toplayalım, kullanıcıyı adım adım takip edelim” der. Hukuk ekibi ise “her yere onay kutusu koyun, onay verilmezse event toplamayın” diyerek süreci bloklar.

Sonuç? Sitenin ortasına yapışan devasa bir çerez banner’ı, bu banner’ı görünce sayfayı terk eden veya “Reddet”e basan ciddi bir kullanıcı kitlesi ve ne yaptığını göremeyen ürün ve pazarlama ekibi.

Çoğu şirket KVKK uyumunu siteye bir pop-up koyup insanların “Kabul Et” butonuna basmasını ummaktan ibaret sanıyor. Oysa Kişisel Verileri Koruma Kurumu’nun yayımladığı Çerez Uygulamaları Hakkında Rehber, zorunlu olmayan çerezler ve benzeri takip teknolojileri söz konusu olduğunda çok daha temel bir soruya odaklanıyor:

Kullanıcının verisini neden, hangi kapsamda ve hangi hukuki şartla işliyorsunuz?

Kaynak: Kişisel Verileri Koruma Kurumu – Çerez Uygulamaları Hakkında Rehber

Elbette teknik mimari tek başına bir web sitesini “KVKK uyumlu” hâle getirmez. Aydınlatma yükümlülüğü, veri işleme şartları, saklama süreleri, veri sorumlusu/veri işleyen ilişkileri ve varsa yurt dışı aktarımlar ayrıca değerlendirilmelidir.

Ama bu durum sitenizin trafiğini veya ürününüzün sağlığını ölçemeyeceğiniz anlamına gelmiyor.

Kullanıcıyı fişlemeden, gereksiz çerez dayatmadan ve mümkün olduğunca az veri işleyerek temiz bir ölçümleme sistemi kurmanın 4 temel kuralı var.

1. Zorunlu Olmayan Tarayıcı Depolamasından Kaçınmak

F12’ye basıp DevTools’u açtığınızda Application sekmesinin altında Cookies, Local Storage, Session Storage ve IndexedDB gibi alanları görürsünüz.

Bunların tamamının her koşulda boş olması gerektiğini söylemek doğru değil. Örneğin oturum açma, güvenlik veya alışveriş sepeti gibi kullanıcının açıkça talep ettiği bir hizmetin çalışması için kesinlikle gerekli bazı teknolojiler farklı değerlendirilebilir.

Ancak iş analitik, reklam veya kullanıcı davranışını takip etmeye geldiğinde tablo tamamen değişiyor.

Kişisel Verileri Koruma Kurumu’nun Çerez Rehberi’nde de belirtildiği üzere; açık rızaya dayanılarak kullanılacak çerezlerde rızanın kullanıcının aktif bir eylemine, yani gerçek bir opt-in mekanizmasına dayanması gerekiyor. Önceden işaretlenmiş kutular veya “siteyi kullanmaya devam ederek kabul etmiş sayılırsınız” gibi pasif yöntemler geçerli bir açık rıza mekanizması olarak kabul edilmiyor.

Kaynak: KVKK – Çerez Uygulamaları Hakkında Rehber & KVKK Kurul Kararı – Çerezler ve opt-in uygulaması

Bu yüzden iyi bir privacy-first analitik mimarisinin ilk sorusu şu olmalı:

Tarayıcıya gerçekten bir şey yazmam gerekiyor mu?

Analitik amacıyla _ga benzeri kalıcı tanımlayıcılar veya kullanıcıyı sonraki ziyaretlerinde yeniden tanımaya yarayan kimlikler bırakmıyorsanız, çerez kaynaklı açık rıza ihtiyacını önemli ölçüde azaltabilirsiniz.

Ama burada kritik bir ayrım var: Tarayıcıya çerez yazmamak, tek başına KVKK kapsamından çıktığınız anlamına gelmez.

Sunucu tarafında kişisel veri işlemeye devam ediyorsanız hâlâ KVKK kapsamındaki yükümlülükleri değerlendirmeniz gerekir. Ayrıca KVKK’nın 5. maddesinde açık rıza dışında da çeşitli kişisel veri işleme şartları bulunur; dolayısıyla “kişisel veri işleniyorsa mutlaka açık rıza gerekir” yaklaşımı da her durumda doğru değildir.

Kaynak: KVKK – Kişisel Verilerin İşlenme Şartları, Madde 5

Ama hedefiniz basitse, en temiz başlangıç noktası da basit: Gerekmiyorsa tarayıcıda kalıcı bir kullanıcı kimliği bırakmayın.

2. “Kişiyi” İşaret Edebilecek Her Şeyden Kaçınmak

Piyasada “biz çerez kullanmıyoruz” diye tanıtılan bazı sistemler başka yöntemlere başvurabiliyor.

Çerez yazmıyorlar ama IP adresi, User Agent detayları, ekran çözünürlüğü, cihaz özellikleri veya tarayıcı parametreleri gibi sinyalleri birleştirip kullanıcının cihazını tekrar tanımaya yarayan gizli bir fingerprint (cihaz parmak izi) oluşturuyorlar.

Kendimizi kandırmayalım.

KVKK Madde 3, kişisel veriyi “kimliği belirli veya belirlenebilir gerçek kişiye ilişkin her türlü bilgi” olarak tanımlar. Bir kişinin adını bilmiyor olmanız, o kişiyi veya cihazını sürekli olarak tekilleştirebildiğiniz bir sistemin otomatik olarak anonim olduğu anlamına gelmez.

Kaynak: Kişisel Verileri Koruma Kurumu – Kişisel veri tanımı ve temel kavramlar

Tarayıcıya dosya yazmasanız bile, teknik parametreleri birleştirerek kalıcı bir ID türetiyor ve aynı kişiyi farklı ziyaretlerde takip ediyorsanız bu da kişisel veri işleme faaliyetine dönüşebilir.

Gerçekten gizlilik odaklı bir mimaride şunları hedeflemek gerekir:

• Ham IP adresini analitik veritabanında saklamamak: IP, isteğin internet üzerinden sunucuya ulaşabilmesi için teknik olarak gereklidir. Ama analitik sisteminizin bunu kalıcı şekilde kaydetmesi şart değildir. CDN, reverse proxy ve sunucu loglarının da bu açıdan ayrıca kontrol edilmesi gerekir.
• Kalıcı kullanıcı kimliği oluşturmamak: Aynı kişiyi haftalar veya aylar boyunca yeniden tanımaya yarayan bir identifier üretmemek.
• Kısa ömürlü oturum bağlamı kullanmak: Aynı ziyaret sırasında gerçekleşen event’leri birbirine bağlamak için kısa ömürlü ve yalnızca o oturumla sınırlı rastgele bir kimlik (ephemeral session ID) kullanılabilir.

Burada küçük ama önemli bir teknik not var: Bir session ID’nin rastgele üretilmesi, onu otomatik olarak “kişisel veri değil” hâline getirmez. Kişiyi belirlenebilir kılan veya başka verilerle ilişkilendirilebilen rastgele kimlikler de koşullara göre kişisel veri niteliğinde olabilir.

Dolayısıyla amaç “başka bir isim altında user ID üretmek” değil; amaç, oturum bittikten sonra kişiyi yeniden tanımaya çalışmamak.

Dün gelen kişiyle bugün gelen kişinin aynı insan olup olmadığını bilmiyorsanız çoğu ürün analitiği senaryosunda dünyanın sonu gelmez. Zaten bir checkout akışının çalışıp çalışmadığını anlamak için kullanıcıyı altı ay boyunca adım adım takip etmek zorunda değilsiniz.

3. Veriyi Kendi Sınırlarında Tutmak

Analytics tarafında “first-party” kelimesi bazen gereğinden fazla sihirli bir kavrammış gibi kullanılıyor.

Script’in veriyi analytics.sirketiniz.com gibi kendi alan adınıza göndermesi güzel bir başlangıçtır; ama tek başına yeterli değildir.

Asıl soru şudur: Veri oradan sonra nereye gidiyor?

İsteği kendi domain’iniz üzerinden alıp daha sonra aynı veriyi ABD’deki veya başka bir ülkedeki üçüncü taraf SaaS sağlayıcısına aktarıyorsanız, tarayıcı açısından first-party bir endpoint kullanmanız bu aktarımı hukuken first-party yapmaz.

Verinin hangi tüzel kişi tarafından işlendiği, hangi alt işleyenlerin kullanıldığı ve fiziksel veya hukuki olarak hangi ülkelere aktarıldığı ayrıca değerlendirilmelidir.

KVKK’nın 9. maddesi kişisel verilerin yurt dışına aktarılmasını düzenliyor. Üstelik bu alan 2024 yılında önemli ölçüde değişti. 1 Haziran 2024’te yürürlüğe giren yeniliklerle birlikte yeterlilik kararlarının yanında standart sözleşmeler, bağlayıcı şirket kuralları ve Kanun’da öngörülen diğer uygun güvence mekanizmaları da kullanılabiliyor.

Kaynak: Kişisel Verileri Koruma Kurumu – Yurt Dışına Aktarım & Standart Sözleşmeler

Dolayısıyla “veriyi Türkiye dışına göndermek her durumda yasaktır” demek de, “first-party domain kullandım, artık aktarım problemi kalmadı” demek de doğru değil.

Privacy-first tarafta temiz mimari şuna benzer:

Plaintext

Tarayıcı (Zero Storage) ───> First-Party Endpoint ───> Kontrol Ettiğiniz Sunucu Altyapısı

Verinin reklam ağlarına, veri aracılarına veya ihtiyacınız olmayan harici sistemlere aktarılmaması hem teknik mimariyi sadeleştirir hem de veri koruma açısından değerlendirilmesi gereken yüzeyi ciddi şekilde küçültür.

Geleneksel reklam teknolojilerinde ise davranış verileri farklı platformlar arasında paylaşılabilir veya başka sinyallerle eşleştirilebilir.

Burada hedef bütün interneti çözmek değil; kendi ürününüzü ölçmek için topladığınız veriyi sadece kendi ürününüzü geliştirmek için kullanmak.

4. “Kişi” Değil “Oturum” Ölçmek

KVKK’nın omurgasını oluşturan Madde 4, kişisel verilerin “işlendikleri amaçla bağlantılı, sınırlı ve ölçülü” olması gerektiğini söyler. Buna veri minimizasyonu diyoruz.

Kaynak: Kişisel Verileri Koruma Kurumu – Madde 4 ve Veri Minimizasyonu İlkesi

Dürüst olalım: Ürün geliştirirken veya pazarlama bütçesi yönetirken Ahmet Bey’in son 6 ay boyunca sitenizde hangi gün saat kaçta gezindiğini şahıs bazında bilmeye gerçekten ihtiyacınız var mı?

Çoğu zaman cevap hayır. İhtiyacınız olan sorular çok daha basittir:

• Hangi pazarlama kampanyası kaç oturum getirdi?
• Yeni checkout akışında dönüşüm oranı arttı mı, düştü mü?
• Kullanıcılar hangi sayfada takılıp siteden çıkıyor?
• Yeni yayınladığımız özellik gerçekten kullanılıyor mu?
• Dün yaptığımız deploy’dan sonra hata oranı arttı mı?

Bu soruların hiçbirinin cevabı için kullanıcıyı aylar boyunca takip eden kalıcı bir profil oluşturmak zorunda değilsiniz.

Ölçüm odağını “tekil kişi”den (unique user) “oturum”a (session) kaydırdığınızda, kalıcı kullanıcı profilleri oluşturmadan ve çok daha az kişisel veri işleyerek ürün ve pazarlama kararlarını yönlendirecek oldukça güçlü trend verilerine ulaşırsınız.

Bu yaklaşımın doğal olarak bazı bedelleri var: Örneğin 30 günlük user retention hesaplamak, uzun dönem kullanıcı yolculuklarını bireysel seviyede izlemek veya farklı cihazlarda aynı kişiyi eşleştirmek zorlaşır.

Ama privacy-first ölçümlemenin temel sorusu zaten tam olarak burada başlıyor:

Bu veriye gerçekten ihtiyacınız var mı?

İyi analitik, mümkün olan en fazla veriyi toplamak değildir; karar vermek için gerçekten ihtiyaç duyduğunuz en az ve en temiz veriyi toplamaktır.