Çerez Rızası Uyumu ve Consent Mode v2 — İspat ve Log Odaklı Rehber

Web sitenize bir çerez banner'ı eklemek, KVKK uyumunu tamamlamak anlamına gelmez. Kurul incelemelerinde ve ilgili kişi taleplerinde sorulan soru nettir: "Bu ziyaretçi hangi tarihte, hangi metne dayanarak, hangi kategorilere rıza verdi — ve bunu kanıtlayabiliyor musunuz?" Banner göstermek aydınlatmanın bir parçasıdır; rızanın alınması, saklanması ve ispatlanması ise ayrı bir mühendislik ve uyum problemidir.

İdari para cezaları tablosu, çerez ve aydınlatma eksikliklerinin somut riskini gösterir. 2026 KVKK idari para cezaları yazısında özetlendiği gibi, aydınlatma yükümlülüğüne aykırılık ayrı bir ceza kalemidir; teknik önlem ve kayıt tutma yükümlülüklerinin ihlali ise farklı bir kategoride değerlendirilir. Çerez uyumunda hem metin hem de kanıt zinciri eksikse risk katlanır.

Bu rehber, geliştirici ve teknik karar verici perspektifinden çerez rızası mimarisini ele alır: değiştirilemez (immutable) rıza logları, tarayıcı depolama teknolojisinden bağımsız rıza zorunluluğu ve Google Consent Mode v2'nin dört sinyalinin nasıl yapılandırılacağı.

KVKK'da çerez rızası: hukuki çerçeve

6698 sayılı Kanun'un 5. maddesi, kişisel verilerin işlenmesi için hukuki sebepleri sıralar. Pazarlama, profilleme ve davranışsal analiz amaçlı çerezler — IP adresi, cihaz tanımlayıcıları, tıklama verileri gibi kişisel veri içerenler — çoğu senaryoda açık rıza (m.5/1) veya meşru menfaat (m.5/2-f) ile gerekçelendirilir. Meşru menfaat, pazarlama çerezleri için sık kullanılan bir gerekçe değildir; pratikte analitik ve reklam çerezleri için açık rıza tercih edilir.

10. madde ise veri sorumlusunun aydınlatma yükümlülüğünü düzenler. Çerez banner'ı, aydınlatmanın bir aracıdır; ancak aydınlatma metni ile rıza mekanizması birbirinin yerine geçmez. Ziyaretçi, hangi çerez kategorisinin ne amaçla kullanıldığını anlamadan bilinçli bir tercih yapamaz.

Çerez envanterinizde hangi çerezin hangi amaçla işlendiği kayıtlı olmalıdır. Veri işleme envanteri nasıl hazırlanır rehberinde anlatıldığı gibi, web sitesi ziyaretçisi verisi de envantere dahil edilmeli; Google Analytics, Meta Pixel ve benzeri servisler "alıcı" veya "veri işleyen" olarak işaretlenmelidir.

Banner yeterli değil: ispat zinciri

Denetimde veya şikâyette karşılaşılan tipik senaryo şöyledir: Kurum, bir CMP (Consent Management Platform) veya kendi banner'ı ile rıza topladığını iddia eder; ancak sunulan kanıt yalnızca ekran görüntüsü veya güncellenebilir bir veritabanı kaydıdır. İlgili kişi "Ben pazarlama çerezlerine rıza vermedim" dediğinde, veri sorumlusu şu bilgileri somut olarak göstermelidir:

• Rızanın verildiği tarih ve saat (UTC+3, ISO 8601)
• Rızanın kapsamı (hangi kategoriler: zorunlu, analitik, pazarlama, tercih)
• O an geçerli olan aydınlatma metni sürümü
• Rızanın alındığı kanal (web widget, mobil uygulama)
• Ziyaretçi tanımlayıcısı (anonim session ID veya hash; kişisel veri minimizasyonu ile)

Bu bilgilerin sonradan değiştirilememesi kritiktir. Immutable log tasarımında:

1. Rıza kaydı oluşturulduktan sonra UPDATE veya DELETE yapılmaz.
2. Rıza geri çekildiğinde yeni bir "withdrawal" kaydı eklenir; orijinal rıza silinmez.
3. Log satırları append-only bir store'da tutulur (WORM semantiği veya denetim tablosu).

Örnek log yapısı (JSON):
{
  "event": "consent_granted",
  "timestamp": "2026-06-30T14:22:01+03:00",
  "categories": ["necessary", "analytics"],
  "policy_version": "cookie-policy-v3.2",
  "visitor_id": "anon_8f3a...",
  "user_agent_hash": "sha256:..."
}

Lexidata çerez widget'ı, rıza olaylarını merkezi Consents havuzunda method='cookie_widget' ile kaydeder; geri çekme olayları ayrı bir event olarak append edilir. Panelden rıza geçmişi sorgulanabilir ve denetimde dışa aktarılabilir.

localStorage, çerez ve teknolojiden bağımsız rıza

Geliştiricilerin sık yaptığı hata, rıza durumunu yalnızca localStorage veya bir first-party çerezde tutmaktır. Örneğin:

localStorage.setItem('cookie_consent', JSON.stringify({ analytics: true, marketing: false }));

Bu yaklaşım iki açıdan yetersizdir:

Hukuki ispat: localStorage istemci tarafında kolayca silinebilir veya manipüle edilebilir. Denetimde "sistemimizde rıza vardı" demek, sunucu tarafında doğrulanabilir bir kayıt olmadan zayıf kalır.

Teknik tutarlılık: Rıza durumu yalnızca tarayıcıda tutulduğunda, farklı cihazlar ve oturumlar arasında senkronizasyon yoktur. Kullanıcı rızasını geri çektiğinde, sunucu tarafında aktif pazarlama listelerinden çıkarılması gerekir.

Doğru mimari:

localStorage, kullanıcı deneyimi için kullanılabilir; ancak asıl rıza kanıtı sunucu tarafında tutulmalıdır. Widget, kullanıcı tercihini hem istemcide saklar hem de sunucuya POST eder; ikisi arasındaki tutarlılık periyodik olarak doğrulanabilir.

Google Consent Mode v2: dört sinyal

Mart 2024 itibarıyla Google, reklam ve analitik ürünlerinde Consent Mode v2 zorunluluğunu Avrupa Ekonomik Alanı (EEA) ve İngiltere için uygulamaya koydu. Türkiye EEA dışında olsa da, Google Ads ve GA4 kullanan Türk siteleri de bu sinyalleri doğru yapılandırmalıdır; aksi halde dönüşüm ölçümü ve remarketing kısıtlanır.

Consent Mode v2'de dört temel sinyal vardır:

Varsayılan durum: denied

Sayfa yüklenmeden önce, rıza verilmemiş tüm sinyaller denied olmalıdır. Google Tag Manager'da Consent Initialization tag'i, tüm diğer tag'lerden önce tetiklenir:

gtag('consent', 'default', {
  ad_storage: 'denied',
  analytics_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  wait_for_update: 500
});

wait_for_update, CMP'nin rıza durumunu okuması için kısa bir süre tanır; banner hızlı yükleniyorsa 500 ms yeterlidir.

Rıza sonrası: granted

Kullanıcı analitik ve pazarlama kategorilerine rıza verdiğinde:

gtag('consent', 'update', {
  ad_storage: 'granted',
  analytics_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted'
});

Kategori bazlı rıza modelinde yalnızca analitik seçildiyse:

gtag('consent', 'update', {
  analytics_storage: 'granted',
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied'
});

Advanced Consent Mode

Rıza verilmediğinde bile, Google modelleme (modeling) ile dönüşüm tahmini yapabilir; ancak bu, denied durumunda cookie'siz ping gönderimi gerektirir. Advanced Consent Mode etkinleştirildiğinde, rıza reddedilse bile anonim sinyaller gönderilir; kişisel veri aktarımı yapılmaz. KVKK açısından bu davranışın envanterde ve aydınlatmada açıkça belirtilmesi gerekir.

Uygulama kontrol listesi

Aşağıdaki tablo, çerez uyumunu teknik ve hukuki boyutta birlikte değerlendirmenize yardımcı olur:

Sık yapılan hatalar

Tag'lerin rızadan önce yüklenmesi. GTM'de GA4 veya Meta Pixel tag'i, Consent Initialization'dan önce tetikleniyorsa, rıza alınmadan çerez yazılır. Bu hem KVKK hem de Consent Mode açısından ihlaldir.

"Tümünü kabul et" varsayılanı. Pre-checked checkbox veya varsayılan açık kategoriler, açık rıza standardını karşılamaz. KVKK ve AB Rehberi (EDPB) opt-in modelini gerektirir.

Log'un güncellenebilir olması. Veritabanında rıza kaydının üzerine yazılması, denetimde güvenilirliği sıfırlar. Append-only tasarım şarttır.

Çerez envanterinin eksik kalması. Sitede 15 servis çalışırken envanterde 3 kayıt olması, aydınlatma ile gerçek uygulama arasında tutarsızlık yaratır.

Lexidata çerez widget'ı ile uyum

Lexidata çerez rıza modülü, yukarıdaki gereksinimleri tek bir embed script ile karşılamak üzere tasarlanmıştır:

• Çerez sözlüğü: Google Analytics, Meta Pixel, Hotjar gibi popüler servisler önceden tanımlı; envanter tek tıkla oluşturulur.
• Kategori bazlı banner: Zorunlu, analitik, pazarlama, tercih; varsayılan kapalı.
• Immutable rıza logu: Her rıza olayı sunucuda append-only kaydedilir; metin sürümü ve zaman damgası dahil.
• Consent Mode v2 entegrasyonu: Widget, gtag consent API'sini otomatik çağırır; GTM ile uyumlu.
• API erişimi: GET /api/integration/cookie-policy ve rıza kaydı endpoint'leri ile headless entegrasyon mümkün.

Banner eklemek bir gün sürer; ispat altyapısını doğru kurmak ise sürdürülebilir uyumun temelidir. Lexidata ile çerez envanterinizi, aydınlatma metninizi ve rıza kanıtınızı tek platformda yönetebilirsiniz.

Lexidata'yı keşfedin: lexidata.io — KVKK uyum platformu; çerez widget'ı, canlı veri envanteri ve TPRM modülleri.

İlgili yazılar