Otel Rezervasyon Motoru İçin Cross-Domain Takip ve Thank You Event Kurulumu

Kısa cevap : Cross-domain takip; kullanıcı bir domainden diğerine geçtiğinde (ör. otelsite.com → bookingengine.com) aynı kullanıcı/oturumun tek yolculuk gibi izlenmesini sağlar. Otellerde rezervasyon motoru ayrı domaindeyse, cross-domain olmadan dönüşüm genellikle “yanlış kaynak” ile raporlanır ve self-referral sorunları oluşur.

Otel dünyasında bu ihtiyaç çok yaygındır çünkü rezervasyon motorları: • ayrı bir domain (tamamen farklı) üzerinde olabilir, • ya da bir subdomain üzerinde çalışabilir (booking.site.com gibi), • bazen ise üçüncü taraf bir sağlayıcıya aittir.

GA4 tarafında amaç şudur: kullanıcı ana siteden rezervasyon motoruna geçerken Client ID / oturum bağlamı korunmalı; aksi halde GA4 bunu “yeni bir oturum” gibi görür ve attribution kayar. Google’ın GA4 cross-domain yaklaşımında önerilen yol, yapılandırmayı mümkün olduğunca Analytics arayüzü (Admin) üzerinden yapmak ve domainleri listelemektir.

Otellerde cross-domain yoksa tipik 4 belirti

1. Referral/self-referral artışı: booking engine domain’i “referral” kaynak gibi görünür.
2. Direct/Other şişmesi: dönüşüm direct gibi raporlanır (kanal kredisi kayar).
3. Dönüşüm yolu kopukluğu: kullanıcı ana site kampanyasından gelir ama dönüşüm başka kaynakta görünür.
4. Ads optimizasyon hatası: dönüşümler yanlış kampanyaya yazıldığı için teklif stratejileri bozulur.

“Referral Exclusion yeter mi, cross-domain şart mı?”

Kısa mantık: • Referral exclusion, belirli domainlerden gelen trafiği “direct”e iter (bazı sorunları maskeler). • Cross-domain ise kullanıcı yolculuğunu doğru şekilde birleştirmeyi hedefler. Otel rezervasyon motoru senaryolarında genellikle cross-domain + doğru hariç tutmalar + test birlikte düşünülür. (Not: GA4’te arayüz ve isimler zamanla değişebilir; prensip aynı kalır.)

Otel tarafında iki sistem vardır: • Pazarlama sitesi: oda/konsept içerikleri, kampanyalar, SEO landing’ler, CTA’lar • Rezervasyon motoru (booking engine): tarih/oda/kişi seçimi, fiyat, ödeme ve onay

Çoğu ekip “web sitesi GA4 kurulu, tamam” der; oysa rezervasyon motoru farklı bir domaindeyse asıl değerli event (purchase/booking_complete) o tarafta gerçekleşir. Bu yüzden ölçüm tasarımını iki parçaya ayırmak gerekir:

Senaryo haritası (pratik)

• •Senaryo A — Aynı domain: • En kolay kurulum: thank you sayfası + GA4 purchase/event
• •Senaryo B — Subdomain: • Çoğu zaman cookie/domain ayarları daha yönetilebilir; yine de test şart
• •Senaryo C — Farklı domain (en yaygın kritik): • Cross-domain + linker mantığı + doğru hariç tutma + event tetikleme entegrasyonu

Developer + Pazarlama ortak dili (köprü)

Bu konu genelde iki ekip arasında “boşluk” oluşturur: • Pazarlama ekibi “Ads dönüşüm yok” der. • Dev ekip “tag var çalışıyor” der. • Sorun: oturum bütünlüğü + sinyal doğruluğu. Bu rehberin amacı da tam olarak bu boşluğu kapatmak: hem teknik hem pazarlama ekibi aynı akışa bakabilsin.

Kısa cevap : GA4 cross-domain ölçümü için, birlikte ölçmek istediğiniz domainlerde aynı GA4 tag ID (G-… aynı web stream) çalışmalı ve GA4 Admin’de cross-domain domain listesi tanımlanmalıdır.

GA4 tarafında cross-domain’in “çekirdeği” şudur: ana site ve rezervasyon motoru aynı property/web stream ile ölçülür ve GA4, domainler arası geçişi ilişkilendirir. Google’ın dokümantasyonunda da vurgulanan kritik nokta: cross-domain kapsamına alacağınız domainlerdeki tag’lerin aynı tag ID’yi kullanmasıdır.

Kurulum mantığı (arayüz değişebilir, prensip sabit)

Genel akış: 1. GA4 property → Data streams (Web) → ilgili stream 2. Tag/measurement ayarları içinde cross-domain bölümünde domainleri ekleme 3. Domain listesi: ana site + booking engine domain’i (ve gerekiyorsa ödeme adımı) 4. Kurulum sonrası test: geçişte attribution kopuyor mu?

Not: GA4’te “up to 100 conditions” gibi limitler ve ayar detayları olabilir; büyük portföylerde kural sayısını yönetmek gerekebilir.

Subdomain için her zaman cross-domain gerekir mi?

Genel prensip: subdomain’ler bazen aynı cookie domain yapısıyla daha kolay ölçülür; ama otel rezervasyon motoru “teknik olarak” ayrı bir uygulama olduğunda yine de self-referral benzeri davranışlar görülebilir. Burada doğru karar, “teoride gerekmez” değil, test sonucuna göre gerek var/yok demektir.

Linker mantığı (neden URL’ye parametre eklenir?)

Cross-domain çalıştığında bazı senaryolarda URL’lerde _gl gibi parametreler görebilirsiniz. Bu, domainler arası kimlik bilgisinin taşınmasına yardımcı olan “linker” mekanizmasının bir parçasıdır. Google Tag Platform dokümantasyonu, GA4 kullanıcılarının çoğunlukla yapılandırmayı Admin üzerinden yapmasını önerirken, cross-domain’in temelinde bu linker yaklaşımının olduğunu da açıklar.

Teknik not (kritik)

Sheet’teki teknik notla uyumlu şekilde: yanlış cross-domain kurulumu direct/other trafik şişmesine ve attribution sapmasına yol açabilir—bu yüzden test süreci “opsiyonel” değil, zorunludur.

Bu bölüm, pratikte iki yöntemle ilerler:

Yöntem 1 — Thank you sayfası (page_view tabanlı) tetikleme

Eğer rezervasyon tamamlandığında kullanıcı belirli bir URL’ye düşüyorsa (ör. /confirmation veya /thank-you), GTM’de şu mantık çalışır: • Trigger: Page View (URL contains / equals …) • Tag: GA4 Event (ör. booking_complete veya GA4 recommended purchase) GTM’de GA4 event tag’leri ve tetikleyici seçimi, Tag Manager’ın resmi yardım akışına uygun şekilde yapılır: GA4 Event tag → Triggering alanı → uygun trigger seçimi → test (Preview) → GA4 DebugView kontrolü.

Avantaj: Basit, hızlı, çoğu tesiste yeterli. Risk: Thank you URL değişirse ölçüm kırılır; ayrıca bazı motorlar SPA/AJAX akış kullanabilir.

Yöntem 2 — Event tabanlı tetikleme (dataLayer / custom event)

Thank you sayfası yoksa veya sayfa değişmeden “modal/step” ile tamamlanıyorsa, daha sağlıklı yöntem: • Rezervasyon motoru “tamamlandı” anında dataLayer.push({ event: "booking_complete", ... }) gönderir • GTM: Custom Event trigger (booking_complete) • GA4 Event tag: parametrelerle birlikte gönderilir Bu yöntem, gelir (value/currency), transaction_id gibi verilerin taşınması için de daha uygundur.

Örnek dataLayer şablonu (otel rezervasyon odaklı)

Aşağıdaki örnek “şablondur”; alan isimleri rezervasyon motorunuza göre uyarlanır: window.dataLayer = window.dataLayer || []; window.dataLayer.push({ event: "booking_complete", transaction_id: "RZV-123456", value: 1250.00, currency: "TRY", nights: 4, adults: 2, children: 0, room_type: "Deluxe Sea View", rate_plan: "Early Booking", booking_engine_domain: "booking.example.com" }); Neden bu alanlar? • GA4 gelir raporlaması için çoğu senaryoda transaction_id + value + currency gibi temel parametreler kritik kabul edilir. • Ek alanlar (nights, room_type, rate_plan) pazarlama analizi için güçlü segmentler üretir; ama önce “temel doğruluk” sağlanmalıdır.

Test (en kritik adım)

Kurulumdan sonra 3 aşama test yapmadan canlıya geçmeyin: 1. GTM Preview: Trigger çalıştı mı, tag ateşledi mi? 2. GA4 DebugView: Event GA4’e düştü mü? 3. Rapor testi: “booking_complete/purchase” event’i normal kullanıcı akışında doğru sayılıyor mu?

Kısa cevap : Geliri doğru raporlamak için event’inizde en azından transaction_id, value ve currency alanlarını taşıyın; bunlar eksikse GA4’te “revenue yok” veya eksik görünebilir.

Bu noktada iki yaklaşım var:

Yaklaşım A — GA4 recommended purchase event’i (e-ticaret mantığı)

GA4 e-ticaret ölçümünde purchase ve ilgili parametreler yaygın kullanılır. “Rezervasyon” da sonuçta bir “satın alma” gibi davranabildiği için, booking complete anında purchase event’i göndermek birçok otelde mantıklıdır. Minimum çekirdek: • transaction_id • value • currency

Yaklaşım B — booking_complete custom event + temel parametreler

Bazı ekipler otel özelinde isimlendirme ister: booking_complete. Bu da gayet olabilir; önemli olan tutarlı isim ve parametrelerin doğru taşınmasıdır.

Otel rezervasyonuna özel pratik parametre seti

Aşağıdaki tablo “kapsam + fayda” mantığıyla iyi bir başlangıçtır: Not: Event parametreleri ve raporlanabilirlik GA4’te “event parameters” mantığıyla yönetilir; hangi parametrenin raporda dimension/metric olacağı kurulumunuza bağlıdır.

Sık hata listesi (otel özelinde)

• •currency yok: value var ama revenue görünmez/eksik olur.
• •transaction_id yok: duplicate sayım riski artar.
• •İki kez ateşleme: thank you + event aynı anda çalışır, double booking olur.
• •Test yapılmaması: “çalışıyor” sanılır, rapor bozulur.

Competitor gap’i kapatan mini bölüm (fark yaratan)

Çoğu kaynak cross-domain’i teorik anlatır; otel ölçümünde asıl fark şu “mini çerçeve” ile gelir: Otel Rezervasyon Ölçüm Çerçevesi (3 katman): 1. Oturum bütünlüğü: cross-domain + linker mantığı doğru mu? 2. Sinyal doğruluğu: booking_complete tekil mi, doğru anda mı? 3. Değer doğruluğu: value/currency/transaction_id doğru mu? Bu üç katmandan biri bile eksikse, yönetim raporları sapar ve Ads optimizasyonu “yanlış hedef” üzerinde çalışır.

1. Domain haritası (ana site + booking engine + ödeme)
2. GA4 cross-domain domain listesi + doğrulama
3. Thank you sinyali seçimi (URL/event)
4. GTM tetik + GA4 event tag (Preview test)
5. Parametreler (transaction_id/value/currency)
6. DebugView + rapor doğrulama (kapanış)

Yanlış kurgulanmış cross-domain ve thank you event yapıları, gelir ve rezervasyon raporlarında ciddi sapmalara yol açabilir. Bu yüzden hedefiniz “bir event görmek” değil; doğru oturumu doğru değerle ölçmektir (ve bunu testle kanıtlamaktır).