1. Neden veri isimlendirme standardı şart? (kök problem)
Raporlama projeleri genelde “ilk dashboard” ile güzel başlar, sonra bozulur. Çünkü yeni kaynak eklenir, yeni ekip gelir, farklı isimler oluşur: `channel`, `kanal`, `sales_channel`, `source_medium`… Bir süre sonra kimse “doğru alan hangisi?” sorusunu cevaplayamaz.
Örnek (Varsayım)
Standart isimlendirme kullanıldığında yeni dashboard yapım süresi ve yeni ekip onboarding süresi belirgin şekilde kısalır; standart yokken aynı alanın farklı isimlerle tekrar edilmesi hata riskini artırır.
☑ Mini Check:
- •Aynı kavram 2–3 farklı isimle mi geçiyor?
- •TR/EN karışık alan adları var mı?
- •Yeni biri raporu açınca “bu kolon ne?” diye soruyor mu?
Ne yapmalıyım?
- • 10–15 kritik alanı seç ve tek isimle kilitle
- • Data dictionary’yi başlat (kolon açıklaması)
- • Yeni kaynak eklenirken “standard check” koy
2. Otel raporlamasında veri isimlendirme neden kritik?
Çünkü Looker Studio’daki dashboard’lar “görünüm”, asıl kalite “veri katmanı”nda başlar. Naming convention; aynı iş kavramının (kanal, segment, oda tipi) her kaynakta aynı isimle temsil edilmesini sağlar ve dashboard’ların tutarlı kalmasına yardım eder. Data dictionary ise bu standardı ekip içinde okunabilir hale getirir.
☑ Mini Check:
- •“channel” alanı tüm kaynaklarda aynı şey mi?
- •“revenue” brüt mü net mi? tanımı var mı?
Ne yapmalıyım?
- • “Kavram sözlüğü” çıkar (kanal, gelir, rezervasyon)
- • Her kavram için tek isim + tek tanım yaz
- • Dashboard’ta bu tanımları görünür kıl
3. Looker Studio için naming convention nasıl hazırlanır?
Önce isimlendirme kurallarını belirleyin (snake_case, TR/EN tek dil, kısa ve anlamlı). Sonra kritik boyut ve metrikleri standardize edin (`channel`, `market_segment`, `room_type`, `hotel_code`, `location`). Ardından GA4, Ads, PMS, OTA alanlarını eşleştirip “canonical” alanlara dönüştürün. Son adımda data dictionary şablonunu doldurup governance (değişiklik onayı) kurun.
Boyut ve metrik isimleri için kurallar (pratik)
- •Boşluk yok: `room_type` (room type değil)
- •TR/EN karışım yok: tek dil seç (Varsayım: İngilizce tercih edilmiştir)
- •Kısaltma standardı: `adr`, `revpar`, `cpa`, `roas`
- •Aynı kavram tek isim: `channel` her yerde `channel`
- •Enum değerleri standardı: `OTA`, `WEB`, `CALL_CENTER` gibi (Varsayım: değer seti kilitlenir)
En kritik 12 canonical alan (otel için)
- •`hotel_code` (multi-property ise zorunlu)
- •`location` / `destination`
- •`date`, `week`, `month`
- •`channel`
- •`market_segment`
- •`country`
- •`language` (varsa)
- •`room_type`
- •`rate_plan` (varsa)
- •`booking_status` (confirmed/cancelled/no_show)
- •`revenue_gross`, `revenue_net` (Varsayım: ayrıştırılabiliyorsa)
☑ Mini Check:
- •Kanalların değer seti sabit mi?
- •Multi-otel yapıda hotel_code her tabloda var mı?
Ne yapmalıyım?
- • Canonical alan listesini kilitle
- • Enum değerlerini standardize et
- • Yeni kaynak eklenince bu listeye uyum zorunlu olsun
4. GA4, Ads, PMS ve OTA alanlarını uyumlu hale getirmek (eşleştirme yaklaşımı)
Bu bölüm, rakip içeriklerde genelde olmayan “eşleştirme matrisi” mantığını kurar. Amaç, her kaynağı olduğu gibi dashboard’a taşımak değil; ortak bir sözlüğe “normalize” etmektir.
GA4 → canonical (örnek)
- •GA4 `source/medium` → `channel` (mapping ile)
- •GA4 event’leri (`booking_start`, `booking_complete`) → `booking_status` veya dönüşüm KPI’ları
- •GA4 `country` → `country`
PMS/OTA → canonical (örnek)
- •PMS “kanal” → `channel`
- •PMS “oda tipi” → `room_type`
- •OTA “platform” → `channel` (OTA alt kırılımı ayrı alan olabilir: `ota_name`) (Varsayım)
☑ Mini Check:
- •GA4 channel grouping ile PMS kanal listesi uyuşuyor mu?
- •Oda tipi isimleri (Deluxe/Superior) tek sözlükte mi?
Ne yapmalıyım?
- • “Mapping tabloları” oluştur (channel_map, room_type_map)
- • Looker Studio’ya sadece canonical alanları göster
- • Kaynak alanları “raw” katmanda sakla
5. Naming convention örnekleri (iyi/kötü karşılaştırma)
İyi isim, hem teknik hem işletme için anlaşılırdır. Kötü isim, kısa vadede “çalışır” ama uzun vadede raporu çökertebilir.
Kötü örnekler (kaçın)
- •`Kanal Adı` (boşluk + TR/EN karışımı)
- •`channel2` (anlamsız)
- •`odaTipi` (camelCase + TR)
- •`Revenue` (net mi brüt mü belirsiz)
İyi örnekler
- •`channel` (enum: OTA/WEB/CALL_CENTER)
- •`room_type` (enum: STANDARD/DELUXE/SUITE)
- •`revenue_gross`, `revenue_net` (tanım net)
- •`market_segment` (ör: LEISURE/BUSINESS/GROUP)
☑ Mini Check:
- •Aynı alanın iki farklı versiyonu var mı (revenue vs revenue_net)?
- •TR/EN karışımı temizlendi mi?
Ne yapmalıyım?
- • Kötü alan adlarını “deprecated” olarak işaretle
- • Canonical isimlere yönlendir
- • 30 gün içinde eski alanları rapordan çıkar
6. Otellerde büyüyen raporlama yapıları için governance modeli (sürdürülebilirlik)
Naming convention tek seferlik doküman değil; bir süreçtir. Multi-property yapılarda (Antalya + Bodrum gibi) en kritik governance öğesi, `hotel_code` ve `location` standardıdır: yeni otel eklendiğinde raporlar bozulmamalı.
Basit governance (işleyen minimal model)
- •Sahip: data dictionary sahibi (ajans/analitik)
- •Onay: GM/revenue lideri (iş tanımları)
- •Değişiklik kuralı: yeni alan eklenirse dictionary güncellenmeden rapora girmez
- •Sürüm: v1.0 → v1.1 (değişiklik günlüğü)
Ne yapmalıyım?
- • Canonical alan listesini çıkar ve kilitle
- • Channel/room_type mapping tablolarını oluştur
- • TR/EN karışımını temizle, snake_case standardını uygula
- • Data dictionary’yi v1.0 yayınla
- • Yeni alan ekleme için onay/günlük süreci kur
7. Naming Convention Template (Otel): Alan, Tanım, Kaynak, Not
| Canonical alan | Tanım | Kaynak örneği | Not/standard |
|---|---|---|---|
| channel | Satış/edinim kanalı | GA4 source/medium, PMS kanal | Enum: OTA/WEB/CALL_CENTER |
| market_segment | Pazar segmenti | PMS segment, CRM | Enum: LEISURE/BUSINESS/GROUP |
| room_type | Oda tipi | PMS oda tipi | STANDARD/DELUXE/SUITE mapping |
| hotel_code | Otel kimliği | PMS/property | Multi-property için zorunlu |
| location | Destinasyon | PMS/CRM | Antalya/Bodrum gibi |
8. Otel Raporlama Data Dictionary Şablonunu İndir — Veri Analizi & Raporlama
Otel Raporlama Data Dictionary Şablonunu İndir — Veri Analizi & Raporlama (v1.0)
Bu şablon, otel raporlamasında GA4/Ads/PMS/OTA alanlarını tek bir canonical sözlükte toplamak için hazırlanmıştır. channel/market_segment/room_type gibi kritik alanları standardize eder, mapping tabloları ve tanımlarla ekip içi anlaşılabilirliği artırır. Yeni dashboard üretimini hızlandırır ve büyüyen raporlama yapılarında hata riskini düşürür.
Kim Kullanır?
Ajans analitik ekibi, otel revenue/pazarlama, çok otelli gruplarda merkez ofis raporlama ekipleri.
Nasıl Kullanılır?
- Canonical alan listesini seç ve şablona ekle.
- Her alan için tanım, kaynak ve enum/mapping değerlerini doldur.
- Yeni alan ekleme kuralını koy: dictionary güncellenmeden rapora girmez.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Template (data dictionary)
- ▢ ✅ Canonical alan adı: ________
- ▢ ✅ Tanım (1 cümle): ________
- ▢ ✅ Veri tipi (string/number/date): ________
- ▢ ✅ Kaynak sistem(ler): GA4 / Ads / PMS / OTA: ________
- ▢ ✅ Enum değerleri / mapping: ________
- ▢ ✅ Owner (sahip): ________
- ▢ ✅ Son güncelleme: ________
- ▢ ✅ Not: ________
- ▢ ✅ Boşluk yok, snake_case kullan.
- ▢ ✅ TR/EN karışımı yapma; tek dil seç.
- ▢ ✅ Enum değerlerini kilitle (OTA/WEB/CALL_CENTER).
- ▢ ✅ Brüt/net gelir gibi metriklerde tanımı net yaz.
- ▢ ✅ Her alan için owner ata ve değişiklik günlüğü tut.
- ▢ ✅ Canonical: `channel`
- ▢ ✅ Tanım: “Satış/edinim kanalı (OTA/Web/Call Center)”
- ▢ ✅ Mapping: GA4 source/medium → channel_map
- ▢ ✅ İlk 12 canonical alan tamam
- ▢ ✅ channel ve room_type mapping hazır
- ▢ ✅ hotel_code multi-property için her tabloda var
- ▢ ✅ Gelir metrikleri net/brüt ayrıldı
- ▢ ✅ Owner ve sürüm notu yazıldı
- ▢ ✅ Data dictionary v1.0
- ▢ ✅ channel_map ve room_type_map
- ▢ ✅ GA4–PMS–OTA eşleştirme matrisi
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
Bir Sonraki Adım
GA4/Ads/PMS/OTA alanlarını tek sözlükte toplayıp sürdürülebilir raporlama kurmak isteyen oteller için