1. Grup otellerde satış ve dönüşüm raporlamasını neden konsolide etmelisiniz?
Kısa cevap : Konsolidasyon, her tesisi ayrı ayrı takip etmek yerine tüm portföyü aynı funnel ve KPI tanımlarıyla tek panelde görmeyi sağlar. Böylece tesisler arası kıyas doğru yapılır, hangi pazar/kanal kombinasyonunun nerede güçlü olduğu görünür ve bütçe/yatırım kararları portföy performansına göre verilir.
Grup raporlamasında “tek panel” tek başına başarı değildir; başarı, panelin doğru kıyas üretmesidir. Doğru kıyasın ön şartı da ortak tanımdır. Aksi halde bir tesiste “rezervasyon” sadece web purchase iken diğer tesiste call center kapanışı da dahil olabilir; bu durumda KPI karşılaştırması sahte olur.
Konsolidasyonun 4 somut faydası
- Portföy kıyası: Hangi tesis hangi pazarda güçlü?
- Kanal stratejisi: OTA/web/call center karması nerede kârlı?
- Bütçe yönetimi: ROAS ve net katkı, tesis bazında doğru okunur
- Standart operasyon: Aynı rapor diliyle saha ve merkez iletişimi hızlanır
Mini örnek (Antalya + Bodrum)
Antalya resort’ta OTA ağırlığı yüksek olabilir; Bodrum’da direct booking büyütmek daha kârlı olabilir. Tek panel, bu farkı net gösterirse yatırım ve kampanya kararları “tek tesis hissi” ile değil portföy verisiyle alınır.
☑ Mini Check
- •Tesisler arası KPI kıyasının “aynı tanım” ile yapılması gerektiğini netleştirdim
- •Grup raporunda hem tesis hem portföy görünümü olacak
- •Destinasyon/pazar kırılımları filtre olarak var
- •Yönetim ve saha için farklı dashboard katmanı tasarlayacağım
Ne yapmalıyım? (3–6 aksiyon)
- • Önce ortak KPI sözlüğü çıkarın (tanım + formül).
- • Tesis bazlı veri kaynaklarını listeleyin (PMS/booking engine/ads/OTA/call).
- • Grup raporunda “filtre mimarisini” tasarlayın (tesis, destinasyon, pazar, kanal).
- • Yönetim ve saha için ayrı görünüm kurun (aynı veri, farklı ekran).
2. Tesis bazlı veriyi grup KPI’larına nasıl çevirirsiniz?
Kısa cevap : Önce her tesisin funnel adımlarını ve KPI formüllerini aynı tanıma eşleyin; sonra ortak veri modelinde “property_id” ile birleştirip grup metriklerini ağırlıklı şekilde hesaplayın. Grup KPI’ları çoğu zaman basit ortalama değil, gelir/rezervasyon hacmi gibi ağırlıklara göre okunmalıdır.
Tesis KPI’larını “normalize” etmek (ortak sözlük)
Ortak sözlükte her KPI için şu üç alan olmalı:
- •Tanım: KPI neyi ölçer?
- •Formül: nasıl hesaplanır?
- •Kapsam: web mi, OTA mı, call center dahil mi?
Örnek (kapsam)
- •“Total bookings”: web+OTA+call mı, yoksa yalnız web mi?
- •“Conversion rate”: oturum→purchase mı, motor girişi→purchase mı?
Grup KPI’larında “ağırlık” kuralı (en kritik nokta)
Grup seviyesinde “ortalama dönüşüm” çoğu zaman yanıltır. Pratik yaklaşım:
- •Gelir ağırlıklı: revenue contribution yüksek tesise daha fazla ağırlık
- •Hacim ağırlıklı: booking volume yüksek tesise daha fazla ağırlık
- •Segment ağırlıklı: (Varsayım) premium segment ağırlığıyla net katkı okumak
Mini örnek
İki tesisin dönüşümü %2 ve %4 ise “ortalama %3” demek kolaydır; ama asıl soru, hangi tesisin hacmi ve net katkısı daha yüksek? Grup kararları bu ağırlıklarla alınmalıdır.
| KPI Katmanı | Tanım / Formül | Kapsam | Ağırlık / Okuma Kuralı |
|---|---|---|---|
| Tesis KPI’ları | Tanım: KPI neyi ölçer? / Formül: nasıl hesaplanır? | Web mi, OTA mı, call center dahil mi? | Tesis bazında “same definition” |
| Grup KPI’ları | Tesis KPI’larını normalize edip tek tabloda birleştirin (property_id) | Tüm tesislerde aynı kapsam | Gelir ağırlıklı / Hacim ağırlıklı / Segment ağırlıklı |
☑ Mini Check
- •KPI sözlüğümde kapsam (hangi kanallar dahil) net
- •Grup KPI’larını basit ortalama yerine ağırlıkla okuyorum
- •Tesis bazında “same definition” sağlandı
- •Kırılım filtreleri (pazar, destinasyon, kanal) aynı modelde
Ne yapmalıyım? (3–6 aksiyon)
- • KPI sözlüğünü “kapsam” alanıyla kilitleyin.
- • Grup KPI’ları için ağırlık kuralı belirleyin (gelir/hacim).
- • Tesis KPI’larını normalize edip tek tabloda birleştirin (property_id).
- • “Kıyas hatası” riskini azaltmak için veri kalite kontrol listesi yapın.
3. Ortak funnel tanımı kurmak (multi-property funnel)
Grup yapıda funnel tanımı “tek otel funnel’ı” değildir; aynı adımları tüm tesislerde aynı isimle ölçmektir. Aksi halde bir tesiste “begin_checkout” ölçülürken diğerinde ölçülmez; funnel kıyası bozulur.
Ortak funnel adımları (çekirdek)
- •Trafik / oturum
- •Niyet: arama / oda seçimi / checkout başlangıcı
- •Rezervasyon (web purchase + call center kapanış, kapsam kararına göre)
- •Gelir (brüt + (Varsayım) net katkı katmanı)
Ortak isimlendirme standardı (event + kanal)
- •“Channel mix” sözlüğü (web direct, OTA, call center, ads)
- •Event sözlüğü (GA4 / backend)
- •Segment sözlüğü (ülke, cihaz, oda tipi)
☑ Mini Check
- •Tüm tesislerde aynı funnel adımlarını ölçüyorum
- •Event ve kanal sözlüğü ortak
- •Segment sözlüğü ortak (ülke/cihaz/oda)
- •Funnel raporunda “kapsam” (call dahil mi?) net
Ne yapmalıyım? (3–6 aksiyon)
- • Her tesiste ölçülebilir minimum funnel adımlarını belirleyin.
- • Event sözlüğünü grup standardı olarak yayınlayın.
- • Kanal ve segment sözlüğünü merkezden yönetin (değişiklik kontrolü).
- • Yeni tesis eklenince “onboarding checklist” ile standardı uygulatın.
4. Looker Studio ve veri ambarı ile konsolide raporlama
Multi-property raporlama “tek rapor” değil, mimari ister. Looker Studio, görselleştirme katmanıdır; asıl güç, veri ambarında ortak modele dönüştürülmüş veriyle gelir.
Minimum veri mimarisi (pratik)
- •Kaynaklar: GA4 (web), Ads (Google/Meta), OTA raporları, PMS/booking engine, call center/CRM
- •Dönüşüm katmanı: event + transaction + lead
- •Kimlik: property_id, destination, brand, segment dims
- •Çıktı: Looker Studio dashboard katmanları
Veri modelinde 3 zorunlu boyut
- •Property (tesis): property_id, tesis adı
- •Destination (destinasyon): Antalya, Bodrum vb.
- •Channel (kanal): web/OTA/call/ads
Mini örnek
Antalya ve Bodrum tesisleri aynı dashboard’ta kıyaslanacaksa, “destination” boyutu filtre olarak zorunludur; aksi halde sezon davranışı kıyası bozar.
☑ Mini Check
- •Looker Studio’yu görselleştirme katmanı olarak konumladım
- •Veri ambarında ortak model (property/destination/channel) var
- •Kaynak sistemlerden data mapping tablom hazır
- •Dashboard performansı için veri modeli sade
Ne yapmalıyım? (3–6 aksiyon)
- • Önce veri modelini kurun; sonra dashboard’u tasarlayın.
- • Kaynaklardan “tekil anahtar” ile birleştirin (property_id).
- • Destination ve channel filtrelerini standartlaştırın.
- • Veri kalitesi kontrollerini (missing, duplicates) otomatikleştirin.
5. Yönetim ve tesis ekipleri için farklı görünümler
Tek dashboard herkese uymaz. Merkez ofis “portföy performansı ve yatırım kararı” ister; tesis ekibi ise “neden kaybediyoruz ve ne yapacağız?” ister. Aynı veriyle iki katman üretmek en doğru yaklaşımdır.
Merkez ofis (Executive) katmanı
- •Portföy toplam gelir + trend
- •Channel mix (rezervasyon payı + (Varsayım) net katkı payı)
- •Destinasyon/pazar kırılımı
- •“Top 3 fırsat / Top 3 risk” kutusu
Tesis (Operations) katmanı
- •Tesis funnel adım kaybı
- •Kanal bazlı dönüşüm (web/OTA/call)
- •Segment bazlı performans (ülke/cihaz/oda)
- •Haftalık aksiyon listesi
6. 3 örnek grup raporlama senaryosu
Senaryo 1 — Antalya tesisi ROAS iyi, net katkı düşük
- •Hipotez: kanal karması komisyonlu tarafa kaydı
- •Aksiyon: direct booking iyileştirme + OTA komisyon kontrolü + call center kapanış
Senaryo 2 — Bodrum tesisi direct güçlü, talep düşük
- •Hipotez: upper/mid funnel beslemesi zayıf
- •Aksiyon: destinasyon içerikleri + YouTube/Meta upper + remarketing mid
Senaryo 3 — Bir tesis mobilde yüksek kayıp yaşıyor
- •Hipotez: mobil checkout sürtünmesi
- •Aksiyon: mobil hız sprint’i + ödeme adımı testleri + GA4 event doğrulama
Key Statistics / Data Point (yumuşatılmış)
Konsolide raporlama kullanan yapılarda bütçe ve yatırım kararları tek otel verisine göre değil, tüm portföy performansına göre alınabildiği için; “yanlış tesise yanlış yatırım” riski azalır ve fırsatlar daha hızlı ölçeklenir. Değer, tek panelden çok “doğru kıyas ve doğru aksiyon” üretmesindedir.
☑ Mini Check
- •Yönetim ve tesis için ayrı dashboard katmanı var
- •Ortak funnel ve KPI sözlüğü uygulanıyor
- •Destination/channel filtreleri standart
- •Senaryo kutuları ile aksiyon üretimi var
Ne yapmalıyım? (3–6 aksiyon)
- • Executive ve operations dashboard’u ayırın.
- • KPI sözlüğünü merkezden yönetin, tesis onboarding’ine ekleyin.
- • Filtre mimarisini sabitleyin (property/destination/channel).
- • Haftalık rapor ritmi + aylık portföy değerlendirme toplantısı kurun.
7. Multi-Property Satış & Dönüşüm Dashboard Şablonunu İndir — Satış & Dönüşüm Raporları
Multi-Property Satış & Dönüşüm Dashboard Şablonunu İndir — Satış & Dönüşüm Raporları (v1.0)
Bu şablon, grup otellerde tüm tesisleri aynı funnel ve KPI tanımıyla konsolide etmek için hazır dashboard katmanları ve filtre mimarisi sunar. Amaç, tesis bazlı ve grup bazlı KPI’ları aynı panelde doğru kıyaslayıp, bütçe ve yatırım kararlarını portföy performansına göre hızlandırmaktır.
Kim Kullanır?
Merkez ofis, grup GM, BI/raporlama ekibi, ajans ve tesis yöneticileri.
Nasıl Kullanılır?
- Tesis listesi ve property_id sözlüğünü şablona ekleyin.
- Ortak KPI tanımlarını (kapsam + formül) doldurun ve veri modeline bağlayın.
- Executive (portföy) ve Operations (tesis) katmanlarını Looker Studio’da ayrı sayfalara kurun.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ KPI kapsamları aynı (call dahil mi?)
- ▢ ✅ Property_id eşlemesi doğru
- ▢ ✅ Destination filtreleri doğru
- ▢ ✅ Veri eksik/çift kayıt kontrolleri var
- ▢ ✅ Executive ve operations sayfaları ayrıldı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Kontrol listesi
- •KPI kapsamları aynı (call dahil mi?)
- •Property_id eşlemesi doğru
- •Destination filtreleri doğru
- •Veri eksik/çift kayıt kontrolleri var
- •Executive ve operations sayfaları ayrıldı
Bir Sonraki Adım
Tüm tesisleri tek KPI diliyle kıyaslamak isteyen merkez ofis ve yatırımcılar için.