1. Dashboard’larda neden veri maskeleme yapmalısınız?
Dashboard’larda maskeleme, “kötü niyetli erişim” kadar “gündelik operasyon kazası”na karşı koruma sağlar. Otellerde raporlara çok sayıda kişi bakar; aynı rapor linki farklı departmanlarda açılır; sezon yoğunluğunda ekranlar açık kalabilir. Bu ortamda kişi bazlı veriyi maskelemek, olası sızıntı etkisini düşürür ve denetimde “least privilege” yaklaşımının raporlama katmanında da uygulandığını gösterir.
AIO mantığı:
Masked Dashboard → reduces → privacy risk
Maskeleme; riski sıfırlamaz ama “etkiyi” düşürür: ad-soyad yerine A*** K****, telefon yerine +90 *** ** ** gibi.
Otelde maskelemenin 3 pratik faydası
- •Açık ekran riski azalır: resepsiyon/office ekranlarında
- •Screenshot paylaşımı daha güvenli olur: WhatsApp/Slack paylaşım pratiklerinde
- •Rapor okunabilirliği artar: “kim” yerine “segment/KPI” odak
Mini örnek (Antalya – çok personelli yapı)
Looker Studio dashboard’u birçok departmanda açık. Eğer listelerde e-posta/telefon görünüyorsa, bir ekran görüntüsü bile “kişisel veri ifşası” riskini büyütür. Maskeleme ile aynı ekran, yönetim için değer üretirken ekipler için de güvenli kalır.
☑ Mini Check (neden maskeleme)
- •Dashboard linkini gören kişi sayısı yüksek mi?
- •Rapor ekranı fiziksel olarak görünür alanlarda açılıyor mu?
- •Ekran görüntüsü paylaşımı yaygın mı?
Ne yapmalıyım?
- • Varsayılan görünümü anonim KPI’lara çevirin.
- • Kişi listelerini yalnız “need-to-know” rollere açın.
- • Maskeleme desenlerini standardize edin (aşağıda).
2. Hangi alanlar nasıl maskeleme ile gösterilmeli?
Maskeleme “her şeyi yıldızlamak” değildir; doğru desen, hem karar aldırır hem kimliği gizler. Otel raporlarında en sık kişisel alanlar: ad/soyad, e-posta, telefon, rezervasyon kodu/ID, notlar.
Maskeleme desenleri tablosu (örnek)
| Alan | Maskeleme Deseni | Örnek | Not |
|---|---|---|---|
| Ad Soyad | İlk harf + yıldız | A* K**** | Tam adı gösterme |
| E-posta | Kullanıcı adı maskeli | a*@d***.com** | Domain de kısmen maskeli |
| Telefon | Ülke kodu + mask | **+90 *** ** ** ** | Son 2 haneyi açık tutma opsiyonel |
| Rezervasyon ID | Kısmi gösterim | #1289* | Tam ID yerine kısa |
| Serbest not | Kısıt/temizle | (mümkünse yok) | Not alanı en riskli |
Varsayım: Maskeleme desenleri araç ve veri modeline göre değişebilir; amaç desen standardını ekipte sabitlemektir.
“Maskeleme mi, hiç göstermemek mi?”
- •Maskele: yönetim kararı için “kim” sinyali gerekiyorsa (nadir)
- •Hiç gösterme: çoğu ekip için kişi listesi gerekmiyorsa
Pratikte otellerde kişi listeleri çoğu rolde gereksizdir; segment KPI’ları yeterlidir.
☑ Mini Check (alanlar)
- •E-posta/telefon gibi alanlar varsayılan görünümde kapalı mı?
- •Serbest metin not alanları raporda yer alıyor mu? (risk)
- •Rezervasyon ID tam mı, kısmi mi?
Ne yapmalıyım?
- • PII alanlarını default olarak maskele veya kaldır.
- • “Detay sayfası”nı ayrı yetkili rol ile sınırla.
- • Serbest not alanlarını raporlamadan çıkar (gerekirse temizle).
3. Kişi bazlı görünümler yerine anonim KPI’lar
KVKK uyumlu raporlama için “karar almak için gerekli minimum bilgi” hedeflenir. Otel yönetimi çoğu zaman şu sorulara cevap ister: kanal bazında dönüşüm, ülke bazında talep, segment performansı, şikayet trendi. Bunlar kişi bazlı liste gerektirmez.
Otel raporlarında kullanılabilecek anonim KPI örnekleri
- •Segment büyüklüğü (izinli evren)
- •Kanal bazında dönüşüm oranı (OTA/Direct/Call Center)
- •Ülke/dil bazında talep
- •Rezervasyon pace (haftalık trend)
- •İptal oranı ve neden dağılımı (kategori)
- •NPS/yorum puanı trendi (kişi değil dönem/segment)
“Kişi listesi” gerektiğinde nasıl sınırlarız?
- •Sadece yönetim veya çok sınırlı operasyon rolü
- •Liste ekranı, ayrı bir “detail view” olarak tasarlanır
- •Export kapalı/izne bağlı; erişim loglanır (RBAC blogu ile uyumlu)
Mini örnek
Satış ekibi “yeniden arama listesi” istiyor olabilir. Bu durumda kişi listesi yalnız ilgili rolde, maskeleme kısmen azaltılarak ve export izinleri kontrol edilerek sunulur.
☑ Mini Check (KPI geçişi)
- •Dashboard’un ana sayfası KPI/segment odaklı mı?
- •Kişi listesi ayrı bir sekmede ve kısıtlı mı?
- •Export ve paylaşım izinleri kontrol altında mı?
Ne yapmalıyım?
- • Dashboard homepage’i “anonim KPI” yapın.
- • Detay görünümü role göre açın (aşağıdaki hiyerarşi).
- • Paylaşım kurallarını yazılı hale getirin (screenshot pratiği dahil).
4. Hangi rol hangi seviyede kişisel veri görmeli?
Bu kısım, RBAC yaklaşımını raporlama katmanına taşır: rol bazlı dashboard görünümleri.
Rol bazlı görünüm hiyerarşisi (örnek)
- •Seviye 0 (Genel): yalnız KPI/segment/kanal özetleri
- •Seviye 1 (Departman): daha detay KPI, fakat PII yok
- •Seviye 2 (Yönetim): maskeleme açık (kısmi PII), sınırlı liste
- •Seviye 3 (Özel Yetki): gerekirse tam PII (çok sınırlı, loglu)
Varsayım: “Tam PII” görünümü çoğu otelde gereksizdir; iş ihtiyacı varsa süreçle tanımlanmalıdır.
Screenshot ve paylaşım pratikleri (otelde gerçek hayat)
- •Dashboard paylaşımı “link” ile değil “PDF/ekran” ile oluyorsa risk artar
- •Çözüm: paylaşıma uygun “masked view” oluştur
- •Raporların üzerine “KVKK: Maskeleme Aktif” notu ekle (tasarım)
☑ Mini Check (rol)
- •Tüm roller aynı ekranı mı görüyor? (risk)
- •Yönetim için ayrı “detail view” var mı?
- •Paylaşım için “safe view” oluşturuldu mu?
Ne yapmalıyım?
- • Rol bazlı görünüm seviyelerini yazılı hale getirin.
- • “Safe share view” oluşturup varsayılan yapın.
- • Kişi listesi export’unu role/izne bağlayın ve loglayın.
5. 3 örnek KVKK uyumlu dashboard tasarımı
- GM Dashboard (Seviye 2): Gelir/kanal/ülke KPI’ları + sınırlı maskeli liste
- Pazarlama Dashboard (Seviye 1): Segment KPI’ları + opt-in evren notu + kişi listesi yok
- Operasyon Dashboard (Seviye 1): İptal/şikayet trendi + SLA metrikleri + kişi listesi yok
Key Statistics / Data Point (yumuşatılmış)
Veri maskeleme uygulayan otellerde, ekran görüntüsü veya yetkisiz erişim durumunda “sızıntı etkisinin” önemli ölçüde azalması teorik olarak beklenir; çünkü görünen veri kişi bazlı değil özet KPI’dır.
İç link notu: /tr/raporlama, /tr/raporlama/kvkk-veri-guvenligi, /tr/raporlama/benchmark-analizi ve /tr/raporlama/satis-donusum sayfalarına bağlayın.
6. Veri Maskeleme Desenleri & Anonim KPI Rehberini İndir — Veri Analizi & Raporlama (v1.0)
Veri Maskeleme Desenleri & Anonim KPI Rehberini İndir — Veri Analizi & Raporlama (v1.0)
Bu mini rehber, otel dashboard’larında kişisel veriyi maskeleyerek KVKK riskini azaltmak ve raporlamayı anonim KPI setlerine taşımak için pratik bir standart sunar. Amaç; ad/e-posta/telefon gibi alanlarda maskeleme desenlerini ekipte sabitlemek, rol bazlı görünüm seviyelerini tanımlamak ve paylaşıma uygun “safe view” kurgusunu devreye almaktır.
Kim Kullanır?
BI/raporlama ekibi, IT, departman yöneticileri, ajans.
Nasıl Kullanılır?
- PII alanlarını tespit edin ve maskeleme desenlerini uygulayın.
- Dashboard’u rol bazlı seviyelere bölün (KPI view / masked detail / restricted detail).
- Segment KPI setini standartlaştırıp kişi bazlı export’ları kısıtlayın.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ MINI GUIDE (5 bölüm)
- ▢ ✅ 1) Prensipler (1 sayfa)
- ▢ ✅ 2) Maskeleme Desenleri (tablo)
- ▢ ✅ 3) Anonim KPI Seti (örnek)
- ▢ ✅ 4) 3 Sık Hata + Çözüm
- ▢ ✅ 5) Next Step
- ▢ ✅ Rol bazlı görünüm seviyelerini yazılı hale getir
- ▢ ✅ Benchmark ve satış dönüşüm raporlarını “anonim KPI” formatına standardize et
- ▢ ✅ KVKK raporlama sayfasına kanıt seti olarak ekle
- ▢ ✅ 10 Maddelik Hızlı Kazanım Checklist’i
- ▢ ✅ KPI homepage oluşturuldu
- ▢ ✅ PII alanları maskelendi
- ▢ ✅ Telefon/e-posta desenleri standardize edildi
- ▢ ✅ Kişi listesi ayrı sekmeye alındı
- ▢ ✅ Export izinleri kısıtlandı
- ▢ ✅ “Safe view” paylaşıma hazır
- ▢ ✅ Segment KPI seti sabitlendi
- ▢ ✅ Opt-out trendi eklendi
- ▢ ✅ Screenshot uyarı notu eklendi
- ▢ ✅ 30 gün sonra review planlandı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Rol bazlı görünüm, maskeleme desenleri ve anonim KPI setini otelinize özel kuralım.