1. Hangi metriği kime göstermeli? (KPI seviyesi = hedef kitle)
Aynı veriyi üç farklı gruba aynı şekilde sunarsanız, iki şey olur: yönetim sıkılır, teknik ekip sinirlenir. Doğru yöntem, “tek veri kaynağı → üç farklı anlatım seviyesi”dir.
1) Yönetim (Owner/GM) — 5 KPI kuralı
Yönetim için amaç: bütçe ve kanal kararı çıkarmak.
- •Toplam direkt rezervasyon geliri (veya booking value)
- •Kanal dağılımı (Direct / Paid Search / Meta / OTA / Referral)
- •ROAS (gelir / reklam harcaması)
- •CPA veya “rezervasyon başı maliyet”
- •Dönüşüm oranı (booking_complete / booking_start veya ziyaret→rezervasyon)
- •(opsiyonel) Doluluğa katkı / sezon hedefiyle sapma
- •(opsiyonel) Pazar kırılımı (TR/UK/DE)
2) Pazarlama ekibi — teşhis + optimizasyon
Pazarlama için amaç: “neyi büyütelim, neyi kapatalım?”
- •Kampanya bazlı ROAS/CPA
- •Funnel drop-off (booking_start→complete)
- •Mikro dönüşümler (fiyat görme, oda detayı)
- •İçerik/landing performansı
3) Teknik ekip — doğruluk + kalite
Teknik ekip için amaç: ölçümün güvenilirliği
- •Event sözlüğü ve parametre doğruluğu
- •Debug bulguları
- •Cross-domain/referral hataları
- •DataLayer değişiklikleri
Teknik not (sheet): Yönetim sunumlarında event sayısı, debug log’ları gibi metrikler kafa karışıklığı yaratır; bunun yerine özet KPI’lar tercih edilmelidir.
Mini Check
- •Yönetim raporunda KPI sayısı 5–7 aralığında mı?
- •Pazarlama raporu teşhis metrikleri içeriyor mu?
- •Teknik raporda doğruluk/kalite kontrol var mı?
- •Üç rapor aynı veri kaynağından mı besleniyor?
Ne yapmalıyım?
- • Yönetim raporunu “5 KPI + 3 karar” formatında tasarla.
- • Pazarlama raporunu funnel ve kampanya seviyesinde derinleştir.
- • Teknik raporu QA ve veri hijyeni checklist’ine bağla.
- • Her raporun “karar amacı”nı başına yaz.
2. Yönetim için önemli KPI’lar (gelir, doluluk, kanal dağılımı, ROAS)
Bu KPI’ları sadece “gösterme” değil, anlamlandırma önemli. Yönetim şu soruya cevap ister: “Ne oldu ve ne yapalım?”
KPI setini “hikâye”ye bağlama
- •Gelir ↑ ama ROAS ↓ → büyüme var ama maliyet artmış, kanal karması kontrol edilmeli
- •Doluluk hedefi tutmuyor ama trafik artıyor → UX/funnel sorunu olabilir
- •Kanal payı OTA lehine kayıyor → direkt kanal teşvikleri ve kampanya kurgusu revize edilmeli
- •ROAS ↑ ama rezervasyon sayısı ↓ → daha az ama daha değerli rezervasyon (oda/paket) olabilir
“Tek sayı” tuzağı
ROAS tek başına yeterli değildir. Yönetim seti mutlaka “gelir + maliyet + dönüşüm” üçgenini göstermeli. Aksi halde iyi görünen bir metrik, diğerinde bozulma saklayabilir.
Mini Check
- •Gelir, maliyet ve dönüşüm birlikte mi okunuyor?
- •Kanal dağılımı “trend” olarak var mı (önceki dönem kıyası)?
- •Doluluk hedefi ile pazarlama KPI’ları aynı sunumda mı?
- •KPI’lar aksiyon önerisine bağlanıyor mu?
Ne yapmalıyım?
- • KPI panelini “önceki dönem kıyası” ile ver.
- • Her KPI için 1 cümle içgörü yaz (ne oldu?).
- • Her içgörü için 1 aksiyon öner (ne yapalım?).
- • KPI’ları 5–7’de tut; detayları ek slayta koy.
3. Teknik detayları basitleştirme (yönetimi boğmadan doğru anlatma)
Yönetim “GTM’de trigger bozuldu” cümlesine değil, “bu yüzden revenue raporu 3 gün yanlış göründü” cümlesine ihtiyaç duyar. Teknik detayları basitleştirmenin yolu:
3 katmanlı anlatım şablonu
- Etki: Ne etkilendi? (gelir/ROAS/kanal payı)
- Sebep: Kısa teknik sebep (tek cümle)
- Önlem: Bir daha olmaması için süreç (QA, rollback)
Örnek
- •Etki: Booking revenue 2 gün eksik göründü
- •Sebep: booking_complete event’inde currency parametresi boş geldi
- •Önlem: publish öncesi QA checklist + DebugView kontrolü zorunlu
Yönetim için “teknik risk” dili
Teknik riskleri KPI diline çevirin:
- •“Double fire” → “gelir şişmesi riski”
- •“Cross-domain bozuk” → “attribution sapması, yanlış bütçe kararı riski”
- •“Bot trafik” → “dönüşüm şişmesi, yanlış optimizasyon riski”
Mini Check
- •Teknik detaylar KPI etkisiyle mi anlatılıyor?
- •Yönetim sunumunda debug/event sayısı gibi metrikler var mı? (çıkar)
- •Riskler “karar riski” olarak ifade ediliyor mu?
- •Önlem süreçleri net mi (QA, versiyon, rollback)?
Ne yapmalıyım?
- • Teknik slaytları ek bölüm yap; ana sunumdan çıkar.
- • Her teknik bulguyu “etki–sebep–önlem” formatına çevir.
- • Yönetimi sayıyla değil “karar riski”yle ikna et.
- • Süreç iyileştirmelerini (QA, governance) KPI’ye bağla.
4. Funnel ve örnek misafir yolculuklarıyla anlatmak (storytelling)
Yönetim, tek bir grafikten çok “net hikâye”yi hatırlar. Otelde en iyi hikâye formatı: misafir yolculuğu.
Örnek misafir hikâyesi (template)
“Kullanıcı Google’da ‘belek aile oteli’ aradı → kampanya sayfasına geldi → oda detayına baktı → fiyatı gördü → rezervasyon motoruna geçti → ödeme adımında terk etti.”
Bu hikâye, funnel verisiyle birleştiğinde aksiyon çıkar:
- •Ödeme adımı drop-off yüksekse → ödeme UX, güven unsuru, hata analizi
- •Oda detayı yüksek ama booking_start düşükse → CTA/fiyat görünürlüğü
- •FAQ’ya sıçrama varsa → itiraz kırıcı içerik (iptal politikası)
Yönetim sunumunda 3 hikâye kuralı
- •1 başarı hikâyesi (ne işe yaradı)
- •1 problem hikâyesi (nerede kaybediyoruz)
- •1 fırsat hikâyesi (neyi büyütelim)
Mini Check
- •Sunumda en az 1 misafir yolculuğu hikâyesi var mı?
- •Hikâye bir KPI’ye bağlanıyor mu? (gelir/ROAS/drop-off)
- •Hikâye aksiyon önerisiyle bitiyor mu?
- •3 hikâye kuralı uygulanıyor mu?
Ne yapmalıyım?
- • Her yönetim toplantısı için 2–3 hikâye hazırla.
- • Hikâyeyi funnel metrikleriyle kanıtla.
- • Hikâyenin sonunda net “karar” öner (bütçe artır/azalt, UX sprint).
- • Hikâyeleri aynı formatta tekrarla (alışkanlık oluşturur).
5. Dashboard ve sunum formatı: Dashboard mı, sunum mu?
İkisi rakip değil; farklı iş görür:
- •Dashboard: sürekli izleme (haftalık/aylık ritim)
- •Sunum: karar ve yön verme (toplantı)
Otel yönetimi için pratik format
- •1 sayfa dashboard (KPI paneli + trend)
- •5–7 slayt sunum (hikâye + içgörü + aksiyon)
- •Ek: detay sayfalar (pazarlama/teknik)
Yönetim dashboard’unda olması gereken 6 blok
- Gelir (direkt) + trend
- Kanal dağılımı (paid/organic/OTA/direct)
- ROAS + harcama
- Funnel health (booking_start→complete)
- Pazar/dil kırılımı (opsiyonel)
- Aksiyon kutusu (bu ay 3 karar)
Mini Check
- •Dashboard 1 sayfada mı?
- •Sunum 7 slaytı geçiyor mu? (gereksiz uzuyor)
- •Her panelin yanında “aksiyon” var mı?
- •Yönetim raporu teknik metrik içermiyor mu?
Ne yapmalıyım?
- • Dashboard’u izleme aracı, sunumu karar aracı yap.
- • Yönetim dashboard’unda sadece KPI göster; detayları ayrı sekmeye koy.
- • Sunumun sonuna “karar listesi” ekle.
- • Aynı formatı her ay tekrar et (kıyas kolaylaşır).
6. KPI → içgörü → aksiyon zinciri (tek tabloyla karar çıkarma)
Bu yazının “en uygulanabilir” parçası bu tablodur. Yönetim toplantısında herkesin aynı şeyi anlamasını sağlar.
KPI → İçgörü → Aksiyon Tablosu (TABLO – 1 adet)
| KPI | Ne gördük? (İçgörü) | Neden olabilir? | Ne yapacağız? (Aksiyon) | Sahip | Zaman |
|---|---|---|---|---|---|
| Booking revenue | ___ | ___ | ___ | ___ | ___ |
| ROAS | ___ | ___ | ___ | ___ | ___ |
| Kanal payı | ___ | ___ | ___ | ___ | ___ |
| Funnel drop-off | ___ | ___ | ___ | ___ | ___ |
| CPA | ___ | ___ | ___ | ___ | ___ |
Mini Check
- •Her KPI için içgörü ve aksiyon yazıldı mı?
- •Aksiyonun sahibi ve zamanı var mı?
- •Sunum “karar” ile bitiyor mu?
- •Teknik detaylar ek bölümde mi?
Ne yapmalıyım?
- • Her ay 5 KPI + 3 karar formatını uygula.
- • KPI→içgörü→aksiyon tablosunu toplantının merkezine koy.
- • Aksiyonları takip et (bir sonraki ay “ne oldu?”).
- • KPI setini yönetim değiştikçe güncelle (365).
Rapor hazırlama checklist’i (kısa)
- •Yönetim KPI seti (5–7) hazır
- •2–3 misafir hikâyesi yazıldı
- •KPI→içgörü→aksiyon tablosu dolduruldu
- •Dashboard (1 sayfa) güncellendi
- •Sunum (5–7 slayt) hazır
- •Teknik ek slaytlar ayrı
- •Karar ve aksiyon sahipleri net
İç link önerisi (Internal Link Targets ile uyumlu)
- •https://dgtlface.com/tr/raporlama/satis-donusum
- •https://dgtlface.com/tr/raporlama/looker-studio
- •https://dgtlface.com/tr/veri-analiz-ve-raporlama
- •https://dgtlface.com/tr/sem/donusum-takibi-tag-manager
Kapanış – İyi rapor, karar çıkaran rapordur
Dönüşüm datasını yönetime anlatmak, teknik doğruluktan çok “doğru çeviri” işidir. KPI’ları sadeleştirip hikâyeye bağladığınızda ve aksiyon önerisiyle bitirdiğinizde, veri gerçek gücünü gösterir.
7. Yönetim Dashboard & Sunum Şablonunu İndir — Raporlama & Storytelling
Yönetim Dashboard & Sunum Şablonunu İndir — Raporlama & Storytelling (v1.0)
Bu şablon, otel dönüşüm datasını yönetim diline çeviren bir raporlama paketidir: 1 sayfa dashboard yapısı, 5–7 slaytlık sunum akışı ve KPI→içgörü→aksiyon tablosu ile “veri → karar” zincirini standartlaştırır. Amaç; teknik detaylara boğmadan gelir, doluluk etkisi, kanal payı ve ROAS üzerinden net bütçe kararları çıkarmaktır.
Kim Kullanır?
Satış-pazarlama müdürü / ajans yöneticisi / GM’ye sunum yapan ekip.
Nasıl Kullanılır?
- KPI setini seç (5–7 KPI) ve önceki dönem kıyasını ekle.
- 2–3 misafir hikâyesi yaz (başarı, problem, fırsat) ve ilgili KPI ile bağla.
- KPI→içgörü→aksiyon tablosunu doldur; sunumu “3 karar” ile bitir.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ 1) Yönetim Dashboard (1 sayfa) – blok şablonu
- ▢ ✅ 2) Sunum Akışı (5–7 slayt)
- ▢ ✅ 3) KPI → İçgörü → Aksiyon Tablosu (doldur)
- ▢ ✅ 4) Rapor Hazırlama Checklist’i
- ▢ ✅ 5) Nasıl doldurulur? (5 kural)
- ▢ ✅ 6) Deliverables
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Sonuç: Veri ancak doğru çevrildiğinde karar üretir
Dönüşüm verisini yönetime anlatmak, teknik doğruluktan çok “doğru çeviri” işidir. KPI’ları sadeleştirip hikâyeye bağladığınızda ve aksiyon önerisiyle bitirdiğinizde, veri gerçek gücünü gösterir.
Bir Sonraki Adım
Yönetim kararlarına etki eden dashboard ve sunum kurgusunu oteliniz için netleştirmek isteyen ekipler için.
Sık Sorulan Sorular
Dönüşüm datası yönetime nasıl sunulmalı?▾
Otel yöneticileri için hangi KPI’lar önemlidir?▾
Veriyle hikâye anlatımı (data storytelling) nedir?▾
Dashboard mu, sunum mu, hangisini kullanmalıyım?▾
Yönetimi teknik metriklerle sunmak neden kötü?▾
Sunumun sonunda ne olmalı?▾
İlgili İçerikler
İlgili Yazılar