Meta Conversions API Nedir? Piksel Kayıplarını Sunucu Tarafında Kapatma Rehberi

Meta Conversions API, web sitenizdeki satış, form ve sepet olaylarını tarayıcı yerine sunucunuzdan doğrudan Meta'ya gönderen bir bağlantıdır. Bu rehberde ne işe yaradığını, pikselle nasıl birlikte çalıştığını, tekrarlanan olayları nasıl ayıkladığını ve KVKK açısından nelere dikkat etmeniz gerektiğini anlatıyoruz. Talha Aslan ve ekibi olarak kurulumları sahada nasıl kontrol ettiğimizi de paylaşıyoruz.

Meta'nın geliştirici belgelerine göre Meta, sunucudan gelen olayları bir veri kümesi kimliğine bağlar ve piksel olaylarıyla aynı biçimde işler. Yani reklam yöneticisinde gördüğünüz satın alma veya potansiyel müşteri sayıları, iki kaynaktan gelen olayların birleşimidir. Bu da kampanyanın neyi optimize edeceğini daha net öğrenmesini sağlar.

Peki neden ihtiyaç duyarsınız? Çünkü tarayıcı tarafı ölçüm, reklam engelleyiciler, tarayıcı gizlilik ayarları, yavaş bağlantılar ve sayfadan erken çıkışlar yüzünden bazı olayları kaybeder. Sunucu tarafı bağlantı bu kayıpları tamamen ortadan kaldırmaz, ancak olay akışını tarayıcıya bağımlı olmaktan çıkarır.

Piksel ile Conversions API arasındaki fark nedir?

Meta pikseli, sitenizin sayfalarına yerleşen ve ziyaretçinin tarayıcısında çalışan bir koddur. Conversions API ise aynı olayı sizin sunucunuzdan gönderir. İkisi rakip değil, birbirini tamamlayan iki kanaldır. Meta da ikisini birlikte kullanmayı önerir.

Pikselin kurulumunu henüz yapmadıysanız önce Meta Pixel nedir rehberimizle başlayın. Ayrıca alan adınızı doğrulamak, olay yapılandırmasının sağlıklı çalışması için iyi bir temeldir; adımları Meta etki alanı doğrulama yazımızda bulabilirsiniz.

Piksel kayıpları neden oluşur?

Tarayıcı tarafı ölçümde kayıp tek bir nedene bağlı değildir. Sahada en sık gördüğümüz nedenleri şöyle sıralayabiliriz:

• Reklam engelleyici eklentiler piksel isteğini durdurur.
• Tarayıcıların gizlilik özellikleri üçüncü taraf çerezlerini ve izleme isteklerini kısıtlar.
• Mobil uygulamalardaki izin istemleri reklam ölçümünü sınırlar.
• Ziyaretçi teşekkür sayfası yüklenmeden sekmeyi kapatır.
• Çerez onay bandı, kullanıcı karar vermeden pikseli çalıştırmaz.
• Ödeme adımı başka bir alan adına gider ve geri dönüş olmaz.

Listedeki son iki madde özellikle önemlidir. Çerez onayı reddedildiğinde olayı başka yoldan göndermek, onayı atlatmak anlamına gelir; bunu yapmamalısınız. Dolayısıyla Conversions API bir "onay boşluğu kapatma" aracı değildir. Teknik kayıpları azaltan, izin kurallarına uyan bir ikinci kanaldır. iOS tarafındaki izin mekanizmasının etkisini uygulama takip şeffaflığı yazımızda anlattık.

Conversions API hangi olayları gönderebilir?

Geliştirici belgelerine göre Conversions API web sitesi, uygulama, işletme mesajlaşması ve çevrim dışı dönüşüm olaylarını taşıyabilir. Pratikte çoğu işletme şu olaylarla başlar:

1. Satın alma: sipariş tamamlandığında, ödeme onayından sonra.
2. Potansiyel müşteri: form gönderildiğinde veya teklif talebi geldiğinde.
3. Sepete ekleme ve ödeme başlatma: e-ticaret hunisinin ara adımları.
4. Kayıt tamamlama: üyelik veya bülten kaydında.
5. Çevrim dışı satış: CRM'de satışa dönen fırsatlar.

Son madde, Conversions API'nin pikselin hiç yapamadığı bir işi gösterir. Örnek senaryo: bir hizmet firması web formundan gelen talebi telefonla satışa çeviriyor. Bu satış tarayıcıda gerçekleşmediği için piksel onu göremez. Ancak CRM'den sunucu tarafı olay olarak gönderdiğinizde kampanya, form dolduran değil gerçekten satın alan kişiyi tanımayı öğrenir.

Kurulum için hangi yollar var?

Meta Conversions API kurulumunda üç ana yol vardır. Hangisini seçeceğiniz teknik kaynağınıza, sitenizin altyapısına ve göndermek istediğiniz olayların karmaşıklığına bağlıdır.

Geliştirici belgelerine göre pikseli olan reklamverenler web sitesi olayları için Conversions API'yi Olay Yöneticisi'nden kod yazmadan kurabilir. Bu yol hızlıdır; ancak hangi olayların ve hangi müşteri bilgilerinin gittiğini yine kontrol etmeniz gerekir. Doğrudan entegrasyonda ise sunucunuz Meta'nın uç noktasına istek gönderir ve her alanı siz belirlersiniz.

İş ortağı entegrasyonunda ise en sık karşılaştığımız sorun, platformun pikselle aynı olay kimliğini üretip üretmediğinin bilinmemesidir. Bu nedenle hangi yolu seçerseniz seçin, kurulumdan hemen sonra test olaylarıyla tekrar ayıklamanın çalıştığını doğrulayın. Ayrıca aynı olayı hem eklentiden hem de elle eklenen bir koddan göndermediğinizden emin olun.

Hangi yolun size uyduğuna karar veremiyorsanız ya da mevcut kurulumda olay sayıları tutarsızsa, işi baştan doğru planlamak zaman kazandırır. Bu denetimi ve kurulumu meta reklam yönetimi hizmetimiz kapsamında kampanya hedeflerinizle birlikte ele alıyoruz.

Doğrudan entegrasyon kavram düzeyinde nasıl çalışır?

Doğrudan entegrasyonda kod örneği vermeden mantığı anlatalım. Siteniz bir olay gerçekleştiğinde, örneğin sipariş onaylandığında, sunucunuz bir işlem başlatır. Bu işlem olay adını, olay zamanını, olayın gerçekleştiği sayfa adresini, benzersiz bir olay kimliğini ve müşteri bilgilerini toplar. Ardından bunları Meta'nın sunucusuna güvenli bir istekle iletir.

Geliştirici belgelerine göre bu bağlantı için üç ön koşul vardır:

• Bir piksel kimliği: sitenizde piksel varsa tarayıcı ve sunucu olayları için aynısını kullanın.
• Meta Business Suite erişimi.
• Her istekte gönderilen bir erişim belirteci.

Erişim belirtecini Olay Yöneticisi'nde pikselin ayarlarından oluşturabilirsiniz. Belgelere göre bu bağlantıyı yalnız geliştirici yetkisine sahip kullanıcılar görür. Belirteç bir parola gibidir; bu nedenle onu web sayfasının kaynak koduna, paylaşılan belgelere veya e-postaya koymayın. Yalnız sunucu tarafında, erişimi kısıtlı bir yerde saklayın.

Deduplikasyon nedir ve event_id neden gerekir?

Deduplikasyon, aynı olayın hem pikselden hem de sunucudan gelmesi durumunda Meta'nın bunları tek olay olarak saymasıdır. Pikselle birlikte çalışan her kurulumda bu ayar zorunludur. Aksi halde bir satış iki satış gibi durur ve kampanya verisi şişer.

Meta'nın resmi deduplikasyon belgesine göre önerilen yöntem şudur: tarayıcıdaki olay kimliği ile sunucudaki event_id aynı olmalı, olay adları da birebir eşleşmelidir. İki olay bu koşulu sağladığında Meta genellikle ilk geleni tutar. Belgeye göre bu eşleştirme, aynı event_id ile gelen ilk olaydan sonraki 48 saat içinde gelen olaylar için çalışır.

Belge alternatif olarak fbp veya external_id değerlerinin tutarlı gönderilmesini de anlatır. Ancak bu yol yalnız tarayıcı olayı önce geldiğinde çalışır. Bu nedenle sahada event_id yöntemini tercih ediyoruz. Pratikte en kolay yol, siparişlerde sipariş numarasını, formlarda ise form kayıt numarasını olay kimliği olarak kullanmaktır; çünkü bu değer hem tarayıcıda hem sunucuda zaten mevcuttur. Çift sayımı nasıl teşhis edip düzelteceğinizi ayrıntılı olarak yinelenen etkinlik ve çift sayım rehberimizde anlattık.

Olay eşleştirme kalitesi ne anlama gelir?

Olay eşleştirme kalitesi, sunucudan gönderdiğiniz olayların bir Meta hesabıyla ne ölçüde eşleşebildiğini gösteren bir puandır. Bu puanı Olay Yöneticisi'nde her olay için ayrı ayrı izlersiniz. Puan düşükse olay gelir ama kime ait olduğu belirsiz kalır; dolayısıyla optimizasyona katkısı azalır.

Puanı belirleyen ana etken, olayla birlikte gönderdiğiniz müşteri bilgisi alanlarıdır. E-posta, telefon, ad, şehir gibi alanlar ile tarayıcıdan gelen tanımlayıcılar eşleşme şansını artırır. Ancak her alanı göndermek zorunda değilsiniz; elinizde gerçekten olan ve göndermeye hukuki dayanağınız bulunan alanları ekleyin.

Puanın nasıl yorumlandığını ve hangi alanların etkisinin büyük olduğunu Meta Event Match Quality yazımızda ayrıca ele aldık. Bu rehberde ise yalnız Conversions API kurulumuyla ilgili kısmına odaklanıyoruz.

Hangi müşteri bilgilerini gönderirsiniz ve nasıl hazırlarsınız?

Meta'nın müşteri bilgisi parametreleri belgesi alanları iki gruba ayırır. Birinci grup, göndermeden önce SHA-256 ile karma değere dönüştürmeniz gereken alanlardır. İkinci grup ise karma işlemine tabi tutmamanız gereken teknik tanımlayıcılardır.

• Karma değere dönüştüreceğiniz alanlar: e-posta, telefon, ad, soyad, doğum tarihi, cinsiyet, şehir, eyalet veya bölge, posta kodu, ülke.
• Karma işlemine sokulmayacak alanlar: IP adresi, tarayıcı kullanıcı aracısı bilgisi, fbc ve fbp tanımlayıcıları.
• external_id için belge karma işlemini önerir ama zorunlu tutmaz.

Göndermeden önce veriyi normalleştirmeniz gerekir. Örneğin belgeye göre e-postanın baştaki ve sondaki boşluklarını silersiniz ve küçük harfe çevirirsiniz; telefon numarasından sembolleri ve baştaki sıfırları çıkarır, ülke kodunu eklersiniz. Normalleştirmeyi atlarsanız aynı kişi farklı karma değer üretir ve eşleşme düşer. Bu nedenle kurulumdan sonra birkaç test olayını mutlaka kontrol edin.

KVKK açısından nelere dikkat etmelisiniz?

Conversions API, kişisel veriyi sizin sunucunuzdan bir üçüncü tarafa aktarır. Karma işlemi veriyi okunamaz hale getirse de bu aktarımın hukuki dayanağını kurmak sizin sorumluluğunuzdadır. KVKK kapsamında aydınlatma metni, açık rıza gerekip gerekmediği ve yurt dışına aktarım konuları özellikle önemlidir.

Uygulamada şu ilkeleri öneriyoruz:

1. Çerez ve pazarlama onayı vermemiş ziyaretçinin olayını sunucudan da göndermeyin.
2. Yalnız gerçekten ihtiyaç duyduğunuz müşteri bilgisi alanlarını ekleyin.
3. Aydınlatma metninde Meta'ya veri aktarımını açıkça belirtin.
4. Erişim belirtecini ve sunucu kayıtlarını yetkisiz erişime karşı koruyun.
5. Saklama süresini ve silme taleplerini nasıl karşılayacağınızı yazılı hale getirin.

Bu yazı hukuki danışmanlık değildir. Kendi durumunuz için bir hukuk danışmanına veya veri koruma uzmanına başvurun. Web sitesi tarafındaki genel uyum adımlarını KVKK ve GDPR uyumlu web sitesi yazımızda, çerez onayının reklam verisine etkisini ise Consent Mode v2 rehberimizde anlattık.

Kurulumdan sonra olayları nasıl test edersiniz?

Kurulumun çalıştığını varsaymak yerine kanıtlamanız gerekir. Geliştirici belgeleri de son adım olarak olayların alındığını, tekrarların ayıklandığını ve eşleşmenin doğru çalıştığını doğrulamayı ister. Şu sırayla ilerleyin:

1. Olay Yöneticisi'nde test olayları bölümünü açın.
2. Sitenizde gerçek bir test siparişi veya form gönderimi yapın.
3. Olayın hem tarayıcıdan hem sunucudan geldiğini görün.
4. İki olayın tek olay olarak birleştiğini kontrol edin.
5. Olay eşleştirme kalitesi puanının hangi alanlarla oluştuğuna bakın.
6. Birkaç gün sonra olay sayılarını sipariş sisteminizle karşılaştırın.

Ekiplerin çoğu son adımı atlar. Oysa reklam paneli ile sipariş sistemi arasındaki fark, kurulumun gerçek sağlığını gösterir. Bu iki sayı arasında makul bir uyum görmeden kampanya kararlarını yeni veriye dayandırmayın.

Test sırasında ekipçe bir not tutun. Hangi tarihte hangi olayı denediğinizi, sonucu ve gördüğünüz uyarıyı yazın. Böylece ileride bir sorun çıktığında değişikliğin ne zaman başladığını kolayca bulursunuz. Ayrıca test siparişlerini gerçek satış raporlarından ayırmak için onları sipariş sisteminde işaretleyin.

Sık yapılan kurulum hataları nelerdir?

Sahada gördüğümüz hataların büyük bölümü birkaç kalıpta toplanır:

• Tarayıcı ve sunucu olaylarına farklı olay kimliği vermek: çift sayıma yol açar.
• Olay adlarını farklı yazmak: biri "Purchase", diğeri özel bir ad olunca eşleşme olmaz.
• IP adresini karma değere çevirmek: belgeye göre IP adresi her zaman ham haliyle gider.
• E-postayı normalleştirmeden karma değere çevirmek: eşleşme düşer.
• Satın alma olayını sipariş onayından önce göndermek: iptal olan siparişler de satış gibi rapora girer.
• Onay vermeyen ziyaretçinin verisini sunucudan göndermek: hukuki risk doğurur.

Bu hataların ortak noktası şudur: panelde olaylar akar, dolayısıyla ekip kurulumun çalıştığını düşünür. Ancak sayılar ya şişer ya da eşleşme düşük kalır. Bu nedenle "olay geliyor" demek yeterli değildir; doğru, tekil ve eşleşebilir gelmesi gerekir.

Conversions API kampanya performansını nasıl etkiler?

Daha eksiksiz olay verisi, algoritmanın kimin dönüşüm yaptığını daha iyi öğrenmesini sağlar. Bu da teslimat kalitesine ve ölçülen sonuçlara olumlu yansıyabilir. Ancak Conversions API tek başına daha çok satış getirmez; mevcut satışları daha doğru görmenizi sağlar.

Bu ayrım önemlidir. Örnek senaryo: kurulumdan sonra raporlanan satın alma sayısı artıyor. Bu artışın bir kısmı gerçek bir performans artışı değil, daha önce görünmeyen satışların artık görünmesidir. Dolayısıyla kurulum öncesi ve sonrası dönemi doğrudan karşılaştırırken dikkatli olun.

Daha sağlıklı bir yöntem, kurulumdan sonraki birkaç haftayı yeni bir başlangıç noktası kabul etmektir. Bu dönemde bütçeyi ve kreatifleri olabildiğince sabit tutun. Ardından maliyet, dönüşüm oranı ve sipariş sistemiyle uyum gibi göstergeleri bu yeni başlangıca göre izleyin. Böylece ölçüm değişikliğinin etkisini performans değişikliğiyle karıştırmazsınız.

Raporu okurken ilişkilendirme ayarını da göz önünde bulundurun. Hangi pencerenin hangi dönüşümü saydığını Meta ilişkilendirme ayarları yazımızda anlattık. Ayrıca harcama ile geliri karşılaştırmak için ROAS hesaplayıcı aracımızı kullanabilirsiniz.

E-ticaret ve hizmet işletmesinde kurulum nasıl farklılaşır?

E-ticaret sitesinde öncelik satın alma ve sepet olaylarıdır. Bu olayların sipariş numarası, tutar ve para birimiyle eksiksiz gitmesi gerekir. Sipariş numarasını olay kimliği olarak kullanmak, tarayıcı ve sunucu tarafında aynı değeri üretmenin pratik bir yoludur.

Hizmet işletmesinde ise asıl değer çoğu zaman formdan sonra gelir. Form gönderimi bir potansiyel müşteri olayıdır, ancak gerçek iş satış görüşmesinden sonra kapanır. Bu nedenle CRM'deki aşamaları sunucu tarafı olay olarak göndermek, kampanyanın nitelikli talebi tanımasına yardım eder.

Formdan CRM'e veri akışını nasıl kuracağınızı CRM entegrasyonlu web sitesi yazımızda anlattık. Süreci otomatikleştirmek isterseniz CRM otomasyonu çözümümüz de bu veri akışını düzenlemeye yardım eder.

Olay planını kurulumdan önce nasıl hazırlarsınız?

Kuruluma başlamadan önce hangi olayı, hangi anda ve hangi bilgilerle göndereceğinizi yazılı bir plana dökün. Bu plan, geliştirici ile pazarlama ekibinin aynı dili konuşmasını sağlar. Ayrıca sonraki denetimlerde başvuracağınız tek kaynak olur.

Tablodaki örnekler bir başlangıç şablonudur. Kendi sitenizde olay adlarını Meta'nın standart olay adlarıyla eşleştirin ve özel olayları gerçekten ihtiyaç duyduğunuzda kullanın. Böylece raporlar sade kalır ve kampanya amacı ile olay arasında net bir bağ oluşur.

Değer ve para birimi bilgisini neden göndermelisiniz?

Satın alma olayında yalnız olayın gerçekleştiğini değil, ne kadar değer ürettiğini de göndermek önemlidir. Tutar ve para birimi bilgisi, değer odaklı optimizasyonu ve getiri raporlarını mümkün kılar. Bu bilgiler eksikse kampanya her satışı eşit görür.

Örnek senaryo: bir mağaza hem düşük hem yüksek sepet tutarlı ürünler satıyor. Değer bilgisi gitmediğinde kampanya ucuz ürünü alan kişiyi de pahalı ürünü alan kişiyi de aynı başarı sayar. Değer bilgisi gittiğinde ise yüksek değerli alıcılara yönelme şansı doğar.

Dikkat etmeniz gereken nokta tutarlılıktır. Tarayıcı ve sunucu tarafında aynı olay için farklı tutar göndermeyin. Ayrıca vergi ve kargo dahil mi hariç mi göndereceğinize bir kez karar verin ve tüm kanallarda aynı kuralı uygulayın. Aksi halde ROAS hesaplarınız tutarsız çıkar.

Birden fazla piksel veya site varsa ne yapmalısınız?

Birden fazla marka, dil sitesi veya alt alan adı yönetiyorsanız piksel yapısı hızla karmaşıklaşır. Genel kural şudur: aynı sitede tarayıcı ve sunucu olayları için aynı piksel kimliğini kullanın. Geliştirici belgeleri de bunu açıkça önerir.

Ayrı markalar için ayrı veri kümeleri tutmak raporları netleştirir. Ancak aynı ziyaretçinin bir sitede başlayıp diğerinde satın aldığı yapılarda olay akışını önceden planlamanız gerekir. Hangi olayın hangi veri kümesine gideceğini olay planınıza yazın.

Ayrıca ajans veya serbest çalışanla çalışıyorsanız piksele erişimi işletme portföyü üzerinden verin. Kişisel hesap paylaşmak hem güvenlik hem de erişim takibi açısından risklidir. Böylece kimin hangi ayarı değiştirdiğini her zaman izleyebilirsiniz.

Uygulama ve mesajlaşma olaylarını nasıl ele almalısınız?

Conversions API yalnız web sitesi için değildir. Geliştirici belgelerine göre uygulama olaylarını ve işletme mesajlaşması olaylarını da taşıyabilir. Bu, mesajlaşma üzerinden satış yapan işletmeler için önemli bir fırsattır.

Örnek senaryo: bir işletme reklamdan gelen kişilerle mesajlaşma üzerinden görüşüyor ve satışı orada kapatıyor. Bu satış web sitesinde gerçekleşmediği için piksel onu göremez. Ancak satışı sunucu tarafı olay olarak gönderdiğinizde kampanya, sohbet başlatan değil satın alan kişiyi tanımayı öğrenir.

Uygulama tarafında ise mobil işletim sistemlerinin izin kuralları belirleyicidir. Bu yüzden uygulama olaylarında da kullanıcının izin tercihine uymanız ve yalnız gerekli veriyi göndermeniz gerekir. Kısacası kanal değişse de ilke aynı kalır: doğru olay, doğru an, izinli veri.

Google tarafındaki benzer ölçüm çözümleriyle ilişkisi nedir?

Birçok işletme Meta ve Google reklamlarını aynı anda yürütür. Google tarafında da birinci taraf müşteri verisini karma değerle göndererek ölçümü güçlendiren bir yaklaşım vardır. Bu iki sistem birbirinden bağımsızdır; ancak aynı veri hazırlama ilkelerini paylaşır.

Bu benzerlik size iş yükü açısından avantaj sağlar. Örneğin e-postayı ve telefonu normalleştiren, onay durumunu kontrol eden ve sipariş numarasını olay kimliği olarak üreten tek bir sunucu katmanı kurabilirsiniz. Ardından aynı katman her iki platforma da kendi kurallarına göre veri gönderir. Böylece iki ayrı kurulumu sıfırdan yapmak yerine ortak bir temel üzerinde ilerlersiniz.

Google tarafındaki kurulumu Google Ads gelişmiş dönüşümler rehberimizde anlattık. İki platformun raporlarını karşılaştırırken her birinin kendi ilişkilendirme mantığıyla saydığını unutmayın; bu yüzden toplamları birebir tutmaz. Ayrıca her reklam kaynağını ayırmak için bağlantılarınıza tutarlı UTM etiketleri eklemek, analiz aracınızda net bir tablo görmenizi sağlar.

Meta Conversions API ne zaman gerekli değildir?

Her işletmenin ilk gün bu kuruluma ihtiyacı yoktur. Örneğin çok düşük reklam bütçesiyle yalnız bilinirlik kampanyası yürütüyorsanız, dönüşüm optimizasyonu kullanmıyorsanız veya sitenizde ölçebileceğiniz bir dönüşüm adımı yoksa, önceliği başka işlere vermek mantıklı olabilir.

Öte yandan şu durumlarda Meta Conversions API kurulumunu ertelememenizi öneririz:

• Satın alma veya potansiyel müşteri amacıyla kampanya yürütüyorsanız.
• Reklam panelindeki dönüşüm sayısı sipariş sisteminizden belirgin biçimde düşükse.
• Satışlarınızın önemli bölümü telefonda veya mağazada kapanıyorsa.
• Ödeme adımınız farklı bir alan adına gidiyorsa.

Kısacası karar, bütçe büyüklüğünden çok kampanya amacına ve ölçüm açığının boyutuna bağlıdır.

Ölçüm açığını kabaca görmek için basit bir karşılaştırma yapın. Son bir ayda sipariş sisteminizde reklamdan geldiğini düşündüğünüz satışları, reklam panelinde raporlanan satın alma sayısıyla yan yana koyun. Fark büyükse ve büyümeye devam ediyorsa, sunucu tarafı ölçümü önceliklendirmek için iyi bir gerekçeniz olur. Fark küçükse önce kreatif ve teklif tarafına odaklanabilirsiniz.

Kurulum bakımını nasıl sürdürürsünüz?

Conversions API bir kez kurup unutabileceğiniz bir yapı değildir. Site güncellemeleri, ödeme altyapısı değişiklikleri, tema değişimi veya yeni bir form eklentisi olay akışını sessizce bozabilir. Bu nedenle düzenli bir kontrol rutini oluşturun.

Önerdiğimiz rutin şöyledir: her hafta Olay Yöneticisi'ndeki uyarılara bakın, her ay olay sayılarını sipariş sistemiyle karşılaştırın, her büyük site değişikliğinden sonra test olayı gönderin. Ayrıca erişim belirtecini kimlerin gördüğünü düzenli gözden geçirin; ekipten ayrılan kişilerin yetkilerini kaldırın.

Örnek hesap: bir ayda sipariş sisteminde iki yüz sipariş, reklam panelinde yüz seksen satın alma görüyorsunuz. Aradaki farkın bir bölümü reklam dışı kanallardan gelen siparişlerdir. Ancak fark ani biçimde büyürse bu, olay akışında bir kopukluk olduğuna işaret edebilir.

Meta Conversions API kurulum kontrol listesi nedir?

Meta Conversions API kurulumunu tamamlamadan önce şu listeyi kullanın:

1. Tarayıcı ve sunucu aynı piksel kimliğini kullanıyor mu?
2. Her olay benzersiz bir olay kimliği taşıyor mu?
3. Olay adları iki tarafta birebir aynı mı?
4. Müşteri bilgileri normalleştirilip karma değere dönüşüyor mu?
5. IP adresi ve kullanıcı aracısı ham haliyle mi gidiyor?
6. Onay vermeyen ziyaretçinin olayını durduruyor musunuz?
7. Erişim belirteci yalnız sunucuda mı duruyor?
8. Test olayları ve sipariş karşılaştırmasını tamamladınız mı?

Bu listedeki her soruya net bir evet verebiliyorsanız kurulumunuz sağlam bir temele oturur. Bir maddeye hayır diyorsanız, kampanya kararlarını vermeden önce o maddeyi düzeltin; çünkü yanlış veriyle optimize olan bir kampanya, zamanla yanlış kitleye yönelir.

Ne zaman profesyonel destek almalısınız?

Hazır bir platformda iş ortağı entegrasyonunu kendiniz kurabilirsiniz. Ancak özel yazılımlı bir site, CRM'den çevrim dışı olay gönderimi, birden fazla piksel veya tutarsız olay sayıları söz konusuysa işin teknik ve hukuki yükü artar. Bu durumda kurulumu planlı biçimde ele almak, aylarca yanlış veriyle kampanya yürütmekten daha az maliyetlidir.

Ekibimiz önce mevcut ölçüm yapısını denetler, sonra olay planını kampanya hedefleriyle eşleştirir ve kurulumu test ederek teslim eder. Sonuç veya performans garantisi vermiyoruz; ancak verinin doğru, tekil ve izin kurallarına uygun akmasını sağlamak elimizdedir. Instagram ve Facebook kampanyalarınızın ölçüm altyapısı için instagram reklam yönetimi sayfamızda çalışma şeklimizi bulabilirsiniz.

Teknik ayrıntılar için Meta'nın Conversions API belgesini, deduplikasyon rehberini ve müşteri bilgisi parametreleri sayfasını inceleyin. Özel kategorili kampanyalarda ölçümün neden daha da önemli olduğunu ise Meta özel reklam kategorisi yazımızda anlattık.

Temel rehber: Dijital Pazarlama Nedir? Türleri, örnekleri ve nasıl yapıldığı, beynin içinden geçen etkileşimli bir filmle tek sayfada.