Çerez onayı verileri nasıl kanıtlanır?

Çerez onayı verileri; kullanıcının seçimini, seçimin zamanını, kapsamını ve sonradan geri çekilmesini değiştirilemez kayıtlarla göstererek kanıtlanır. KVKK bakımından reklam, pazarlama ve zorunlu olmayan analitik çerezleri varsayılan olarak çalışmamalıdır. Kullanıcı, bu amaçlar için aktif ve açık bir tercih yapmadan önce ilgili script, piksel, depolama alanı veya üçüncü taraf çağrısı yüklenmemelidir.

Yalnızca banner ekran görüntüsü saklamak yeterli değildir. Denetim sırasında hangi metnin gösterildiği, hangi kategorilerin sunulduğu, hangi servislerin çalıştığı ve kullanıcının neyi kabul ettiği birlikte incelenir. Bu nedenle kanıt, arayüz kaydıyla teknik logların eşleştirilmesine dayanır.

Çerez onayını kanıtlamak neden yalnızca banner kaydıyla mümkün değildir?

Çerez onayını kanıtlamak için banner tasarımı, kullanıcı tercihi ve gerçek teknik davranış aynı sonucu göstermelidir. Banner kabul seçeneği sunarken Google Analytics, Meta Pixel veya reklam etiketi sayfa açılışında çalışıyorsa, görsel uyum teknik uyumu kanıtlamaz.

Bir ekran görüntüsü, belirli bir tarihte belirli bir tasarımın bulunduğunu gösterebilir. Ancak kullanıcının hangi seçeneğe bastığını, hangi amaçları kabul ettiğini veya etiketlerin o seçimden sonra çalıştığını göstermez. Bu ayrım, onay kayıtlarının ispat değerini belirler.

Kanıt zincirinin ilk parçası, onay arayüzünün sürümüdür. Metin, kategori adları, satıcı listesi, gizlilik politikası bağlantısı ve buton davranışı sürüm numarasıyla saklanmalıdır. Böylece eski bir onay, sonradan değişen banner metniyle karıştırılmaz.

Kanıt zincirinin ikinci parçası, kullanıcının yaptığı işlemdir. “Tümünü kabul et”, “tümünü reddet” ve kategori bazlı seçimler ayrı olaylar olarak kaydedilmelidir. Yalnızca “banner görüldü” kaydı, açık rıza verildiğini göstermez.

Kanıt zincirinin üçüncü parçası, site davranışıdır. Onaydan önce ve sonra tarayıcı depolaması, ağ istekleri ve script yüklemeleri karşılaştırılmalıdır. Bu test yapılmadan tutulan loglar, fiili uygulamayı açıklamakta yetersiz kalabilir.

Çerez onayı kaydında hangi bilgiler bulunmalıdır?

Çerez onayı kaydında en az kullanıcıya ait takma kimlik, olay zamanı, tercih kapsamı, banner sürümü, politika sürümü ve teknik uygulama sonucu bulunmalıdır. Gerçek kimlik bilgisi her senaryoda gerekli değildir.

Takma kimlik, tarayıcıya verilen rastgele bir consent ID olabilir. Bu ID, doğrudan ad veya e-posta içermemelidir. IP adresi tutulacaksa amaç, saklama süresi ve erişim yetkisi ayrıca belgelenmelidir; IP tek başına güvenilir onay kanıtı değildir.

Zaman bilgisi saat dilimiyle birlikte kaydedilmelidir. Sunucu zamanı, istemci zamanı ve logun oluşturulma zamanı birbirinden ayrılabilir. Denetimde zaman sırasını göstermek için UTC kullanmak ve uygulama standardını yazılı hale getirmek faydalıdır.

Tercih kapsamı ayrıntılı tutulmalıdır. Örneğin “analitik kabul edildi” kaydı, reklam ve pazarlama kategorilerinin de kabul edildiği anlamına gelmez. Kategori adları, çerez kategorileri nasıl doğru adlandırılır açıklamasıyla tutarlı kullanılmalıdır.

Her kayıt, kullanıcı işleminin türünü de belirtmelidir. “Kabul”, “reddet”, “kategori güncelleme”, “geri çekme” ve “tercih merkezi açıldı” farklı olaylardır. Geri çekme işlemi, önceki kabul kaydını silmemeli; yeni ve daha sonraki bir olay olarak kaydedilmelidir.

Örnek bir kayıt yapısı şöyle olabilir: consent_id, event_type, event_time, selected_categories, banner_version, policy_version, vendor_version, page_url, locale ve implementation_status. Bu alanlar tek başına yeterli değildir; logların nasıl korunduğu da ayrıca gösterilmelidir.

Opt-in çerez sistemi teknik olarak nasıl çalışmalıdır?

Opt-in sisteminde zorunlu olmayan etiketler, kullanıcı aktif seçim yapana kadar yüklenmemelidir. Varsayılan işaretli kutular, önceden seçilmiş kategori anahtarları ve yalnızca bannerı kapatma davranışı geçerli reklam rızası olarak yorumlanmamalıdır.

Uygulama genellikle bir rıza katmanıyla başlar. Bu katman, consent ID üretir ve kullanıcının kategori tercihini kaydeder. Ardından etiket yöneticisi veya site kodu, her etiketi ilgili kategoriye bağlar. “analytics” seçilmeden analitik etiketi, “advertising” seçilmeden reklam etiketi tetiklenmez.

Burada kritik nokta, etiket yöneticisinin varsayılan davranışıdır. Sadece tetikleyici kuralı değiştirmek yeterli olmayabilir. Script doğrudan tema dosyasına, eklentiye, sunucu tarafı bileşene veya üçüncü taraf iframe içine gömülmüşse, bu çağrıların tamamı incelenmelidir.

Örneğin bir video hizmeti iframe'i, kullanıcı oynat düğmesine basmadan önce üçüncü taraf çerezi bırakabilir. Harita, canlı destek, sosyal medya akışı ve reklam pikseli de benzer risk taşır. Bu bileşenler gerekli değilse, önce nötr yer tutucu gösterilmelidir.

Teknik doğrulama için üç ayrı tarama yapılmalıdır: temiz tarayıcıda ilk ziyaret, tüm kategoriler reddedildikten sonra ziyaret ve yalnızca tek kategori kabul edildikten sonra ziyaret. Her taramada çerezler, localStorage kayıtları, network istekleri ve üçüncü taraf alan adları listelenmelidir.

Yanlış: “Banner var, bu nedenle analitik ve reklam çerezleri uyumludur.” Doğru: “Onay öncesi etiketler engellendi, seçilen kategori sonrasında yalnızca ilgili servis çalıştı ve bu olay loglandı.”

Reklam ölçümünün teknik sınırlarını ayrıca değerlendirmek gerekir. Üçüncü taraf çerezleri olmadan reklam ölçülür mü sorusunun cevabı, kullanılan ölçüm yöntemi ve rıza mimarisi birlikte incelenerek verilmelidir.

Çerez onayı geri çekme işlemi nasıl kanıtlanır?

Çerez onayı geri çekme işlemi, kabul kadar kolay erişilen bir tercih merkeziyle yapılmalı ve geri çekme sonrasında ilgili teknolojiler durdurulmalıdır. Kullanıcıdan destek talebi açması veya e-posta göndermesi istenmemelidir.

Geri çekme bağlantısı, sitenin sabit bir bölümünde görünür olmalıdır. Footer, gizlilik merkezi veya yüzen bir tercih düğmesi kullanılabilir. Bağlantının yalnızca ilk ziyaret bannerında bulunması yeterli değildir; kullanıcı kararını daha sonra da değiştirebilmelidir.

Geri çekme gerçekleştiğinde yeni bir olay kaydı oluşturulmalıdır. Bu kayıt, hangi consent ID'nin hangi kategoriler için geçersiz hale geldiğini ve işlemin ne zaman yapıldığını göstermelidir. Eski kabul kaydını silmek, karar geçmişinin bütünlüğünü zayıflatır.

Tarayıcıdaki çerezlerin silinmesi de ayrıca ele alınmalıdır. Bazı first-party çerezler JavaScript ile silinebilir, bazı üçüncü taraf depolama alanları ise aynı yöntemle yönetilemeyebilir. Böyle durumlarda yeni reklam ve analitik çağrıları durdurulmalı, teknik sınırlama belgelenmelidir.

Geri çekme sonrasında test, yalnızca banner ekranına bakılarak yapılmaz. Tarayıcı geliştirici araçlarında network kayıtları incelenir. Yeni sayfa yüklemesinde piksel çağrısı, ölçüm isteği, reklam kimliği veya üçüncü taraf çerezi oluşup oluşmadığı kontrol edilir.

Rıza mekanizmasının kullanıcıya açık anlatılması da önemlidir. Web sitesinde reklam çerezi için rıza nasıl alınır içeriğinde açıklanan aktif seçim ilkesi, geri çekme ekranında da korunmalıdır. Kabulden daha zor bir geri çekme akışı kullanılmamalıdır.

Çerez onayı kayıtlarının bütünlüğü nasıl korunur?

Çerez onayı kayıtlarının bütünlüğü, sonradan sessizce değiştirilemeyecek log yapısı ve düzenli erişim kayıtlarıyla korunur. Veritabanında bir satırı güncellemek yerine olayların eklenerek ilerlediği append-only yapı tercih edilmelidir.

Her olay için benzersiz bir kayıt numarası kullanılabilir. Önceki kaydın özeti veya hash değeri sonraki kayda bağlanırsa, aradaki değişiklikler daha kolay fark edilir. Bu yöntem hukuki sonucu tek başına garanti etmez; teknik bütünlük kontrolü sağlar.

Log sunucusuna erişim, uygulama yöneticilerinden ayrılmalıdır. Uygulama kodunu değiştirebilen kişinin geçmiş onay kayıtlarını da değiştirebilmesi risk oluşturur. Rol tabanlı yetki, iki aşamalı yönetici erişimi ve erişim olaylarının kaydı uygulanmalıdır.

Yedekleme düzeni de kanıtın parçasıdır. Onay logları yalnızca canlı veritabanında tutulursa, silinme veya bozulma sonrasında geçmiş kararlar kaybolabilir. Yedeklerin şifrelenmesi, geri yükleme testinin yapılması ve saklama politikasının yazılı olması gerekir.

Rapor dışa aktarılırken ham kayıt ile özet rapor ayrılmalıdır. Özet rapor “bu kategoride şu kadar kabul” bilgisini verir. Ham kayıt ise hangi consent ID'nin hangi sürümle ve hangi işlemle oluştuğunu gösterir.

Kayıtların saklama süresi, işletmenin hukuki değerlendirmesine ve veri minimizasyonu kararına göre belirlenmelidir. Her site için geçerli tek bir süre varsayılmamalıdır. Süre, amaç, erişim yetkisi ve silme yöntemiyle birlikte dokümante edilmelidir.

Üçüncü taraf araçların çerez onayıyla bağlantısı nasıl gösterilir?

Üçüncü taraf araçların onayla bağlantısı, her servis için amaç, kategori, alan adı ve tetiklenme koşulu kaydedilerek gösterilir. Google Analytics, reklam etiketleri, Meta Pixel, video oynatıcılar ve sohbet araçları ayrı ayrı envantere alınmalıdır.

Servis envanterinde yalnızca marka adı yazmak yeterli değildir. Hangi scriptin hangi alan adından geldiği, hangi çerezleri veya depolama anahtarlarını kullandığı ve hangi kategoriye bağlı olduğu belirtilmelidir. Vendor değişirse sürüm veya envanter tarihi güncellenmelidir.

Bir etiketin “analitik” olarak adlandırılması, otomatik biçimde zorunlu olduğu anlamına gelmez. Ziyaretçi davranışı ölçülüyor, profil çıkarılıyor veya reklam performansı izleniyorsa amaç ve hukuki dayanak ayrıca değerlendirilmelidir.

Sunucu tarafı ölçüm, tarayıcıdaki tüm yükümlülükleri ortadan kaldırmaz. Tarayıcıda çerez bırakılmasa bile kullanıcıya ait olay verisi başka bir sisteme gönderilebilir. Bu nedenle server-side tracking de rıza akışındaki ilgili koşula bağlanmalıdır.

Google veya başka bir reklam platformu, kendi teknik ayarlarında “consent” sinyali destekleyebilir. Ancak bu sinyal, sitedeki açık rıza sürecinin yerine geçmez. Önce site üzerindeki tercih kaydedilmeli, sonra platforma uygun durum bilgisi iletilmelidir.

Üçüncü taraf veri aktarımını değerlendirirken güvenlik de kontrol edilmelidir. Web sitesinde güvenlik başlıkları nasıl eklenir rehberindeki CSP ve ilgili başlıklar, izinsiz script eklenmesini azaltabilir. Güvenlik başlıkları ise tek başına rıza kanıtı değildir.

Çerez onayı için hangi teknik kontrol listesi kullanılmalıdır?

Çerez onayı kontrol listesi, arayüzü, tarayıcı davranışını, kayıt sistemini ve geri çekme sürecini aynı denetimde incelemelidir. Liste yalnızca tasarım ekibine değil, geliştirici ve veri sorumlusu ekiplerine de uygulanmalıdır.

• Zorunlu olmayan çerezler ilk ziyarette varsayılan olarak çalışmıyor mu?
• “Tümünü kabul et” ve “tümünü reddet” seçenekleri görünür ve dengeli mi?
• Kategori bazlı seçimlerde kutular başlangıçta boş mu?
• Her kategori için amaç, sağlayıcı ve çerez bilgisi açıklanıyor mu?
• Banner, tercih merkezi ve aydınlatma metni sürümleri kaydediliyor mu?
• Consent ID, olay zamanı ve seçilen kategoriler tutuluyor mu?
• Onay öncesi network istekleri ve depolama kayıtları kontrol edildi mi?
• Geri çekme bağlantısı her sayfadan erişilebilir mi?
• Geri çekme sonrası yeni reklam ve analitik çağrıları duruyor mu?
• Loglara erişim yetkisi sınırlandırılıyor ve yedekleniyor mu?

Kontrol listesi her sürüm değişikliğinde yeniden uygulanmalıdır. Banner metni, etiket yöneticisi, tema, analiz aracı veya reklam hesabı değiştiğinde eski test sonucu geçerli sayılmamalıdır.

Test sonucu yalnızca “başarılı” veya “başarısız” şeklinde tutulmamalıdır. Test tarayıcısı, sayfa adresi, tarih, kullanıcı seçimi, görülen çağrılar ve ekran görüntüsü birlikte saklanmalıdır. Böylece sonucu başka ekip de tekrarlayabilir.

Banner reddetme seçeneğiyle ilgili ayrıntılar için çerez bannerında reddet seçeneği zorunlu mu başlığındaki değerlendirme kullanılabilir. Buradaki temel test, kullanıcıyı kabul seçeneğine zorlamayan eşit erişilebilirliktir.

Çerez onayı kanıtı hazırlanırken hangi adımlar izlenmelidir?

Çerez onayı kanıtı hazırlamak için önce mevcut teknolojiler çıkarılmalı, sonra rıza kategorileriyle eşleştirilmelidir. Doğrudan banner tasarımına başlamak, arka planda çalışan gizli scriptlerin gözden kaçmasına neden olabilir.

1. Siteyi temiz tarayıcı profiliyle açın ve ilk yükleme çağrılarını kaydedin.
2. Çerezleri, localStorage anahtarlarını, piksel isteklerini ve üçüncü taraf alan adlarını listeleyin.
3. Her teknolojiyi zorunlu, analitik, reklam veya pazarlama amacıyla sınıflandırın.
4. Banner ve tercih merkezi seçeneklerini kategorilerle eşleştirin.
5. Her etiketi yalnızca ilgili aktif tercih sonrasında çalışacak şekilde bağlayın.
6. Onay, ret ve geri çekme işlemlerinde ayrı olay kayıtları üretin.
7. Test sonuçlarını banner, politika ve etiket sürümleriyle birlikte arşivleyin.

İlk adımın amacı, sitenin kullanıcıya ne söylediğini değil, tarayıcıya ne yaptığını görmektir. Tarama sırasında hiçbir seçim yapılmadan oluşan her kayıt incelenmelidir. Bir çağrının gerekliliği varsayımla değil, amacıyla açıklanmalıdır.

İkinci aşamada tercih modeli belirlenir. Örneğin kullanıcı yalnızca analitik kategoriyi kabul ederse reklam etiketleri çalışmamalıdır. Tek bir genel “consent=true” değişkeni, kategori ayrımını ispatlamak için yetersiz olabilir.

Son aşamada teknik kayıtla kullanıcı arayüzü eşleştirilir. Logda banner sürümü 4 görünürken arşivde yalnızca sürüm 3 varsa, kayıtların yorumlanması zorlaşır. Bu nedenle sürümleme süreci yayın takviminin parçası olmalıdır.

Çerez onayı uygulamasında en sık yapılan hatalar nelerdir?

En sık hata, bannerı ekledikten sonra site kodunu taramamaktır. Eklentiler, tema dosyaları, gömülü formlar ve üçüncü taraf iframe'ler banner kararından bağımsız çalışabilir. Bu durumda kullanıcı seçimi ile teknik işlem arasında kopukluk oluşur.

İkinci hata, tüm çerezleri tek kategori altında toplamaktır. “İşlevsel” adıyla reklam veya davranışsal analiz teknolojilerini gizlemek, kullanıcıya yeterli bilgi vermez. Kategori isimleri teknik ekip için değil, tercihte bulunan kullanıcı için anlaşılır olmalıdır.

Üçüncü hata, reddetme işleminde yalnızca yeni çerez yazımını durdurmaktır. Daha önce oluşturulmuş kimliklerin, sonraki sayfa çağrılarının ve sunucu tarafı veri akışının da incelenmesi gerekir.

Dördüncü hata, consent ID'yi kullanıcı hesabı sanmaktır. Kimliksiz ziyaretçide de tercih kaydı tutulabilir. Ancak consent ID'nin hangi cihaz veya tarayıcı bağlamında geçerli olduğu açıkça belgelenmelidir.

Beşinci hata, logları manuel tabloya aktarmaktır. Manuel tablolar rapor hazırlamak için kullanılabilir; fakat ham olay kaydının yerini tutmaz. Kaynağı belli olmayan bir Excel satırı, teknik uygulamayla ilişkilendirilemez.

Altıncı hata, yasal metni güncelleyip teknik sürümü değiştirmemektir. Yeni bir sağlayıcı veya yeni bir reklam amacı eklendiğinde, eski rızanın kapsamının devam edip etmediği değerlendirilmelidir. Kapsam değişiyorsa yeniden seçim gerekebilir.

Sonuç olarak güçlü kanıt, tek bir belge değil; arayüz sürümü, aktif seçim, etiket engelleme, olay logu, geri çekme kaydı ve test raporunun birlikte oluşturduğu dosyadır.