1. Anomali tespiti nedir, dönüşüm verisinde nasıl kullanılır?
Kısa cevap : Anomali tespiti, bir metriğin zaman içindeki “normal” davranışından sapmalarını (ani düşüş, ani artış, beklenmedik pattern değişimi) otomatik işaretleme tekniğidir. Dönüşüm verisinde bu, booking_complete sayısının sıfırlanması, value/currency hatasıyla gelir şişmesi veya belirli bir pazarda dönüşümün çökmesi gibi sorunları erken yakalamak için kullanılır.
GA4 tarafında “Analytics Intelligence/Insights” ve anomaly detection yaklaşımı, zaman serisi metriklerde olağandışı değişimleri işaretlemek için kullanılan bir mekanizmadır.
Mini Check
- • Dönüşüm KPI’larınız “günlük” izleniyor mu (adet + gelir)?
- • Haftaiçi/haftasonu sezon pattern’leri var mı (normal davranış tanımı)?
- • “Sıfırlanma” ve “şişme” gibi kritik durumlar için alarm var mı?
- • Alarm geldiğinde kimin ne yapacağı belli mi?
Ne yapmalıyım?
- • Önce 5 kritik metriği seç (booking_complete, booking_value, booking_start, ROAS, consent rate).
- • “Normal”i tanımla (7/28 günlük baseline).
- • Eşik bazlı alarmla başla; sonra pattern/ML ekle.
- • Alarm sonrası triage playbook yaz (15 dk içinde kontrol listesi).
2. Oteller için kritik anomali türleri (ani düşüş, ani artış, yanlış event)
Kısa cevap : Otellerde en kritik anomali türleri; (1) rezervasyonların bir günde sıfırlanması, (2) yanlış tetikleme/double-fire ile dönüşüm şişmesi, (3) belirli pazarda veya cihazda dönüşümün çökmesi ve (4) gelir parametresi (value/currency) bozulmasıdır.
1) “Sıfırlanma” anomalisi (en kritik)
- •booking_complete = 0
- •booking_value = 0
Muhtemel kök neden: tag tetiklenmiyor, thank-you değişti, cross-domain kırıldı, consent akışı kesti.
2) “Şişme” anomalisi (gizli tehlike)
- •dönüşüm adedi 2–3 kat artar
- •gelir “uçmuş” görünür
Muhtemel kök neden: double-fire, duplicate transaction_id, test verisi, bot/iç trafik.
3) Segment çöküşü (pazar/cihaz)
- •DE pazarı dönüşümü çöker ama TR normal
- •Mobil çöküp desktop normal kalır
Muhtemel kök neden: banner UX, cihaz bazlı ödeme hatası, lokasyon bazlı erişim sorunu.
4) “Yanlış event” anomalisi
- •booking_complete yerine booking_start conversion olmuş gibi görünür
Muhtemel kök neden: GA4 conversion işaretlemesi veya GTM mapping hatası.
Mini Check
- • “0 rezervasyon” alarmı ayrı ve en yüksek öncelikte mi?
- • Double-fire ve test verisi için ayrı sinyal var mı?
- • Pazar/dil ve cihaz kırılımında alarm üretilecek mi?
- • Gelir parametresi (currency/value) bozulunca yakalıyor musun?
Ne yapmalıyım?
- • Öncelik sırası koy: 0 → şişme → segment çöküşü → diğer.
- • Her anomali tipi için “kök neden checklist” yaz.
- • Segment alarmlarında “yanlış pozitif” riskini azalt (min hacim şartı).
- • Alarm sonrası 24 saat içinde postmortem yap (neden, çözüm, önlem).
3. GA4 ve Looker Studio’da basit anomali görselleştirme (eşik temelli)
Her otelin ilk adımı “ML” olmak zorunda değil. Basit ama etkili yaklaşım: zaman serisi grafikleri + eşik.
GA4 tarafında pratik
GA4 Insights/Analytics Intelligence; olağandışı değişimleri (anomali) işaretleme ve bildirim üretme mantığı sunar.
Bu katman, “ilk alarm” için işe yarar; ama operasyonel playbook ile birleşmezse tek başına yeterli olmayabilir.
Looker Studio tarafında pratik
Looker Studio’da grafik üzerinde belirli koşullar sağlandığında bildirim gönderen “chart alerts” yaklaşımı bulunur (özellikle Pro özellik setlerinde).
Otel kullanımında en pratik 3 grafik:
- •Günlük booking_complete (adet)
- •Günlük booking_value (gelir)
- •Booking_start → booking_complete dönüşüm oranı
Not: Alert’leri aşırı sık çalıştırmak gürültü üretir. “Günlük veriye günlük kontrol” çoğu otelde yeterlidir.
Eşik tasarımı (hızlı başlangıç)
- •booking_complete: son 28 gün ortalamasına göre %X düşüş → alarm
- •booking_value: aynı mantık + currency kontrolü
- •segment: yalnız hacim > N ise alarm (yoksa false positive)
Mini Check
- • Zaman serisi grafikleri tek sayfada mı (operasyon paneli)?
- • Eşikler “sezon” ve “hafta içi/sonu” farkını dikkate alıyor mu?
- • Segment alarmlarında min hacim şartı var mı?
- • Alert’ler kime gidiyor ve ne zaman aksiyon bekleniyor?
Ne yapmalıyım?
- • Önce eşik tabanlı alarmla başla (MVP).
- • Onay/consent ve test trafiği gibi “yanlış pozitif” kaynaklarını ayır.
- • Alarm mesajına “ilk 3 kontrol adımı” ekle (triage).
- • 30 gün sonra eşikleri güncelle (sezon değişimine uyum).
4. Eşik–pattern–ML yaklaşımı (ne zaman hangisi?)
Aynı işi üç olgunluk seviyesinde yapabilirsiniz. Aşağıdaki tablo, hangi aşamada hangisinin mantıklı olduğunu netleştirir.
| Yaklaşım | Ne yapar? | Artı | Eksi | Otel için ne zaman? |
|---|---|---|---|---|
| Eşik (Threshold) | % düşüş/% artış yakalar | Hızlı, ucuz, anlaşılır | Sezon/pattern’de false alarm | Başlangıç, MVP |
| Pattern (Seasonality-aware) | Haftaiçi/haftasonu, sezon kalıbını dikkate alır | Daha az false alarm | Kurulum daha zor | Orta hacim, 2+ pazar |
| ML (Model tabanlı) | Zaman serisi modelinden anomali çıkarır | Karmaşık sapmaları yakalar | Maliyet/karmaşıklık + bakım | Çok otel, yüksek hacim, BI olgun |
5. AI/Machine Learning ile otomatik uyarı sistemleri (BigQuery ML dahil)
ML tabanlı sistemlerde amaç “her şeyin alarmı” değil; karmaşık pattern değişimlerini (sezon, kampanya, pazar) daha akıllı yakalamaktır. Burada iki pratik yaklaşım öne çıkar:
1) BigQuery ML ile anomali tespiti (SQL tabanlı)
BigQuery ML’de ML.DETECT_ANOMALIES fonksiyonu zaman serisi dahil farklı model türleriyle anomali tespiti için kullanılır.
Otel için pratik: GA4→BigQuery export varsa, booking_complete ve booking_value metriklerini “hotel_code/pazar/cihaz” kırılımında izleyip anomali skoruyla alarm üretebilirsiniz.
2) “Uyarı” katmanı (Slack/e-posta)
Uyarıların e-posta veya ekip kanallarına düşmesi gerekir. Looker/Looker Studio veya veri platformu katmanında bildirim mekanizmaları kurulabilir; örneğin Looker tarafında zaman serisi alert’ler ve bildirimler vardır.
Otel pratiğinde önemli olan: alarmın aksiyon doğurması. Aksi halde ekip alarmları susturur.
Teknik not (kritik)
AI tabanlı sistemlerde yanlış pozitif (sorun yokken alarm) ve yanlış negatif (sorun varken kaçırma) riski vardır. Bu nedenle insan kontrolünü tamamen devre dışı bırakmayın; “insan-onaylı triage” en güvenli tasarımdır.
Mini Check
- • GA4 verisi BigQuery’ye akıyor mu (event-level)?
- • Alarmı tetikleyecek metrikler net mi?
- • False positive’i azaltmak için min hacim ve seasonality kuralı var mı?
- • Alarm sonrası insan triage süreci yazılı mı?
Ne yapmalıyım?
- • ML’ye geçmeden önce threshold/pattern ile olgunlaş.
- • ML’de önce tek metrik + tek otel pilotu yap.
- • Alarm mesajına “ilk 5 kontrol” checklist’i ekle.
- • 60 gün sonra modeli yeniden kalibre et (sezon etkisi).
6. Oteller için kullanım senaryoları (operasyonel çerçeve)
Bu bölüm, “alarm geldiğinde ne yapacağız?” sorusunu kapatır.
Senaryo 1 — “Rezervasyonlar bir günde sıfırlandı”
Alarm: booking_complete = 0
Hızlı triage (15 dk):
- •GA4 DebugView: booking_complete geliyor mu?
- •GTM Preview: tag tetikleniyor mu?
- •Booking engine thank-you değişti mi?
- •Consent/banner değişikliği yapıldı mı?
Senaryo 2 — “Gelir birden 3 katına çıktı”
Alarm: booking_value anormal
Hızlı triage:
- •Double-fire var mı? (transaction_id tekrar ediyor mu?)
- •Test rezervasyon/staging karıştı mı?
- •currency/value formatı bozuldu mu?
Senaryo 3 — “Sadece bir pazarda çöküş”
Alarm: market=DE booking_complete düşüş
Hızlı triage:
- •Consent oranı o pazarda düştü mü?
- •Dil/banner metni sorunlu mu?
- •Ödeme/engine o pazarda hata veriyor mu?
Data point (sheet’ten, abartısız)
Erken fark edilen dönüşüm kırılmaları, günlerce fark edilmeyen hatalara kıyasla ciddi gelir kaybını önleyebilir. Bu yüzden amaç “mükemmel model” değil, “erken uyarı + hızlı müdahale” disiplinidir.
Mini Check
- • Alarm geldiğinde 15 dk triage checklist’i var mı?
- • Sorumluluk net mi (kim bakar, kim düzeltir)?
- • False alarm için “susturma” değil “kalibrasyon” süreci var mı?
- • 365 gün bakım: eşikler ve modeller güncelleniyor mu?
Ne yapmalıyım?
- • Alarmı “olay yönetimi” sürecine bağla (ticket + owner + SLA).
- • İlk 30 gün sadece kritik 3 metrikle çalış.
- • Sonra segment alarmlarını ekle (pazar/cihaz).
- • Her büyük site/engine değişikliğinden sonra eşikleri yeniden kalibre et.
7. Anomali Tespiti için Metrik ve Eşik Tanımlama Şablonunu İndir
Anomali Tespiti için Metrik ve Eşik Tanımlama Şablonunu İndir — Monitoring (v1.0)
Bu şablon, otel dönüşüm verisi için anomali izleme sistemini sade ve uygulanabilir şekilde tasarlamanızı sağlar: hangi metrik izlenecek, hangi eşik/pattern kuralıyla alarm üretilecek, alarm kime gidecek ve ilk 15 dakikalık triage adımı ne olacak—hepsi tek yerde toplanır. Böylece “ölçüm kırıldı mı?” sorusu günler değil saatler içinde cevaplanır.
Kim Kullanır?
Otel pazarlama/performance + teknik ekip + raporlama/BI + ajans (ortak operasyon dokümanı).
Nasıl Kullanılır?
- Kritik 5 metriği seç ve baseline dönemini belirle (7/28 gün).
- Eşik/pattern/ML kuralını ve min hacim koşulunu yaz; alarm kanalını belirle (e-posta/Slack).
- Triage checklist’i ekle; her alarm sonrası postmortem ile eşikleri kalibre et.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ A) Metrik kataloğu
- ▢ ✅ B) Alarm yönlendirme (routing)
- ▢ ✅ C) 15 dakikalık triage checklist
- ▢ ✅ D) Postmortem (olay kapanışı)
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Kapanış – Ölçümün yeni seviyesi: izleme ve erken uyarı
Anomali tespiti, otel ölçümlemesini “rapor”dan “monitoring” seviyesine taşır. Amaç; geliri etkileyen kırılmaları erken yakalamak ve hızlı müdahale etmek—insanı tamamen devreden çıkaran bir otomasyon değil, insanı güçlendiren bir sistem kurmaktır.
Bir Sonraki Adım
Dönüşüm kırılmalarını erken yakalayıp hızlı müdahale süreci kurmak isteyen oteller için.
Sık Sorulan Sorular
Anomali tespiti nedir, dönüşüm verisinde nasıl kullanılır?▾
Otel rezervasyon verisinde ani düşüşler nasıl takip edilir?▾
AI ile otomatik uyarı sistemi kurmak mümkün mü?▾
Looker Studio veya GA4’te anomali nasıl görselleştirilir?▾
Anomali alarmı çok sık çalarsa ne yapmalıyım?▾
Hangi metriklerle başlamak en doğrusudur?▾
İlgili Yazılar