Meta Piksel ve Conversion API Kurulumu

İki katmanın görev dağılımını baştan yazın

Önce bir olay sözlüğü hazırlayın: olay adı, gerçek tetiklenme koşulu, tarayıcı ve sunucu kaynağı, kimliği üreten sistem ve sorumlu ekip. Purchase için işletmenin tamamlanmış sipariş tanımı açık olmalı; ödeme bekleyen kayıt ile tahsil edilmiş siparişin aynı sayılıp sayılmayacağı tesadüfe bırakılmamalıdır.

Aynı Purchase olayının hem Piksel hem CAPI ile iletilmesi olağandır. İki kaynak için olay adı ve kimliğini eşleştirin. Olayın sunucudan gelmesi, iptal ve iadelerin bütün raporlardan otomatik düşeceği anlamına gelmez; satış sonrası durumları ve mali raporlamayı ayrıca tasarlayın.

Tabloyu yana kaydırarak inceleyin.

Piksel kurulumu ve olay eşlemesi

Önce sitedeki mevcut etiket, eklenti ve platform bağlantılarını sayın; yeni entegrasyon mevcut olayları ikinci kez göndermemeli. Pikseli veri toplama tercihleri ve sayfanın niteliğine uygun çalıştırın. Ürün incelemesi ViewContent, başarılı sepete ekleme AddToCart, ödeme başlangıcı InitiateCheckout gibi ayrı koşullara bağlanabilir. Hangi ekranın açıldığı kadar işlemin gerçekten tamamlanıp tamamlanmadığını da kontrol edin.

Kurulumdan sonra Events Manager'da olayların geldiğini görün ama tek başına orada durdurmayın: gerçek bir test siparişini uçtan uca yürütün ve her adımın doğru olayı tetiklediğini doğrulayın. Onay sayfası yenilendiğinde yeni bir satın alma kaydediliyorsa ölçümünüz şişer; bu hatayı test siparişiyle yakalamak en hızlı yoldur.

Yenileme ve yeniden denemeyi aynı işlemle eşleştirin

Onay ekranı yenilendiğinde yeni Purchase kimliği üretmeyin. Aynı siparişin tekrar webhook veya ağ denemeleri, kalıcı olay kaydı üzerinden aynı kimlikle işlenmelidir. Sunucuya taşımak tek başına tekrarları kapatmaz; işlemin bir kez oluşması ve yeniden iletilmesi arasındaki ayrımı kodda koruyun.

Conversions API için aktarım yolunu seçin

Platformun partner entegrasyonu, doğrudan sunucu bağlantısı veya uygun bir ağ geçidi değerlendirilebilir. Kararı hazır bağlantının desteklediği olaylar, bakım sorumluluğu, veri kontrolü ve mevcut altyapıyla uyum üzerinden verin. Doğrudan geliştirme her mağaza için otomatik olarak daha güvenilir değildir; izleme ve bakım yükünü de üstlenmek gerekir.

Olay zamanı, kaynak, ad ve kimlik alanlarının yanında yalnız amaç için uygun eşleştirme verilerini kullanın. E-posta ve telefon gibi alanlarda Meta’nın normalleştirme ve hash kurallarını izleyin; bütün alanlara aynı işlemi uygulamayın. Hash uygulanması veriyi anonim hale getirmez. Veri toplama tercihleri ve ilgili kurallar sunucu akışında da korunmalı; erişim anahtarı tarayıcı koduna yazılmamalıdır.

Olay kuyruğunu ve tekrar gönderimi tasarlayın

Sunucu gönderimi ağ hatalarıyla karşılaşabilir; başarısız olayı yeniden gönderme düzeni kurun ama aynı olayın iki kez gitmemesi için bir olay kimliği tutun. Bu, özellikle satın alma olayında rapor güvenliğini belirleyen teknik detaydır.

İkileme ve doğrulama testleri

Tarayıcı ve sunucu aynı işlemi gönderiyorsa event_name ile event_id değerleri eşleşmelidir. Farklı gerçek işlemler için farklı kimlikler, aynı olayın yeniden iletiminde aynı kimlik kullanılmalıdır. Entegrasyonun Meta’ya kabul edilmiş yanıt alması, satın almanın reklam raporuna atfedildiğini tek başına kanıtlamaz. Testi işlem düzeyinde yürütün.

• Kontrollü test siparişinin kimliğini ve tetiklenme zamanını kaydedin.
• Piksel ve sunucu kaydının aynı olay adına ve kimliğine sahip olduğunu doğrulayın.
• Onay ekranını yenileyin, ödeme başarısızlığını ve tekrar bildirimi deneyin.
• Test olaylarında kaynak ve tekrar ayıklamayı inceleyin; sorunlu bileşeni test ortamında izole edin.
• Gönderim hatalarını, gecikmeyi ve veri toplama tercihine göre beklenen eksikleri ayrı raporlayın.

Olay alımı ile reklama atfı ayırın

Events Manager’daki alınan olaylar ile Ads Manager’da reklama atfedilen satın almalar aynı rapor değildir. Mağazanın bütün siparişlerinin reklama yazılması beklenmez. Saat dilimi, rapor dönemi, atıf penceresi, gönderim gecikmesi ve iptal tanımlarını eşitlemeden sayıları karşılaştırmayın. Açıklanamayan farkı “normal” diye kapatmak yerine örnek işlem üzerinden araştırın.

Reklam tarafına bağlanırken tanımları netleştirin

Optimizasyon olayını işletmenin ulaşmak istediği sonuç, olayın doğruluğu ve kullanılabilir sinyal hacmi birlikte belirler. Satın alma temel hedef olabilir; form odaklı işlerde nitelikli başvuru farklı bir tanım gerektirir. Farklı paydalı huni oranlarından en küçük yüzdeyi seçmek doğru yöntem değildir. Üst aşama bir eylemi kullanıyorsanız gerçek satışla ilişkisini ayrıca izleyin.

Kampanya raporunda kullanılan atıf penceresini, zaman dilimini ve karşılaştırma dönemini belirtin. Bir kanalın kendisine atfettiği satışları diğer kanalların sayılarıyla toplamak tekil toplam satış vermez. Meta Ads yönetimi kampanya hedeflerini, özel yazılım çalışması ise sunucu akışının güvenilirliğini aynı olay sözlüğüne bağlayabilir.

Bakım: ölçümün bozulması sessiz olur

Tema, ödeme sağlayıcısı veya eklenti değişikliği ölçümü sessizce bozabilir. Her ilgili sürümden sonra test akışını tekrarlayın; düzenli inceleme sıklığını işlem hacmine göre belirleyin. Ani olay kaybı ya da beklenmedik artış için izleme kurmak, yalnız ay sonu raporuna bakmaktan daha erken uyarı verir.

• Başarılı ve başarısız ödeme senaryolarını yeniden deneyin.
• Olay hacmini kampanya, stok ve site değişiklikleriyle birlikte yorumlayın.
• Gönderim hatalarında yeniden deneme ve kalıcı hata kuyruğunu inceleyin.
• Sipariş verisi, alınan olaylar ve reklama atfedilen satışları ayrı sütunlarda tutun.

Sonuç

Kurulumdan önce olay sözlüğünü yazın, her gerçek işleme kararlı bir kimlik verin ve tarayıcı-sunucu eşleşmesini test siparişiyle doğrulayın. Ardından aktarım sağlığı ile reklam atfını ayrı izleyin. Worgoo E-Ticaret kapsamında bu çalışma; mağaza altyapısı, veri tercihleri ve reklam yönetiminin ortak sorumluluğudur.