1. Neden BigQuery + Looker Studio kombinasyonu?
BigQuery + Looker Studio kombinasyonu, oteller için iki temel probleme aynı anda çözüm verir:
- Performans: Ham veriyi (GA4 export, PMS/OTA satırları, çağrı kayıtları) doğrudan dashboard’a bağlamak büyüdükçe yavaşlar.
- Tutarlılık: “gelir”, “rezervasyon”, “kanal” gibi kavramlar farklı kaynaklarda farklı isim/hesapla geldiğinde ekip aynı raporu farklı okur.
BigQuery “tek model, tek sözlük” yaklaşımıyla veriyi merkezileştirir; Looker Studio ise bu modele bağlanıp yönetime uygun “tek panel” deneyimi sağlar.
Mini örnek (grup otel)
Antalya’da 3 resort + Bodrum’da 2 oteliniz var. Her otelde kanal listesi farklı isimlenmiş (Booking/OTA/Online Travel), gelir brüt/net karışmış. BigQuery’de tek bir `channel` ve `revenue_net` standardı kurduğunuzda, zincir KPI’ları tek ekranda karşılaştırılabilir olur.
☑ Mini Check
- •Dashboard’lar veri büyüdükçe yavaşlıyor mu?
- •“Gelir/rezervasyon” tanımı ekipten ekibe değişiyor mu?
- •Her ay CSV/Excel aktarımı yapılıyor mu?
Ne yapmalıyım?
- • KPI sözlüğünü tek yerde standardize et (BigQuery model katmanı)
- • Looker Studio’yu ham veri yerine view/model’e bağla
- • “tek doğru kaynak” mantığıyla manuel export’ları azalt
2. PMS, OTA, Call Center ve Web verisini BigQuery’de toplamak
Veriyi BigQuery’ye toplamak, “her şeyi bir yere yığmak” değil; kaynakları düzenli ve izlenebilir bir pipeline ile içeri almak demektir. Bu aşamada 4 kaynak ailesi için kısa bir strateji belirlemek yeterlidir.
PMS (Property Management System)
- •Rezervasyon ve konaklama gerçekliği: `stay_date`, `room_nights`, `revenue`, `room_type`, `country`, `booking_status`
- •Otel kodu (`hotel_code`) multi-property için zorunlu
OTA (Booking/Expedia vb.)
- •Kanal performansı: rezervasyon, iptal/no-show, komisyon sinyali (varsa)
- •OTA’yı `channel = OTA` altında standardize edip alt kırılımı `ota_name` ile tutmak mantıklıdır. (Varsayım)
Call Center
- •Çağrı hacmi, cevaplanma, talep → rezervasyon dönüşümü
- •Dil/pazar kırılımı (TR/EN/DE/RU) varsa operasyon planını güçlendirir.
Web (GA4 export)
- •BigQuery’de GA4 export; web davranışını “satış hunisi” ile bağlamada güçlüdür.
- •“web conversion” ile “PMS satış gerçekliği”ni katmanlı okumak gerekir.
Mini örnek (eşleştirme)
Call center’dan gelen “talep” kaydı, PMS’deki rezervasyona `inquiry_id` veya tarih+telefon+otel kodu üzerinden eşleştirilebilir. (Varsayım: sistemler izin veriyorsa)
☑ Mini Check
- •Her kaynakta `hotel_code` ve `date` ortak mı?
- •Kanal isimleri tek sözlükte mi? (OTA/Web/Call Center)
- •GA4 export ve PMS gelir tanımı ayrıştırıldı mı?
Ne yapmalıyım?
- • Önce “minimum ortak boyutlar”ı kilitle: `hotel_code`, `date`, `channel`, `currency`
- • Kaynakları “raw → modeled” katmanlarla ayır
- • Eşleştirmeyi (PMS ↔ web ↔ call center) iteratif kur
3. Veri modeli ve tablo tasarımı (fact & dimension)
Büyük veri mimarisinde en kritik kalite unsuru, doğru veri modelidir. Oteller için en pratik model, fact + dimension yaklaşımıdır:
- •Fact tablolar: ölçüm satırları (rezervasyon, gelir, tıklama, çağrı)
- •Dimension tablolar: sözlükler (otel, kanal, pazar, oda tipi)
Örnek fact tablolar (otel için)
- •`fact_stays` (PMS): stay_date, hotel_code, room_type_id, channel_id, revenue_net, room_nights, booking_status
- •`fact_ota` (OTA): date, hotel_code, ota_name, bookings, cancellations, commission_cost (Varsayım)
- •`fact_calls` (Call center): date_time, hotel_code, language, answered, wait_time, inquiry_outcome
- •`fact_ga4_events` (GA4): event_date, session_source, event_name, conversion_value (Varsayım: modelleme yapılır)
Örnek dimension tablolar
- •`dim_hotel` (hotel_code, destination, brand, timezone)
- •`dim_channel` (channel_id, channel_group: OTA/WEB/CALL_CENTER, channel_name)
- •`dim_room_type` (room_type_id, room_type_name, category)
- •`dim_market` (country, market_group)
Teknik not (maliyet + performans)
- •Partitioning: tarih alanına göre böl (örn. `event_date` / `stay_date`)
- •Clustering: sık filtrelenen alanlarda (`hotel_code`, `channel_id`) clustering
- •Bu sayede hem hız hem maliyet kontrolü daha iyi yönetilir.
☑ Mini Check
- •Fact tablolar tarih ile partition edilmiş mi?
- •Otel ve kanal gibi boyutlar dimension olarak ayrıldı mı?
- •TR/EN alan isimleri tek standarda çekildi mi?
Ne yapmalıyım?
- • Önce 1 fact + 2 dimension ile MVP kur (örn. stays + hotel + channel)
- • Sonra OTA ve GA4’ü ekleyerek modeli büyüt
- • Partition/clustering’i baştan tasarla (sonradan maliyet artabilir)
4. Looker Studio üzerinden büyük veri setlerini raporlamak
Looker Studio’da büyük veriyle çalışmanın sırrı, ham tablolara değil view’lara bağlanmaktır. View, BigQuery tarafında “iş sorusuna göre hazırlanmış” özet katmandır. Bu yaklaşım; dashboard’ı hızlandırır, KPI tanımını sabitler.
3 tip BigQuery görünümü (önerilen)
- Günlük özet (daily_summary_view): hotel_code + date + occupancy/revenue/RevPAR
- Kanal bazlı (channel_performance_view): date + channel_group + revenue_net + commission_cost
- Otel bazlı (property_drilldown_view): hotel_code + channel + market + room_type kırılımları
Mini örnek
Looker Studio’da “son 30 gün kanal bazlı net gelir” kartı, doğrudan `fact_stays` üzerinde çalışırsa milyonlarca satır tarayabilir; `channel_performance_view` ile özetlenmiş bir view üzerinden çalışırsa çok daha hızlı yanıt verir.
☑ Mini Check
- •Looker Studio data source ham tablo mu, view mı?
- •Aynı KPI farklı sayfalarda farklı mı hesaplanıyor?
- •Dashboard’da filtreler performansı düşürüyor mu?
Ne yapmalıyım?
- • Dashboard KPI’larını view katmanına taşı (tek tanım)
- • Looker Studio’da gereksiz boyut kırılımlarını azalt
- • Raporları “Executive” ve “Drill-down” sayfalar olarak ayır
5. Grup ve zincir oteller için örnek mimari (multi-property)
Zincir yapılarda en kritik iki standart:
- •`hotel_code` (tesis kimliği)
- •`destination/location` (Antalya/Bodrum gibi destinasyon)
Bu iki alan, hem operasyon hem yatırımcı raporlarında “aynı KPI’yı doğru karşılaştırma”yı sağlar.
Key Statistics / Data Point (sheet’e uygun, yumuşatılmış)
Veri ambarı kuran otel gruplarında, yeni dashboard üretim süresinin ve manuel CSV/Excel aktarma ihtiyacının belirgin şekilde azaldığı; ayrıca tarihsel veri derinliğinin arttığı sık görülen bir sonuçtur. Bu kazanım, KPI’ların tek modelde standardize edilmesinden gelir.
☑ Mini Check
- •Tüm tesislerde aynı KPI tanımı var mı?
- •Hotel_code her tabloda zorunlu mu?
- •Yönetim raporu ile otel raporu ayrılmış mı?
Ne yapmalıyım?
- • Multi-property için dim_hotel’i zorunlu hale getir
- • Grup dashboard’ında 12 KPI ile sınırlı executive sayfa kur
- • Otel bazlı drill-down’u ayrı sayfalarda yönet
6. Fact & Dimension Modeli: Otel Veri Ambarı Örnek Şeması
| Tablo | Tür | Amaç | Örnek ana alanlar |
|---|---|---|---|
| fact_stays | Fact | PMS satış gerçekliği | stay_date, hotel_code, channel_id, room_nights, revenue_net |
| fact_ga4_events | Fact | Web davranışı | event_date, event_name, source_medium, conversion_value |
| fact_calls | Fact | İletişim performansı | date_time, hotel_code, language, answered, outcome |
| dim_hotel | Dimension | Tesis sözlüğü | hotel_code, destination, brand |
| dim_channel | Dimension | Kanal sözlüğü | channel_id, channel_group, channel_name |
| dim_room_type | Dimension | Oda tipi sözlüğü | room_type_id, room_type_name |
7. Grup Oteller İçin BigQuery Veri Modeli Örnek Şemasını İndir — Veri Analizi & Raporlama
Grup Oteller İçin BigQuery Veri Modeli Örnek Şemasını İndir — Veri Analizi & Raporlama (v1.0)
Bu asset, çok otelli yapılarda PMS/OTA/GA4/Call Center verisini BigQuery’de tek bir fact/dimension modele oturtmak için hazır bir şema iskeleti sunar. Partitioning, clustering ve view katmanı önerileriyle Looker Studio panellerinin hızlı çalışmasını hedefler. KPI sözlüğünü standardize ederek dashboard üretimini ve onboarding sürecini hızlandırır.
Kim Kullanır?
Otel gruplarında BI/analitik ekipleri, ajans teknik ekipleri ve merkez ofis revenue/finans birimleri.
Nasıl Kullanılır?
- Şemayı dataset seviyesinde kur (raw → modeled → mart).
- Fact tabloları tarih ile partition et; hotel_code/channel için clustering uygula.
- Looker Studio’yu ham tablolar yerine view’lara bağla (daily_summary, channel_performance, property_drilldown).
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Template
- ▢ ✅ Dataset yapısı: `raw_` / `modeled_` / `mart_` : ________
- ▢ ✅ `dim_hotel` alanları: hotel_code, destination, brand, timezone : ________
- ▢ ✅ `dim_channel` alanları: channel_id, channel_group, channel_name : ________
- ▢ ✅ `fact_stays` partition alanı: ________ (örn. stay_date)
- ▢ ✅ `fact_ga4_events` partition alanı: ________ (örn. event_date)
- ▢ ✅ Clustering alanları: ________ (örn. hotel_code, channel_id)
- ▢ ✅ View listesi: daily_summary_view / channel_performance_view / property_drilldown_view : ________
- ▢ ✅ Her fact tabloda `hotel_code` zorunlu (multi-property ölçeği için).
- ▢ ✅ Tarih partition’ı olmadan büyük tablo açma (maliyet artar).
- ▢ ✅ Kanal sözlüğünü tekleştir (OTA/WEB/CALL_CENTER).
- ▢ ✅ Looker Studio’da hesapları çoğaltma; KPI’ları view katmanında sabitle.
- ▢ ✅ Yetkilendirmeyi dataset seviyesinde planla (role-based access).
- ▢ ✅ `mart.daily_summary_view`: hotel_code + date + occupancy + revenue_net + revpar
- ▢ ✅ `mart.channel_performance_view`: date + channel_group + revenue_net + commission_cost (Varsayım)
- ▢ ✅ raw/modeled/mart katmanları ayrıldı
- ▢ ✅ fact tablolar partition edildi
- ▢ ✅ hotel_code ve channel sözlüğü tutarlı
- ▢ ✅ 3 temel view oluşturuldu
- ▢ ✅ Looker Studio view’dan besleniyor
- ▢ ✅ Fact/dimension şeması (v1.0)
- ▢ ✅ 3 temel view seti
- ▢ ✅ Yetki ve maliyet kontrol notları
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
Çok otelli yapılarda veri ambarı kurup dashboard’ları hızlandırmak isteyenler için