Meta Conversion API ve Google Enhanced Conversions Oteller İçin Ne İfade Ediyor?

Server-side tracking, “etiket tarayıcıda çalışmazsa veri gitti” problemine alternatif bir kanal açar: event’lerinizin bir kısmını sunucu üzerinden platforma iletirsiniz. Bu, “mucize” değildir; fakat özellikle tarayıcı kaynaklı kayıpların arttığı ortamlarda sinyalin daha istikrarlı olmasına yardımcı olabilir.

Otel özelinde en sık görülen sorun kümeleri: • Rezervasyon motoru ayrı sistem: satın alma/rezervasyon onayı farklı bir alanda oluşur. • Lead akışı çok kanallı: form + telefon + WhatsApp + call center kapanışı. • Kısıtlı çerez/izin oranı: özellikle iOS/Safari yoğun pazarlarda sinyal zayıflar. • Attribution sapması: doğru kaynak/kampanya okunamadığı için optimizasyon kararları bozulur.

“Server-side çözüm” her şeyi çözer mi?

Hayır. Server-side yaklaşım, doğru uygulanırsa “sinyal taşıma”yı güçlendirebilir; ama: • yanlış kurgulanırsa çift sayım (double counting) riski doğurur, • izin/uyum yönetimi yoksa hukuki ve itibar riski doğurur, • veri minimizasyonu yapılmazsa gereksiz veri taşırsınız.

• •Ölçüm kaybı “gerçekten” var mı (platform raporu vs back-office karşılaştırması)?
• •Rezervasyon motoru / CRM / call center kapanışı ölçüme dahil mi?
• •Çift sayım riski için deduplication planı var mı?
• •KVKK, saklama ve minimizasyon prensipleri tanımlı mı?

1. Önce “ölçüm açığı”nı kanıtlayın (rezervasyon raporu vs platform dönüşümü).
2. Sonra sinyali güçlendirecek en küçük adımı seçin (Enhanced mı CAPI mı?).
3. Kurulum öncesi “deduplication + izin” tasarımını netleştirin.
4. 2 haftalık test planı olmadan canlıya almayın.

Kısa cevap : Pixel/Tag (client-side) event’i tarayıcıdan gönderir; server-side event’i sunucudan gönderir. Client-side kolay kurulur ama tarayıcı kısıtlarına daha açıktır; server-side daha kontrollü olabilir ama daha fazla teknik tasarım ve uyum yönetimi ister.

Bu farkı otel diliyle söyleyelim: • Client-side: “Ziyaretçi butona bastı → tarayıcı tag’i çalıştıysa event gitti.” • Server-side: “Rezervasyon/lead sunucuda oluştu → sunucu platforma event’i gönderdi.”

Otellerde pratik sonuçlar

• •Rezervasyon tamamlandı sinyali çoğu zaman “sunucu tarafında” daha güvenilir olur (çünkü ödeme/onay orada).
• •Form lead’i hem tarayıcıda hem sunucuda doğrulanabilir (Enhanced Conversions için daha anlamlı).
• •Telefon/WhatsApp tarafında asıl değer, call center kapanışıyla birleştiğinde çıkar.

En kritik kavram: Deduplication (çift sayımı engelleme)

Meta tarafında Pixel + CAPI birlikte kullanıldığında aynı event iki kanaldan gelebilir. Bu yüzden Meta, event_id ile deduplication önerir: Pixel’deki eventID ile CAPI’deki event_id eşleşirse çift sayım engellenir.

• •Pixel/Tag ve server-side aynı event’i gönderiyorsa event_id tasarımı yapıldı mı?
• •Rezervasyon/lead event’leri için “tek kaynak gerçek” neresi? (browser mı server mı?)
• •Hangi event’lerde server-side gerçekten değer katacak?

1. “Sadece kritik event” ile başlayın (rezervasyon/lead).
2. Meta için event_id deduplication kurgusunu zorunlu kabul edin.
3. Google tarafında Enhanced Conversions’ı önce lead formlarında deneyin.

Kısa cevap : Meta CAPI, dönüşüm event’lerini sunucudan Meta’ya iletmenizi sağlar; Pixel ile birlikte kullanıldığında daha dayanıklı bir ölçüm katmanı oluşturabilir. Aynı event’i iki yerden yolluyorsanız deduplication için event_id gerekir.

Otel için anlamı şudur: • Rezervasyon onayı (booking_complete / purchase) gibi kritik sinyal, tarayıcı engeline takılsa bile sunucudan iletilebilir. • Lead (form/teklif) gibi sinyaller, CRM’de doğrulandığında daha temiz raporlanabilir. • Optimizasyon için platformun elindeki “kaliteli sinyal” artar.

CAPI kurulumu için gerekenler (özet)

• •Event’lerin “nerede” oluştuğu net olmalı: web, booking engine, CRM.
• •Sunucu tarafında Meta’ya gönderilecek payload tasarımı yapılmalı.
• •Event deduplication planı yapılmalı (Pixel + CAPI birlikteyse).

Deduplication nasıl çalışır? (otellere göre sade)

Aynı “rezervasyon” olayı hem tarayıcıdan hem sunucudan gidiyorsa: • event_name + event_id eşleşirse Meta birini tekilleştirir. • Bu sayede “satış iki kez sayıldı” hatasını minimize edersiniz.

CAPI ile otel için ideal event seti

Başlangıç (Core) için aşırı genişlemeyin: • Purchase / booking_complete (rezervasyon onayı) • Lead (form) • (Opsiyonel) Contact (WhatsApp/telefon lead’i; ama kapanış yoksa “lead sinyali” olarak)

• •CAPI ile göndermek istediğiniz “kritik event” listesi 2–3 madde mi?
• •event_id üretim ve eşleme mantığı tasarlandı mı?
• •Sunucudan giden event’lerin doğrulama/test planı var mı?

1. CAPI’ye “tek bir kritik event” ile başlayın (rezervasyon).
2. Deduplication olmadan Pixel + CAPI birlikte canlıya almayın.
3. 14 günlük test sprint’iyle, rapor sapmasını ölçerek ilerleyin.

Kısa cevap : Enhanced Conversions, dönüşüm anında elde edilen birinci taraf kullanıcı verisini (ör. e-posta) SHA-256 ile hash’leyerek Google’a gönderir; bu veri Google hesaplarıyla eşleştirilip dönüşüm ölçüm doğruluğunu artırmaya yardımcı olur.

Otel tarafında bu özellikle şu senaryolarda değer üretir: • İletişim/teklif formu (e-posta/telefon alınır) • Rezervasyon formu (misafir bilgileri alınır) • Lead → satış süreci (CRM ile kapanış) Google’ın kendi açıklamasına göre Enhanced Conversions, mevcut dönüşüm etiketlerini “tamamlar” ve dönüşüm ölçüm doğruluğunu artırmayı hedefler; veriler hash’lenerek gönderilir.

Enhanced Conversions “ne değildir”?

• •Çerez reddedildiğinde bile %100 takip garantisi değildir.
• •“Daha çok dönüşüm” vaadi değil; daha iyi eşleşme ve doğrulama yaklaşımıdır.
• •Yanlış veriyle (yanlış e-posta/format) fayda sınırlı kalır.

Google tarafında kritik gereksinimler

• •Dönüşüm anında kullanıcı verisinin (e-posta vb.) yakalanması
• •Verinin hash’lenmesi (SHA-256)
• •Müşteri verisi şartları/politikaları ve uygunluk (hesap tarafı kabul süreçleri olabilir).

• •Form/rezervasyon sırasında e-posta/telefon gibi birinci taraf veri alıyor musunuz?
• •Bu veriyi KVKK ve izin yönetimiyle birlikte kullanabiliyor musunuz?
• •Hashing (SHA-256) akışı tasarlandı mı?

1. Enhanced Conversions’ı önce “lead form” üzerinde pilotlayın.
2. Veri alanlarını minimum tutun (e-posta gibi).
3. Uygulama sonrası 2–4 hafta “ölçüm tutarlılığı” karşılaştırması yapın.

Bu bölüm, pazarlama ekibi için “net karar” içindir.

Hızlı karar matrisi

• •Sadece Google Ads çalışıyor + lead form var: Enhanced Conversions çoğu zaman ilk adımdır.
• •Meta odaklı kampanya + sinyal kaybı: CAPI (deduplication’lı) değerlendirilebilir.
• •Rezervasyon motoru ayrı sistem + ölçüm kopuk: önce GA4 cross-domain + booking_complete netleşmeli; sonra server-side katmanı düşünülmeli.
• •Call center kapanışı çok yüksek: offline dönüşüm ve CRM entegrasyonu, “tıklama”dan daha değerlidir.

“Artı/Eksi” yaklaşımı

Artılar (doğru kurulumla): • Daha istikrarlı sinyal → daha tutarlı optimizasyon • Lead/rezervasyon doğrulaması güçlenir • Çok kanallı ölçüm (CRM/booking engine) daha anlamlı hale gelir Eksiler / riskler: • Teknik karmaşıklık artar • Deduplication yapılmazsa çift sayım riski • KVKK/uyum yönetimi gerektirir (minimizasyon, hashing, saklama)

Key Statistics / Data Point (sheet): Server-side sinyaller sayesinde bazı hesaplarda ölçülen dönüşüm sayısında anlamlı artış ve optimizasyon performansında iyileşme gözlemlenebiliyor; ancak bu “kurulum kalitesi + izin oranı + veri kaynakları”na bağlıdır. (Kesin rakam iddiası yapılmaz.)

• •“Hedefim ölçüm mü, optimizasyon mu, attribution mu?” net mi?
• •Lead/rezervasyon verisi sunucu/CRM tarafında erişilebilir mi?
• •2 haftalık pilot + 4 haftalık değerlendirme planı var mı?

1. Önce en büyük ölçüm açığını bulun (Google mu Meta mı?).
2. En az eforla en çok faydayı veren katmanı seçin (Enhanced genelde daha hızlı).
3. Sonra CAPI gibi daha teknik katmanlara geçin.
4. Pilot ölçmeden “tam geçiş” yapmayın.

Server-side çözümler “daha fazla veri toplamak” değildir; doğru yaklaşım daha kaliteli, daha minimum ve izinli veri taşımaktır. Google Enhanced Conversions, kullanıcı verisinin hash’lenerek gönderildiğini ve mevcut etiketleri tamamladığını açıkça belirtir; bu bile bize şunu söyler: veri aktarımı “privacy-safe” tasarlanmalıdır.

Oteller için 5 pratik uyum prensibi

1. Veri minimizasyonu: Sadece gerekli alanlar (örn. e-posta)
2. Amaç sınırlaması: Ölçüm ve optimizasyon dışında kullanım yok
3. Saklama süresi: “gerekenden uzun” saklama yok
4. Hashing ve güvenli aktarım: SHA-256 hashing + güvenli kanal
5. Erişim yetkileri: Kim erişir, kim görür, kim siler?

Pazarlama ekibi için net çizgi

“Hash’li gönderiyorum, o yüzden her şey serbest” yaklaşımı doğru değildir. İzin metinleri, çerez/izin yönetimi ve platform şartları birlikte düşünülmelidir. (Google tarafında müşteri verisi şartlarının kabul süreçleri olabildiğini gösteren yönergeler bulunur.)

• •Hangi veri alanlarını gönderdiğiniz yazılı mı?
• •İzin/aydınlatma metinleri bu veri kullanımını kapsıyor mu?
• •Saklama süresi ve erişim yetkisi tanımlı mı?

1. Uyum tarafını “kurulumun parçası” kabul edin.
2. Minimum veri ile başlayın (pilot).
3. Süreç oturunca ölçekleyin; her platform güncellemesinde yeniden gözden geçirin.

Bu rehberin sonunda, pratik bir “başlangıç paketi” önerelim:

Paket A (hızlı kazanım – 7 gün)

• •Google Ads: Enhanced Conversions (lead form)
• •GA4: doğru conversion seti + cross-domain kontrol
• •Meta: Pixel event seti “sade” (Lead, Purchase)

Paket B (ölçüm derinleşme – 14 gün)

• •Meta CAPI: sadece Purchase + Lead
• •Deduplication: event_id zorunlu
• •CRM: lead kapanış etiketleri standardı

• •Başlangıç paketi “minimum efor + maksimum etki” mi?
• •Teknik ekip zamanı ve önceliği uygun mu?
• •Pilot ölçüm kriterleri net mi (önce/sonra karşılaştırma)?

1. Önce 7 günlük hızlı kazanımı bitirin.
2. Sonra 14 günlük server-side sprint’e geçin.
3. Sonuçları “rezervasyon raporu” ile çapraz doğrulayın.
4. Başarı kriteri yoksa ölçeklemeyin.

Kapanış – “Server-side bir teknoloji değil, bir ölçüm stratejisidir”

Meta CAPI ve Enhanced Conversions’ı “trend” diye değil, ölçüm açığınız ve optimizasyon hedefiniz varsa devreye alın. Başarı; daha çok event göndermek değil, daha doğru ve izinli sinyal taşımaktır.