Meta Dönüşüm API’si (Conversions API) Rehberi

Dönüşüm API’si (Conversions API), site üzerindeki olayları tarayıcı yerine sunucudan Meta’ya ileten ölçüm yöntemidir. Reklam engelleyiciler, çerez kısıtları ve tarayıcı politikaları nedeniyle kaybolan verinin önemli bölümünü geri kazandırır. Ancak yanlış kurulduğunda faydadan çok zarar verir: aynı dönüşüm iki kez sayılır ve tüm bütçe kararları bozulur. Bu rehber, kurulumu, tekilleştirmeyi, eşleştirme kalitesini ve doğrulama adımlarını uçtan uca anlatıyor.

Dönüşüm API’si nedir?

Dönüşüm API’si, pazarlama olaylarını doğrudan sunucunuzdan Meta’ya iletmenizi sağlayan bir arayüzdür. Kullanıcının tarayıcısına bağımlı olmadığı için, tarayıcı tarafındaki engellerden etkilenmez.

Gönderilen olaylar, pikselin gönderdikleriyle aynıdır: sayfa görüntüleme, içerik görüntüleme, sepete ekleme, ödemeye başlama, satın alma, potansiyel müşteri. Fark, verinin izlediği yoldadır.

Bu yöntem pikselin yerine geçmek için değil, onunla birlikte çalışmak için tasarlanmıştır. İkisini birlikte kullanan kurulumlar, tek başına tarayıcı ölçümüne göre belirgin biçimde daha eksiksiz veri üretir.

Neden gerekli hâle geldi?

Birkaç yıl öncesine kadar tarayıcı tabanlı ölçüm çoğu durumda yeterliydi. Bu tablo, birbirini izleyen üç gelişmeyle değişti.

Birincisi, reklam engelleyici kullanımının yaygınlaşması: bu araçlar ölçüm kodlarının çalışmasını doğrudan engelliyor. İkincisi, tarayıcıların üçüncü taraf çerezlere ve betikle oluşturulan tanımlayıcılara getirdiği kısıtlar. Üçüncüsü, gizlilik düzenlemeleri ve rıza gerekliliği: kullanıcı rıza vermediğinde ölçüm kodu hiç çalışmamalıdır.

Bu üçünün toplamı, tarayıcıdan gönderilen olayların gerçekte olan biten eylemlerin bir bölümünü kaçırması anlamına geliyor. Sunucu tarafı ölçüm, bu kaybın ilk iki kaynağını büyük ölçüde ortadan kaldırır; üçüncüsü ise hukuki bir sınırdır ve aşılamaz.

Veri kaybı nereden geliyor?

Kaybın nedenlerini ayırmak önemlidir çünkü her birinin çözümü farklıdır.

• Reklam engelleyiciler. Ölçüm isteği hiç gönderilmez. Sunucu tarafı bunu çözer.
• Tarayıcı kısıtları. Tanımlayıcıların ömrü kısalır, eşleşme zayıflar. Sunucu tarafı kısmen çözer.
• Ağ ve cihaz sorunları. İstek yolda kaybolur. Sunucu tarafı çözer.
• Sayfa erken kapatılması. Olay gönderilmeden kullanıcı ayrılır. Sunucu tarafı çözer.
• Rıza reddi. Ölçüm yapılmamalıdır. Bu kayıp meşrudur ve giderilmemelidir.
• Kurulum hataları. Yanlış tetikleyici, eksik parametre. Sunucu tarafı çözmez; kurulum düzeltilmelidir.

Piksel ile farkı

Piksel, kullanıcının tarayıcısında çalışır ve olayı oradan gönderir. Dönüşüm API’si, olayı sunucunuzdan gönderir. Aradaki farkın pratik sonuçları vardır.

Piksel, tarayıcı bilgisine doğrudan erişir: çerez tanımlayıcıları, tarayıcı kimliği, sayfa adresi. Sunucu tarafı bu bilgilere kendiliğinden sahip değildir; eşleşme için gereken verinin sunucuya taşınması gerekir.

Bu yüzden iyi kurulmuş bir sunucu tarafı ölçüm, tarayıcıdan gelen bazı bilgileri (özellikle Meta’nın tıklama ve tarayıcı tanımlayıcılarını) yakalayıp sunucuya iletir. Bu adım atlandığında olaylar Meta’ya ulaşır ama kullanıcıyla eşleştirilemez ve reklamla ilişkilendirilemez.

İkisi birlikte nasıl çalışır?

Önerilen kurulum, aynı olayın hem tarayıcıdan hem sunucudan gönderilmesidir. Bu, gereksiz bir tekrar gibi görünür ama değildir: iki kanaldan biri engellenirse diğeri devreye girer.

Meta, aynı olayın iki kopyasını aldığında bunları birleştirir ve tek olay olarak sayar. Bu birleştirmenin çalışabilmesi için iki kopyanın eşleştirilebilir olması gerekir; işte tekilleştirme burada devreye girer.

Sonuç olarak sağlıklı bir kurulumda toplam olay sayısı iki katına çıkmaz; kapsama oranı yükselir. Yani daha çok olay değil, daha eksiksiz olay elde edilir.

Tekilleştirme: olay kimliği

Tekilleştirme, kurulumun en kritik adımıdır ve en sık atlanan adımdır. Mantığı basittir: aynı olayın her iki kopyasına da aynı benzersiz kimlik verilir.

Bu kimlik, olay başına üretilir ve hem tarayıcı hem sunucu gönderiminde aynı değeri taşır. Meta, aynı kimliğe sahip iki olayı gördüğünde bunların tek bir olay olduğunu anlar ve birini yok sayar.

Kimlik üretiminde yaygın bir hata, sipariş numarasını doğrudan kullanmaktır. Bu çoğu durumda çalışır ancak sipariş onay sayfası yenilendiğinde aynı kimlikle yeni bir olay üretilir; bu aslında istenen davranıştır çünkü tekrar sayımı engeller. Asıl sorun, her gönderimde rastgele yeni bir kimlik üretilmesidir: bu durumda tekilleştirme hiç çalışmaz.

Kurulum yöntemleri

Üç ana yol vardır ve seçim, teknik kaynağınıza ve altyapınıza bağlıdır.

Doğrudan sunucu entegrasyonu: uygulamanızın kodundan doğrudan Meta’ya istek gönderilir. En fazla kontrol sağlayan yöntemdir, geliştirme kaynağı gerektirir.

Sunucu tarafı etiket yöneticisi: olaylar önce sizin kontrolünüzdeki bir sunucuya, oradan Meta’ya gider. Birden çok platforma aynı anda gönderim yapan kurulumlarda verimlidir.

Hazır ortak entegrasyonlar: bazı e-ticaret altyapıları ve ölçüm platformları hazır bağlantı sunar. En hızlı yoldur ama esneklik ve doğrulama imkânı sınırlıdır.

Doğrudan sunucu entegrasyonu

Bu yöntemde, olay gerçekleştiğinde sunucu tarafındaki kod Meta’nın uç noktasına bir istek gönderir. İstek; olay adı, zaman damgası, olay kimliği, kullanıcı bilgileri ve özel parametreleri taşır.

Uygulamada dikkat edilecek noktalar şunlardır: istek asenkron gönderilmeli ve sayfa yanıtını geciktirmemeli, başarısız istekler için yeniden deneme mekanizması bulunmalı, ve erişim anahtarı sunucuda güvenli biçimde saklanmalıdır.

Bu yöntemin en büyük avantajı, verinin kaynağının sistemin kendisi olmasıdır. Sipariş gerçekten oluştuğunda olay gönderilir; tarayıcının veya kullanıcının davranışına bağımlı değildir. Bu, özellikle iade ve iptal yönetiminde önemli bir esneklik sağlar.

Sunucu tarafı etiket yöneticisi

Bu kurgu, tarayıcıdan gelen olayları önce kendi kontrolünüzdeki bir sunucuya toplar ve oradan farklı platformlara dağıtır. Böylece tek bir veri akışından hem Meta’ya hem diğer reklam platformlarına gönderim yapılabilir.

Avantajları belirgindir: tarayıcı tarafındaki kod yükü azalır, veri üzerinde dönüşüm ve zenginleştirme yapılabilir, ve gizlilik kontrolleri merkezî hâle gelir.

Dezavantajı ise ek altyapı maliyeti ve yönetim yüküdür. Ayrıca kurulum, tarayıcıdan gelen veriye dayandığı için reklam engelleyici sorununu tamamen çözmez; asıl kapsama kazancı, gerçek sunucu tarafı olaylarla birleştiğinde ortaya çıkar.

Hazır ortak entegrasyonlar

Birçok e-ticaret altyapısı, birkaç ayar girilerek etkinleştirilen hazır bağlantı sunar. Bu pratiktir ancak üç noktayı kontrol etmeden bırakmayın.

Birincisi, hangi olayların gönderildiği: bazı entegrasyonlar yalnızca satın alma gönderir, huninin üst basamakları eksik kalır. İkincisi, tekilleştirmenin kurulup kurulmadığı: entegrasyon piksel olaylarıyla aynı kimliği kullanıyor mu? Üçüncüsü, eşleştirme verisinin zenginliği: yalnızca e-posta mı gönderiliyor, yoksa telefon, ad ve konum bilgileri de ekleniyor mu?

Bu üç kontrol yapılmadan etkinleştirilen entegrasyonlar, iyi niyetle kurulup aylarca yanlış veri üretebilir.

Hangi olaylar gönderilmeli?

Genel ilke, tarayıcı tarafında gönderilen olayların aynısının sunucudan da gönderilmesidir. Ancak öncelik sıralaması yapmak gerekirse:

• Satın alma. En kritik olay; mutlaka sunucudan da gönderilmelidir.
• Potansiyel müşteri. Hizmet işletmelerinde satın almanın karşılığı.
• Ödemeye başlama. Huninin alt basamağı, optimizasyon için değerli.
• Sepete ekleme. Kitle oluşturma ve orta huni optimizasyonu için.
• İçerik görüntüleme. Yeniden pazarlama kitlelerini besler.
• Kayıt tamamlama. Üyelik odaklı işlerde önemli.

Sayfa görüntüleme gibi yüksek hacimli olayları sunucudan göndermek genellikle gereksiz yük yaratır; bu olaylar tarayıcı tarafında bırakılabilir.

Zorunlu ve önerilen parametreler

Her olay gönderiminde bulunması gereken temel alanlar vardır: olay adı, olayın gerçekleştiği zaman, olay kimliği, olayın kaynağı ve kullanıcı bilgileri.

Kullanıcı bilgileri kısmı eşleşmeyi belirler ve ne kadar zenginse eşleşme o kadar iyi olur. Gönderilebilecek alanlar: e-posta, telefon, ad, soyad, şehir, ülke, posta kodu, doğum tarihi, harici kimlik, IP adresi, tarayıcı kimliği ve Meta’nın tıklama tanımlayıcısı.

Satın alma olaylarında ayrıca değer, para birimi, ürün kimlikleri ve içerik türü gönderilmelidir. Bu alanlar eksik olduğunda değer bazlı optimizasyon ve getiri raporlaması çalışmaz.

Eşleştirme kalitesi puanı

Meta, gönderilen olayların kullanıcılarla ne kadar iyi eşleştirilebildiğini bir puanla gösterir. Bu puan, kurulumun sağlığını ölçmenin en pratik yoludur.

Puanı yükselten şey, gönderilen tanımlayıcı çeşitliliğidir. Yalnızca e-posta gönderen bir kurulumla; e-posta, telefon, ad, konum ve tıklama tanımlayıcısını birlikte gönderen bir kurulum arasında belirgin fark oluşur.

Düşük puanın en yaygın nedenleri şunlardır: biçimlendirme hataları, tıklama tanımlayıcısının hiç gönderilmemesi, misafir alışverişlerinde kullanıcı bilgisi toplanmaması, ve karma işleminin yanlış uygulanması. Puanı izlemek, sorunların erken fark edilmesini sağlar.

Karma (hash) kuralları

Kişisel veriler Meta’ya asla ham hâlde gönderilmez; tek yönlü bir karma işlemiyle dönüştürülerek gönderilir. Bu hem politika gereğidir hem de veri koruma açısından zorunludur.

Karma işleminden önce biçimlendirme kurallarına uyulması şarttır çünkü aynı verinin farklı yazımları farklı karma değerleri üretir. Örneğin e-postalar küçük harfe çevrilmeli ve baştaki ile sondaki boşluklar temizlenmeli; telefon numaraları ülke kodu dâhil, yalnızca rakamlardan oluşacak biçimde normalleştirilmelidir.

Biçimlendirme atlandığında olaylar başarıyla iletilir ama hiçbir kullanıcıyla eşleşmez. Bu, hata mesajı üretmediği için en sinsi sorunlardan biridir: her şey çalışıyor görünür, ölçüm ise boştur.

Rıza yönetimi ve KVKK

Sunucu tarafı ölçüm, rıza yükümlülüğünü ortadan kaldırmaz. Kişisel veri işlenmesi söz konusu olduğunda, verinin hangi kanaldan gittiğinin hukuki bir önemi yoktur.

Pratik sonuç şudur: rıza vermeyen kullanıcılar için kişisel tanımlayıcı içeren olay gönderilmemelidir. Bu kararın sunucu tarafında da uygulanabilmesi için, rıza durumunun sunucuya taşınması ve gönderim mantığının buna göre kurulması gerekir.

Rıza durumunu göz ardı eden sunucu kurulumları, tarayıcı tarafında özenle kurulmuş rıza yönetimini işlevsiz kılar. Bu, denetimlerde sık karşılaşılan ve ciddi sonuçları olabilen bir uyum açığıdır.

Zaman damgası ve gecikme

Her olay, gerçekleştiği anın zaman damgasıyla gönderilmelidir. Gönderim gecikse bile zaman damgası doğru olmalıdır; aksi hâlde atıf pencereleri yanlış hesaplanır.

Meta, geçmişe dönük olayları belirli bir süre içinde kabul eder. Bu süre aşıldığında olay reddedilir. Toplu gönderim yapan kurulumlarda bu sınır önemlidir: günlük toplu iş çalıştıran sistemlerde gecikme birikirse veri kaybı yaşanır.

Ayrıca gecikmeli gönderim, optimizasyonu olumsuz etkiler. Sistem, dönüşümü ne kadar geç öğrenirse o kadar geç tepki verir. Mümkün olan en yakın zamanlı gönderim, hem raporlama hem optimizasyon açısından tercih edilmelidir.

Çevrimdışı ve CRM olayları

Dönüşüm API’sinin en değerli kullanımlarından biri, sitede gerçekleşmeyen dönüşümleri bildirmektir. Mağazada tamamlanan satışlar, telefonla alınan siparişler ve satış ekibinin kapattığı anlaşmalar bu kapsamdadır.

Bu bildirim, hizmet ve B2B işlerinde oyun değiştirici olabilir. Sistem, formu dolduran herkesi değil gerçekten müşteriye dönüşenleri öğrenir ve buna göre kitle arar. Nitelik farkı belirgindir.

Uygulaması, müşteri ilişkileri sisteminden düzenli olarak nitelikli dönüşümlerin gönderilmesiyle olur. Burada kritik nokta, kullanıcı bilgilerinin form aşamasında toplanmış tanımlayıcılarla eşleşebilmesidir; eşleşme kurulamazsa geri bildirim işe yaramaz.

İade ve iptalleri bildirmek

İade oranı yüksek kategorilerde, platformun gördüğü ciro ile kasaya giren ciro belirgin biçimde ayrışır. Bu fark yönetilmediğinde kampanya performansı sürekli olduğundan iyi görünür.

Sunucu tarafı ölçüm, bu sorunu çözmek için bir imkân sunar: iade gerçekleştiğinde ilgili olayın silinmesi veya negatif değerli bir düzeltme olayı gönderilmesi mümkündür.

Bu uygulama yaygın değildir ama etkisi büyüktür. Özellikle giyim gibi iade oranının yüksek olduğu kategorilerde, gerçek kârlılıkla raporlanan performans arasındaki farkı kapatır ve bütçe kararlarının doğru veriye dayanmasını sağlar.

Test ve doğrulama

Kurulum tamamlandığında yapılması gereken doğrulama adımları şunlardır.

Önce test olay aracı ile gönderimlerin ulaştığı doğrulanır. Ardından tekilleştirme durumu kontrol edilir: Etkinlik Yöneticisi, tarayıcı ve sunucu olaylarının eşleştirilip eşleştirilmediğini gösterir. Sonra eşleştirme kalitesi puanı incelenir ve düşükse hangi alanların eksik olduğu belirlenir.

Son ve en güvenilir adım, gerçek veriyle karşılaştırmadır: bir günlük satın alma sayısı ve toplam değeri, sipariş sisteminizin verisiyle yan yana konur. Bu karşılaştırma yapılmadan yapılan hiçbir doğrulama tam sayılmaz.

Sürekli izleme

Kurulum bir kez yapılıp unutulacak bir iş değildir. Site değişiklikleri, altyapı güncellemeleri ve eklenti değişiklikleri ölçümü sessizce bozabilir.

Haftalık izlenmesi gereken üç gösterge vardır: gönderilen olay sayısı ve trendi, eşleştirme kalitesi puanı, ve tekilleştirme oranı. Bu üçünden birindeki ani değişim, neredeyse her zaman teknik bir sebebe işaret eder.

Ek olarak, platformun raporladığı dönüşüm sayısı ile sipariş sisteminin sayısı arasındaki oranı izlemek faydalıdır. Bu oran istikrarlıysa kurulum sağlıklıdır; ani sapmalar müdahale gerektirir.

Sık karşılaşılan sorunlar

Dönüşüm sayısı iki katına çıktı. Tekilleştirme kurulmamıştır veya olay kimlikleri eşleşmiyordur. En sık ve en kritik sorundur.

Eşleştirme puanı çok düşük. Biçimlendirme kuralları uygulanmamış, tıklama tanımlayıcısı gönderilmiyor veya kullanıcı bilgisi çok sınırlı olabilir.

Olaylar reddediliyor. Zaman damgası çok eski, erişim anahtarı geçersiz veya zorunlu alanlar eksik olabilir.

Sunucu olayları hiç görünmüyor. Genellikle yanlış piksel kimliği veya erişim anahtarı sorunudur.

Değerler yanlış. Kargo ve vergi dâhil tutar gönderiliyor veya para birimi eksik olabilir.

Erişim anahtarı güvenliği

Sunucu tarafı gönderim, bir erişim anahtarıyla yetkilendirilir. Bu anahtar, reklam hesabınıza olay yazma yetkisi taşır ve sızdığında kötüye kullanılabilir.

Temel kurallar şunlardır: anahtar asla istemci tarafı koda, depoya veya yapılandırma dosyalarının herkese açık kısmına yazılmamalıdır. Sunucu ortam değişkenlerinde veya bir sır yönetim sisteminde saklanmalıdır. Ekipten ayrılan kişiler sonrasında ve düzenli aralıklarla yenilenmelidir.

Ajansla çalışan kurulumlarda ek bir kural daha vardır: anahtarın üretildiği hesap markanın kendi işletme portföyünde olmalıdır. Ajans portföyünde üretilmiş bir anahtar, ilişki bittiğinde geçersiz kalır ve ölçüm bir gecede durur; bu durum genellikle geçiş dönemlerinde ve en kötü zamanda fark edilir.

Birden çok platforma gönderim

Çoğu işletme aynı anda birden çok reklam platformu kullanır ve her birinin kendi sunucu tarafı arayüzü vardır. Her platform için ayrı ayrı kurulum yapmak, aynı işin defalarca tekrarlanması anlamına gelir.

Bu noktada merkezî bir yaklaşım verimlidir: olaylar bir kez toplanır, standart bir yapıya dönüştürülür ve oradan tüm platformlara dağıtılır. Böylece yeni bir platform eklendiğinde sıfırdan kurulum gerekmez, yalnızca yeni bir çıkış tanımlanır.

Merkezî yapının ikinci faydası tutarlılıktır: tüm platformlar aynı olay tanımlarını ve aynı değerleri alır. Ayrı ayrı kurulan sistemlerde, platformlar arasında farklı sayılar raporlanması sık görülür ve bu farkın kaynağını bulmak zordur.

Kaynak ve maliyet planlaması

Sunucu tarafı ölçüm, tarayıcı tarafına göre daha fazla kaynak gerektirir ve bu, planlamada hesaba katılmalıdır.

Kalemler şunlardır: ilk kurulum için geliştirme zamanı, merkezî bir yapı kuruluyorsa sunucu veya bulut hizmeti maliyeti, ve süregiden bakım. Bakım kalemi genellikle küçümsenir; oysa site her değiştiğinde ölçümün doğrulanması gerekir.

Buna karşılık getirisi somuttur: daha eksiksiz veri, daha iyi optimizasyon ve daha güvenilir raporlama. Karar verirken sorulacak soru, “kurulum ne kadar tutar” değil; “eksik ölçüm nedeniyle yanlış yönlendirilen bütçe ne kadar” olmalıdır. Reklam harcaması belirli bir düzeyin üzerindeki hesaplarda bu karşılaştırma, kurulumu neredeyse her zaman haklı çıkarır.

Kurulum kontrol listesi

• Sunucu olayları doğru piksel kimliğine gidiyor mu?
• Her olayda benzersiz ve tutarlı bir olay kimliği var mı?
• Tarayıcı ve sunucu olayları aynı kimliği paylaşıyor mu?
• Tekilleştirme durumu Etkinlik Yöneticisi’nde doğrulandı mı?
• Kişisel veriler karma hâlinde ve doğru biçimlendirmeyle gönderiliyor mu?
• Tıklama tanımlayıcısı ve tarayıcı kimliği sunucuya taşınıyor mu?
• Değer, para birimi ve ürün kimlikleri eksiksiz mi?
• Rıza durumu sunucu tarafında da dikkate alınıyor mu?
• Zaman damgaları olayın gerçek anını yansıtıyor mu?
• Başarısız istekler için yeniden deneme var mı?
• Eşleştirme kalitesi puanı izleniyor mu?
• Bir günlük veri sipariş sistemiyle karşılaştırıldı mı?

Sık yapılan 12 hata

• Tekilleştirmesiz kurulum. Dönüşümler iki kez sayılır, tüm kararlar bozulur.
• Her gönderimde rastgele kimlik üretmek. Tekilleştirme hiç çalışmaz.
• Ham kişisel veri göndermek. Politika ihlali ve hukuki risk.
• Biçimlendirme kurallarını atlamak. Olaylar ulaşır ama eşleşmez.
• Tıklama tanımlayıcısını taşımamak. Olaylar reklamla ilişkilendirilemez.
• Rızayı sunucu tarafında yok saymak. Uyum açığı üretir.
• Gecikmeli toplu gönderim. Olaylar reddedilebilir, optimizasyon zayıflar.
• Sadece satın alma göndermek. Huninin üst basamakları eksik kalır.
• Kargo ve vergi dâhil değer göndermek. Getiri hesabı şişer.
• İadeleri hiç bildirmemek. Raporlanan ciro gerçekten sapar.
• Hazır entegrasyonu kontrol etmeden açmak. Eksik veya çift gönderim riski.
• Kurulumu bir daha kontrol etmemek. Site değiştikçe ölçüm sessizce bozulur.

Sıkça sorulan sorular

Pikselim varken dönüşüm API’sine gerçekten ihtiyacım var mı?

Evet. Tarayıcı tabanlı ölçüm; reklam engelleyiciler, tarayıcı kısıtları, ağ sorunları ve sayfanın erken kapatılması nedeniyle olayların bir bölümünü kaybeder. Sunucu tarafı gönderim bu kayıpların büyük kısmını telafi eder ve algoritmanın daha eksiksiz sinyalle çalışmasını sağlar. Ancak API tek başına bir çözüm değildir: tekilleştirme kurulmadan eklendiğinde aynı dönüşüm iki kez sayılır ve kurulum faydadan çok zarar verir.

Dönüşüm API’si kurunca dönüşüm sayım iki katına çıkar mı?

Doğru kurulmuş bir sistemde çıkmaz. Aynı olayın her iki kopyasına da aynı benzersiz olay kimliği verildiğinde Meta bunları birleştirir ve tek olay olarak sayar. Sayının iki katına çıkması, tekilleştirmenin kurulmadığını veya kimliklerin eşleşmediğini gösterir. Bu durum kurulumdan hemen sonra Etkinlik Yöneticisi’ndeki tekilleştirme durumu kontrol edilerek anlaşılabilir.

Sunucu tarafı ölçüm KVKK yükümlülüğünü ortadan kaldırır mı?

Hayır. Kişisel veri işlenmesi söz konusu olduğunda verinin hangi kanaldan gittiğinin hukuki bir önemi yoktur. Rıza vermeyen kullanıcılar için kişisel tanımlayıcı içeren olay gönderilmemelidir ve bu kararın sunucu tarafında da uygulanabilmesi için rıza durumunun sunucuya taşınması gerekir. Rızayı yok sayan sunucu kurulumları, tarayıcı tarafında kurulmuş rıza yönetimini işlevsiz kılar.

Eşleştirme kalitesi puanım düşük, nasıl yükseltirim?

Puanı belirleyen şey, gönderilen tanımlayıcı çeşitliliği ve doğruluğudur. Önce biçimlendirme kurallarını kontrol edin: e-postalar küçük harfe çevrilmiş ve boşluklardan arındırılmış mı, telefonlar ülke kodlu ve yalnızca rakamlardan oluşuyor mu? Ardından Meta’nın tıklama tanımlayıcısının ve tarayıcı kimliğinin sunucuya taşındığından emin olun. Son olarak misafir alışverişlerinde de e-posta ve telefon gibi bilgilerin toplandığını doğrulayın.

Mağazada yapılan satışları da bildirebilir miyim?

Evet ve bu, API’nin en değerli kullanımlarından biridir. Mağazada tamamlanan satışlar, telefonla alınan siparişler ve satış ekibinin kapattığı anlaşmalar sunucudan bildirilebilir. Bu, özellikle hizmet ve B2B işlerinde niteliği belirgin biçimde yükseltir: sistem formu dolduran herkesi değil gerçekten müşteriye dönüşenleri öğrenir. Koşul, kullanıcı bilgilerinin form aşamasında toplanmış tanımlayıcılarla eşleşebilmesidir.

İade ve iptalleri Meta’ya bildirmeli miyim?

İade oranı yüksek kategorilerde bu güçlü bir iyileştirmedir. Platformun gördüğü ciro ile kasaya giren ciro arasındaki fark yönetilmediğinde kampanya performansı sürekli olduğundan iyi görünür. Sunucu tarafı ölçüm, iade gerçekleştiğinde ilgili olayın silinmesine veya düzeltme gönderilmesine imkân tanır. Yaygın bir uygulama değildir ama gerçek kârlılıkla raporlanan performans arasındaki farkı kapatır.

Terimler sözlüğü

• Dönüşüm API’si: Olayları sunucudan Meta’ya ileten ölçüm arayüzü.
• Olay kimliği: Aynı olayın iki kopyasını eşleştiren benzersiz değer.
• Tekilleştirme: Aynı olayın birden çok kez sayılmasını engelleyen mekanizma.
• Eşleştirme kalitesi: Gönderilen olayların kullanıcılarla ne kadar iyi eşleştirilebildiğini gösteren puan.
• Karma (hash): Kişisel verinin tek yönlü olarak dönüştürülmesi.
• Tıklama tanımlayıcısı: Reklam tıklamasıyla oluşan ve atıf için kullanılan değer.
• Sunucu tarafı etiketleme: Olayların kendi sunucunuza toplanıp oradan dağıtılması.
• Çevrimdışı dönüşüm: Sitede değil, mağaza veya telefon üzerinden gerçekleşen dönüşüm.

Özet

Dönüşüm API’si, tarayıcı tabanlı ölçümün kaybettiği verinin önemli bölümünü geri kazandırır ve bugün standart bir bileşen hâline gelmiştir. Ancak tek başına bir çözüm değildir; doğru kurulmadığında sorunu çözmek yerine büyütür.

Kurulumun üç kritik noktası vardır: tekilleştirmenin çalıştığını doğrulamak, eşleştirme için gereken tanımlayıcıları doğru biçimlendirerek göndermek, ve rıza durumunu sunucu tarafında da uygulamak. Bu üçü tamamlanmadan yapılan hiçbir kurulum sağlıklı sayılmaz.

Son olarak doğrulamayı bir alışkanlığa dönüştürün: platformun raporladığı sayı ile sipariş sisteminizin sayısı arasındaki oran, kurulumun sağlığını gösteren en güvenilir tek göstergedir.

İlgili içerikler: Meta pixel kurulumu, Facebook reklam verme, GA4 ve GTM kurulumu, ileri analitik hizmetimiz.