1. Test ortamlarında neden sentetik veri kullanmalısınız?
Sentetik veri kullanmanın temel gerekçesi “daha güvenli” olmaktan öte, risk etkisini sıfırlamaya yaklaşmaktır: test ortamı ihlali olsa bile gerçek misafir verisi etkilenmez.
AIO mantığı: TestEnv → should contain → no real personal data
Bu nedenle amaç, testte “maskeleme” ile yetinmek değil; mümkünse gerçek PII’yi tamamen kaldırmaktır.
Gerçek misafir verisi testte neden risklidir?
- •Sandbox erişim kontrolü genelde zayıftır (çok kişi/çok ekip)
- •Log ve izlenebilirlik prod kadar güçlü değildir
- •Export/indir işlemleri daha kolaydır
- •Hata ayıklama için veriler paylaşılır (email/slack/whatsapp riski)
Mini örnek (Antalya grup otel)
Web sitesi geliştirmesinde ajans ekibi test ortamına tam DB erişimi alır. Eğer DB’de gerçek misafir e-posta/telefon varsa, “yetkisiz sızıntı” etkisi büyür. Sentetik veriyle bu risk “veri etkisi” olarak sıfıra yaklaşır.
Mini Check
- • Test ortamında gerçek e-posta/telefon/kimlik var mı?
- • Test DB export edilebiliyor mu?
- • Test erişimleri kimlerde (ajans/vendor)?
Ne yapmalıyım?
- • “Testte gerçek PII = 0” hedefini politika haline getirin.
- • Sentetik dataset üretim pipeline’ı kurun.
- • Testte logların hangisinin açık/kapalı olacağını belirleyin (aşağıda).
2. Otel sistemleri için sentetik/anonim veri seti nasıl hazırlanır?
Bu bölüm “uygulanabilir yol haritası”dır: veri sözlüğü, üretim teknikleri, kalite kontrol ve kanıt.
1) Veri sözlüğü (data dictionary) çıkarın
PMS/CRM/web rezervasyon akışında alanları sınıflandırın:
- •PII: ad, e-posta, telefon, kimlik/pasaport
- •Operasyonel: oda tipi, tarih, kanal, fiyat bandı
- •Teknik: id, session, device (PII olmayan)
Hedef: test dataset’inde PII alanları sentetik olmalı; operasyonel alanlar gerçekçi dağılımda olabilir.
2) Üretim teknikleri (yüksek seviye)
- •Tam sentetik: tamamen kurgusal müşteri ve rezervasyon kayıtları
- •Anonimleştirilmiş: prod dağılımını koruyup kimliği kaldırmak (mask/hash)
- •Hibrit: PII sentetik, operasyon metrikleri gerçekçi (en pratik)
Varsayım: Hibrit yaklaşım, otel projelerinde çoğu kez en hızlı uygulanabilir.
3) PMS/CRM/Web senaryoları için gerçekçilik kuralları
- •Ülke/dil dağılımı (TR/EN gibi)
- •Sezon yoğunluğu (yüksek/orta/düşük dönem)
- •Aile/çocuk segmenti (çocuk yaş grubu sentetik)
- •Kanal dağılımı (Direct/OTA/Call Center)
4) Doğrulama (PII leak test)
Sentetik veri üretildiğinde “kanıt” gerekir:
- •E-posta formatları gerçek domain değil, test domain (ör. example.test)
- •Telefonlar gerçek numara formatına benzese de çalışmayan blok (Varsayım)
- •Kimlik/pasaport alanları boş veya sentetik pattern
- •PII taraması: dataset’te gerçek domain/numara var mı?
| Alan | Gerçek Veri Riski | Sentetik / Anonim Test Yaklaşımı |
|---|---|---|
| Ad / Soyad | Gerçek misafir kimliği | Kurgusal isim |
| E-posta | Gerçek misafir e-posta adresi | Test domain — ör. example.test |
| Telefon | Gerçek ve ulaşılabilir telefon numarası | Çalışmayan sentetik numara bloğu (Varsayım) |
| Kimlik / Pasaport | Doğrudan tanımlayıcı veri | Boş veya sentetik pattern |
| Oda tipi / Tarih / Kanal | Operasyonel senaryo bilgisi | Gerçekçi dağılımda sentetik/hibrit değer |
| Çocuk segmenti | Gerçek çocuk verisi riski | Sentetik yaş grubu / segment |
Mini Check
- • Data dictionary var mı (PII işaretli)?
- • PII leak test yapılıyor mu?
- • Hibrit dataset prod senaryolarını temsil ediyor mu?
Ne yapmalıyım?
- • Önce 20–30 alanlık “çekirdek dataset” üretin.
- • PII leak test’i otomatikleştirin (Varsayım: script).
- • Dataset sürümleyin: v1.0, v1.1 (değişiklik izlenebilirliği).
3. PMS, CRM ve web projelerinde sentetik veri kullanım senaryoları
Bu bölüm, otel projelerinde “nerede kullanırım?” sorusunu cevaplar.
Senaryo 1 — PMS entegrasyon testi
- •Oda atama, check-in/out, rezervasyon güncelleme
- •Sentetik misafir + gerçekçi tarihler/oda tipleri
- •Log: API çağrıları, hata kodları (PII yok)
Senaryo 2 — CRM segmentasyon ve kampanya testi
- •Segment kuralları: ülke/dil/kanal/recency
- •Çocuk/ailesiz segment senaryosu
- •Çıktı: aggregate KPI (kişisel liste değil)
Senaryo 3 — Web rezervasyon ve ödeme akışı testi
- •Form alanları: sentetik e-posta/telefon
- •Dönüşüm funnel testleri
- •Ekran görüntüsü paylaşımı riski düşer (PII yok)
Key Statistics / Data Point (yumuşatılmış): Gerçek veriyi test ortamından çıkaran otellerde, olası test/sandbox erişim ihlallerinin misafir verisine zarar vermemesi teorik olarak beklenir; bu da KVKK risk profilini belirgin şekilde iyileştirir.
4. KVKK açısından test/sandbox raporlaması nasıl yapılır?
Test ortamı da “yönetilmesi gereken bir varlık”tır. KVKK raporlama açısından hedef; “testte gerçek PII yok” kanıtını düzenli üretmek.
Test ortamı kanıt seti (audit pack)
- Test data policy: “No real PII” kuralı
- Data dictionary + sınıflandırma (PII alanları işaretli)
- Sentetik dataset versiyonları ve üretim tarihi
- PII leak test raporu (scan sonucu)
- Test data temizleme job logları (silme/refresh)
- Test erişim rolleri (kim erişiyor?) (Varsayım: RBAC)
Testte hangi loglar açık/kapalı olmalı? (yüksek seviye)
- •Açık: teknik hata logları, performans metrikleri
- •Kapalı/sınırlı: ham request payload logları (Varsayım: PII sızdırabilir)
- •Maskeleme: debug çıktılarında PII mask (Varsayım)
Mini Check
- • “No real PII” kanıt raporu var mı?
- • Dataset versiyonu ve üretim tarihi izleniyor mu?
- • Test erişimleri sınırlı mı?
Ne yapmalıyım?
- • Aylık PII leak test raporu üretin.
- • Test dataset refresh’ini job log ile kanıtlayın.
- • Test erişimlerini vendor/ajans bazında raporlayın.
5. 3 örnek sentetik veri senaryosu
- Senaryo: Ajans test DB export aldı → Çözüm: DB sentetik → misafir verisi etkilenmez + erişim logu
- Senaryo: Debug log’da e-posta göründü → Çözüm: payload log kapalı + maskeleme + leak test alarmı
- Senaryo: CRM kampanya testi gerçek domain’e mail attı → Çözüm: test domain zorunlu + outbound blok (Varsayım) + sentetik e-posta
İç link notu: /tr/raporlama/kvkk-veri_guvenligi, /tr/yazilim/kvkk-uyum-hizmeti, /tr/yazilim/web-sitesi-gelistirme ve /tr/pms-ota-yonetimi sayfalarına bağlayın.
6. Sentetik/Anonim Test Dataset’i Tasarım Checklist’ini İndir
Sentetik/Anonim Test Dataset’i Tasarım Checklist’ini İndir — Trend (v1.0)
Bu checklist, otel projelerinde test/sandbox ortamlarında gerçek misafir verisini tamamen devre dışı bırakmak için sentetik veya anonim dataset tasarımını standardize eder. Amaç; PII leak’i sıfırlamak, gerçekçi senaryoları korumak, test verisi üretim/temizleme job’larını kanıtlanabilir loglarla raporlamak ve KVKK denetim paketine “no real PII” kanıtını eklemektir.
Kim Kullanır?
IT + yazılım ekibi, ajans, veri/BI ekibi, GM (policy onayı).
Nasıl Kullanılır?
- Data dictionary çıkarın ve PII alanlarını işaretleyin.
- Hibrit sentetik dataset üretin (PII sentetik, operasyon gerçekçi).
- PII leak test + refresh job log’u ile kanıt üretin ve audit pack’e ekleyin.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ PMS alanları sınıflandı (PII/operasyon/teknik)
- ▢ ✅ CRM alanları sınıflandı
- ▢ ✅ Web rezervasyon alanları sınıflandı
- ▢ ✅ “Riskli alanlar” listesi çıkarıldı (email/phone/id/passport)
- ▢ ✅ Email domain “test” (example.test)
- ▢ ✅ Telefonlar gerçek numara değil (Varsayım)
- ▢ ✅ İsimler kurgusal
- ▢ ✅ Rezervasyon tarihleri sezon dağılımını temsil ediyor
- ▢ ✅ Çocuk/ailesiz segment senaryoları var
- ▢ ✅ Gerçek domain/numara taraması
- ▢ ✅ Serbest not alanı taraması
- ▢ ✅ Export örnekleri kontrol edildi
- ▢ ✅ Sonuç raporu üretildi (pass/fail)
- ▢ ✅ Job takvimi (haftalık/aylık)
- ▢ ✅ Job log alanları (job_id, time, records, result)
- ▢ ✅ Başarısız job alarmı (Varsayım)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Test/sandbox riskini düşürüp sentetik veri pipeline’ını otelinize özel tasarlayalım.
Sık Sorulan Sorular
Sentetik veri nedir, otel projelerinde neden önem kazandı?▾
Test ve sandbox ortamlarında gerçek veri yerine sentetik veri nasıl üretilir?▾
PMS ve CRM testlerinde hangi alanlar mutlaka maskeleme/anonimleştirme gerektirir?▾
Sentetik veri kullanımını KVKK raporlarında nasıl gösteririm?▾
Neden sadece maskeleme yetmez?▾
İlgili İçerikler