Meta Conversions API kurulumu ve olay eşleşme kalitesi

Meta Conversions API, satın alma, kayıt veya form gönderimi gibi olayları tarayıcıya hiç uğramadan doğrudan kendi sunucunuzdan Meta'ya ilettiğiniz bir arayüzdür. Pikselin yerine geçmez, aynı olayı ikinci bir yoldan taşıyan paralel bir kanaldır. Bu yazı kavramsal tartışmayı değil kurulum tarafını ele alıyor: veri kümesini nasıl bağlarsınız, hangi entegrasyon yolunu seçersiniz, hangi müşteri alanlarını gönderirsiniz ve kurulumun gerçekten çalıştığını nasıl anlarsınız.

Kurulumdan önce: neyi çözer, neyi çözmez

Tarayıcı tarafındaki ölçüm, reklam engelleyiciler, çerez kısıtları ve olay gönderilmeden kapatılan sekmeler yüzünden olayların bir kısmını kaçırır. Sunucu tarafı gönderim bu kaybın bir bölümünü kapatır. Tarayıcı ile sunucu ölçümünün karşılaştırması başlı başına ayrı bir konu; buradaki varsayım pikselinizin zaten kurulu ve çalışıyor olduğu. Eğer temel kurulum henüz yoksa önce piksel kurulumunu tamamlayın, sunucu tarafını üstüne ekleyin.

Neyi çözmediğini de baştan yazmak gerekir. Yanlış tetiklenen bir olayı düzeltmez; yanlış olayı iki kanaldan birden gönderir. Eksik kalan gelir değerini tamamlamaz. Onay yönetimi ve KVKK tarafındaki yükümlülüklerinizi de ortadan kaldırmaz, çünkü veriyi kimin adına ve hangi izinle gönderdiğiniz değişmez. Bu rehber, verinin gönderilebilir olduğu varsayımıyla teknik kuruluma bakıyor.

Meta Conversions API kurulumunun omurgası: veri kümesi bağlantısı

Kurulumun tamamı tek bir şeye dayanır: sunucudan giden olayların, tarayıcıdan giden olaylarla aynı veri kümesine düşmesi. Events Manager içinde piksel olayları ve sunucu olayları aynı veri kümesi altında toplanır. İki ayrı veri kümesi açarsanız iki ayrı gerçek üretmiş olursunuz ve tekilleştirme hiçbir zaman devreye giremez.

Pratikte üç şeye ihtiyacınız var. Birincisi veri kümesi kimliği. İkincisi bu veri kümesi için üretilmiş bir erişim jetonu; bu jeton yalnızca sunucu tarafında, ortam değişkeni olarak durmalı, hiçbir koşulda ön yüz koduna veya depoya girmemeli. Üçüncüsü olayların gideceği uç noktanın sürüm bilgisi. Meta bu uç noktayı sürümler halinde yayınlar ve zorunlu alanlar sürümden sürüme değişebilir, bu yüzden entegrasyonu kurmadan önce güncel resmî dokümandaki alan listesini kendiniz kontrol edin.

Gönderdiğiniz her olayda taşıması gereken çekirdek alanlar da bellidir: olay adı, olayın gerçekleştiği zaman damgası, olayın nereden geldiğini belirten kaynak bilgisi ve olayın gerçekleştiği sayfanın adresi. Zaman damgasını sunucu saatinizden üretiyorsanız sunucunun saat diliminin doğru ayarlandığından emin olun; kayan bir saat, olayları geçmişe veya geleceğe yazar ve raporda sebebi bulunması zor bir sapma bırakır.

Hangi entegrasyon yolunu seçeceksiniz

Kurulum için birbirinden oldukça farklı üç yol var ve seçim teknik değil operasyonel bir karardır.

• Hazır platform entegrasyonu. E-ticaret altyapınızın kendi bağlantısını kullanırsınız. En hızlı yol ama olay şeması üzerinde kontrolünüz sınırlıdır. Shopify tarafındaki akış ayrı bir konu olduğu için burada girmiyorum.
• Doğrudan sunucu tarafı geliştirme. Sipariş oluşturma akışınıza kod yazarsınız. En çok kontrolü bu verir; hangi alanın gideceğine siz karar edersiniz. Karşılığında bakımı da siz üstlenirsiniz.
• Sunucu kapsayıcısı üzerinden. Etiket yöneticisinin sunucu tarafı kapsayıcısı olayları toplar ve iletir. Birden fazla platforma aynı anda gönderim yapıyorsanız mantıklı; barındırma ve maliyet tarafı ayrı bir tartışma.

Seçerken üç soruyu sorun: bu entegrasyonu altı ay sonra kim güncelleyecek, sipariş anındaki müşteri alanlarına erişimi var mı, ve bir olay şeması değiştiğinde değişikliği ne kadar sürede canlıya alabilirsiniz. Hangi yolu seçerseniz seçin, kurulum adımlarını Meta'nın güncel resmî dokümanından doğrulayın; ekran adları ve zorunlu alanlar dönem dönem değişiyor.

Hangi müşteri alanlarını göndereceksiniz

Bu, kurulumun en çok atlanan kısmı. Sunucudan gönderdiğiniz olayın bir kişiyle ilişkilendirilebilmesi için olayla birlikte müşteri bilgisi alanları da gitmelidir. Elinizde tipik olarak şunlar vardır: e-posta adresi, telefon numarası, ad ve soyad, şehir ve ülke bilgisi, bir de kendi sisteminizdeki müşteri kimliği. Bunların yanına sunucunun gördüğü IP adresi ve tarayıcı bilgisi eklenir.

Kritik nokta şu: iki alan sunucuda kendiliğinden yoktur, tarayıcıdan taşınması gerekir. Meta'nın tıklama ve tarayıcı çerezleri müşterinin tarayıcısında oluşur. Bu değerleri ödeme akışında yakalayıp sipariş kaydına yazmazsanız sunucu olayınız onlarsız gider. Kurulum planına bu adımı ayrı bir madde olarak yazın, çünkü sonradan eklemek sipariş tablosunda şema değişikliği demek.

Kişisel alanlar düz metin olarak değil, hashlenerek gönderilir. Normalizasyon kuralları (küçük harfe çevirme, boşlukları temizleme, telefonu ülke koduyla yazma) resmî dokümanda tanımlıdır ve harfi harfine uygulanmalıdır. Gönderdiğiniz alanların sayısı ve doğruluğu, Events Manager'daki olay eşleşme kalitesi puanını belirler; puanın nasıl okunacağı ve nasıl yükseltileceği ayrı bir konudur, burada kurulum kararına odaklanıyoruz.

Karar kuralı basit: zaten sahip olduğunuz alanları gönderin. Sırf skor için ödeme formuna yeni zorunlu alan eklemek, dönüşüm oranınıza dokunan ve izin metinlerinizi ilgilendiren ayrı bir karardır; ölçüm iyileştirmesi diye sessizce yapılmaz.

Aynı satın almanın iki kez sayılmaması

Aynı satın alma hem tarayıcıdan hem sunucudan gidiyorsa, iki olayın da aynı olay kimliği ve aynı olay adıyla gönderilmesi gerekir; Meta bu ikisini tek olay sayar. Kurulum sırasında yapmanız gereken tek şey, bu kimliği sipariş akışında bir kez üretip hem piksel çağrısına hem sunucu isteğine aynı değerle vermek. Tekilleştirmenin sessizce bozulduğu durumlar ve tekilleştirme raporunun okunması başlı başına bir konu; kurulum aşamasında kuralı uygulayın, yeter.

Kurulumu doğrulama ve canlıya alma

Canlıya almadan önce test olay kodunu kullanarak birkaç olayı gönderin ve Events Manager'ın test ekranında beklediğiniz alanların gerçekten geldiğini görün. Alan listesi ekranda görünmüyorsa gönderilmemiştir; varsayımla ilerlemeyin. Test aşamasında bakılacaklar şunlar:

• Olay adı, panelde tanımlı olay adıyla harfi harfine aynı mı.
• Müşteri bilgisi alanlarının kaçı tanınmış görünüyor.
• Tıklama ve tarayıcı çerezleri sunucu olayına gerçekten taşınmış mı.
• Aynı sipariş için piksel ve sunucu olayı tek olay olarak mı görünüyor.

Canlıya aldıktan sonra ilk hafta olay hacmini günlük izleyin. Piksel tarafında bir hata varsa sunucu tarafı onu maskeleyebilir; iki kanalın dağılımına ayrı ayrı bakın. Panelde tuhaf bir şey görürseniz önce piksel tarafındaki bilinen hataları eleyin.

Kapsama oranını kendi verinizle ölçün

Kurulumun işe yarayıp yaramadığını anlamanın en dürüst yolu, panelde görünen ham olay sayısını kendi sipariş kaydınızla karşılaştırmaktır. Bir örnek üzerinden gidelim.

Diyelim ki e-ticaret panelinizde bir ay içinde 600 sipariş var, Events Manager'da aynı ay 420 satın alma olayı görünüyor. 420 ÷ 600 = 0,70; yani olayların %70'i kaydedilmiş, 600 − 420 = 180 olay hiç ulaşmamış, bu da %30 kayıp demek. Sunucu tarafını açtıktan sonraki ay yine 600 siparişe karşılık 540 olay görüyorsanız 540 ÷ 600 = 0,90 olur. Olay sayısındaki artış 540 − 420 = 120; bu da 120 ÷ 420 ≈ 0,29 ile bir önceki aya göre yaklaşık %29 daha fazla kayıtlı olay anlamına gelir.

Buradaki rakamlar hesabın nasıl kurulduğunu göstermek için; sizin hesabınızda çıkacak oran tamamen kendi kurulumunuza bağlıdır ve bir vaat değildir. Önemli olan iki dönemde de aynı tanımı kullanmak: aynı olay adı, aynı takvim ayı, iptalleri ve iadeleri aynı biçimde ele alan aynı sipariş tanımı. Bu ölçüm ham olay sayısıyla ilgilidir; panelde raporlanan atfedilmiş dönüşüm sayısı başka nedenlerle de farklılaşır ve o ayrı bir konudur.

Son bir uyarı: olay sayısı değiştiğinde panelde raporlanan gelir ve dolayısıyla ROAS da değişir. Kurulum öncesi ve sonrası dönemi kıyaslamadan önce hesabı aynı tanımla yeniden yapın, yoksa ölçüm değişikliğini performans artışı sanırsınız. Sinyal tarafı düzeldiğinde otomatik hedefleme modelleri daha az eksik örnekle çalışır; eksik olay, modelin hiç görmediği bir müşteri demektir.