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. Bu yüzden SEM stratejisi içinde rezervasyon ölçümleme katmanında domain geçişinin korunması kritik hale gelir.

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. Cross-domain takibe başlamadan önce GA4 ve Tag Manager ile otel dönüşüm takibi mantığının net olması gerekir.

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: pazarlama tarafında oturumun korunması, operasyon tarafında ise rezervasyon yönetiminde dönüşüm adımları ile tamamlanan booking bilgisinin doğru okunması.

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. Bunun için otel booking engine ölçümleme altyapısı web geliştirme ve entegrasyon tarafıyla birlikte ele alınmalıdır.

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. Burada rezervasyon motoru için data layer tasarımı kritik hale gelir.

Ö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 çekirdek veri seti, booking engine gelir ölçümü tarafında GA4 ve Google Ads doğrulamasının başlangıcıdır.

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. Bu parametrelerin operasyon tarafındaki kayıtla eşleşmesi için PMS entegrasyonu ile rezervasyon verisini doğrulamak da önemlidir.

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).

Bu yapıyı sahada netleştirmek için oteller için dönüşüm takibi ve Tag Manager kurulumu sayfasına geçebilir, karar öncesinde dönüşüm takibi ve Tag Manager hakkında sık sorulan sorular bölümünü inceleyebilirsiniz.