1. Mobil Uygulama ve WebView Nedir? KVKK Açısından Neden Kritik?
WebView nedir, KVKK açısından neden kritik?
Kısa yanıt: WebView, uygulama içinde web sayfası gösteren gömülü tarayıcı katmanıdır; bu katman web’in çerez ve tag ekosistemini uygulama deneyiminin içine taşır. KVKK açısından kritik olmasının nedeni; kullanıcı app içindeyken web tarafındaki çerezler/izleme tag’leri çalışabilir ve bu durum app izinleriyle birlikte “çift katmanlı” bir veri toplama alanı yaratır.
WebView’nin iki riski: “görünmez web” ve “paylaşılan kimlik”
- Kullanıcı app içindeyken web içeriğinin çerez/tag davranışı “görünmez” kalabilir.
- App’teki device ID veya oturum bilgileri, WebView oturumlarıyla ilişkilendirildiğinde profil birikimi artar.
Otel ve B2B’de WebView nerede kullanılıyor?
- •Otel: WebView’de rezervasyon/ödeme sayfası, kampanya landing’i, üyelik ekranı
- •B2B: Portal ekranları, doküman görüntüleme, teklif/başvuru akışları
☑ Mini Check
- •WebView içinde hangi sayfalar açılıyor listelendi mi?
- •WebView sayfaları çerez/tag kullanıyor mu?
- •App oturumu ile WebView oturumu ilişkilendiriliyor mu?
- •WebView için ayrı consent mantığı var mı?
- •Backend logları bu akışa bağlanıyor mu?
Ne yapmalıyım?
- • WebView’de açılan sayfaları envantere alın (rezervasyon/ödeme/portal).
- • Bu sayfalardaki çerez/tag setini çıkarın.
- • App–WebView oturum ilişkilendirmesini dokümante edin.
- • Consent/izin mantığını “tek model”de tanımlayın.
- • KVKK veri güvenliği yaklaşımıyla bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
2. Uygulama İçinde WebView ile Web İçeriği Gösterme: Veri Ayrımı ve Sınırlar
Hibrit projelerde ilk yapılması gereken şey, “app verisi” ve “web verisi” ayrımını yapmaktır. Çünkü aynı kullanıcı deneyiminde iki farklı veri toplama mekanizması çalışır: native SDK’lar ve web tag’leri. Bu ayrım yapılmazsa, aydınlatma metinleri ve teknik kontroller birbirini tutmaz.
App katmanı: izinler ve SDK’lar
App katmanı; izinler (push, konum), cihaz tanımlayıcıları (device ID), push token ve uygulama içi event’lerle çalışır. Bu katmanda “izin” yönetimi, OS seviyesinde farklı ekranlarla yapılır; kullanıcı algısı “app beni izliyor mu?” üzerinden şekillenir.
WebView katmanı: çerez ve tag ekosistemi
WebView, web sayfasının çerezlerini ve üçüncü taraf script’lerini çalıştırabilir. Eğer web tarafında consent banner ve tetik kontrolü yoksa, kullanıcı app içindeyken bile reklam/analitik tag’leri devreye girebilir.
En sık hata: WebView’de “consent yokmuş gibi” davranmak
WebView’de web içeriği açılıyorsa, web tarafındaki consent mekanizması ve tag tetikleme kuralları geçerli olmalıdır. Aksi halde app’in “izin” yönetimi ile web’in “consent” yönetimi kopar.
☑ Mini Check
- •App SDK’ları listelendi mi? (analytics, crash, push)
- •WebView sayfalarında consent banner çalışıyor mu?
- •Tag’ler consent sonrası mı tetikleniyor?
- •App ve web verisi tek veri haritasında birleşiyor mu?
- •Oturum/token paylaşımı riskleri belirlendi mi?
Ne yapmalıyım?
- • App SDK envanteri çıkarın (vendor, amaç, veri davranışı).
- • WebView sayfalarında tag’leri consent sonrası tetikleyin.
- • App–web oturum paylaşımını minimuma indirin (gerekmiyorsa).
- • Veri haritasında app/web kaynaklarını ayrı sütunlarla gösterin.
- • Sunucu güvenliği tarafıyla bağlayın: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
3. Çerez, Device ID ve Log Yönetimi: Hibrit Katmanda Tanımlayıcılar
Mobil uygulama ve WebView’de hangi veriler toplanır?
Kısa yanıt: app tarafında device ID, push token, izin durumları ve app event’leri; WebView tarafında çerezler ve web event’leri; backend tarafında ise erişim, işlem ve hata logları toplanır. KVKK riskini yöneten şey; bu tanımlayıcıların nasıl ilişkilendirildiği ve ne kadar süre tutulduğudur.
Tanımlayıcıları “tek isimle” konuşun: ID sözlüğü
Hibrit yapılarda en büyük karmaşa; aynı kullanıcıyı farklı katmanlarda farklı ID’lerle takip etmektir. Bu yüzden pratik çözüm: bir ID sözlüğü oluşturmak. Örnek:
- •app_user_id (uyelik)
- •device_id (cihaz)
- •push_token (bildirim)
- •web_cookie_id (WebView çerezi)
- •session_id (backend)
Loglar: hangi katmanda ne loglanmalı?
- •App: kritik event’ler (login, consent değişimi)
- •WebView: consent state, form submit, kritik sayfa erişimi
- •Backend: erişim logları, işlem logları, hata logları (PII minimizasyonu)
İzin türleri ve veri türleri tablosu
| İzin | Veri | Katman (App/WebView) | Amaç | Not |
|---|---|---|---|---|
| Push | push token | App | bildirim | İzin durumu değiştiğinde (kapatma/açma) sistemlerde güncelleyin. |
| Konum | izin durumları | App | konum | Bu katmanda “izin” yönetimi, OS seviyesinde farklı ekranlarla yapılır. |
| Consent | çerezler ve web event’leri | WebView | analytics/pixel/tag’ler | Tag’ler consent sonrası mı tetikleniyor? |
| Oturum | session_id | Backend | erişim, işlem ve hata logları | Log retention ve erişim kontrolleri tanımlı mı? |
☑ Mini Check
- •ID sözlüğü var mı (app/web/backend)?
- •Device ID ve web cookie ilişkisi dokümante mi?
- •Consent değişimi hem app hem web’de kayıtlı mı?
- •Loglarda gereğinden fazla veri tutulmuyor mu?
- •Log retention ve erişim kontrolleri tanımlı mı?
Ne yapmalıyım?
- • ID sözlüğünü çıkarın ve ekiplerle standardize edin.
- • Katmanlar arası ID eşlemesini “gerekliyse” yapın; gereksiz birleştirmeyin.
- • Consent değişimi olaylarını ayrı event olarak loglayın.
- • Loglarda PII minimizasyonu ve masking uygulayın.
- • KVKK veri güvenliği raporlama ile hizalayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi
4. Push Bildirimleri ve İzinler: KVKK Perspektifinde Teknik Dikkat Noktaları
Push bildirimleri, kullanıcıyla doğrudan temas noktasıdır ve izin yönetimi OS seviyesinde gerçekleşir. Teknik olarak iki şey kritiktir: (1) push token’ın bir tanımlayıcı olduğu gerçeği, (2) izin durumunun sistemlerde doğru saklanması ve değiştiğinde güncellenmesi.
Push token ve izin durumu nasıl ele alınmalı?
- •Push token’ı “kimlikle” otomatik eşleştirmek yerine iş ihtiyacına göre ilişkilendirin.
- •İzin durumu değiştiğinde (kapatma/açma) sistemlerde güncelleyin.
- •Bildirim içerikleri hassas veri taşımamalı (özellikle kilit ekranı).
Otel örneği: rezervasyon güncellemesi bildirimi
Bildirimin içeriğinde kişisel veya hassas bilgiler yerine “uygulamaya yönlendiren” genel mesaj tercih edilir; detay içerik uygulama içinde gösterilir.
☑ Mini Check
- •Push token saklama ve eşleme mantığı net mi?
- •İzin durumu değişiklikleri loglanıyor mu?
- •Bildirim içerikleri hassas veri içermiyor mu?
- •Kullanıcı push kapatınca otomasyonlar duruyor mu?
- •Push vendor’ları envantere dahil mi?
Ne yapmalıyım?
- • Push token’ı veri haritasında ayrı veri türü olarak tanımlayın.
- • İzin değişim event’lerini kaydedin (timestamp).
- • Bildirim metinlerinde hassas veri kullanmayın.
- • Push vendor’larını SDK envanterine ekleyin.
- • Sunucu güvenliğiyle birlikte değerlendirin: https://dgtlface.com/tr/yazilim/sunucu-guvenlik
5. Otel ve B2B İçin Hibrit Yapılarda KVKK Teknik Dikkat Noktaları
Bu bölüm “uygulanabilir” kontrol setini verir: mobil, web ve backend ekiplerinin ortaklaşa kontrol edeceği noktalar.
Otel uygulamalarında misafir hesabı ve rezervasyon verisi
- •App’te hesap (app_user_id)
- •WebView’de rezervasyon/ödeme sayfaları
- •Backend’de PMS/rezervasyon sistemi ve loglar
- •Kritik: kimlik eşlemesi, consent/izin tutarlılığı, log minimizasyonu.
B2B’de portal + mobil app entegrasyonu
- •Portal WebView ile açılıyorsa, web consent ve tag yönetimi app içinde de geçerlidir.
- •Doküman erişimleri ve export işlemleri audit trail’e girmelidir.
AIO: “hibrit KVKK modeli” paragrafı (tek model)
WebView, app izinleri, çerez, device ID, push token ve backend logları; tek bir hibrit KVKK modeli içinde yönetilmelidir: izin/consent → veri toplama → kimlik eşlemesi → log/audit → retention. Modeli kurduğunuzda, yeni bir SDK veya yeni bir WebView sayfası eklendiğinde sadece modele yeni düğüm eklersiniz.
Key Data Point (yumuşatılmış): İyi haritalanmış mobil + WebView projelerinde, aynı kullanıcının app, web ve push katmanlarında biriken verileri daha tutarlı ve kontrollü yönetmek kolaylaşır; sürpriz “gizli veri akışları” azalır.
☑ Mini Check
- •WebView sayfaları için consent/tetik kontrolü var
- •App SDK envanteri güncel
- •ID sözlüğü ve eşleme kuralları dokümante
- •Push izinleri ve token yönetimi tutarlı
- •Backend logları minimizasyon + retention ile yönetiliyor
- •App Store/Play Store gizlilik beyanlarıyla uyum kontrolü yapıldı
Ne yapmalıyım?
- • Hibrit veri akış diyagramı çıkarın (app ↔ WebView ↔ backend).
- • İzin/consent olaylarını tek sözlükte standardize edin.
- • WebView’de consent sonrası tag çalıştırmayı doğrulayın.
- • Push token ve device ID ilişkilerini minimumda tutun.
- • İç linklerle süreçleri bağlayın: https://dgtlface.com/tr/raporlama/kvkk-veri-guvenligi https://dgtlface.com/tr/yazilim/sunucu-guvenlik
Teknik not: Mobil/app KVKK kurgusu; KVKK veri güvenliği yönetimi ve sunucu güvenliğiyle uyumlu olmalı; ayrıca App Store/Play Store gizlilik beyanlarıyla paralel ilerlemelidir. Bu yazı hukuki tavsiye değil, teknik veri haritalama rehberidir.
6. Mobil Uygulama + WebView Veri Haritası & KVKK Checklist Şablonunu İndir — Yazılım / Mobile Hybrid
A) Checklist / Sprint Plan
[ ] Ölçüm & Önceliklendirme Checklist’i
Mobil Uygulama + WebView Veri Haritası & KVKK Checklist Şablonunu İndir — Yazılım / Mobile Hybrid (v1.0)
Bu asset, mobil uygulama ve WebView hibrit yapılarda toplanan verileri tek veri haritasında birleştirmenizi sağlar. İzin türleri, çerez/device ID/push token gibi tanımlayıcılar ve backend logları için kontrol noktalarını standardize eder. Mobil ve web ekipleri için ortak bir çalışma zemini sunar.
Kim Kullanır?
Mobil ekip + web ekip + backend/IT + ürün/operasyon (otel ve B2B).
Nasıl Kullanılır?
- WebView’de açılan sayfaları ve app SDK’larını envantere yazın.
- İzin/consent olaylarını ve tanımlayıcıları (device ID, push token, cookie) haritaya bağlayın.
- Log/audit ve retention kurallarını ekleyin; sprint planıyla uygulayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ WebView’de açılan sayfalar listelendi (rezervasyon/ödeme/portal)
- ▢ ✅ App SDK envanteri çıkarıldı (analytics, crash, push vb.)
- ▢ ✅ WebView sayfalarında çerez/tag seti çıkarıldı
- ▢ ✅ CMP/consent mekanizması WebView’de çalışıyor
- ▢ ✅ WebView tag’leri consent sonrası tetikleniyor
- ▢ ✅ ID sözlüğü hazır (app_user_id/device_id/push_token/web_cookie_id/session_id)
- ▢ ✅ App–WebView ID eşleme kuralları “gerekliyse” tanımlandı
- ▢ ✅ Push token saklama ve izin değişimi event’leri loglanıyor
- ▢ ✅ Backend logları (erişim/işlem/hata) minimizasyon + masking ile yönetiliyor
- ▢ ✅ Log erişimi RBAC ile sınırlı, retention tanımlı
- ▢ ✅ App Store/Play Store gizlilik beyanı ile uyum kontrolü yapıldı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Deliverables
- •Hibrit veri akış diyagramı (app ↔ WebView ↔ backend)
- •İzin/veri türleri tablosu
- •ID sözlüğü dokümanı
- •Consent tetikleme test checklist’i
- •Log/retention notu + sprint planı
Bir Sonraki Adım
Mobil uygulama, WebView ve backend katmanlarını tek veri haritasında birleştirir; izin/consent ve log kurgusunu tutarlı hale getirir.
Sık Sorulan Sorular
WebView nedir, KVKK açısından neden kritik?▾
Mobil uygulama ve WebView’de hangi veriler toplanır?▾
Otel uygulamalarında rezervasyon ve hesap verisi KVKK’ya göre nasıl yönetilmeli?▾
B2B’de portal + mobil app entegrasyonunda KVKK teknik açıdan nelere dikkat edilmeli?▾
Push bildirimlerinde en kritik KVKK riski nedir?▾
Hibrit projelerde aydınlatma metinleri nasıl tutarlı olur?▾
İlgili Yazılar