OpenAI Ads'te Dedup: Aynı Dönüşümü İki Kez Saymamak

OpenAI Ads ölçümünde pixel ve Conversions API sık sık aynı dönüşümü taşır: kullanıcı tarayıcıda siparişi tamamlar, pixel ateşler; aynı sipariş sunucuda da kaydedilir ve Conversions API’den gider. Doğru kurulmazsa bu tek dönüşüm iki kez sayılır ve raporlar şişer. Tekilleştirme (deduplication), bu iki kaydı tek dönüşüme bağlayan mekanizmadır.

Bu yazı eşleşmenin hangi alanlarla kurulduğunu, kararlı bir event_id’nin nasıl üretildiğini ve sık yapılan hataları gösterir. Pixel ve sunucu kurulumlarının kendisi ayrı yazıların konusu; burada odak iki katmanı çakışmadan uzlaştırmak.

Dedup Neden Gerekir

Pixel ve Conversions API tek başına eksik kalır. Pixel reklam engelleyici, onay reddi ve çerez kısıtlarıyla budanır; Conversions API ise tarayıcıdaki canlı etkileşimi değil sunucudaki kaydı görür. İkisi birlikte kullanıldığında kapsama genişler, ama aynı dönüşüm iki kaynaktan gidince çift sayım riski doğar. Dedup, kapsamı genişletirken sayımı tek tutmanın yoludur.

Aynı dönüşüm yalnızca tek bir katmandan gönderiliyorsa dedup’a gerek yoktur. event_id yalnızca aynı dönüşüm hem pixel hem sunucudan gittiğinde devreye girer.

Eşleşme Anahtarı: Üç Bileşen

OpenAI Ads iki kaydın aynı dönüşüm olduğuna üç bileşenin eşleşmesiyle karar verir: Pixel ID, event adı ve event_id¹. Üçü de iki tarafta aynıysa kayıtlar tek dönüşüm olarak sayılır.

Sunucu tarafında dönüşümün kimliği id alanında taşınır; pixel tarafında aynı değer options.event_id olarak gönderilir². Yani eşleşmeyi kuran şey, sunucudaki id ile pixel’deki event_id’nin birebir aynı olmasıdır.

event_id’yi Geliştirici Üretir

Kritik nokta: event_id’yi OpenAI üretmez. Dönüşüm başına kararlı ve tekil bir kimliği geliştirici belirler ve aynı pixel ile sunucu event’inde tekrar kullanır¹. İyi bir event_id iki özelliği taşır:

• Tekil: Her dönüşüm farklı bir değer alır, böylece ayrı siparişler birbirine karışmaz.
• Kararlı: Aynı dönüşüm için pixel ve sunucu aynı değeri üretebilmeli. Sipariş numarası, ödeme kimliği gibi sistemde zaten var olan ve tekrar okunabilen bir değer bu yüzden uygundur.

Sipariş kimliği bu iki koşulu doğal olarak karşılar: hem her sipariş için tekildir hem de tarayıcıda ve sunucuda aynı değer okunabilir.

// Pixel tarafı: dönüşüm kimliğini event_id olarak gönder
oaiq(
  "measure",
  "order_created",
  { type: "contents", amount: 2599, currency: "USD" },
  { event_id: "order_12345" },
);

// Sunucu tarafı: aynı değeri id olarak gönder
{
  "id": "order_12345",
  "type": "order_created",
  "timestamp_ms": 1773892800000,
  "data": {
    "type": "contents",
    "amount": 2599,
    "currency": "USD",
    "contents": [
      {
        "id": "sku_123",
        "name": "Starter bundle",
        "content_type": "product",
        "quantity": 1
      }
    ]
  }
}

İki tarafta da event_id/id değeri order_12345, event adı order_created ve aynı Pixel ID kullanıldığı için OpenAI bu iki kaydı tek dönüşüm sayar.

Custom Event’lerde Eşleşme

Standart bir event yerine custom gönderiliyorsa, eşleşme standart event adı yerine custom_event_name ile kurulur. Custom event’lerde iki tarafta da aynı custom_event_name kullanılmalıdır¹. Pixel tarafında custom_event_name options nesnesinde, sunucu tarafında event alanında taşınır; ikisi farklıysa eşleşme kurulmaz.

Sık Yapılan Hatalar

Dedup’ı bozan hatalar genellikle aynı kalması gereken bir değerin iki tarafta ayrışmasından kaynaklanır:

• Her gönderimde yeni rastgele event_id: Pixel ve sunucu farklı değer üretir, eşleşme kurulmaz, dönüşüm iki kez sayılır. event_id dönüşüm başına kararlı olmalı.
• Farklı Pixel ID: İki gönderim farklı Pixel ID taşırsa eşleşme baştan kurulmaz.
• Event adı uyuşmazlığı: Pixel order_created, sunucu farklı bir tip gönderirse kayıtlar eşleşmez.
• Custom event’te ad ayrışması: İki tarafta farklı custom_event_name aynı sorunu yaratır.
• Gereksiz event_id: Dönüşüm tek katmandan gidiyorken event_id eklemek zarar vermez ama gereksizdir; dedup yalnızca iki kaynak varken anlamlıdır.

Sonraki Adımlar

Dedup kurulduğunda pixel ve Conversions API artık kapsamı genişletip sayımı tek tutar. Bundan sonraki adım, hangi event’in ne zaman gönderileceğini netleştirmek: event taksonomisi ve her event’in beklediği veri şekli ölçümün doğru sayılması için belirleyicidir.