1. DataLayer nedir, oteller için neden önemlidir?
Kısa cevap : DataLayer, sayfa yüklenirken ve kullanıcı aksiyonları gerçekleşirken (ör. booking_start, booking_complete) “ölçüm için gereken bilgileri” standart formatta toplayan veri katmanıdır. Oteller için önemlidir çünkü oda tipi, gece sayısı, check-in/out, fiyat ve para birimi gibi rezervasyon detayları çoğu zaman farklı sistemlerde üretilir; dataLayer bu bilgileri GA4/GTM ve reklam platformlarına tutarlı taşır.
Otellerde dataLayer’in kritik olmasının 3 temel nedeni var:
- Rezervasyon motoru gerçekliği: “Satın alma” e-ticaret gibi tek ürün değildir; oda, tarih, misafir sayısı, rate plan gibi alanlar gerekir.
- Çok kanallı kapanış: Web rezervasyonu + call center + WhatsApp kapanışı; hepsinde ortak bir “sözlük” ihtiyacı doğar.
- Sürdürülebilirlik: Bugün GA4’e gönderdiğiniz alanı yarın Meta CAPI, CRM veya BI’da da kullanmak isteyebilirsiniz.
DataLayer olmayan bir projede tipik sonuç
- •Event isimleri çoğalır (her ekip kendi adını uydurur).
- •“Gelir” bir yerde TRY, bir yerde EUR görünür.
- •Oda tipi raporlanamaz; sadece “purchase var/yok” kalır.
- •Yeni bir platform eklendiğinde her şey yeniden kodlanır.
Mini Check
- • Ölçmek istediğin şey sadece “rezervasyon sayısı” mı, yoksa “oda/tarih/gelir detayı” da var mı?
- • Rezervasyon motoru ayrı bir sistem mi?
- • Pazarlama ve dev ekibin aynı event/alan sözlüğü var mı?
- • Yeni kanal eklendiğinde (yeni Ads platformu/BI) aynı alanları reuse edebiliyor musun?
Ne yapmalıyım?
- • 1. DataLayer’i “ölçüm sözlüğü” olarak ele al; sadece GTM için değil.
- • 2. Alanları minimum ama işlevsel seç (oda, tarih, misafir, fiyat).
- • 3. Event-bazlı akışa geç (page_load + event_push).
- • 4. Sözlüğü dokümante etmeden kurulum sprint’ine başlama.
2. Otel sitelerinde hangi bilgiler dataLayer’e taşınmalı?
Buradaki kural “her şeyi dataLayer’e koy” değil; raporda karar verdiren alanları standartlaştırmaktır. Otel sitelerinde en çok değer üreten alanlar genelde 4 grupta toplanır:
1) Sayfa/bağlam alanları (context)
- •page_type (home/room/offer/blog/booking)
- •language (tr/en/de/ru)
- •market (opsiyonel: TR/UK/DE gibi)
- •campaign_code (varsa, site içi kampanya kodu)
2) Oda ve ürün alanları (room/product)
- •room_name (ör. Deluxe Sea View)
- •room_code (ör. DSV-01)
- •rate_plan (ör. Early Booking)
- •board_type (opsiyonel: BB/HB/AI)
3) Tarih ve misafir alanları (stay/party)
- •checkin_date, checkout_date
- •nights
- •adults, children
- •rooms_count (çok odalı rezervasyonlarda kritik)
4) Fiyat ve para birimi (revenue)
- •value (toplam tutar)
- •currency (TRY/EUR/USD)
- •(opsiyonel) tax_included (true/false)
- •(opsiyonel) discount_code
Örnek (otel pazarlama senaryosu)
- •“Aile odası” sayfası yüksek trafik alıyor ama booking_start düşük.
Bu sorunun cevabı “sadece pageview” ile bulunmaz; room_type, nights, adults/children, value_range gibi alanlar, segment bazlı funnel analizi yapmanı sağlar.
Mini Check
- • Raporlarda oda tipi / gece sayısı / gelir kırılımına gerçekten ihtiyacın var mı?
- • Para birimi standardın net mi (tek raporlama currency)?
- • Çok dilli pazarlarda dil/market kırılımı gerekiyor mu?
- • Kampanya kodu gibi site içi işaretleyiciler var mı?
Ne yapmalıyım?
- • 1. Alanları 4 grupta topla (context/room/stay/revenue).
- • 2. Her alan için “kaynak sistem” yaz (web mi booking engine mi?).
- • 3. Currency ve value formatını tek standarda bağla.
- • 4. “Nice to have” alanları pilot sonrası ekle.
3. Rezervasyon motoru için zorunlu dataLayer alanları (tutar, para birimi, gece, oda tipi)
Kısa cevap : Rezervasyon motoru dataLayer’ında minimum zorunlu set: transaction_id (veya booking_id), value, currency, checkin_date, checkout_date, nights, room_type (veya room_code) ve adults/children alanlarıdır. Bu set olmadan booking ölçümü “genel” kalır ve optimizasyon/segment analiz zorlaşır.
Otel rezervasyonu e-ticaretten farklıdır: tek ürün + tek fiyat değil; tarih ve misafir kompozisyonu fiyatı belirler. Bu yüzden booking engine tarafında “tutar + tarih + oda” alanlarının standardı kritik.
Zorunlu alanlar (minimum “çalışan” paket)
- •event: booking_complete (veya purchase)
- •transaction_id / booking_id
- •value
- •currency
- •checkin_date, checkout_date
- •nights
- •room_type veya room_code
- •adults, children
- •(çok odalı) rooms_count
Çok odalı rezervasyonlarda yapı (kritik pratik)
Çok odalı rezervasyonlarda iki yaklaşım var:
- •Özet yaklaşım: tek value + rooms_count + “temsil oda tipi” (basit)
- •Detay yaklaşım: rooms array içinde her odanın room_code, rate_plan, room_value gibi alanları (ileri seviye)
Başlangıç için öneri: önce özet yaklaşımı doğru kur, sonra array yapısına geç. Çünkü yanlış detaylandırma, hem dev süresini uzatır hem de raporu kırabilir.
“Gelir” alanında sık yapılan 4 hata
- value string gelir (“1890,00”) → sayısal format bozulur
- currency yoktur → revenue raporu tutarsız olur
- tax/fees dahil mi değil mi belirsizdir
- booking_id yoktur → duplicate sayım yakalanamaz
Mini Check
- • booking_complete anında tekil bir transaction_id üretebiliyor musun?
- • value sayısal mı ve para birimi net mi?
- • check-in/out ve nights tutarlı mı?
- • Çok odalı rezervasyon senaryosu var mı?
Ne yapmalıyım?
- • 1. Minimum zorunlu alan setini kilitle (ID + value + currency + dates + room).
- • 2. Duplicate riskini booking_id ile yönet.
- • 3. Çok odalı yapıyı “özet → detay” şeklinde kademeli genişlet.
- • 4. Booking engine değişirse dataLayer sözlüğünü revize etmeyi planla.
4. Event bazlı dataLayer yapısı (page load vs event push)
Otel dataLayer tasarımında en sağlıklı mimari, iki katmanlıdır:
- Page load context: Sayfa yüklenirken sayfanın bağlamını set edersin (page_type, language, room_code varsa).
- Event push: Kullanıcı aksiyonu olduğunda (booking_start, booking_complete, click_whatsapp) event bazlı payload push edersin.
Bu ayrım, hem “her sayfada aynı veriyi taşımayı” engeller, hem de event’lerin tekil ve temiz olmasını sağlar.
Önerilen isim standardı (dev–marketing ortak dili)
- •Event isimleri: view_room_detail, booking_start, booking_complete, form_submit, click_to_call, click_whatsapp
- •Parametreler: room_code, rate_plan, nights, value, currency, placement, page_type
Not: TR isimlendirme de kullanılabilir (otel_rezervasyon_tamamlandi gibi). Önemli olan tek sözlük ve tutarlılıktır.
Örnek 1 — Sayfa yüklenirken context
window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: "page_context", page_type: "room", language: "tr", room_code: "DSV-01", room_name: "Deluxe Sea View" });
Örnek 2 — booking_start event push
window.dataLayer.push({ event: "booking_start", room_code: "DSV-01", rate_plan: "Early Booking", checkin_date: "2026-06-10", checkout_date: "2026-06-15", nights: 5, adults: 2, children: 1, currency: "EUR" });
Örnek 3 — booking_complete (purchase) event push
window.dataLayer.push({ event: "booking_complete", transaction_id: "RZV-845193", value: 1890.00, currency: "EUR", checkin_date: "2026-06-10", checkout_date: "2026-06-15", nights: 5, room_code: "DSV-01", room_name: "Deluxe Sea View", rate_plan: "Early Booking", adults: 2, children: 1, rooms_count: 1 });
Double-fire ve tekrar tetiklenme riskini azaltma
- •booking_complete event’ini tek bir noktadan üret (thank you + event aynı anda değil)
- •Aynı rezervasyon için aynı transaction_id ile tekrar push yapma
- •SPA/tek sayfa akış varsa “state” yönetimi ile tekilleştir
| Event | Amaç | Temel alanlar |
|---|---|---|
| page_context | Sayfa bağlamını kurmak | page_type, language, room_code, room_name |
| booking_start | Rezervasyon başlangıcını ölçmek | room_code, rate_plan, checkin_date, checkout_date, nights, adults, children, currency |
| booking_complete | Satın alma / rezervasyon tamamlanmasını ölçmek | transaction_id, value, currency, checkin_date, checkout_date, nights, room_code, room_name, rate_plan, adults, children, rooms_count |
Mini Check
- • Page context ile event payload ayrımı yapıldı mı?
- • booking_complete tek noktadan mı tetikleniyor?
- • transaction_id ile tekillik korunuyor mu?
- • SPA/booking engine akışında “tek sefer” kuralı var mı?
Ne yapmalıyım?
- • 1. page_context’te sadece bağlam taşı, event’te aksiyon taşı.
- • 2. booking_complete’i tekilleştir (ID + tek tetik).
- • 3. Event isim/parametre sözlüğünü dondur.
- • 4. Her büyük release sonrası mini QA yap (Preview/DebugView).
5. Geliştirici ve pazarlama ekipleri için ortak sözlük (alignment document)
DataLayer’ın “teknik doküman” olarak kalmaması gerekir. Pazarlama ekibi şu soruyu sorar: “Hangi alanla hangi raporu üreteceğiz?” Developer şu soruyu sorar: “Bu alanı nereden üreteceğim, hangi formatta?”
Bu yüzden ortak sözlükte her alan için şu kolonlar olmalı:
- •Field name (room_code)
- •Tanım (oda kodu)
- •Kaynak (CMS / booking engine / API)
- •Format (string/number/date)
- •Örnek değer (DSV-01)
- •Kullanım (GA4 dimension / Ads optimization / BI)
Rakip içeriklerdeki boşluğu kapatan “otel-özel” bölüm
Birçok kaynak dataLayer’i e-ticaret ürünleri üzerinden anlatır. Otelde ise kritik farklar şunlardır:
- •Tarih aralığı (check-in/out) fiyatı belirler
- •Nights + party composition (adults/children) segment için kritiktir
- •Room/rate plan değişkenliği yüksektir
- •Booking engine bağımsız bir uygulama olabilir
Bu yüzden otel dataLayer sözlüğü “room/stay/revenue” ekseninde kurulmalıdır.
Örnek otel dataLayer sözlüğü (mini)
- •room_code: string — “DSV-01” — oda segmenti
- •room_name: string — “Deluxe Sea View” — rapor okunabilirliği
- •rate_plan: string — “Early Booking” — kampanya/teklif
- •checkin_date: YYYY-MM-DD — “2026-06-10” — tarih analizi
- •nights: number — 5 — segment
- •value: number — 1890.00 — revenue
- •currency: string — “EUR” — revenue doğruluğu
- •campaign_code: string — “SUMMER26” — pazarlama atribüsyonu (varsa)
Mini Check
- • Her alanın “kaynağı” belli mi (web mi engine mi API mi)?
- • Formatlar standart mı (date/number/currency)?
- • Pazarlama ekibinin rapor ihtiyacı alanlara bağlandı mı?
- • Değişiklik yönetimi var mı (sözlük versiyonları)?
Ne yapmalıyım?
- • 1. “Field dictionary” dokümanını tek kaynak gerçek yap.
- • 2. Alanları minimal tut, sonra genişlet.
- • 3. Her alan için örnek değer ve format ver.
- • 4. Versiyonlama + change log ile sürdürülebilir kıl.
6. Uygulama, test ve bakım: dataLayer QA ritmi
Sheet’teki teknik not çok kritik: DataLayer yanlış tasarlanırsa ileride tüm ölçüm yapısını yeniden yazmanız gerekebilir. Bu yüzden kurulum sonrası “bitti” yaklaşımı yerine QA ritmi kurmak gerekir.
Test sırası (kısa ama etkili)
- Dev ortamında dataLayer push’larını konsolda kontrol et (event name + payload)
- GTM Preview’da custom event trigger doğru mu bak
- GA4 DebugView’da event + parametre geliyor mu doğrula
- Rapor/BI tarafında 1 hafta tutarlılık izle (özellikle revenue)
Sık bakım tetikleyicileri (ne zaman gözden geçirmeli?)
- •Rezervasyon motoru değişikliği / versiyon yükseltme
- •Para birimi/vergilendirme mantığı değişikliği
- •Çok dilli/pazar açılımı (market/language alanları)
- •Yeni kanal ekleme (yeni Ads platformu, server-side ölçüm, CRM entegrasyonu)
Mini Check
- • booking_complete revenue alanı doğru formatta mı?
- • transaction_id tekil ve tekrar etmiyor mu?
- • Değişikliklerde sözlük güncelleniyor mu?
- • QA testi release checklist’ine eklendi mi?
Ne yapmalıyım?
- • 1. DataLayer QA’yı release sürecine bağla.
- • 2. 1 haftalık revenue/currency tutarlılık kontrolü yap.
- • 3. Rezervasyon motoru değişince sözlüğü revize et.
- • 4. Şablon + sözlük + test kanıtını tek pakette sakla.
7. Otel DataLayer Alan & JSON Şablonunu İndir — SEM / DataLayer Mimarisi (v1.0)
Otel DataLayer Alan & JSON Şablonunu İndir — SEM / DataLayer Mimarisi (v1.0)
Bu şablon, otel web sitesi ve rezervasyon motoru için dataLayer sözlüğünü “tek kaynak gerçek” haline getirir: alan adı–tanım–kaynak–format–örnek–kullanım eşlemesini tek tabloda toplar. Ayrıca event-bazlı JSON payload’lar için hazır snippet alanları vererek, GA4/GTM ve reklam platformlarına güvenilir veri taşımayı hızlandırır.
Kim Kullanır?
Developer + pazarlama/performance + ajans (ortak çalışma dokümanı).
Nasıl Kullanılır?
- “Alan sözlüğü” tablosunu doldur (room/stay/revenue/context).
- Booking_start ve booking_complete JSON payload’larını gerçek sistem alanlarıyla eşleştir.
- Test planına göre dev→staging→prod doğrulaması yap; değişiklikleri change log’a işle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ 1) Field Dictionary (Alan Sözlüğü) – tablo şablonu
- ▢ ✅ 2) Event Sözlüğü – liste şablonu
- ▢ ✅ 3) JSON Snippet Şablonları
- ▢ ✅ A) page_context
- ▢ ✅ B) booking_start
- ▢ ✅ C) booking_complete
- ▢ ✅ 4) Nasıl doldurulur? (5 kural)
- ▢ ✅ 5) 1 kısa örnek (dolu)
- ▢ ✅ 6) Kontrol listesi
- ▢ ✅ 7) Deliverables
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
8. Kapanış – DataLayer “tek seferlik kod” değil, ölçüm mimarisidir
Bugün yalnız GA4’e hizmet eden bir dataLayer, yarın yeni kanal/araç geldiğinde yeniden yazdırır. Bu yüzden doğru yaklaşım; alan sözlüğünü kilitlemek, event-bazlı yapı kurmak ve QA ritmiyle sürdürülebilir kılmaktır.
Bir Sonraki Adım
DataLayer sözlüğünü ve booking engine ölçümünü sürdürülebilir kurmak isteyen ekipler için.