Meta Pixel ve Conversions API kurulumu, iki kanaldan mümkün olduğunca çok olay göndermek değildir. Amaç, gerçekleşen işlemi doğru kimlikle ve uygun veri kapsamıyla aktarmaktır. Aynı satış tarayıcıdan ve sunucudan gönderildiğinde iki ayrı satış gibi görünmemesi, teknik kabulün temel parçasıdır.
Olay sahipliğini tarayıcıdan sunucuya kadar çıkarın
Mağaza eklentisi, GTM etiketi, tema kodu ve sunucu entegrasyonunun hangi olayı gönderdiğini çıkarın. Bir kanalın kurulması, diğerinin devre dışı kaldığını kanıtlamaz. Özellikle eski eklenti kaldırıldıktan sonra kalan tema kodunu inceleyin.
Olay envanterinde olayın iş anlamı, oluştuğu yer, gönderim kanalı, kimlik kaynağı ve hata durumunu kaydedin. Sepete ekleme ile satın alma aynı işlem değildir. Ödeme ekranının açılması da siparişin gerçekleştiğini göstermediği için satın alma kaynağını işletmenin sipariş sistemiyle ilişkilendirin.
İşlem kaynağı ile gönderim yolu aynı kavram değildir
Satın alma sonucunu sipariş sistemi belirler; tarayıcı ve sunucu bu sonucu farklı yollarla aktarabilir. Sunucudan gönderilen olay sırf sunucudan geldiği için doğru değildir. Yanlış sipariş durumu veya para birimi iki kanalda aynı biçimde gönderilirse hata yalnız daha tutarlı hâle gelir. Önce olayın iş anlamını, sonra kanal sahipliğini tanımlayın.
Envanterde tema, platform bağlantısı, GTM ve özel entegrasyonu ayrı satırlarda gösterin. Eski bağlantı kapatıldıktan sonra kalan kodlar tekrar olay üretmeye devam edebilir. Kullanılmayan token veya test yapılandırmasının nasıl kaldırılacağı da devir dosyasında bulunmalıdır. Hesap erişimi olmadan bütün gönderimlerin tekilleştiği iddiası yapılmaz; kod incelemesi yalnız tasarımın bir bölümünü doğrular.
Aynı işlemi iki kanalda aynı kimlikle tanıyın
9 Ekim 2026 tarihinde incelenen Meta’nın resmî Business SDK ServerEvent kaynağı, event_id ile event_name alanlarını aynı olayın belirlenmesinde birlikte ele alıyor. Bu, hesabınızda tekilleştirmenin çalıştığına dair sonuç testi değildir; teknik tasarımın birincil dayanağıdır.
Temsili bir kabul senaryosunda DEMO-ORDER-01 işlemine ait Purchase olayı iki kanalda aynı olay kimliğiyle gönderilir. DEMO-ORDER-02 ise ayrı kimlik taşır. Her yeniden denemede yeni rastgele kimlik üretmek ilk işlemi ikinci kez saydırabilir; bütün müşterilerde aynı sabit kimliği kullanmak ise farklı satışları birbirine karıştırabilir.
Yeniden deneme ile yeni işlemi ayırın
Ağ hatası nedeniyle aynı kaydın yeniden gönderilmesi, yeni satış değildir. Kimliğin uygulamada hangi noktada üretildiğini ve kalıcı tutulduğunu belgeleyin. Sipariş düzenleme, başarısız ödeme ve iade için ayrıca olay sözleşmesi oluşturun; yalnız bir Purchase olayını her duruma uyarlamayın.
Kimlik kalıcı olmalı, farklı işlemleri birleştirmemeli
Meta'nın resmî SDK kaynağındaki event_id açıklaması, event_name ile birlikte aynı olayın belirlenmesini anlatır. Buradan bütün hesaplarda tekilleştirmenin başarıyla gerçekleştiği sonucu çıkmaz. Uygulama tasarımında kimliğin üretildiği nokta, saklandığı kayıt ve iki kanala nasıl ulaştırıldığı yazılmalıdır. Aynı siparişin tekrar gönderimi aynı olay olarak izlenirken ayrı gerçek işlem ayrı kimlik taşımalıdır.
Temsili hata: Tarayıcı sipariş kodunu kimlik olarak kullanır, sunucu ise her gönderimde yeni rastgele değer üretir. Aynı satış iki farklı işlem gibi görünebilir. Çözüm olay kimliğini güvenilir iş kaydına bağlayan ortak sözleşmedir. Kimliği yalnız geçici tarayıcı belleğinde tutmak, yenileme veya başka cihazdan açılma durumlarını tek başına çözmez.
Diğer sütunları görmek için yatay kaydırın.
| Senaryo | Beklenen ilişki | Kontrol sorusu |
|---|---|---|
| Tek satış, iki kanal | Aynı olay kimliği ve anlamı | Aynı gerçek işlem eşleniyor mu? |
| Aynı gönderimin tekrarı | Yeni satış oluşturmayan tekrar | Kimlik yeniden üretiliyor mu? |
| İkinci gerçek sipariş | Ayrı olay kimliği | Sabit kimlik işlemleri birleştiriyor mu? |
| Başarısız ödeme | Başarılı satış olarak gönderilmeme | Olay yanlış durumdan mı üretiliyor? |
Zaman, ürün ve tutar aynı iş kaydını anlatmalı
Sunucu olayının oluşma zamanı ile gönderilme zamanı farklı olabilir. SDK kaynağında event_time saniye cinsinden Unix zamanıyla tanımlanır; milisaniye değerini doğrudan taşımayın. Zaman dilimi dönüşümü ve kuyruğun gecikmesi için örnek kayıt inceleyin.
Tutarın neyi kapsadığını da belirleyin: ürün toplamı, indirim, teslimat ve vergiler hangi muhasebe tanımıyla raporlanıyor? İki kanal farklı tutar gönderiyorsa platform ekranındaki tek toplamı doğru kabul etmeyin. Para birimini ayrı doğrulayın; bu rehber güncel bir SDK sürümüne hazır bağlantı kodu sunmaz.
Kuyruk gecikmesini olayın gerçekleşme zamanından ayırın
Gönderimin gecikmesi, işlemin sonradan gerçekleştiği anlamına gelmez. Olay zamanı ile gönderim zamanını günlüklerde ayrı tutun. SDK'daki zaman alanının birimini doğru uygulayın; milisaniye ve saniye karışıklığı yalnız görünüm hatası değildir. Geç gelen veya yeniden gönderilen kayıtların güncel kabul koşulları doğrudan resmî belge ve hesap teşhisiyle doğrulanmalıdır; burada sabit bir kabul penceresi uydurulmuyor.
İki kanalın ürün kimliği, para birimi ve değer tanımı da tutarlı olmalıdır. Bir kanalda indirim öncesi, diğerinde indirim sonrası tutar kullanılması rapor farkını açıklayabilir. Sipariş düzenlemesi ve kısmi iade ayrı iş durumlarıdır. Bunları aynı Purchase olayını tekrar göndererek modellemeye çalışmak yerine olay sözleşmesini ve kullanılacak platform yöntemini ayrıca değerlendirin.
İzin ve erişim kontrolü bütün gönderim yollarını kapsar
Tarayıcı etiketi çalışmadığında sunucu gönderimiyle bütün izin kontrollerini aşan bir yapı kurmayın. Hangi veri alanının hangi amaçla işlendiğini değerlendirin. Hash uygulanması, veriyi kendiliğinden anonim veya hukuken serbest hâle getirdiği anlamına gelmez.
Erişim token’ını tarayıcı koduna, HTML’e veya açık hata günlüklerine koymayın. Test kayıtlarında gerçek kişisel bilgileri gereksiz yere saklamayın. Entegrasyonun başarısız olması sipariş işlemini engellememeli; hata izleme, tekrar deneme ve erişim sorumluluğu ayrı tasarlanmalıdır.
Sunucu bağlantısı tarayıcı iznini aşma yöntemi olarak tasarlanmamalıdır. İşlenen alanların amacı, kaynağı, aktarım kapsamı ve saklama ihtiyacı veri planında değerlendirilir. Hash uygulanması kişisel veriyi otomatik anonimleştirmez. Bu rehber hukuki uygunluk onayı vermez; ilgili işletme koşulları yetkili kişilerce incelenmelidir.
Hata günlükleri de veri aktarımının parçasıdır
Token, ham müşteri bilgisi veya bütün istek gövdesi açık günlüklere yazılmamalıdır. Sorun incelemesi için gerekli işlem referansı ve güvenli hata bilgisiyle sınırlı kayıt tasarlayın. Yetkili kişilerin erişimi ve saklama ihtiyacı belirlenmelidir. Ölçüm gönderimi başarısız olduğunda gerçek sipariş kabulünü engelleyen bir yapı kurulması ayrıca operasyon riski yaratır.
Kabul dosyası ve uygulama sonrası takip
Başarısız gönderim kuyruğunun sahipliği de tasarlanmalıdır. Aynı hatayı sürekli tekrar etmek yerine hata türüne göre kimlik, veri veya yetkilendirme sorununu ayırın. Tekrar denenecek kayıt, ilk işlem referansını korumalıdır. Sorun giderilince bütün geçmiş olayları kontrolsüz toplu göndermek yerine güncel kabul koşulları ve veri kapsamı incelenir.
Tarayıcıdan alınan bir olay kimliğinin sunucuda her sipariş için güvenilir kabul edilmesi ayrıca değerlendirilmelidir. Yetkisiz bir isteğin başka işleme ait kimliği kullanamaması gerekir. Sipariş sahipliği ve olay üretim yetkisi teknik katmanda doğrulanmalıdır; tekilleştirme tasarımı kimlik doğrulamanın yerine geçmez. Güvenlik testi, ölçüm sayısının kontrolünden farklı bir kabul adımıdır.
Önce tek kanal, sonra iki kanal ve yeniden deneme senaryolarını kontrollü test edin. İşletme kayıtlarında bir sipariş bulunurken olay incelemesinde aynı işlemin doğru eşlendiğini kontrol edin. Başarısız ödeme, tekrar sayfa açma ve ikinci gerçek sipariş de test kapsamına girer.
Meta geliştirici dokümanlarının tamamına doğrudan erişim bu araştırmada kısıtlıydı; güncel hesaba özgü teşhis ekranı ve kabul koşulları uygulama sırasında doğrulanmalıdır. Meta Ads ölçüm çalışmasına bu kontrolleri ekleyin. Ürün eşleştirmesi için katalog reklamları rehberini de kullanın. Teknik kabul, satış artışı garantisi değildir.
API'nin isteği kabul etmesi, olayın doğru eşleştiğini veya reklam atfında beklenen sonucu verdiğini tek başına göstermez. Kontrollü işlemin gerçek sipariş kaydını, iki kanalın güvenli olay referanslarını ve hesap teşhisini birlikte inceleyin. Test ortamındaki sonucu gerçek müşteri satış artışı gibi sunmayın. Uygulama kabulü ile kampanyanın ticari etkisi ayrı değerlendirmelerdir.
Devir dosyasında olay envanteri, kimlik kuralı, yeniden deneme davranışı, erişim sahibi ve hata izleme yöntemi bulunmalıdır. Entegrasyon sürümü değiştiğinde örnek kabul senaryolarını yeniden çalıştırın. Özellikle eklenti güncellemesi sonrası ikinci bir gönderim yolu eklenip eklenmediğini kontrol edin. Amaç daha yüksek olay sayısı değil, gerçekleşen işlemin doğru ve sınırları bilinen biçimde temsil edilmesidir.
