1. Clean Room Nedir? Reklam Teknolojilerinde Nasıl Çalışır?
Clean room nedir, reklam teknolojilerinde nasıl çalışır?
Kısa yanıt: clean room, iki tarafın (ör. reklam platformu + reklamveren) verilerini doğrudan birbirine açmadan belirli kurallar altında analiz etmeyi amaçlayan bir ortamdır. Teknik olarak çıktıların çoğu “segment/aggregate” seviyesinde tutulur; ham kişisel veri kullanıcıya açılmaz. Buradaki başarı kriteri; kimin neyi görebildiğinin net tanımlanması ve çıktıların minimum risk seviyesinde sınırlandırılmasıdır.
Clean room’un teknik bileşenleri (genel)
- •Girdi veri setleri (reklamveren 1st party + platform sinyalleri)
- •Eşleştirme anahtarı (çoğunlukla hashlenmiş tanımlayıcı)
- •Erişim rolleri (kim sorgu çalıştırabilir?)
- •Çıktı kısıtları (aggregate/threshold)
- •Audit/raporlama (kim ne çalıştırdı?)
“Kimin neyi gördüğü” sorusu en kritik risk kontrolüdür
Clean room yaklaşımı, ham veriyi tamamen ortadan kaldırmaz; “görünürlük ve kullanım sınırı” koyar. Bu sınırların teknik ve hukuki olarak birlikte ele alınması gerekir.
☑ Mini Check :
- •Clean room’da tarafların görünürlük sınırları net mi?
- •Çıktıların segment/aggregate seviyesinde kaldığı garanti mi?
- •Sorgu/rapor yetkileri rol bazlı mı?
- •Audit log var mı (kim ne çalıştırdı)?
- •Refresh planı var mı (180 gün)?
Ne yapmalıyım?
- • Clean room kullanım amacını yazın (hedefleme mı ölçüm mü?).
- • Çıktı seviyesini sınırlandırın (segment/aggregate).
- • Rolleri belirleyin (pazarlama analisti ≠ admin).
- • Sorgu ve export olaylarını loglayın.
- • KVKK veri güvenliğiyle hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Hashlenmiş Kitleler (Hashed Audiences) ve KVKK: Teknik Gerçekler
Hashlenmiş kitleler KVKK açısından avantaj sağlar mı? (Teknik bakış)
Kısa yanıt: hash, ham tanımlayıcıyı (e-posta/telefon) doğrudan paylaşmaktan daha kontrollü bir adım olabilir; ancak tek başına “uyum garantisi” değildir. Teknik avantajı, ham veriyi dışarıda tutmaya yardımcı olmasıdır; teknik riski ise yanlış uygulanırsa (zayıf süreç, geniş erişim, gereksiz veri) yine kontrol kaybı yaratmasıdır.
Hashing’de pratik kurallar
- •Minimum alan: yalnız gerekli tanımlayıcılar (gereksiz kolon yok)
- •Standart format: normalize edilmeden hashleme hatalı eşleşme yaratır
- •Erişim kontrolü: ham veri + hash çıktısı aynı yerde durmamalı
- •Pipeline: hashleme adımı otomatik ve loglanan olmalı
Hashing + minimizasyon birlikte çalışır
“Ne kadar çok alan, o kadar iyi eşleşme” motivasyonu risklidir. En güvenli yaklaşım; kullanım amacına göre minimum veri ile ilerlemektir.
☑ Mini Check :
- •Hashleme öncesi veri normalize ediliyor mu?
- •Kullanılan alanlar minimum mu?
- •Ham veri erişimi çok kısıtlı mı?
- •Hashleme pipeline’ı loglanıyor mu?
- •Hash çıktısının retention’ı tanımlı mı?
Ne yapmalıyım?
- • Hashleme için “input standardı” belirleyin (format/temizlik).
- • Ham veriyi ayrı ve erişimi kısıtlı yerde tutun.
- • Hash pipeline’ını otomatikleştirin ve audit log ekleyin.
- • Hash çıktısına retention/rotate uygulayın.
- • Veri sınıflandırma yaklaşımıyla hizalayın: https://dgtlface.com/tr/yazilim/blog/veri-siniflandirma-ve-etiketleme-kvkk-icin-teknik-data-classification-modeli
3. 1st Party Veri ile Platform Entegrasyonları: CRM→Hash→Platform Akışı
1st party veri aktivasyonu, genelde CRM’den başlar. Bu noktada akış tasarımı kritik hale gelir: ham CRM listesini doğrudan taşımak yerine hashleme katmanı ve erişim kontrolleriyle taşımak hedeflenir.
Akışın ideal bileşenleri
- •CRM listesi seçimi (segment bazlı, minimum alan)
- •Hashleme servisi (otomatik, loglanan)
- •Platform entegrasyonu (upload/API)
- •Erişim rolleri (kim listeleri oluşturur/yükler?)
- •Audit log (hangi liste, ne zaman, kim?)
Otel: sadakat listelerinden remarketing
Sadakat listeleri genelde yüksek kalite segmentlerdir. Burada “segment tanımı” ve “kullanım amacı” net olmalı; gereksiz veri taşınmamalıdır.
B2B: müşteri listesi eşleştirme
B2B’de ABM yaklaşımında müşteri listeleri sık kullanılır. Bu listelerde “iş e-postası” alanı bile hassas kabul edilip süreçle yönetilmelidir.
☑ Mini Check :
- •Liste oluşturma yetkisi rol bazlı mı?
- •Liste içeriği minimum alan mı?
- •Hashleme pipeline’ı otomatik ve loglanan mı?
- •Platform entegrasyonunda export/upload log var mı?
- •Liste lifecycle (silme/yenileme) tanımlı mı?
Ne yapmalıyım?
- • “Liste talebi → onay → üretim → yükleme” süreci yazın.
- • Liste oluşturma/yükleme rollerini ayırın.
- • Upload olaylarını loglayın (kanıt).
- • Liste retention politikası belirleyin (180 gün gözden geçirme).
- • Sosyal medya reklamları ve remarketing içerikleriyle bağlayın: https://dgtlface.com/tr/smm/sosyal-medya-reklamlari — https://dgtlface.com/tr/sem/remarketing-ve-display
4. Riskler ve Sınırlar: Hashing + Clean Room Nerede Yanlış Gider?
Hashing + clean room kullanımında hangi teknik sınırlar olmalı?
Kısa yanıt: minimum veri, minimum erişim, minimum çıktı. Teknik sınırlar; (1) ham veriye erişim, (2) liste üretim/yükleme yetkisi, (3) clean room sorgu yetkileri ve (4) çıktıların aggregate seviyede tutulmasıdır.
Tipik riskler
- •Gereksiz kolonlarla liste büyütme
- •Ham veri ve hash çıktısını aynı ekipte yayma
- •Platform panel erişimlerinin çok geniş olması
- •Clean room çıktılarının mikro segmentlere düşmesi
- •Liste lifecycle’ının olmaması (sonsuz saklama)
“Hukuk + teknik” birlikte çalışmalı
Bu kullanım, yalnız teknik mesele değildir; ama teknik kontroller olmazsa hukuki çerçeve de yürütülemez. Bu rehber hukuki yorum yapmaz; teknik sınırları netleştirir.
☑ Mini Check :
- •Ham veri erişimi minimum mu?
- •Platform panel MFA/RBAC var mı?
- •Clean room çıktıları segment seviyesinde mi?
- •Liste retention/silme kuralı var mı?
- •Olay/denetim için audit log saklanıyor mu?
Ne yapmalıyım?
- • Platform panel erişimini MFA + rol bazlı sınırlayın.
- • Clean room çıktılarında minimum segment eşiği uygulayın.
- • Hashlenmiş liste lifecycle’ı belirleyin (süre, silme).
- • Audit log’ları saklayın (kim, ne zaman, hangi liste).
- • KVKK veri güvenliğiyle bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
5. Otel ve B2B İçin Kullanım Senaryoları: Privacy-Aware AdTech Modeli
Bu bölüm, “nasıl uygulanır”ı senaryo bazında bağlar: otelde sadakat + remarketing; B2B’de ABM + müşteri listesi eşleştirme.
Otel senaryosu: sadakat listesi remarketing
- •Segment: tekrar gelen misafir / erken rezervasyon kitlesi
- •Akış: CRM segment → hash → platform → kampanya
- •Kontrol: sadece gerekli alanlar, liste erişimi sınırlı, audit log
B2B senaryosu: müşteri listesi eşleştirme (ABM)
- •Segment: hedef hesap listesi
- •Akış: CRM → hash → platform → ABM kampanyası
- •Kontrol: panel erişimi dar, clean room ölçüm segment seviyesinde
Key Statistic / Data Point (yumuşatılmış)
Hashlenmiş kitle/clean room kullanan kurumlarda, ham müşteri verisini doğrudan platforma vermek yerine daha kontrollü paylaşım modelleri test edilebiliyor; ancak başarının anahtarı süreç ve erişim kontrolüdür.
☑ Mini Check :
- •Liste üretimi minimum veri prensibinde
- •Hash pipeline loglanıyor ve erişim kısıtlı
- •Platform panel MFA/RBAC aktif
- •Clean room çıktıları aggregate
- •Liste lifecycle ve retention tanımlı (180 gün refresh)
Ne yapmalıyım?
- • CRM segmentlerini “amaç”a göre standartlaştırın (kullanım gerekçesi).
- • Hashleme pipeline’ını otomatikleştirin ve audit ekleyin.
- • Panel erişimlerini daraltın (MFA + rol).
- • Clean room çıktılarında minimum segment eşiği koyun.
- • İç linklerle süreçleri bağlayın: https://dgtlface.com/tr/smm/sosyal-medya-reklamlari — https://dgtlface.com/tr/sem/remarketing-ve-display — https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
Teknik not: Hashing’in geri döndürülemezliği, clean room’da hangi tarafın neyi görebildiği ve çıktıların hangi seviyede raporlanacağı gibi kritik hususlar hukuk/KVKK ekibiyle birlikte yorumlanmalıdır. Bu içerik teknik risk azaltma modelidir. Refresh cycle: 180 gün.
6. Hashed Audience + Clean Room Kullanım & Risk Checklist Şablonunu İndir — Yazılım / AdTech Privacy
Hashed Audience + Clean Room Kullanım & Risk Checklist Şablonunu İndir — Yazılım / AdTech Privacy (v1.0)
Bu asset, CRM listelerini hashleyerek reklam platformlarına aktarma ve clean room kullanımı için risk azaltıcı teknik kontrol seti sağlar. Minimum veri, minimum erişim ve minimum çıktı prensipleriyle panel yetkileri, hashing pipeline’ı, audit log ve liste lifecycle (retention/silme) adımlarını standardize eder. Otel ve B2B kampanyalarında daha kontrollü paylaşım modeli kurmayı hedefler.
Kim Kullanır?
Pazarlama + CRM owner + IT/BT + KVKK/uyum.
Nasıl Kullanılır?
- Liste üretim kriterlerini ve alan setini belirle (minimum veri).
- Hashing pipeline + panel erişimi kontrollerini uygula (MFA/RBAC/log).
- Clean room çıktı sınırlarını ve liste retention/silme politikasını yaz; 180 gün refresh ekle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Liste amacı yazılı (remarketing/ABM/ölçüm)
- ▢ ✅ Liste alan seti minimum (gereksiz kolon yok)
- ▢ ✅ Veri normalize edilerek hashleniyor
- ▢ ✅ Ham veri erişimi çok kısıtlı (need-to-know)
- ▢ ✅ Hashing pipeline otomatik ve loglanan
- ▢ ✅ Platform panel erişimi RBAC ile sınırlı
- ▢ ✅ Platform panel MFA zorunlu
- ▢ ✅ Liste yükleme/yenileme işlemleri audit log’a giriyor
- ▢ ✅ Clean room’da çıktı seviyesi aggregate/segment
- ▢ ✅ Minimum segment eşiği uygulanıyor (mikro segment yok)
- ▢ ✅ Liste lifecycle tanımlı (retention + silme)
- ▢ ✅ Vendor/alt servis envanteri mevcut
- ▢ ✅ 180 gün refresh planı var
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
CRM→hash→platform ve clean room kullanımını denetlenebilir hale getirir; erişim/minimizasyon/log kontrolleriyle KVKK riskini azaltır.
Sık Sorulan Sorular
Clean room nedir, reklam teknolojilerinde nasıl çalışır?▾
Hashlenmiş kitleler KVKK açısından avantaj sağlar mı? (Teknik bakış)▾
Otel ve B2B için sadakat/müşteri listelerini reklam platformlarıyla nasıl entegre etmeliyim?▾
Hashing + clean room kullanımında hangi teknik sınırlar olmalı?▾
Hashlenmiş listeyi kimler görebilmeli?▾
En sık yapılan hata nedir?▾
İlgili İçerikler