Katalog reklamı aslında neyi eşleştirir?
Dinamik ürün kitleleri ve katalog tabanlı reklamlar tek bir varsayım üzerine kurulu: sitede birinin baktığı ürün ile katalogdaki ürün aynı kimliğe sahip. Sistem bu eşleşmeyi kurabilirse "baktı ama almadı" kitlesini oluşturur, kullanıcının gördüğü ürünü reklamda tekrar gösterir ve satın alanları listeden çıkarır.
Meta'nın dokümantasyonunda dinamik ürün kitlelerini besleyen olaylar sayılıdır: ViewContent (ürün detay sayfası), AddToCart, Purchase ile birlikte Search ve ViewCategory. Bu olaylar tetiklenmiyorsa kitle oluşmaz; tetikleniyor ama kimlikler tutmuyorsa daha kötüsü olur — kitle oluşur, doğru sanılır ve yanlış ürünü gösterir.
content_ids zorunludur ve kataloğa uymak zorundadır
Her olayın ya `content_ids` ya da `contents` parametresini taşıması gerekiyor; dokümantasyon bunu zorunlu olarak tanımlıyor. `content_ids`, perakendecinin ürün veya ürün grubu kimliklerini ifade eder — yani sizin kataloğunuzdaki kimlikleri. `contents` kullanıyorsanız her kalemde en az `id` ve `quantity` alanları bulunmalı.
Buradaki "perakendecinin kimliği" ifadesi kritik. Site tarafındaki iç veritabanı kimliği (örneğin `product_id: 91422`) ile katalogdaki `id` alanı farklıysa eşleşme kurulmaz. Kataloğunuzda SKU kullanıyorsanız olaylarda da SKU gitmeli; katalog XML'inizi bir entegratör üretiyorsa hangi alanın `id` olarak yazıldığını bizzat açıp bakmanız gerekir.
product mu product_group mu? En sık yapılan hata
`content_type` parametresi, gönderdiğiniz kimliğin türünü bildirir. `product`, tekil SKU'yu (beden ve renk gibi varyant belirlenmiş hali) işaret eder. `product_group`, aynı ürünün varyantlarını bir arada tutan grup kimliğini (`item_group_id`) işaret eder.
Kural şudur: `content_type` ile gönderdiğiniz kimliğin türü birbirini tutmalı. Kullanıcı beden seçmeden önce görüntülenen bir ürün sayfasında ViewContent için `product_group` kullanmak makul; ama AddToCart ve Purchase olaylarında `product_group` kullanılmamalı, çünkü insanlar belirli bir ürünü satın alır. Sepet ve satın alma olaylarında varyant düzeyinde SKU gitmeli.
Bu ayrım kozmetik değil. Satın alma varyant düzeyinde gitmezse "satın alanı yeniden hedeflemeden çıkar" mantığı yanlış çalışır: müşteri siyah 42 numarayı aldığı halde aynı ürünün tüm varyantları reklam envanterinden düşer ya da tam tersi, alınan ürün günlerce yeniden gösterilir.
Kimlikler tutmazsa tam olarak ne kırılır?
Uyuşmazlığın en can sıkıcı yanı, bir hata mesajı üretmemesidir. Kampanya yayında kalır, gösterim alır, harcama yapar. Kırılan şeyler şunlardır:
- Kullanıcının baktığı ürün reklamda gösterilemez; yerine ilgisiz ürünler döner
- "Satın alanları hariç tut" mantığı çalışmaz; ödeme yapmış müşteriye aynı ürün gösterilmeye devam eder
- Sepete ekleyip ayrılan kullanıcı için kurulan kitleler dolmaz ya da yanlış dolar
- Cihazlar arası niyet sinyali kullanılamaz hale gelir: mobilde bakıp masaüstünde dönen kullanıcı takip edilemez
- Ürün düzeyinde performans raporu anlamsızlaşır; hangi ürünün gerçekten sattığı görülemez
- Katalog kapsamı düşer ama bu düşüş kampanya raporunda değil, katalog tarafında görünür
En sık kırılma anları
Uyuşmazlık genellikle bir gün aniden ortaya çıkmaz; bir değişiklikle birlikte gelir. En sık üç senaryo: e-ticaret altyapısının değişmesi, katalog entegrasyonunun yeni bir araca taşınması ve ürün kodlama şemasının güncellenmesi. Üçünde de olay kodu eski kimliği göndermeye devam ederken katalog yeni kimliğe geçer.
Dördüncü ve daha sinsi senaryo, varyant yönetimidir. Ana ürün kodu ile varyant SKU'sunun karıştığı kurulumlarda ViewContent ana koda, Purchase varyant koduna gider ve `content_type` her ikisinde de aynı bırakılır. Bu kurulum aylarca yayında kalabilir, çünkü kampanya bir miktar dönüşüm üretmeye devam eder — sadece üretebileceğinin altında.
Panelde hata çıkmaz, doğrulamayı kendiniz kurmalısınız
Ölçüm sağlığını sayısal olarak izlemek için Meta'nın veri kalitesi metrikleri var: Event Match Quality, sunucudan gönderilen müşteri bilgisinin olayı bir Meta hesabıyla eşleştirmedeki etkinliğini 10 üzerinden puanlar. Event Coverage ise Pixel olaylarının Conversions API tarafından kapsanma ve tekilleştirme anahtarı paylaşma oranını 7 günlük ortalama olarak verir. Bu metrikler Dataset Quality API ile çok sayıda veri kaynağı için toplu çekilebilir, yani denetim otomatikleştirilebilir.
Ama burada bir yanılgıya dikkat: bu metrikler müşteri eşleşmesini ölçer, ürün eşleşmesini değil. Event Match Quality skoru 9 olan bir hesapta katalog kimlikleri tamamen yanlış olabilir. Ürün tarafını doğrulamak ayrı bir iştir ve elle yapılır.
Bir saatlik doğrulama protokolü
Aşağıdaki adımları sırayla uygulayın. Hepsi mevcut araçlarla, geliştirici desteği olmadan başlatılabilir; yalnızca son adımda kod tarafına dokunmanız gerekebilir.
- Kataloğunuzdan rastgele 10 ürün seçin ve `id` ile `item_group_id` alanlarını not edin
- Aynı 10 ürünün detay sayfasına girip tetiklenen ViewContent olayındaki content_ids değerini okuyun; iki listeyi karşılaştırın
- Bir test siparişi verip Purchase olayında varyant SKU'sunun mu ana kodun mu gittiğini doğrulayın
- Her olayda content_type değerinin gönderilen kimlik türüyle uyumlu olduğunu kontrol edin (satın almada product_group olmamalı)
- Katalog tarafında eşleşmeyen ya da kapsam dışı kalan ürün sayısını çıkarın ve toplam ürün sayısına oranlayın
- Uyuşmazlık varsa önce olay tarafını kataloğa uydurun; kataloğu değiştirmek reklam geçmişini de etkiler
- Düzeltmeden sonra en az 7 gün bekleyip kitle büyüklüklerinin dolmasını izleyin
Özet
Katalog reklamlarında performans sorunlarının önemli bir kısmı hedefleme ya da kreatif değil, kimlik meselesidir. Sistem yanlış ürünü gösteriyorsa bunun nedeni genellikle algoritmanın kötü çalışması değil, ona verdiğiniz kimliğin katalogdakiyle tutmamasıdır. İyi haber: bu, tahmin gerektiren bir sorun değil; iki listeyi yan yana koyup karşılaştırarak kesin cevap alınabilir.
Kataloğunuzla site olaylarınız arasındaki eşleşmenin ne durumda olduğunu bilmiyorsanız, mevcut kurulumunuz için ücretsiz bir eşleşme kontrolü talep edebilirsiniz.