Telefonla kapanan satış, mağazada tamamlanan ödeme ya da CRM’de onaylanan bir lead, GA4’e kendiliğinden düşmez. Bu boşluğu kapatan katman, GA4 Measurement Protocol tarafıdır.
Ama tek başına HTTP isteği göndermek yetmez. Doğru kimlikleri önceden toplamazsanız, offline dönüşüm görünür; yine de doğru kullanıcıya, oturuma ve kampanyaya bağlanmaz. Pratikte en kritik konu, eşleştirme mantığını baştan doğru kurmaktır.
Offline etkinliği doğru kullanıcıyla nasıl eşleştirirsiniz
Google’ın Measurement Protocol kullanım senaryoları dokümanı net bir çerçeve veriyor: web veya uygulamada oluşan kimlik bilgisini, daha sonra oluşan offline olayla birleştirin. Web tarafında bu işin ana omurgası çoğu durumda client_id olur.
En sade kurgu şöyle çalışır. Kullanıcı sitede form doldurur, teklif ister ya da giriş yapar. O anda tarayıcıdaki client_id değerini alır, backend’e gönderir ve CRM kaydına yazarsınız. Günler değil, mümkünse aynı iş günü içinde gerçekleşen mağaza satışı, çağrı merkezi satışı veya satış temsilcisi onayı geldiğinde, aynı kayıt içindeki client_id ile GA4’e event basarsınız.
user_id varsa tablo daha da güçlenir. Çünkü giriş yapan kullanıcıyı cihazlar arasında daha iyi birleştirirsiniz. Yine de web akışında sadece user_id‘ye güvenmek doğru değildir; mümkün olduğunda client_id ile birlikte gönderin. Oturum bağını korumak istiyorsanız session_id de saklanmalıdır. Aksi halde bazı raporlarda (not set) görmeniz şaşırtıcı olmaz.
Aşağıdaki alanlar, offline event gönderirken en çok işinize yarar:
| Alan | Ne zaman kullanılır | Neden önemli |
|---|---|---|
client_id | Web kullanıcılarını eşleştirirken | Tarayıcı kimliğini taşır |
user_id | Giriş yapan ya da CRM’de tanınan kişi varsa | Cihazlar arası bağı güçlendirir |
transaction_id | purchase ve refund olaylarında | Tekrarlı kayıt riskini azaltır |
engagement_time_msec | Çoğu eventte faydalıdır | Etkileşim ve gerçek zamanlı görünüm için yardımcıdır |
timestamp_micros | Olay anı, gönderim anından farklıysa | Etkinliğin gerçek zamanını taşır |
session_id | Oturum ve atıf bağını korumak istediğinizde | (not set) riskini düşürür |
Tablodaki en önemli nokta şu: client_id ve mümkünse session_id toplanmadıysa, sonradan kusursuz eşleştirme beklememek gerekir.
İstek yapısı ve çalışan örnek payload
Gönderim mantığı basittir. İstek, https://www.google-analytics.com/mp/collect uç noktasına gider. measurement_id ve api_secret query string içinde yer alır; event gövdesi ise JSON olarak POST edilir. Resmi alan yapısını görmek için Google’ın etkinlik gönderme dokümantasyonu iyi bir referanstır.
Temel akış dört adımda ilerler:
- GA4 veri akışından
measurement_idalın. - Aynı akış altında
api_secretüretin. - CRM veya backend kaydından
client_id, varsauser_idvesession_idçekin. - Olay tipine uygun event’i gönderin, satış için çoğu zaman
purchaseen doğru seçimdir.
cURL ile kısa ama gerçekçi bir örnek şöyle olabilir:
curl -X POST 'https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXX&api_secret=SECRET' -H 'Content-Type: application/json' -d '{"client_id":"1871825471.1713529001","user_id":"crm_8471","timestamp_micros":1772611200000000,"events":[{"name":"purchase","params":{"session_id":1744381102,"transaction_id":"OFF-2026-0412-984","currency":"TRY","value":3499.90,"engagement_time_msec":100}}]}'
JavaScript tarafında aynı mantık korunur:
await fetch(endpoint, { method: "POST", headers: { "Content-Type": "application/json" }, body: JSON.stringify(payload) })
Burada birkaç alanı doğru yorumlamak gerekir. transaction_id, satış ve iade tarafında neredeyse zorunlu gibidir; hem sipariş bazlı analiz yaparsınız hem de tekrar gönderimlerde karışıklık azalır. engagement_time_msec, offline event için anlamsız görünse de GA4’in bazı etkileşim hesapları açısından faydalıdır. timestamp_micros ise olay sonradan sisteme işleniyorsa değerlidir; örneğin mağaza satışı saat 14:05’te olduysa ama siz 16:20’de gönderiyorsanız, gerçek olayı zamanına yakın işaretlersiniz. Yine de bunu eski kayıtları topluca geriye basmak için sihirli bir çözüm gibi görmeyin.
Offline satış event’ini bugün göndermek mümkündür. Geçen ayın eksik satışlarını bugün yükleyip aynı atfı beklemek gerçekçi değildir.
Sınırlamalar, rapor farkları ve kısa senaryo notları
GA4 Measurement Protocol, eksik veri boşluklarını kapatır; fakat geçmişi kusursuz biçimde yeniden yazmaz. Google’ın Measurement Protocol yardım sayfası da buna dolaylı biçimde işaret eder. Oturum bilgisi yoksa raporlarda boşluk oluşabilir. Olay geç gönderildiyse atıf beklediğiniz kadar güçlü olmayabilir. Gerçek Zamanlı raporda hızlı görünüm alırsınız, standart raporların oturması ise daha uzun sürebilir.
SPA tarafında en sık hata, client_id toplama işini sadece ilk sayfa yüklenmesine bağlamaktır. Form, teklif veya giriş anında yeniden yakalayıp backend’e yazmak daha güvenlidir. Çünkü route değişimleri, state yönetimi ve form akışı farklı ilerleyebilir.
Backend senaryosunda idempotency düşünmek gerekir. Aynı sipariş iki kez işlendiğinde aynı transaction_id ile veri kalitesini korursunuz. Ayrıca event adlarını iş kuralına göre sabitleyin; bir gün offline_purchase, ertesi gün store_sale kullanmak raporları parçalar.
CRM senaryosunda aşama bazlı event tasarımı daha verimlidir. MQL, SQL veya kazanılan fırsat gibi aşamalar taşıyorsanız, CRM’den Measurement Protocol ile lead eventi yaklaşımı iyi bir referans verir. Ancak her CRM alanını GA4’e dökmek doğru değildir. Raporlamada kullanacağınız birkaç net event ve birkaç temiz parametre çoğu zaman daha iyi sonuç verir.
Sonuç
Offline event göndermede başarı, payload yazmaktan önce kimlik toplamaya bağlıdır. client_id, varsa user_id, gerekiyorsa session_id düzgün saklanıyorsa GA4 tarafı oldukça net ilerler.
En güvenli yaklaşım, olayı geciktirmeden göndermek ve satış için purchase gibi standart event’leri tercih etmektir. Doğru eşleştirme kurulduğunda, mağaza satışıyla web oturumu arasındaki mesafe büyük ölçüde kapanır.