Meta CAPI Purchase Event Neden Çift Sayılır? Duplicate Purchase Sorunu Nasıl Önlenir?

Meta Pixel ile Conversion API'yi birlikte kullanmak, e-ticaret ölçümünü daha dayanıklı hale getirebilir. Ancak kurulum doğru yapılmadığında aynı sipariş hem browser hem server tarafından ayrı bir satış gibi Meta'ya gönderilebilir.

Sonuç:

purchase sayısı şişer,
ROAS olduğundan yüksek görünür,
optimizasyon modeli yanlış veriyle beslenir,
reklam raporları ile gerçek siparişler arasında fark oluşur.

Bu problemin temelinde çoğu zaman deduplication bulunur.

Meta Pixel ve Conversion API neden birlikte kullanılır?

Meta Pixel tarayıcı tarafında çalışır. Conversion API ise aynı işlemi backend üzerinden Meta'ya gönderebilir.

Bu yaklaşım özellikle browser tracking kısıtlamaları, ad blocker'lar, cookie problemleri ve network kesintileri gibi nedenlerle kaybolabilecek eventlerin server tarafından desteklenmesini sağlar.

Deduplication nedir?

Deduplication, Meta'nın browser ve server üzerinden gelen iki event'in aynı kullanıcı aksiyonuna ait olduğunu anlayarak yalnızca bir tanesini işlemesidir.

Örnek:

Browser

Purchase event_id = order_123

Server

Purchase event_id = order_123

↓

Tek Purchase

Purchase neden çift sayılır?

1. Browser ve server farklı event ID gönderiyor

Browser purchase_abc123, server order_abc123 gönderiyorsa sistem bunları farklı eventler olarak değerlendirebilir.

Aynı transaction için oluşturulan event identifier iki tarafta da aynı olmalıdır.

2. Event ID yalnızca CAPI tarafında bulunuyor

Browser eventinde eventID yok, server eventinde event_id varsa iki event'in ilişkilendirilmesi zorlaşır.

3. Purchase confirmation page refresh edildiğinde tekrar çalışıyor

Kullanıcı sipariş başarı sayfasını refresh ettiğinde frontend tekrar Purchase gönderiyorsa aynı sipariş ikinci kez gidebilir.

Satış event'i mümkün olduğunca gerçek sipariş state'inden üretilmelidir.

4. GTM ve uygulama kodu aynı anda Purchase gönderiyor

Uygulama kendi kodunda Purchase gönderirken aynı anda GTM dataLayer üzerinden başka bir Purchase tag'i tetiklenebilir.

Audit sırasında GTM, application source, platform entegrasyonları ve custom scriptler birlikte incelenmelidir.

5. Backend callback birden fazla kez işleniyor

Ödeme sağlayıcıları başarısız network koşullarında callback'i tekrar gönderebilir.

Backend idempotent değilse aynı ödeme callback'i iki kez gelir ve iki defa Purchase gönderilir.

Çözüm: order/payment ID bazlı idempotency.

Event ID nasıl oluşturulmalı?

Event ID aynı purchase için sabit, farklı purchase'lar için benzersiz, browser/server arasında aynı ve debugging için takip edilebilir olmalıdır.

Örneğin:

purchase_ORDER12345

veya doğrudan:

ORDER12345

Order ID ile event ID aynı şey mi?

Kavramsal olarak görevleri farklıdır:

Order ID ticari işlemin kimliğidir.
Event ID tracking event'inin deduplication kimliğidir.

Pratikte stabil olduğu sürece order ID'den türetilmiş event ID kullanmak güvenilir olabilir.

En güvenli purchase mimarisi

Daha sağlam bir yapı:

Payment provider callback

↓

Payment verified

↓

Order status = PAID

↓

Event outbox / queue

↓

Meta CAPI

şeklindedir.

Bu model UI refresh veya component lifecycle sorunlarından daha az etkilenir.

Idempotency nasıl uygulanabilir?

Veritabanında şu alanlardan biri tutulabilir:

meta_purchase_sent_at
meta_purchase_event_id
ayrı bir tracking_events tablosu

Event gönderilmeden önce aynı order/event kombinasyonunun daha önce işlendiği kontrol edilir.

Yüksek hacimli yapılarda unique constraint ile:

UNIQUE(platform, event_name, external_id)

gibi bir garanti kurulabilir.

Event Match Quality ile duplicate aynı şey mi?

Hayır.

Event Match Quality, Meta'nın server event'ini kullanıcıyla ne kadar iyi eşleştirebildiğiyle ilgilidir.

Deduplication ise browser ve server üzerinden gelen iki event'in aynı ticari olaya ait olup olmadığını anlamakla ilgilidir.

İyi match quality duplicate problemini otomatik çözmez.

Hangi alanlar birlikte tutulmalı?

Tracking event modelinde en azından:

event_name
event_id
order_id
timestamp
value
currency
fbp
fbc
client_ip_address
client_user_agent
consent state

gibi alanlar merkezi olarak tutulabilir.

Meta CAPI duplicate audit checklist

Browser Purchase var mı?
Server Purchase var mı?
İki tarafta aynı event ID kullanılıyor mu?
GTM aynı event'i ayrıca gönderiyor mu?
Success page refresh event üretiyor mu?
Payment callback retry ediliyor mu?
Backend idempotent mi?
Event kuyruğunda retry duplicate yaratıyor mu?
Event ID order ile stabil ilişkili mi?
CAPI response loglanıyor mu?
Gerçek order sayısı ile Meta purchase sayısı karşılaştırılıyor mu?

Deduplication contract'ı tam olarak neyi garanti etmeli?

Sağlam bir tasarımda aynı ticari olay hangi kanaldan gelirse gelsin tek kimliğe sahiptir.

event_name: Purchase
event_id: purchase:ORDER-12345
external_id: ORDER-12345

Browser ve server bu kimliği bağımsız üretmemeli; aynı order state'inden türetmelidir.

Random UUID kullanmak teoride benzersizdir ama retry ve multi-source senaryosunda aynı purchase için farklı UUID üretildiğinden deduplication'ı zorlaştırır.

Browser ve server eventleri aynı anda neden tutulur?

Amaç “iki purchase göndermek” değildir. Amaç iki transport yolunun aynı ticari sinyali taşımasıdır.

Browser tarafı:

fbp/fbc gibi first-party browser context,
page/session context

sağlayabilir.

Server tarafı:

doğrulanmış order value,
payment state,
güvenilir timestamp

sağlayabilir.

Event sourcing yaklaşımı

Daha dayanıklı akış:

Payment verified
→ Order state transition
→ Domain event: OrderPaid
→ Outbox
→ Tracking worker
→ Meta CAPI

Avantajlar:

ödeme request'i tracking yüzünden yavaşlamaz,
retry kontrollüdür,
event kaybolmaz,
audit edilebilir.

Outbox tablosu örneği

id
event_type
aggregate_id
destination
event_id
payload_version
status
attempt_count
next_retry_at
sent_at
last_error

Unique constraint:

UNIQUE(destination, event_type, aggregate_id)

aynı sipariş için ikinci logical purchase kaydını engelleyebilir.

Retry nasıl duplicate üretmeden yapılır?

Yanlış:

attempt 1 → event_id=A
timeout
attempt 2 → event_id=B

Doğru:

attempt 1 → event_id=A
timeout
attempt 2 → event_id=A

Transport retry yeni ticari olay yaratmamalıdır.

Purchase value hangi state'ten alınmalı?

Frontend'deki cart total güvenilir source of truth değildir.

Purchase payload:

order net total,
currency,
line items,
discounts

gibi alanları confirmed order snapshot'tan üretmelidir.

Observability olmadan duplicate bulmak zordur

Her outbound event için:

order_id
event_id
source
destination
payload_hash
attempt
response_code
timestamp

loglanmalıdır.

Audit senaryoları

Success page refresh.
Payment callback iki kez gelir.
Queue worker timeout alır ve retry eder.
Browser event network gecikmesi yaşar.
GTM container iki trigger eşleştirir.
Order update purchase event'i tekrar tetikler.

Beklenen: her durumda aynı ticari purchase tek logical event olarak kalır.

Günlük reconciliation

backend paid orders: 1,245
meta purchase events: 1,238
difference: -0.56%
duplicate candidates: 3
missing candidates: 10

Ardından order id seviyesinde drill-down yapılmalıdır. Yalnız toplam sayıya bakmak hangi siparişin sorunlu olduğunu göstermez.

Production'da hangi alarm kurulmalı?

Order-level event tablosundan şu alarmlar üretilebilir:

aynı order_id için birden fazla unique event_id,
aynı event_id için beklenmedik farklı value,
CAPI success rate düşüşü,
retry sayısında ani artış,
backend paid order ile Meta event count farkında anomali.

Bu alarmlar duplicate problemi kampanya raporuna yansımadan önce yakalayabilir.

Payload değişikliğinde regression riski

Tracking payload'ı ürün ekibi, GTM ekibi ve backend ekibi ayrı ayrı değiştirebilir. Bu nedenle schema contract ve test fixture tutulması önemlidir. Örnek sipariş payload'ı snapshot olarak saklanıp deployment sırasında expected event ile karşılaştırılabilir.

Sonuç

Meta CAPI duplicate problemi genellikle tek bir “Pixel ayarı” değildir.

Sorun browser, backend, GTM, ödeme callback'i ve event idempotency katmanlarının birlikte tasarlanmamasından doğar.

Reliefers olarak tracking projelerinde yalnız tag kurulumu değil, gerçek sipariş state'inden reklam platformuna kadar tüm event akışını birlikte ele alıyoruz. Meta'daki purchase sayısı backend siparişlerinizle uyuşmuyorsa önce event kaynaklarını ve deduplication contract'ını incelemek gerekir.