Otel Rezervasyonları GA4 ile Nasıl Ölçülür?

Otel rezervasyonları GA4'te, misafirin siteden rezervasyon motoruna ve ödeme sayfasına kadar tek bir oturum olarak izlenmesi ve onaylı rezervasyonun tekil kimlik, değer ve para birimiyle kaydedilmesiyle ölçülür. Doğru kurulumda dört parça birlikte çalışır. Site ile harici motor arasında alanlar arası ölçüm, tarih aramasından ödemeye kadar ayrı tanımlanmış olaylar, rezervasyon kimliğini işlem kimliği olarak kullanan tek bir satın alma olayı ve iptalleri ayıran bir PMS mutabakatı. GA4 rezervasyonun nereden geldiğini gösterir, konaklamanın gerçekleşip gerçekleşmediğini ise PMS söyler.

Akdeniz kıyısındaki 96 odalı bir otelde çalışmaya başladığımda aynı misafir dört sistemde dört ayrı hikayeydi. Reklam paneli dönüşüm, motor onay, PMS konaklama, muhasebe gerçekleşen gelir gösteriyordu. Bazı raporlar aynı oda rezervasyonunu iki kez sayıyor, harici motora geçişte reklam izi kayboluyordu. Doğrudan rezervasyonların yüzde 25,9'u iptal edildiği halde panelde başarılı dönüşüm olarak duruyordu. İlk ay tek bir yeni kampanya açmadım, önce ölçümü yeniden kurdum. Bu yazıda o kurulumun olay sözlüğünü, alan listesini ve test planını paylaşıyorum.

Otel sitesinde rezervasyon ölçümü neden zor?

Bir online mağazada satın alma ile gelir aynı anda oluşur. Otelde ise misafir bugün rezervasyon yapar, aylar sonra konaklar ve arada iptal edebilir. Buna otel sitelerinin teknik yapısı eklenince ölçüm beş noktada kırılır.

• Harici rezervasyon motoru. Motor çoğu zaman başka bir alan adında çalışır. Ayar yapılmazsa misafir motora geçtiği anda yeni bir oturum başlar ve reklam kaynağı kaybolur.
• Ödeme sağlayıcısı. Kart doğrulama sayfasından dönen misafir, ödeme sağlayıcısından gelmiş gibi kaydedilebilir. Satış doğru kaynağa yazılmaz.
• Rezervasyon ile konaklama arasındaki süre. Bugün alınan rezervasyon yaz aylarının gelirine aittir. İki tarih karışırsa hem raporlar hem bütçe kararları bozulur.
• Telefon ve WhatsApp. Misafirlerin bir kısmı kararını motorda değil, bir konuşmada verir. Bu satışlar sitede iz bırakmaz.
• Çift sayım. Motorun kendi entegrasyonu ile sitenin etiketi aynı rezervasyonu ayrı ayrı gönderebilir. Teşekkür sayfasının yenilenmesi de ikinci bir satış yaratabilir.

Bu kırılmalar giderilmeden kampanya değiştirmek, aynı hatayı daha iyi bir algoritmayla büyütmek demektir. Reklamların neden rezervasyon getirmediğini teşhis ederken ölçüm halkasına da bu yüzden ilk sırada bakıyorum. Teşhis tablosunun tamamı otel reklamlarının neden rezervasyon getirmediğini anlattığım yazıda.

Site ile rezervasyon motoru ölçümü nasıl birleşir?

Yöntem, motorun nasıl çalıştığına bağlıdır. Kurulumdan önce motor sağlayıcısına hangi yapıyı kullandığını ve kendi GA4 etiketinize izin verip vermediğini sorun.

Motor ayrı alan adındaysa alanlar arası ölçüm GA4'ün yönetici bölümünde, veri akışının etiket ayarlarında iki alan adı tanımlanarak açılır. Siteden motora giden bağlantıya otomatik bir parametre eklenir ve oturum kopmaz. Ödeme sağlayıcısının alan adı ise aynı bölümdeki istenmeyen yönlendirmeler listesine yazılır. Böylece kart doğrulamasından dönen misafir yeni bir kaynaktan gelmiş gibi görünmez. Sözlükte bunun karşılığı referral exclusion.

Vakadaki otelde sağlayıcının desteklediği alanlar arası ölçüm yöntemini, aynı GA4 veri akışını ve yönlendirmelerde bağlantı bilgisinin korunmasını tek tek test ederek kurduk. Kaynağı bilinmeyen satışı tahminle bir kampanyaya yazmadık.

Olay sözlüğünde hangi olaylar olmalı?

Olay sözlüğü, misafirin her adımının hangi isimle, hangi alanlarla ve hangi amaçla kaydedileceğini yazan kısa bir belgedir. Pazarlama ekibi, motor sağlayıcısı ve geliştirici aynı belgeye bakar. Benim otellerde kullandığım temel liste şu.

Olay adlarını GA4'ün önerdiği satış olaylarıyla uyumlu tutmak, raporların hazır gelmesini sağlar. Özel alanlar için GA4'te olay parametresi tanımlanır. Hangi olayın hedef sayılacağı ise ayrı bir karardır. Ben otellerde yalnızca onaylı rezervasyonu önemli etkinlik olarak işaretliyorum. Ara adımlar hunideki kaybı görmek içindir, teklif algoritmasına hedef olarak verilmez. GA4 satış olaylarının genel yapısını GA4 ecommerce eventleri yazısında anlattım.

Müsait oda bulunamaması olayı çoğu kurulumda unutulur, oysa otel için en değerli raporlardan biridir. Hangi tarihlerde, hangi gece sayısında ve hangi pazardan gelen misafirin boş elle döndüğünü gösterir. Reklamın tanıttığı tarihte oda yoksa sorun reklamda değil, takvimdedir.

Rezervasyon olayında hangi alanlar bulunmalı?

Satın alma olayı otelin en önemli verisidir ve her alanı bir karar besler. Eksik ya da yanlış bir alan, aylar sonra bütçe kararında hata olarak geri döner.

Vakadaki otelde ön ödeme tutarı, rezervasyonun beklenen brüt değeri ve gerçekleşen oda geliri ayrı alanlarda tutuldu. Kapora hiçbir raporda toplam konaklama değeri gibi gösterilmedi. Grup ya da çok odalı rezervasyonlarda her oda rezervasyonu kendi kimliğiyle işlendi, çünkü iptal ve tarih değişikliği çoğu zaman tek oda için yapılır.

Çift sayım nasıl önlenir?

Aynı rezervasyonun iki kez sayılması, otel hesaplarında gördüğüm en yaygın ve en pahalı hatadır. Panel olduğundan iyi görünür, algoritma olmayan bir başarıyı büyütmeye çalışır. Dört kaynağı kontrol ediyorum.

1. Teşekkür sayfasının yenilenmesi. Misafir onay sayfasını yenilediğinde ya da geri dönüp tekrar açtığında ikinci bir satın alma oluşmamalı. İşlem kimliğinin her seferinde gönderilmesi ve etiketin yalnızca ilk onayda tetiklenmesi gerekir.
2. İki ayrı kurulum. Motorun hazır GA4 entegrasyonu açıkken siteye ikinci bir satın alma etiketi eklenmişse aynı rezervasyon iki kez gelir. Hangisinin kalacağına karar verilir.
3. Google Ads'te iki birincil dönüşüm. Google Ads etiketi ile GA4'ten içe aktarılan satın alma aynı anda birincil hedefse kampanya her rezervasyonu iki kez sayar.
4. Meta'da tarayıcı ve sunucu bildirimi. İkisi birlikte kullanılıyorsa aynı satın alma aynı olay kimliğiyle gönderilmeli. Vakadaki otelde böyle tekilleştirildi. Kurulumun ayrıntısı Meta Conversions API kurulumu yazısında.

Her gün motorun onay sayısı, GA4'teki satın alma sayısı ve Google Ads dönüşüm sayısı yan yana yazılıyor. Rakamların birebir tutması beklenmez, ama farkın nedeni bilinmelidir. Açıklanamayan fark, ölçümün bir yerde kırıldığını gösterir.

Telefon ve WhatsApp talepleri nasıl takip edilir?

Telefon ya da WhatsApp tıklaması bir rezervasyon değildir, bir iletişim niyetidir. Bu tıklamayı satın alma hedefi yaparsanız algoritma tıklayan kişiyi bulmayı öğrenir, konaklayan misafiri değil. Vakadaki otelde tıklama hiçbir zaman satın alma hedefi yapılmadı. Görüşme ve onaylı rezervasyon satış ekibinin CRM kaydına, konaklama PMS kaydına bağlandı.

Akış şöyle kuruldu. Talebin kaynağı ilk temasta kaydedildi, CRM'deki satış fırsatı PMS'deki rezervasyonla kimlik üzerinden eşleşti ve konaklamanın gerçekleşip gerçekleşmediği takip edildi. Otelde PMS ve motor Cloudbeds'teydi, satış ekibinin talep akışı HubSpot'ta yönetildi ve ikisi n8n ile bağlandı. Yılın sonunda 2.200 tekil talepten 396 gerçekleşen oda rezervasyonu çıktı. Bu 396 rezervasyon 1.410 doğrudan rezervasyonun insan destekli kısmıydı ve online rezervasyonlara ikinci kez eklenmedi.

Mesajdan rezervasyona giden yolu, ilk yanıt süresini ve teklif akışını otellerde WhatsApp taleplerinin rezervasyona dönüştürülmesi konusunda ayrıca ele alıyorum.

İptaller ve gerçekleşen konaklama nasıl kontrol edilir?

GA4 rezervasyonun alındığı anı ölçer. Konaklamanın tamamlandığını ise yalnızca PMS bilir. Bu yüzden iptali iki yerde işliyorum. GA4'te iptal edilen rezervasyon için aynı işlem kimliğiyle bir iade olayı gönderiliyor. Google Ads'te iptal ve kısmi iadeler desteklenen süre içinde dönüşüm düzeltmesiyle geri bildiriliyor.

Ama hiçbir reklam platformunun, aylar sonra gerçekleşen konaklamayı eksiksiz yazacağını varsaymıyorum. Platformun eşleme süresinin dışında kalan sonuç PMS raporunda korunuyor ve bütçe kararları o tabloya göre veriliyor. Vakadaki otelde iptal oranı yüzde 25,9'dan yüzde 16,8'e indi, ama bu düşüşü görebilmemizin tek nedeni iptalin ayrı bir olay olarak ölçülmesiydi. Konunun bütün ayrıntısını iptal edilen rezervasyonların reklam sonuçlarına etkisi yazısında anlattım. Reklam paneli ile GA4'ün neden farklı rakam gösterdiğini de reklam paneli ve GA4 farkı yazısında açıkladım.

Atıf kuralı nasıl yazılmalı?

Ölçüm kurulduktan sonra bir rezervasyonun hangi kanala yazılacağı açıkça yazılmalı. Aksi halde her platform aynı satışı kendi başarısı olarak raporlar ve toplam, gerçek gelirden büyük çıkar.

Vakadaki otelde kural şuydu. PMS ile eşleşmiş, gerçekleşmiş her oda rezervasyonu, 30 gün içindeki son uygun ücretli tıklamaya atandı. Bir rezervasyon yalnızca bir kanala gitti. Görüntülemeye dayalı katkı ve platformların kendi atıf modelleri bu tablonun üstüne eklenmedi. Sonuçta 1.410 doğrudan rezervasyonun 840'ı ücretli kanallara yazıldı. Kalan 570 rezervasyonun hepsi SEO'ya da yazılmadı. Organik arama, Google ücretsiz rezervasyon bağlantıları, CRM, tavsiye ve kaynağı bilinmeyen kayıtlar ayrı tutuldu.

Bu kural tek doğru kural değil, ama yazılı ve tutarlı olması şart. Son tıklama modelinin neyi gösterip neyi göstermediğini atıf hataları yazısında tartıştım.

İzin ve kişisel veri nasıl yönetilir?

Otel sitesine Avrupa'dan gelen misafir, çerez izni konusunda Türkiye'deki misafirden farklı kurallara tabidir. İzin bandı, Consent Mode v2 ayarı ve sunucu tarafındaki bildirimler bu kurallara göre kurulmalı. Vakadaki otelde kampanya izleri izin sınırları içinde sunucu kaydına bağlandı. Analytics'e misafirin adı, iletişim bilgileri ya da serbest metin gönderilmedi. Hangi verinin hangi hukuki dayanakla işleneceği hukuk danışmanınızla birlikte verilecek bir karardır. Benim işim ölçümün bu sınırlar içinde çalışmasını sağlamak.

Kurulum nasıl test edilir?

Ölçüm kurulumu, test edilmeden bitmiş sayılmaz. Her otelde aşağıdaki planı uyguluyorum. Test rezervasyonları PMS'de iptal ediliyor ve raporlardan ayrılıyor.

Satın alma olayının testine dair genel kontrolleri purchase event testi yazısında topladım. Otelde fark, testin mutlaka mobilde, yabancı dilde ve dövizle de yapılmasıdır.

Otel ölçümünde en sık hangi hatalar yapılıyor?

• Kaporayı rezervasyon değeri saymak. Getiri olduğundan düşük, bazen de tamamen yanlış görünür.
• Telefon tıklamasını satın alma hedefi yapmak. Algoritma tıklayanı bulur, konaklayanı değil.
• Rezervasyon tarihi ile konaklama tarihini karıştırmak. Gelecek yazın rezervasyonu bugünün cirosu gibi görünür.
• İptalleri hiç işlememek. Panelde başarılı duran rezervasyonların bir kısmı hiç konaklamaz.
• Kaynağı bilinmeyen satışı bir kampanyaya dağıtmak. Tahmin, ölçüm gibi raporlanır.
• Kurulumu bir kez yapıp bırakmak. Motor güncellemesi ya da yeni ödeme sağlayıcısı ölçümü sessizce bozar.

Ben bu işi nasıl kuruyorum?

Bir otelde ölçüme kampanyadan önce başlıyorum. İlk hafta PMS'deki son 12 ayı oda tipi, kanal, kalış süresi, pazar, iptal ve rezervasyon öncesi süreyle eşliyor, motor ve ödeme sağlayıcısındaki kaynak kaybını test ediyorum. Ardından olay sözlüğünü yazıyor, motor sağlayıcısıyla birlikte kuruyor ve yukarıdaki test planını uyguluyorum. Ölçüm ancak günlük mutabakat temiz çıktığında kampanyalara hedef olarak bağlanıyor.

Ölçüm oturduktan sonra her rezervasyonun gerçek maliyeti hesaplanabilir hale gelir. Bu hesabı otellerde rezervasyon başına pazarlama maliyeti yazısında, kampanyaya nasıl bağlandığını otel Google Ads kampanyası ve Google Hotel Ads yazılarında anlattım. Ölçülen kaybın sitede nasıl kapatıldığını otel web sitesinde rezervasyon dönüşümü yazısında bulabilirsiniz. Bütün sistemin bir otelde nasıl çalıştığı otel dijital pazarlama vaka analizinde, çerçevesi otel pazarlaması rehberinde. Ölçümünüzü birlikte kurmak isterseniz otel dijital pazarlama ve reklam yönetimi sayfasından ücretsiz rezervasyon analizi isteyebilirsiniz.

Sık sorulan sorular

GA4 otel rezervasyonlarını tek başına doğru ölçer mi?

Rezervasyonun nereden geldiğini ölçer, ama gerçekleşen geliri tek başına ölçemez. Misafir aylar sonra konaklar ya da iptal eder. Bu bilgi PMS'tedir. Doğru kurulumda GA4 kaynağı ve misafirin yolunu, PMS ise konaklamayı ve net geliri gösterir. İkisi rezervasyon kimliğiyle eşleşir.

Harici rezervasyon motorunda GA4 nasıl çalışır?

Motor kendi GA4 etiketinize izin veriyorsa aynı ölçüm kimliği ve alanlar arası ölçüm ayarıyla site ve motor tek oturumda birleşir. Motor yalnızca kendi entegrasyonunu sunuyorsa sağlayıcının hangi olayları hangi alanlarla gönderdiği kontrol edilir. Her iki durumda da ödeme sağlayıcısının alan adı istenmeyen yönlendirmelere eklenmelidir.

Rezervasyon değeri olarak hangi tutar gönderilmeli?

Rezervasyonun beklenen oda geliri, kapora ya da ön ödeme değil. Değerin vergi dahil mi hariç mi olduğuna bir kez karar verilip her yerde aynı tanım kullanılmalı. Ek hizmet geliri ayrı tutulursa oda satışının performansı daha net okunur.

İptal edilen rezervasyon GA4'ten silinir mi?

Silinmez. Aynı işlem kimliğiyle gönderilen iade olayı, gelir raporunda iptali düşer. Google Ads tarafında dönüşüm düzeltmesi ayrıca gönderilir. Net konaklama gelirinin ana kaynağı yine PMS raporu olmalı.

Telefonla gelen rezervasyonlar GA4'te görünür mü?

Kendiliğinden görünmez. Telefon tıklaması GA4'te iletişim niyeti olarak kaydedilir. Görüşmenin rezervasyona dönüşüp dönüşmediği CRM'de, konaklamanın gerçekleşip gerçekleşmediği PMS'te izlenir. Bu kayıtlar kaynakla birlikte tutulursa telefon satışları da reklama bağlanabilir.