Aynı gün:
- backend 100 sipariş,
- GA4 91 purchase,
- Meta 47 purchase attribution,
- Google Ads 38 conversion
gösterebilir.
Bu rakamların eşit olmaması otomatik olarak tracking hatası değildir.
Çünkü bu sistemler aynı soruyu cevaplamaz.
Backend: Kaç gerçek sipariş oldu?
GA4: Kullanıcı yolculuğunu kendi identity/attribution modelimde nasıl görüyorum?
Meta: Hangi satışlarda Meta temasına credit veriyorum?
Google Ads: Hangi dönüşümlerde Google Ads temasına credit veriyorum?
Önce iki problemi ayırın
Measurement completeness
Gerçek event teknik olarak yakalanıyor mu?
Attribution
Yakalanan dönüşüme hangi kanal credit alıyor?
Bu iki problem karıştırılırsa “Meta fazla sayıyor” diye event tracking bozulabilir.
Backend neden source of truth olmalı?
Order database:
- gerçek order id,
- paid/cancelled status,
- gross/net total,
- refunds
bilgisine sahiptir.
Bu nedenle transaction truth backend’dedir.
Analytics sistemleri bu gerçeğin pazarlama bağlamındaki temsilleridir.
GA4 neden farklı raporlar?
GA4:
- consent,
- browser identifiers,
- session logic,
- cross-device identity,
- attribution model
üzerinden kullanıcı yolculuğu kurar.
Güncel GA4 attribution seçenekleri arasında data-driven attribution, paid and organic last click ve Google paid channels last click gibi modeller bulunur.
Data-driven attribution her key event için kullanıcı etkileşimlerinin katkısını modellemeye çalışır.
Bu nedenle GA4’ün revenue’su backend order table ile birebir eşit olmak zorunda değildir; ancak event completeness farkı açıklanabilir seviyede olmalıdır.
Meta neden aynı purchase’a credit verir?
Bir kullanıcı:
- Instagram reklamını görür,
- iki gün sonra Google’da brand search yapar,
- siteye girer,
- satın alır.
Meta kendi attribution window’u içinde bu satın alımda etkisi olduğunu söyleyebilir.
Google da tıklamaya credit verebilir.
GA4 ise kendi modelinde krediyi farklı dağıtabilir.
Toplam platform-attributed conversions’ın gerçek order sayısından büyük olması bu nedenle mümkündür.
Attribution toplamsal muhasebe değildir.
Conversion window kritik
Platformları karşılaştırırken:
- 1-day click,
- 7-day click,
- view-through,
- engaged-view
gibi pencerelerin aynı olmadığını bilmek gerekir.
Aynı zaman aralığında farklı attribution windows karşılaştırılıyorsa “hangi platform doğru?” sorusu geçersizdir.
Identity neden bozulur?
Modern tracking’in en zor problemi event göndermek değil, event’i kullanıcıya bağlamaktır.
Identity sinyalleri:
- first-party cookie
- login/customer id
- click identifiers
- hashed customer data
- browser/device ids
gibi kaynaklardan gelir.
Safari/ITP, consent, ad blockers ve cross-device journeys bu zinciri kırabilir.
Server-side tracking veri kaybını azaltabilir; ancak attribution gerçeğini sihirli şekilde çözmez.
Duplicate purchase problemi
Duplicate purchase'in platform bazinda cozumu icin: GA4 purchase event neden çift sayılır? ve Meta CAPI duplicate purchase sorunu nasıl önlenir?
Server + browser event birlikte gönderiliyorsa aynı purchase iki kez raporlanabilir.
Deduplication tasarımında:
- deterministic event id,
- order id,
- event name,
- stable retry behavior
kullanılmalıdır.
En iyi pattern: purchase:{orderId} gibi deterministik event identity.
Random UUID her retry’da değişirse aynı sipariş yeniden yeni event gibi görünebilir.
Reconciliation tablosu kurun
Her gün:
| Metric | Backend | GA4 | Meta | Google Ads |
|---|---|---|---|---|
| Orders | 100 | 91 | 47 | 38 |
| Revenue | 250k | 229k | 131k | 104k |
Ardından üç oran:
GA4 capture rate
GA4 purchases / backend paid orders
Revenue capture rate
GA4 revenue / backend net revenue
Platform attribution share
Attributed purchase / backend purchase
İlk ikisi tracking health metriğidir. Sonuncusu attribution metriğidir.
Ne kadar fark normal?
Evrensel yüzde vermek doğru değildir.
Şunlara göre değişir:
- consent rate,
- mobile/browser mix,
- payment redirect flow,
- checkout architecture,
- server-side instrumentation,
- attribution windows.
Önemli olan:
- farkın trendi,
- ani kırılma,
- order id seviyesinde audit
yapabilmektir.
Attribution yerine incrementality
Attribution şu soruyu sorar: “Bu satışta hangi temas noktaları rol oynadı?”
Incrementality: “Reklam olmasaydı satış yine olur muydu?”
Growth bütçesi açısından ikinci soru daha önemlidir.
Google’ın Conversion Lift ve Experiment Center çözümleri, exposed ve control grupları üzerinden causal impact ölçmeye yöneliktir.
Bu nedenle büyük bütçelerde “Meta 5 ROAS / Google 7 ROAS” karşılaştırmasından daha doğru soru:
Hangi kanal bütçeyi artırdığımda incremental satış yaratıyor?
Reliefers measurement architecture
Katman 1 — Order truth
PostgreSQL / commerce backend.
Katman 2 — Event truth
Normalized event pipeline:
- event id
- order id
- timestamp
- value
- currency
- customer state
Katman 3 — Analytics
GA4 / warehouse.
Katman 4 — Ad destinations
Meta CAPI, Google Ads conversions vb.
Katman 5 — Reconciliation
Backend vs analytics vs platform.
Bu model debugging’i çok daha kolaylaştırır.
Sonuç
GA4, Meta ve Google Ads’in aynı rakamı göstermesi hedef değildir.
Hedef:
- backend transaction truth’un doğru olması,
- analytics event capture’ın ölçülebilir olması,
- platform attribution’ın kendi bağlamında anlaşılması,
- bütçe kararının incrementality ve business economics üzerinden verilmesidir.
CTA: Reliefers; GA4, GTM, Meta CAPI, Google Ads conversion ve backend event’lerini tek measurement architecture içinde tasarlayarak “hangi dashboard doğru?” sorununu “hangi sistem hangi gerçeği ölçüyor?” seviyesine taşır.