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.
Bu yapı, web ve yazılım hizmetlerinde hibrit veri yönetimi perspektifiyle ele alınmadığında; aynı kullanıcı için app, WebView ve backend tarafında birbirinden kopuk izin ve kayıt katmanları oluşabilir.
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.
Bu nedenle WebView veri akışı app, API, backend, CRM, PMS ve destek kanallarıyla birlikte tek veri haritası üzerinde gösterilmelidir.
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.
Özellikle API yanıtları, uygulama logları ve saklama katmanı konuşulurken mobil backend veri lokasyonu kararı; hangi verinin hangi bulut servisinde tutulduğunu görünür kılar.
Bu katmanda app izinleri ve loglar birlikte değerlendirilmelidir; çünkü izin durumu, tanımlayıcılar ve backend kayıtları aynı güvenlik ve raporlama mantığı içinde yönetilmezse denetlenebilirlik zayıflar.
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.
Destek, arama ve mesajlaşma modülleri uygulama içinde yer alıyorsa app içi chatbot veri akışı da bu hibrit modele dahil edilmelidir; çünkü sohbet verisi çoğu zaman ayrı vendor ve ayrı log katmanında akar.
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.
Bu zincirde otel mobil uygulamasında PMS veri akışı ayrıca kritik hale gelir; rezervasyon, oda, fiyat ve misafir verisinin WebView ve backend üzerinden PMS’e hangi kuralla aktarıldığı net olmalıdır.
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.
Kullanıcı destek veya geri arama talebi bırakıyorsa mobil uygulama destek talepleri çağrı merkezi ve operasyon tarafına hangi kayıtlarla aktarıldığı da aynı hibrit veri modelinde görünmelidir.
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ı
Bu yapıyı kurumunuza göre uygulamak isterseniz KVKK uyum hizmetiyle mobil ve WebView veri kontrolü planlayabilir, temel süreç soruları için de KVKK uyum hizmeti hakkında sık sorulan sorular sayfasını inceleyebilirsiniz.
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