Meta Conversion API ile Tekilleştirme Rehberi

Tarayıcı pikseli ile sunucu olayı aynı siparişi ayrı kimliklerle bildirirse Meta reklamları iki satın alma yazar. Bu rehber, Meta Conversion API tekilleştirmesini event_id, kullanıcı alanları ve test adımlarıyla kurmanızı sağlar. Google dönüşüm etiketi ve GA4 kurulumundan bağımsız durur.

Meta reklamlarında dönüşüm çoğu zaman tarayıcıdaki pikselle ölçülür. Teşekkür sayfası açılır, Purchase olayı gider, reklam hesabı satın almayı görür. Ad engelleyici, tarayıcı kısıtı veya ödeme sonrası yönlendirme bu sinyali kesince olay hiç ulaşmaz.

Bu boşluğu kapatmak için sunucudan Meta Conversion API ile aynı olayı göndermek yaygın bir çözümdür. Piksel çalışmasa bile sipariş kaydı duruyorsa sunucu olayı gidebilir. Asıl risk şudur: iki kanal aynı satın almayı ayrı kimliklerle bildirirse Events Manager iki dönüşüm yazar. Optimizasyon şişmiş satın alma görür, maliyet yanıltıcı hale gelir.

Bu rehber Google dönüşüm etiketi ve GA4 kurulumundan ayrı durur. Konu, tarayıcı pikseli ile sunucu olayının aynı satın almayı iki kez saymamasıdır. Aşağıdaki adımlar event_id, kullanıcı alanları, gönderim düzeni ve test ekranına odaklanır.

Piksel ve sunucu olayı neden birlikte kullanılır

Piksel, tarayıcıda çalışan bir etikettir. Sayfa yüklenir, JavaScript çalışır, olay Meta’ya gider. Bu yol hızlıdır; tıklama, görüntüleme ve sayfa içi davranış için yeterlidir. Satın alma ise çoğu sitede ödeme sağlayıcısının dönüşünden sonra oluşur. Teşekkür sayfası açılmazsa piksel Purchase’ı hiç görmez.

Sunucu olayı sipariş kaydına bağlanır. Ödeme onaylandı, stok düştü, sipariş numarası yazıldı. Bu noktada tarayıcının açık olup olmaması ikincildir. E-ticaret sitesi tarafında asıl kaynak sipariş tablosudur; piksel yalnızca tarayıcının o anki görüntüsüdür.

İki kanalı birlikte tutmanın nedeni yedektir. Piksel kesilirse sunucu tamamlar. Sunucu gecikirse piksel erken sinyal verir. Yedek, aynı işi iki kez yazmak demek değildir. Yedek, aynı işin tek kimlikle iki yoldan bildirilmesi demektir.

• Piksel: tarayıcı açıkken hızlı sinyal.
• Sunucu: sipariş kesinleşince kalıcı sinyal.
• Tekilleştirme: Meta’nın bu iki sinyali tek satın alma sayması.

Sosyal medya reklamları ölçümünde bu üçlü ayrı durmaz. Piksel kurulu, API bağlı, kimlik sözleşmesi yoksa rapor şişer. Kontrol listesinin ilk maddesi bu sözleşmedir: tarayıcı ve sunucu aynı satın almayı aynı event_id ile konuşur.

Meta Conversion API tekilleştirmesi neyi eşleştirir

Meta, tarayıcı ve sunucu olayını rastgele “benzer görünüyor” diye birleştirmez. Eşleştirmenin omurgası iki alandır: event_name ve event_id. İkisi de aynıysa, iki gönderim aynı dönüşüm kabul edilir. Biri farklıysa iki ayrı olay gibi durur.

event_name Purchase ise her iki kanal da Purchase demelidir. Pikselde Purchase, sunucuda purchase veya OrderCompleted yazmak eşleşmeyi bozar. Büyük-küçük harf ve standart olay adları burada süs değildir; sözleşme maddesidir.

event_id o satın almaya özgü bir kimliktir. Aynı siparişin pikseli ve sunucu olayı bu kimliği paylaşır. Farklı siparişler farklı kimlik alır. Aynı kimliği her güne, her teste, her deneme tıklamasına basmak da yanlıştır; o zaman ayrı satın almalar tek olay gibi görünebilir.

Tekilleştirme, “iki kez göndermeyi yasaklamak” değildir. Aynı dönüşümü iki yoldan gönderip Meta’ya “bu ikisi bir” demektir.

Değer, para birimi ve event_time da tutarlı olmalıdır. Piksel 1200 TRY, sunucu 12.00 veya USD yazarsa rapor içi sapma çıkar. event_time sipariş anına yakın tutulur; sunucu kuyruğu üç saat sonra çalışıyorsa zaman damgasını kuyruk anına değil sipariş anına bağlamak daha temiz bir iz bırakır.

Kurulum	Meta ne görür	Pratik sonuç
Yalnız piksel	Tarayıcı olayı	Engelleyici ve kesik yönlendirmede boşluk
Yalnız Conversion API	Sunucu olayı	Tarayıcı sinyali yok; yedek kanal da yok
İkisi, farklı event_id	İki ayrı Purchase	Çift sayım, şişmiş öğrenme
İkisi, aynı event_name ve event_id	Tek Purchase	Yedek kanal, tek dönüşüm

event_id’yi sipariş anında üretmek

Kimliği piksel kodunun içinde rastgele üretmek yaygın bir hatadır. Tarayıcı bir UUID basar, sunucu başka bir UUID basar. İkisi de Purchase gider, ikisi de “benzersiz”dir; Meta için bunlar iki sipariştir.

Doğru an, sipariş kaydının oluştuğu andır. Veritabanına sipariş numarası yazılır yazılmaz bu numara event_id olur. Piksel teşekkür sayfasında bu numarayı okur. Sunucu da aynı numarayı CAPI gövdesine koyar. Numara yoksa, sipariş satırına ayrı bir event_id kolonu yazılır; iki kanal yine o kolonu okur.

1. Ödeme onayında sipariş kaydını oluşturun.
2. Kalıcı bir kimlik seçin: sipariş numarası veya siparişe bağlı event_id.
3. Teşekkür sayfasına bu kimliği güvenli biçimde taşıyın.
4. Piksel Purchase çağrısına aynı kimliği eventID olarak verin.
5. Sunucu CAPI Purchase gövdesine aynı değeri event_id olarak yazın.
6. CAPI yeniden denemesinde yeni kimlik üretmeyin; aynı değeri tekrar gönderin.

Yeniden deneme burada kritiktir. Ağ zaman aşımı, 5xx yanıtı veya kuyruk tekrarı aynı satın almayı ikinci kez yazmasın diye event_id sabit kalır. Bu, sipariş tablosuna ikinci satır basmamakla aynı fikirdir; fark, hedefin reklam hesabı olmasıdır.

Piksel tarafında kimlik, izleme çağrısının olay parametresinden ayrı durur. Değer ve para birimi ürün bilgisidir. eventID ise o olayın kimliğidir. İkisini tek nesnede karıştırmak, sunucunun okuduğu alanla tarayıcının yazdığı alanın kaymasına yol açar.

Kullanıcı eşleştirme alanlarını aynı olayda taşımak

Tekilleştirme event_id ile biter sanılır. event_id çift sayımı keser. Kullanıcı alanları ise olayın kime ait olduğunu güçlendirir. E-posta, telefon, dış kullanıcı kimliği, fbp ve fbc gibi alanlar boşsa olay gider ama eşleşme zayıf kalır.

Sunucu, tarayıcının gördüğü çerezleri kendiliğinden bilmez. fbp ve fbc değerlerini istek anında okuyup siparişle birlikte saklamak gerekir. Ödeme başka bir alt alanda bitiyorsa bu değerler kaybolur. Bu alanlar sipariş kaydına, CAPI çağrısından önce işlenir; teşekkür sayfası kapanınca iz silinmesin diye.

• e-posta ve telefon: tek biçime getirilip hash’lenerek gönderilir.
• external_id: sizin üye veya müşteri numaranız, tutarlı olduğu sürece yararlıdır.
• fbp / fbc: tarayıcıdan okunup sunucu olayına kopyalanır.
• IP ve user-agent: sunucunun gördüğü istemci bilgisi, sahte bir bot kimliği uydurmadan.

Piksel zaten tarayıcı bağlamındadır. CAPI ise kördür; körlüğü azaltan şey sipariş anında toplanan bu alanlardır. İki kanalın kullanıcı seti tamamen farklıysa event_id eşleşse bile tanılama ekranında “zayıf eşleşme” uyarısı çıkabilir. Amaç uyarıyı silmek değil, aynı kişinin aynı siparişini aynı olayda anlatmaktır.

Hassas veri burada reklam metni değildir. Gereksiz alan göndermeyin. Gönderdiğiniz alanı normalize edin. Hash kuralını piksel ile sunucuda ayrı yorumlamayın. Aynı e-posta bir yanda küçük harf, diğer yanda boşluklu giderse eşleşme zayıflar.

Çift gönderimi önleyen sunucu düzeni

Tekilleştirme Meta’nın işidir; sizin işiniz aynı olayı üç yerden rastgele basmamaktır. Sık görülen düzen şudur: teşekkür sayfası piksel atar, aynı sayfa bir AJAX ile CAPI tetikler, ödeme bildirimi bir kez daha CAPI atar. event_id doğru olsa bile üç yol bakımı zorlaştırır. Bir tarayıcı yolu, bir sunucu yolu yeter.

Sunucu yolunu siparişin kesinleştiği yere bağlayın. Ödeme sağlayıcısının bildirimi bu iş için uygundur. Bildirimin nasıl doğrulanacağı ayrı bir konudur; imza, tekrar teslimat ve sıra dışı durumlar ödeme ve kargo bildirimi akışında ele alınır. CAPI çağrısı, bildirimin “ödeme alındı” dediği anda, sipariş satırındaki event_id ile gider.

Teşekkür sayfasından ikinci bir sunucu Purchase atmayın. O sayfa yalnız piksele hizmet etsin. Sunucu yalnız sipariş durumuna hizmet etsin. Böylece tarayıcı kesilse bile CAPI durur; sunucu gecikse bile piksel erken sinyal verir; ikisi de aynı kimliği taşır.

1. Purchase için tek bir sunucu üreticisi seçin: sipariş servisi veya bildirim işleyicisi.
2. Bu üretici event_id’yi sipariş kaydından okusun, üretmesin.
3. Başarısız HTTP yanıtında kuyruk aynı gövdeyi tekrarlasın.
4. İade, iptal ve kısmi iade ayrı olay adlarıdır; Purchase kimliğini yeniden kullanmayın.
5. Test siparişlerini canlı piksele karıştırmayın; test kodu ayrı kalsın.

Özel entegrasyon gerekiyorsa yazılım geliştirme işi reklam panelindeki bir anahtarı yapıştırmaktan ibaret değildir. Sipariş durumu, tekrar deneme ve kimlik kolonu aynı sözleşmenin parçasıdır. Anahtar Events Manager’da durur; asıl karar sipariş servisinin hangi anda “bu Purchase gitti” demesidir.

Events Manager’da tekilleştirmeyi doğrulamak

Kurulum kodda bitmez. Canlı bir test siparişi, hem piksel hem CAPI için aynı event_id ile gitmelidir. Events Manager’daki test olayı ekranı bu iş için vardır. Test kodunu sunucu çağrısına ekler, tarayıcıda da aynı test oturumunu açarsınız. Amaç, iki olayın ayrı satır değil, eşleşmiş tek dönüşüm olarak görünmesidir.

Tanılama ekranı arayüz olarak değişebilir. Yine de bakılacak şeyler sabittir: event_id geldi mi, iki kanalda aynı mı, event_name standart mı, değer ve para birimi tutarlı mı, kullanıcı alanları boş mu. “Olay sayısı arttı” tek başına başarı değildir. Sayı, çift sayımdan da artar.

• Aynı sipariş numarasıyla bir test Purchase tamamlayın.
• Piksel çağrısındaki eventID ile CAPI event_id metnini yan yana kontrol edin.
• Events Manager’da bu kimliğin iki kaynakta tekrarlanıp tekileştiğine bakın.
• Değer, para birimi ve action_source alanlarını karşılaştırın.
• Canlıya almadan test kodunu kaldırın; canlı olayla test olayını karıştırmayın.

action_source, olayın nerede doğduğunu söyler. Sitedeki satın alma için her iki kanalda da website kullanmak sık görülen ve tutarlı bir seçimdir. Sunucuyu “bu olay sistemden doğdu” diye ayrı bir kaynakla göndermek, aynı event_id olsa bile yorumu dağıtır. Kaynağı gerçek akışa göre seçin; süs için değiştirmeyin.

Sık yapılan kurulum hataları

Hataların çoğu “API bağlı” cümlesinin ardında gizlenir. Bağlı olmak, tekilleştirilmiş olmak değildir. Aşağıdaki liste, şişmiş Purchase raporunun sık kaynaklarıdır.

• Piksel rastgele UUID, sunucu sipariş numarası kullanır.
• Piksel Purchase, sunucu AddPaymentInfo veya özel bir sipariş adı gönderir.
• Teşekkür sayfası hem piksel hem CAPI atar; bildirim bir CAPI daha atar; kimlikler dağınık kalır.
• Yeniden deneme her seferinde yeni event_id basar.
• fbp ve fbc siparişle saklanmaz; CAPI kör gider.
• Değer kuruş/lira veya KDV dahil/hariç olarak iki kanalda ayrılır.
• İade olayı Purchase olarak tekrarlanır.

Bu hataların reklam metniyle ilgisi yoktur. Kampanya kopyasını değiştirmek çift sayımı düzeltmez. Düzeltme, sipariş anındaki kimlik sözleşmesidir. Sözleşme oturunca piksel kesintisi yedeklenir; sözleşme yoksa yedek, ikinci bir satın alma gibi durur.

Google Ads dönüşüm etiketi, GA4 purchase ve Meta olayı aynı JavaScript dosyasında durabilir. Bu, onların da aynı event_id’yi paylaştığı anlamına gelmez. Her platform kendi kimliğini ister. Bu rehberin sınırı Meta piksel ile Meta Conversion API’dir. GA4 ölçüm kimliğini Meta event_id’si sanmak, üç raporu birden bozar.

Sıkça Sorulan Sorular

event_id olarak sipariş numarası kullanılabilir mi?

Evet, sipariş numarası kalıcı ve o satın almaya özgüyse uygun bir event_id’dir. Aynı numarayı piksel ve CAPI paylaşmalıdır. Aynı numarayı başka bir olay türünde tekrar kullanmayın.

Piksel hiç ateşlenmezse Conversion API tek başına sayılır mı?

event_id doğru olsa bile eşleşecek ikinci olay yoksa Meta sunucu olayını tek dönüşüm olarak işler. Tekilleştirme, iki olay varken birleştirir; tek olay varken yedek kanalın kendisi ölçüm olur.

Aynı event_id’yi günler sonra başka siparişte kullanmak sorun olur mu?

Evet. event_id o dönüşüm örneğine aittir. Yeni sipariş yeni kimlik alır. Eski kimliği yeniden basmak ayrı satın almaları tek olay gibi göstermesin diye kimliği sipariş kaydına bağlayın.

Google dönüşüm etiketindeki kimlik bu işi görür mü?

Görmez. Google dönüşüm ve GA4 kendi ölçüm bağlamlarında çalışır. Meta tekilleştirmesi event_name ve event_id çiftine bakar. Bu rehber o çifte odaklanır; Google kurulumunu buraya taşımayın.

İade, Purchase ile aynı event_id’yi mi almalı?

Hayır. İade ayrı bir olaydır. Purchase kimliğini iade satırında tekrarlamak, satın almayı geri sarmak yerine aynı olayı yeniden yazmak gibi durabilir. İade için ayrı olay adı ve ayrı kimlik kullanın; sipariş numarasıyla ilişkiyi kendi kaydınızda tutun.

Piksel ve sunucu olayını aynı sipariş kimliğiyle konuşturmak, reklam hesabının şişmesini kod tarafında keser. Ölçüm sözleşmesini sitenizle birlikte netleştirmek isterseniz KepezWeb’e teklif al sayfasından yazın. Sipariş anı, event_id ve CAPI yolunu birlikte sadeleştiririz.