1. Data kalitesi neden kritik?
Kısa cevap : Data kalitesi; raporların güvenilir olması, kanal/kampanya karşılaştırmalarının doğru yapılması ve optimizasyon algoritmalarının doğru sinyalle çalışması için kritiktir. Bot/iç/test trafiği dönüşümleri şişirirse, CPA/ROAS gibi karar metrikleri yanıltıcı olur ve bütçe boşa harcanabilir.
Otel bağlamında veri kalitesi, sadece “analytics” konusu değildir; doğrudan satış ve gelir etkisi vardır. Çünkü kampanya bütçesi ve teklif stratejileri dönüşüm sinyaline göre şekillenir. Veri kirliyse:
- •“En iyi kampanya” sandığınız kampanya aslında iç/test trafiğiyle şişmiş olabilir.
- •Conversion rate yükselmiş gibi görünür ama gerçek misafir davranışı değişmemiştir.
- •Yönetim raporunda “başarı” görünen şey, gerçekte veri hatası olabilir.
Kirlilik belirtileri (otel projelerinde sık görülen)
- •Dönüşüm sayısı bir günde anormal sıçrar (kampanya değişmeden).
- •“Direct/Other” aşırı büyür (özellikle bot ve test akışlarında).
- •Form/rezervasyon conversion rate % gerçek dışı dalgalanır.
- •Aynı IP bloklarından yoğun trafik ve dönüşüm gelir.
- •Staging domain raporlarda görünür.
Mini Check
- • Dönüşüm artışı gerçekten satış raporunda da var mı?
- • Anomali aynı gün bir deploy/test ile çakışıyor mu?
- • Staging domain veya test URL’leri rapora karışıyor mu?
- • Bot saldırısı dönemleri (peak) biliniyor mu?
Ne yapmalıyım?
- • Önce “anomali kanıtı” çıkar (GA4 vs PMS/rezervasyon raporu).
- • İç/test trafiğini etiketlemeden agresif filtreye geçme.
- • Staging–prod ayrımı yoksa ilk iş bunu kur.
- • Hijyen kontrolünü aylık ritme bağla.
2. Bot ve spam trafiğin etkisi (ne bozar, nasıl fark edilir?)
Bot trafik yalnızca sayfa görüntüleme şişirmez; form submit veya sahte dönüşüm davranışlarıyla conversion verisini de bozabilir. Otellerde bot/spam genellikle şu etkileri yaratır:
- •Kampanya “dönüşüyor” gibi görünür (özellikle düşük kaliteli network’lerde).
- •GA4’te event’ler yoğunlaşır ama kullanıcı davranışı mantıksızdır (çok kısa oturum, anormal etkileşim).
- •Landing page bazlı raporlar hatalı karar verdirir.
Bot trafik örnekleri (pratik)
- •Tek bir sayfaya saniyeler içinde yüzlerce giriş
- •Aynı user-agent ve benzer ekran çözünürlükleri
- •Normal kullanıcı yolculuğuyla uyuşmayan event dizileri
- •Aynı gün “0 bütçe değişimi” varken dönüşüm artışı
Bot trafiğe karşı güvenli yaklaşım
Bot filtreleme her zaman “keskin bıçak”tır. Çünkü fazla agresif filtre, gerçek kullanıcıyı da kesebilir. Otel için güvenli sırayı önerelim:
- Önce bot şüphesini raporda işaretle (not düş)
- Kaynağı analiz et (hangi channel/source)
- Kademeli azalt: en bariz pattern’leri filtrele/engelle
- Sonra etkiyi ölç (conversion ve davranış metrikleri normalleşti mi?)
Mini Check
- • Bot şüphesini doğuran kaynak/kanal net mi?
- • Anomali günleri işaretlendi mi (deploy/test ile çakışma)?
- • Filtreleme yerine önce “etiketleme/segment” yapılabilir mi?
- • Filtre sonrası gerçek kullanıcı trafiği kesiliyor mu?
Ne yapmalıyım?
- • Bot kaynaklarını listele: source/medium + landing.
- • En bariz pattern’leri kademeli filtrele (tek seferde sert kesme).
- • Filtre sonrası 7 gün “doğrulama” izlemesi yap.
- • Bot dalgaları değiştikçe stratejiyi güncelle.
3. İç trafik (otel personeli, ajans, geliştirici) nasıl yönetilir?
İç trafik; otel çalışanlarının, ajans ekibinin, geliştiricilerin ve call center ekibinin siteyi test etmesinden oluşur. Özellikle “rezervasyon butonuna tıklama”, “form gönderme”, “telefon/WhatsApp tıklama” gibi event’ler iç trafikte yoğun olduğu için conversion verisini şişirir.
En güvenli strateji: önce etiketleme, sonra filtre
Sheet’teki teknik notla uyumlu bir prensip: fazla agresif filtreler gerçek kullanıcıyı yanlışlıkla kesebilir. Bu yüzden iç trafikte en güvenli yöntem:
- •Önce iç trafiği etiketle (internal=true)
- •Raporlarda “internal hariç” görünüm/filtre ile analiz et
- •Emin olduktan sonra kademeli filtre uygula
İç trafiği işaretleme (labeling) pratikleri
- •GTM üzerinden “internal_flag” parametresi göndermek (örn. debug paramı varsa)
- •Özel boyut/dimension ile iç trafiği raporda ayırmak
- •İç ekip için ayrı test URL/parametre kullanmak (?internal=1 gibi)
Varsayım: İç ekiplerin IP listesi dinamik olabilir (VPN, mobil). Bu yüzden sadece IP’ye güvenmek yerine “etiket + IP” hibrit yaklaşım daha güvenlidir.
IP filtreleme (dikkatli kullan)
IP filtreleme kolaydır ama riskleri vardır:
- •Otel personeli mobil ağdan da siteye girer (IP değişken).
- •Ajans VPN kullanır (IP blokları geniş).
- •Gerçek misafir ile aynı IP bloğunda çakışma ihtimali vardır (özellikle kurumsal ağlar).
Bu nedenle IP filtreyi “son adım” gibi düşünmek daha güvenlidir.
Mini Check
- • İç trafik kaynakları listelendi mi? (otel, ajans, dev, call center)
- • Etiketleme kurgusu var mı (internal=true)?
- • IP listeleri güncel ve yönetilebilir mi?
- • Raporlarda “internal hariç” analiz yapılıyor mu?
Ne yapmalıyım?
- • İç trafiği önce etiketle, raporda ayrı göster.
- • IP filtreyi kademeli ekle ve yanlış kesmeyi izle.
- • İç ekip için test parametresi standardı oluştur.
- • Ajans ve dev ekibine “iç trafik protokolü” yaz (1 sayfa SOP).
4. Test ortamı ve canlı ortam ayrımı (staging vs production)
Test ortamı (staging), QA ve geliştirme için gereklidir; ama ölçüm verisine karışırsa dönüşüm datasını bozar. En sık görülen hatalar:
- •Staging domain GA4 raporlarında görünür
- •Test rezervasyonlar gerçek rezervasyon gibi sayılır
- •QA tıklamaları dönüşüm oranını şişirir
Staging–prod ayrımı nasıl kurgulanır?
Pratikte üç yaklaşım var (en güvenliden daha az güvenliye):
- Ayrı GA4 property (staging): test verisi prod’u kirletmez
- Ayrı data stream (staging): tek property içinde ayrışır
- Aynı stream + etiketleme: en düşük efor, ama disiplin ister
Genelde otel gruplarında “ayrı property” veya “ayrı stream” daha temiz olur; tek stream içine karıştırmak uzun vadede raporu yorabilir.
GTM’de ortam yönetimi
- •Staging’de çalışan test tag’leri prod’da ateşlememeli
- •QA tag’leri klasörde tutulmalı (prod publish’te kapalı)
- •Preview/Debug testleri “kanıt” ile kayıt altına alınmalı
Debug parametreleri ve test klikleri
Geliştirici ve QA ekipleri için “test tıklaması protokolü” yazın:
- •Test rezervasyonlar her zaman test flag ile işaretlenir
- •QA akışında conversion tetiklenirse “test=true” parametresi eklenir
- •Raporlarda bu flag ile filtrelenir
Mini Check
- • Staging verisi prod rapora karışıyor mu?
- • Test rezervasyonları ayıran bir işaret var mı?
- • QA tag’leri prod’da ateşliyor mu?
- • Staging için ayrı property/stream planı yapıldı mı?
Ne yapmalıyım?
- • Staging’i prod’dan ayır: property veya stream ile.
- • Test işlemlerini “test=true” ile etiketle.
- • QA tag’lerini staging klasöründe tut ve prod’da kapalı bırak.
- • Her release sonrası 24–72 saat veri anomali kontrolü yap.
5. GA4 ve GTM’de filtre ve etiketleme senaryoları (pratik tablo)
Bu bölüm, ekiplere “hangi durumda ne yapmalıyım?” rehberi verir.
Filtre/Etiketleme Senaryo Tablosu (TABLO – 1 adet)
| Sorun | En güvenli ilk adım | İkinci adım | Risk notu |
|---|---|---|---|
| İç trafik (otel/ajans/dev) | Etiketle: internal=true | Kademeli IP filtre | Aşırı filtre gerçek kullanıcıyı kesebilir |
| QA/test rezervasyonlar | Etiketle: test=true | Ayrı stream/property | Test verisi prod’u kirletmesin |
| Bot/spam dalgası | Kaynak analizi + işaretleme | Kademeli filtre/engelleme | Pattern değişebilir, düzenli güncelle |
| Staging domain raporda | Ayrı property/stream | Prod’da domain kısıtı | Yanlış kısıt prod’u kesebilir |
| Double fire ile şişme | Debug + tekilleştirme | Versiyon kontrol + QA SOP | Önce kök neden çöz |
Raporlamaya etkisi (neden bu iş “şart”?)
- •Kanal performansı daha doğru görünür
- •Conversion rate “gerçek misafir” davranışına yaklaşır
- •Smart bidding daha stabil sinyalle çalışır
- •Yönetim raporlarında güven artar
Key Statistics / Data Point (sheet): Data kalitesi düşük hesaplarda, kampanya optimizasyon algoritmaları yanlış sinyallerle beslendiği için bütçe boşa harcanabilir. (Kesin oran iddiası yok; ama risk mekanizması nettir.)
Mini Check
- • İç/test/bot ayrımı için “etiket alanları” tanımlandı mı?
- • Raporlarda bu etiketlerle filtrelenmiş görünüm var mı?
- • Filtreler kademeli mi, yoksa sert mi?
- • Hijyen kontrolü için aylık checklist var mı?
Ne yapmalıyım?
- • Önce etiketle (internal/test), sonra kademeli filtrele.
- • Staging’i prod’dan ayır (property/stream).
- • Bot dalgalarını takip edip filtreleri güncelle.
- • Aylık data hygiene rutini oluştur.
6. Data hygiene checklist + bakım ritmi (kurumsallaştırma)
Veri hijyeni tek seferlik iş değildir. Otelin ekip yapısı, test süreçleri ve bot saldırı dinamikleri değiştikçe strateji güncellenmelidir. Bu yüzden “ayda 1” kısa bir ritim, uzun vadede çok değer üretir.
Data Hygiene Checklist ve Filtre Örneklerini İndir — SEM / Dönüşüm Datası Kalitesi (v1.0)
Bu checklist, otel dönüşüm verisini kirleten üç ana kaynağı (bot, iç trafik, test ortamı) güvenli sırayla yönetmek için hazırlanmıştır. Önce etiketleme ile riski düşürür, sonra kademeli filtrelemeyle gerçek misafir davranışını veri setinin merkezine alır; staging–prod ayrımı ve aylık bakım ritmi ile sürdürülebilir hale getirir.
Kim Kullanır?
Otel pazarlama/performans + ajans + developer/QA + raporlama sorumlusu.
Nasıl Kullanılır?
- Önce iç/test trafiğini etiketle (internal/test flag).
- 7 günlük gözlem sonrası kademeli filtre ekle (yanlış kesmeyi izle).
- Staging–prod ayrımını kur ve aylık hygiene kontrolünü rutinleştir.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Anomali günleri işaretlendi (deploy/test dönemleri)
- ▢ ✅ Staging domain raporlarda görünüyor mu kontrol edildi
- ▢ ✅ İç trafik kaynakları listelendi (otel/ajans/dev/call center)
- ▢ ✅ İç trafik etiketi tasarlandı (internal=true)
- ▢ ✅ Test/QA etiketi tasarlandı (test=true)
- ▢ ✅ Bot şüphesi olan kaynaklar listelendi (source/landing)
- ▢ ✅ Double fire (çift sayım) kontrol edildi (debug rehberiyle)
- ▢ ✅ Filtreler kademeli mi? (önce etiket, sonra filtre)
- ▢ ✅ Filtre sonrası “yanlış kesme” kontrol planı var (7 gün)
- ▢ ✅ Aylık hygiene bakım ritmi tanımlandı (365 uyumlu)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Mini Check
- • Aylık anomali kontrolü yapılıyor mu?
- • Etiket alanları (internal/test) raporda kullanılıyor mu?
- • Filtreler yanlış kesmeye neden oluyor mu (monitor ediliyor mu)?
- • Staging değişiklikleri prod’a taşınmadan önce QA var mı?
Ne yapmalıyım?
- • Data hygiene checklist’i aylık rutin yap.
- • Filtreleri kademeli uygula ve “yanlış kesme”yi izle.
- • Test ortamı protokolünü ekiplere öğret (ajans/dev).
- • Büyük bot dalgalarında hızlı müdahale planı hazır tut.
7. Kapanış – Temiz veri olmadan doğru karar yok
Bot, iç ve test trafiği ayrıştırılmadığında rapor güveni düşer ve optimizasyon bozulur. En güvenli yaklaşım; önce etiketleme, sonra kademeli filtreleme ve staging–prod ayrımıdır.
Bir Sonraki Adım
Bot/iç/test trafiği nedeniyle raporu şaşan oteller ve ajans ekipleri için, hijyen planını ve güvenli filtre stratejisini netleştirir.
Sık Sorulan Sorular
Bot ve iç trafik dönüşüm verisini nasıl bozar?▾
Otel personeli ve ajans trafiği GA4’te nasıl filtrelenir?▾
Test ortamı verisini canlı raporlardan nasıl ayırırım?▾
Data kalitesi düşükse optimizasyon ne kadar bozulur?▾
Fazla agresif filtre neden risklidir?▾
Staging domain raporlara karışıyorsa ne yapmalıyım?▾
İç trafik protokolü nasıl olmalı?▾
İlgili Yazılar