KVKK & Pazarlama Verisi Rehberi

Giriş: Pazarlama Ekibinin Sessiz Çelişkisi

Türk markalarının pazarlama ekipleri 2026'da sessiz bir çelişkinin ortasında. Bir tarafta last-click attribution ve performance marketing'in yıllar içinde kurduğu cookie + üçüncü taraf piksel zinciri var; öbür tarafta KVKK denetimleri, çerez uyum kararları ve tüketici nezdinde artan veri farkındalığı. CMO, CFO'ya "ROAS'ımız 4'e çıktı" derken, hukuk müşaviri "GA4'ten Meta CAPI'ye akan kullanıcı id'leri için açık rıza zinciriniz var mı?" diye sorduğunda toplantı gergin bir sessizliğe düşüyor.

Bu yazı, o sessizliği iyi sorularla doldurmak için yazıldı. Pazarlama Mix Modelleme (MMM) gibi agregat veriyle çalışan attribution yöntemlerinin neden KVKK ile doğal uyum sağladığını, KVKK Madde 12'nin pazarlama ekibinden ne istediğini, hangi verinin "PII" sayıldığını, açık rıza ile sözleşme yükümlülüğünün hukuki ayrımını, GA Consent Mode V2 sinyallerinin nasıl respect edileceğini ve silme talebinin 48 saatte nasıl işleneceğini pratik düzeyde anlatıyor. Bu yazı bağlayıcı hukuki tavsiye değildir — son satırdaki disclaimer'ı lütfen ihmal etmeyin.

KVKK Madde 12 Nedir?

Kişisel Verilerin Korunması Kanunu'nun 12. maddesi, "veri güvenliğine ilişkin yükümlülükler" başlığını taşır. Veri sorumlusunun (yani markanın) kişisel veriyi işlerken alması gereken teknik ve idari tedbirleri tarif eder. Pazarlama bağlamında bu yükümlülükler somutlaşır:

Veri akış kayıtları — hangi veri nereden geldi, nereye gitti, hangi amaçla işlendi. Standart MMM SaaS'ları bunu otomatik üretmek zorundadır; manuel dokümantasyon savunulamaz.
Aydınlatma metni — kullanıcıya ne tür verinin ne amaçla, hangi sürede, kimlerle paylaşılarak işlendiği yazılı olarak açıklanmalı. Bunu cookie banner'a sıkıştırmak yetmez; ayrı bir KVKK aydınlatma metni şarttır.
Açık rıza vs sözleşme yükümlülüğü — pazarlama analitiği için işlenen veri, kullanıcı sözleşmesinin bir parçası mı (örnek: müşteri panelinde "siparişlerinizi takip etmek için") yoksa açık rıza mı gerektiriyor (örnek: e-posta gönderimi için segment oluşturma)? Bu hukuki temel ayrımı yanlış kurarsanız KVKK denetiminde "rıza alınmamış" eleştirisiyle karşılaşırsınız.
Teknik tedbir — şifreleme (in-transit + at-rest), erişim kontrolü, audit log, veritabanı seviyesinde tenant izolasyonu gibi kontroller. Bu, "biz bulutu güvenli kullanıyoruz" yetmez; spesifik kontrolleri kanıtlayabilmelisiniz.
İdari tedbir — veri işleyenlerin (vendor) sözleşmeleri, çalışan eğitimleri, ihlal bildirim prosedürleri, periyodik denetimler.

Pratik anlamı: bir KVKK denetiminde "MMM modelinize hangi veriyi sokuyorsunuz, bu veri nasıl korunuyor, kim erişebiliyor, ne kadar süre saklanıyor, silme talebine kaç saatte yanıt veriyorsunuz?" sorularına satır satır cevap verebilmeniz gerekir. MMMytics bu cevapların hazır olduğu bir ürün olarak tasarlandı; her data submission'da otomatik bir KVKK Madde 12 kaydı üretilir, audit log'a yazılır, silme talebi tek tıkla 48 saatlik SLA'ya bağlanır.

Pazarlama Verisi Sınıflandırması

KVKK uyumunda en kritik adım, hangi verinin "kişisel veri" sayıldığını net görmektir. Pazarlama bağlamında verilerin kabaca üç kategorisi vardır:

1. Anonim agregat veri. Bu kategoride toplam impression, toplam click, toplam GRP, kanal bazlı haftalık harcama gibi hiçbir bireyi tanımlamayan, tamamen toplulaştırılmış sayılar yer alır. KVKK kapsamında "kişisel veri" değildir — çünkü bireyle ilişkilendirilemez. MMM tam olarak bu kategori ile çalışır. Modele "geçen hafta TV'de 1.2 milyon impression aldık" girer; "bu impression'ları kim gördü" girmez. Bu, MMM'in yapısal KVKK uyumudur, sonradan eklenmiş bir sertifika değil.

2. Pseudonymous (takma adlı) veri. Bu kategoride kullanıcı id (uid), client id (cid), advertising id (gaid/idfa), hash'lenmiş e-posta gibi bireyle yeniden ilişkilendirilebilen ama doğrudan kimlik bilgisi taşımayan veriler vardır. KVKK bu veriyi "kişisel veri" sayar — çünkü tek başına olmasa da diğer verilerle birleşince bireyi tanımlar. GA4 bu kategoride çalışır; Meta CAPI ve Conversions API hash'lenmiş e-posta + hash'lenmiş telefon ister. Bu veriler MMM'e girmez; girmesine gerek yoktur. Eğer pazarlama ekibi GA4 raw event export'unu MMM'e bağlamayı düşünüyorsa, agregasyon adımı şart: günlük/haftalık toplam impression'a düşürün, uid'leri silin.

3. Kişisel veri (PII). Doğrudan bireyi tanımlayan veri: ad-soyad, e-posta açık metin, telefon açık metin, TCKN, adres, doğum tarihi. MMMytics PII saklamaz. Daha da ötesi, MMMytics PII tespiti yapan bir yükleme öncesi kontrol katmanı çalıştırır: Data Hub upload pipeline, CSV'lerde TCKN regex, Türkçe ad-soyad pattern, e-posta + telefon formatı tespit eder ve PII içeren satırlar varsa yüklemeyi reddeder. Bu, KVKK Madde 12'nin "teknik tedbir" yükümlülüğünün somut hali — vendor PII'yi yanlışlıkla bile alamasın.

GA4 ve Meta CAPI gibi platformlardan MMM'e veri aktarırken pratik kural şudur: agregasyon zinciri uçtan uca kuralı. Raw event tablonuzdan MMM modeline doğrudan akış yapmayın; arada bir agregasyon adımı (haftalık toplam, sektör + bölge bazlı) bulunsun. Bu sadece KVKK için değil, model performansı için de iyi: MMM gürültüye değil, sinyale ihtiyaç duyar.

Veri Saklama & Lokasyon

KVKK Madde 9, kişisel verinin yurtdışına aktarımını sıkı koşullara bağlar: ya açık rıza, ya yeterli koruma sağlayan ülke listesi, ya bağlayıcı kurumsal kurallar. Türk pazarına hizmet eden bir SaaS için ABD region'ında veri tutmak pratik anlamda yasaktır — Cloud Act ve FISA gibi mekanizmalar nedeniyle ABD region "yeterli koruma" testini geçmez.

MMMytics tüm Türk müşteri verilerini AB bölgesinde tutar. Veritabanı, cache, dosya depolama ve hesaplama — uçtan uca Avrupa Birliği bölgesi. ABD region'a fallback yoktur; tasarım gereği imkansız.

Tenant izolasyonu için veritabanı seviyesinde tenant izolasyonu kullanılır. Her marka kendi brand_id'siyle filtrelenir; bir markanın analisti başka markanın verisini görmez, denese de göremez (politika veritabanı tarafında zorlar). Bu, "uygulama kodunda kontrol ediyoruz" değil, "veritabanı satır satır engelliyor" anlamına gelir — daha sağlam, denetlenebilir.

CDN tarafında bir nüans var: global CDN'ler ABD üzerinden de geçebilir. Bu noktada pratik ayrım şudur: statik asset (logo, JS bundle, CSS) global CDN'den servis edilebilir — bunlarda kişisel veri yoktur. API endpoint'leri ve data plane ise her zaman AB region'a sabitlenmelidir. MMMytics'te API çağrıları doğrudan AB bölgesine gider; CDN sadece marketing site statik içerik için kullanılır.

Açık Rıza & GA Consent Mode V2

2024'te Google Avrupa için Consent Mode V2'yi zorunlu hale getirdi; consent sinyali olmadan reklam veri akışı kesiliyor. Türkiye doğrudan AB değil ama KVKK + reklam ekosistemi pratiği aynı yola gidiyor. Pazarlama ekibinin pratik olarak yönetmesi gereken 4 consent kategorisi var:

ad_storage — reklam çerezi izni
analytics_storage — analitik çerezi izni
ad_user_data — reklam ağıyla kullanıcı verisi paylaşma izni
ad_personalization — kişiselleştirilmiş reklam izni

Cookie banner bu 4 kategoriyi ayrı ayrı sormalıdır; "Hepsini kabul et" tek tuşu KVKK ile tutarsızdır (rıza spesifik ve özgür olmalı). Banner reddedildiğinde GA4, Google Ads ve Meta Pixel reklam veri akışını keser; analytics_storage denied'da bile aggregate impression sayımı (consent-less aggregation) devam eder ama kullanıcı bazlı attribution durur.

İşte MMM'in KVKK avantajının somut göründüğü yer: consent denied modda bile MMM çalışmaya devam eder, çünkü modele kullanıcı bazlı veri zaten girmiyor. Toplam impression, toplam click, toplam GRP — bu sayılar consent durumundan bağımsız sayılır. Cookie reddedildiğinde last-click attribution kör olur; MMM görmeye devam eder. Bu, "MMM, cookie sonrası dünyanın attribution standardıdır" iddiasının en somut kanıtı.

Pratik öneri: cookie banner + Consent Mode V2 + MMM üçlüsünü beraber kurun. Kullanıcı consent verirse last-click + MMM hibrit; consent vermezse MMM tek başına. Her iki dünyada da CFO'ya rapor üretebilirsiniz.

Silme Hakkı & 48 Saatlik SLA

KVKK Madde 11, kullanıcıya "kişisel verisinin silinmesini talep etme" hakkı verir. Pazarlama veri ekosisteminde bu hakkı işlemek karmaşık görünür: veri 5 yerde olabilir — DB, dosya depolama, cache, CDN edge cache, vendor (örnek: CRM ve email pazarlama platformları). Bir noktada bile silinmemiş kalırsa "silme talebi tamamlanmadı" sayılır.

MMMytics bu süreci 48 saatlik bir SLA'ya bağlar:

Müşteri silme talebini panel üzerinden veya destek kanalı ile iletir.
Talep audit log'a düşer; admin onay görür.
48 saat içinde silme akışı çalışır: veritabanı satırı, dosya depolama objesi, cache key, audit log retention pointer.
Silme tamamlandı kaydı yine audit log'a yazılır (silinen verinin meta'sı kalır; veri kendisi gider).
Müşteriye e-posta + dashboard bildirimi gider.

Burada önemli bir ayrım: audit log retention silinmez. Yani "şu kullanıcı X tarihinde silme talep etti, X+48h içinde Y veriler silindi" kaydı yasal yükümlülük olarak saklanır — ne yaptığınızı kanıtlayan kayıt KVKK Madde 12'nin gereği. Veri kendisi gider; yapılan işlemin meta kaydı kalır.

Bu süreç agregat veride farklı işler. MMM modeline giren haftalık toplam impression bir bireyle ilişkili değildir; bu yüzden silme talebi MMM modelini etkilemez. Müşteri "X kullanıcısının verisini silin" diyebilir; "X kullanıcısının bu hafta yarattığı toplam impression katkısını silin" diyemez (anonim agregatta birey tanımlı değil). Bu, MMM'in KVKK uyum sürecinde silme adımını sadeleştiren bir özelliği.

CTA

KVKK uyumunu pazarlama ölçümünün önünde bir engel değil, modeli daha temiz veriyle besleyen bir disiplin olarak görmek mümkün. MMMytics'in nasıl çalıştığını görmek için Demo Talep Et; ürün ve metodoloji için Hakkımızda; planlar için Fiyatlandırma sayfasını inceleyebilirsiniz. Resmi mevzuat metni için kvkk.gov.tr referans kaynağıdır.

Bu yazı genel bilgilendirme amaçlıdır; bağlayıcı hukuki tavsiye için kurumunuzun KVKK danışmanına başvurun. Avukat metinleri ofisimizle netleşmektedir; nihai sözleşme metinleri Enterprise sözleşme görüşmesinde paylaşılır.