2025’te Çapraz Platform İzleme: Tracking ID, Device Graph ve GDPR Uyum Riskleri
2025 itibarıyla pazarlama analitiği, reklam teknolojileri ve müşteri deneyimi sistemleri; kullanıcıyı web, mobil uygulama, e-posta, CRM ve reklam ağları arasında
tekil bir dijital profil altında birleştirmeye odaklanmış durumdadır.
Bu yaklaşım iş hedefleri açısından güçlü görünse de,
tracking ID’ler, device graph yapıları ve çapraz platform eşleştirme teknikleri
GDPR ve KVKK kapsamında yüksek riskli kişisel veri işleme faaliyetleri olarak değerlendirilmektedir.
2025 denetimlerinde temel soru artık şudur:
Bu yazıda; 2025’te kullanılan çapraz platform izleme tekniklerini, bu tekniklerin hangi noktada profiling ve otomatik karar alma
kapsamına girdiğini ve kurumların en sık düştüğü GDPR uyum hatalarını net bir çerçevede ele alıyoruz.
İçerik Haritası
- Çapraz platform izleme nedir ve neden risklidir?
- 2025’te kullanılan başlıca teknikler: Tracking ID, device graph, reklam kimlikleri, fingerprinting
- GDPR/KVKK uyum sorunları: şeffaflık, rıza, profiling ve otomatik karar alma
- Yıl sonu için pratik uyum playbook’u ve kontrol listesi
1) Çapraz Platform İzleme Nedir?
Çapraz platform izleme; bir kullanıcının farklı cihazlar ve kanallar üzerindeki etkileşimlerinin tek bir kimlik (identifier) altında birleştirilmesidir.
Bu birleştirme “ölçüm” için başlayabilir; ancak çoğu senaryoda segmentasyon, hedefleme ve skorlamaya evrilir.
2025’te en sık kullanılan izleme bileşenleri
- Tracking ID: User ID, Client ID, App Instance ID
- Mobil reklam kimlikleri: IDFA, GAID
- Device graph: cihazlar arası eşleştirme (probabilistic / deterministic)
- Fingerprinting: cihaz/tarayıcı parmak izi
- Server-side tagging: tarayıcı yerine sunucu üzerinden tetikleme ve aktarım
Bir identifier, davranışla birleştiği anda “kişisel veri” etkisi yaratır.
2) Teknik Teknik Uyum Sorunları: 2025’te En Çok Patlayan Noktalar
2.1 Tracking ID (User ID / Client ID) Riskleri
Tracking ID’ler “pseudonymous” görünse de, web + app + CRM eşleştirmesiyle kalıcı bir kullanıcı profili oluşturur.
En sık uyum hataları:
- Aydınlatmada “User ID / cross-device eşleştirme”nin açıkça yazılmaması
- Rıza alınmadan kalıcı ID atanması (özellikle analitik/ads amaçlı)
- Oturum kapansa dahi ID’nin uzun süre yaşaması (retention sorunu)
- “Anonim ID” gibi muğlak ifadelerle şeffaflığın sağlandığının düşünülmesi
2.2 Mobil Reklam Kimlikleri (IDFA/GAID) ve App-to-Web Birleştirme
Mobil reklam kimlikleri, reklam ekosisteminde kullanıcıyı farklı uygulamalar arasında izlemeye yarar.
Bu kimliklerin web çerezleriyle birleştirilmesi (app-to-web identity resolution) denetimlerde “profiling” şüphesini artırır.
- İzin akışının (OS-level permission + CMP) uyumsuz tasarlanması
- Rıza geri alındığında tüm platformlarda eş zamanlı durdurulamaması
- Üçüncü taraf SDK’ların arka planda veri aktarımı (kontrol/denetim eksikliği)
2.3 Device Graph (Cihazlar Arası Eşleştirme) = Görünmeyen Profiling
Device graph, aynı kişiye ait olduğu varsayılan cihazları eşleştirir. Eşleştirme şu sinyallerle yapılabilir:
IP, cihaz özellikleri, oturum davranışları, lokasyon örüntüleri, login eşleşmeleri.
2025’te en kritik risk: bu eşleştirmenin kullanıcıya anlatılmaması.
- Device graph kullanımının aydınlatmada belirtilmemesi
- Probabilistic eşleştirmede yanlış eşleşme riski (accuracy) ve itiraz mekanizmasının olmaması
- Üçüncü taraf “identity provider”ların controller/processor rol karışıklığı
Profiling varsa: şeffaflık düzeyi yükselir, hukuki dayanak tartışması daralır, risk değerlendirmesi (LIA/DPIA) ihtiyacı artar.
2.4 Fingerprinting ve Server-Side Tagging: Banner’ı Baypas Eden Risk
Fingerprinting (cihaz/tarayıcı parmak izi) ve server-side tagging, kullanıcı tarafındaki çerez kontrollerini “dolaylı” aşabilir.
Denetimlerde en ağır sonuçlar, “cookie banner var ama arka planda izleme devam ediyor” senaryolarında ortaya çıkar.
- Fingerprinting sinyallerinin “zorunlu” gibi gösterilmesi
- Server-side tetiklerin rıza durumuna bağlanmaması
- Tag governance eksikliği: hangi event hangi vendor’a gidiyor bilinmemesi
3) Profiling ve Otomatik Karar Alma Eşiği
Çapraz platform izleme “ölçüm” seviyesinde kalırsa risk yönetilebilir; ancak aşağıdaki çıktılar oluştuğunda işlem artık
profiling ve bazı durumlarda otomatik karar alma çerçevesine girer:
- Kişiselleştirilmiş içerik / teklif / kampanya uygunluğu
- Dinamik fiyatlama veya görünürlük bastırma
- Risk, değer, churn skoru üretimi
- Kredi/limit/başvuru ön değerlendirmesi gibi “önemli etki” doğuran kararlar
“Bu profil, kullanıcı üzerinde hukuki veya benzer derecede önemli bir etki yaratıyor mu?”
Evetse: şeffaflık, itiraz, insan müdahalesi ve değerlendirme mekanizmaları gerekir.
4) Hukuki Dayanak: 2025’te Neyi Neye Dayandırmak Riskli?
Uygulamada iki dayanak tartışılır: açık rıza ve meşru menfaat.
2025 sonu pratik yaklaşım:
- Davranışsal izleme + reklam hedefleme → çoğunlukla açık rıza
- Cross-device birleştirme / device graph → açık rıza + yüksek şeffaflık
- Sınırlı, düşük etkili ölçüm → bazı senaryolarda LIA ile meşru menfaat tartışılabilir
5) 2025 Yıl Sonu İçin Uyum Playbook’u (Pratik ve Denetlenebilir)
Adım 1: Identifier Haritası Çıkarın
- Hangi ID’ler var? (web/app/CRM/ads)
- ID’ler nerede üretiliyor, nerede saklanıyor, nerede eşleştiriliyor?
- Vendor bazında veri akış diyagramı hazır mı?
Adım 2: “Profiling Var mı?” Karar Ağacı
- Davranış birleştirme var mı?
- Segment/score üretiliyor mu?
- Karar otomatik mi? İnsan onayı var mı?
Adım 3: Aydınlatma Metni ve Politika Setini Güncelleyin
- Cross-platform izleme açıkça yazılsın (hangi tanımlayıcılar, hangi amaçlar)
- Profiling ve otomatik karar alma varsa ayrı başlık açın
- Üçüncü taraf alıcı kategorileri (SDK, ad network, identity provider) net olsun
Adım 4: Rıza Mimarisi (CMP + App + Server-Side) Tek Standartta Birleşsin
- Rıza yoksa: tetikler durmalı (web tag, server-side event, SDK)
- Rıza geri alınırsa: tüm kanallarda aynı anda uygulanmalı
- Rıza kayıtları: timestamp + kapsam + versiyon + kaynak kanalı ile loglanmalı
“Bu kullanıcıya şu tarihte, şu kapsamda rıza gösterildi; şu vendor’lar şu amaçla çalıştı; geri alma sonrası tetikler durdu.”
6) 2025 Uyum Kontrol Listesi
- Web/App/CRM/Ads tanımlayıcı haritası var mı?
- Device graph / identity resolution kullanımı açıkça dokümante mi?
- Server-side event’ler rıza durumuna bağlı mı?
- Fingerprinting kullanılıyorsa açık rıza + şeffaflık sağlandı mı?
- Rıza geri alma tüm platformlarda çalışıyor mu?
- Vendor’lar için rol analizi (controller/processor) ve sözleşme seti tamam mı?
Kısa SSS
“Anonim ID kullanıyoruz” demek yeterli mi?
Hayır. ID davranışla birleşip kullanıcıyı ayırt edilebilir kılıyorsa pratikte kişisel veri etkisi doğurur.
Device graph kullanıyorsak mutlaka rıza mı gerekir?
Çoğu senaryoda evet; çünkü cihazlar arası eşleştirme profiling riskini yükseltir ve şeffaflık standardını ağırlaştırır.
Server-side tagging bizi “daha uyumlu” yapar mı?
Tek başına hayır. Rıza durumuna bağlanmayan server-side event’ler, cookie banner’ı fiilen baypas eden bir risk alanına dönüşür.
