Etkinlik eşleşme kalitesi nasıl yükseltilir

Etkinlik eşleşme kalitesi, gönderdiğin bir olayın gerçek bir kişiyle ne kadar güvenilir biçimde eşleştirilebildiğini gösteren bir ölçüdür. Events Manager bunu veri kümesi ve olay türü bazında ayrı ayrı raporlar. Skor düşük çıktığında ilk akla gelen şey pikselin bozulmuş olmasıdır, ama çoğu vakada olay sorunsuz ateşlenir, panelde görünür, sayısı da doğrudur. Eksik olan başka bir şeydir: olayın içinde kişiyi tanımlayacak parametre ya hiç yoktur ya da makinenin kullanamayacağı bir biçimde gönderilmiştir. Bu yazı skorun kendisini değil, skoru oluşturan parametre katmanını ele alıyor.

Etkinlik eşleşme kalitesi neyi ölçer, neyi ölçmez

Ölçtüğü şey dar ve nettir: olayla birlikte gönderdiğin müşteri bilgisi parametrelerinin varlığı ve bunların bir profille eşleşebilecek biçimde olup olmadığı. Ölçmediği şeyler ise uzun bir liste. Reklamının performansını ölçmez. Olayın doğru anda tetiklenip tetiklenmediğini ölçmez. Gönderdiğin değer parametresinin doğru tutarı taşıyıp taşımadığını ölçmez. Olay hiç gitmiyorsa, mükerrer gidiyorsa ya da yanlış sayfada tetikleniyorsa bunlar ayrı arızalardır ve önce onları kapatman gerekir; Pixel verilerinin yanlış görünmesinin nedenleri o tarafı anlatıyor. Kurulumun kendisinden emin değilsen Facebook Pixel kurulumunun temeli başlangıç noktası.

Panelde skorun yanında bir ölçek ve bir derecelendirme ifadesi görürsün. Buradaki en yaygın hata, internette okuduğun bir hedef sayıyı kendine hedef koymaktır. Skorun tabanı iş modeline bağlıdır: üyelik zorunlu bir mağaza ile misafir alışverişinin baskın olduğu bir mağaza aynı yerden başlamaz. Doğru kıyas kaynağı kendi hesabının geçmişidir. Bugünkü skoru bir ay öncekiyle karşılaştır, başka bir şirketin skoruyla değil.

Önce parametre kapsamını ölç, skoru sonra yorumla

Skor bir sonuçtur; sebep, hangi alanın kaç olayda gittiğidir. Meta'nın müşteri bilgisi alanları arasında e-posta, telefon, ad, soyad, şehir, il, posta kodu, ülke, harici kimlik ve tarayıcı tarafındaki tanımlayıcılar bulunur. Bu listenin güncel hali ve zorunlu biçim kuralları için resmî dokümana bakmak zorundasın, çünkü alan adları ve normalizasyon beklentileri zaman içinde değişiyor.

Kapsama hesabını kendi verinle çıkar

Tek bir zaman aralığı ve tek bir olay seç, karıştırma. Diyelim son 7 günde 1.200 satın alma olayı gönderildi. Bunların 900'ünde e-posta parametresi var: 900 ÷ 1.200 = 0,75, yani %75 kapsama. Telefon yalnızca 300 olayda var: 300 ÷ 1.200 = 0,25, yani %25. E-posta kapsaman telefonun tam üç katı, çünkü 75 ÷ 25 = 3.

Şimdi biçim kontrolüne gel. Telefonun gittiği 300 olayın 240'ında numara mağaza tarafında 0532 ile başlayan yerel biçimde duruyor ve ülke kodu eklenmeden hash'lenmiş. Bu 240 olay teknik olarak dolu, eşleşmede işe yaramaz. Kullanılabilir telefon 300 − 240 = 60 olaya, yani 60 ÷ 1.200 = 0,05 ile %5'e iner. Parametrenin gönderilmiş olması ile parametrenin eşleşmeye katkı vermesi aynı şey değil. Bu tabloyu çıkarmadan skora bakmak, ateşi ölçüp hastalığı aramamak gibi.

Hash biçimi hataları skoru sessizce düşürür

Sessiz olmalarının sebebi şu: hatalı biçimde gönderilen bir alan hata vermez, reddedilmez, sadece eşleşmez. Sık karşılaşılanlar sırayla şunlar.

• Normalizasyon atlanması. Hash almadan önce değeri sadeleştirmen gerekir: baştaki ve sondaki boşluklar silinir, harfler küçültülür. " Ayse@Firma.com " ile "ayse@firma.com" hash'lendiğinde iki farklı sonuç üretir ve ikincisi eşleşir.
• Telefonda ülke kodu eksikliği. Türkiye'de numaralar 0 ile başlayan yerel biçimde kaydedilir; gönderimde beklenen ise yalnızca rakamlardan oluşan, ülke kodu içeren biçimdir. Boşluk, parantez ve tire temizlenmeden hash alınması da aynı sonuca çıkar.
• Çift hash'leme. Tarayıcı tarafında hash'lenmiş bir değeri alıp sunucu tarafında bir kez daha hash'lemek en pahalı hatalardan biri. Alan dolu görünür, hiçbir zaman eşleşmez.
• Hash'lenmemesi gereken alanların hash'lenmesi. Tarayıcı tanımlayıcıları, IP adresi ve tarayıcı bilgisi düz gönderilir. Bunları hash'lersen kimlik sinyalini kendi elinle silmiş olursun.
• Boş değerin doldurulması. Alan yoksa alanı hiç göndermemek doğrusudur. Boş metin, "null" ya da "undefined" gibi yer tutucuların hash'lenip gönderilmesi, tüm siparişlerin aynı sahte kimliğe işaret etmesine yol açar.

Bu beş maddeyi düzeltmek yeni veri toplamayı gerektirmez, elindeki veriyi doğru biçime sokar. Bu yüzden sıraya en başa koyulur: maliyeti en düşük, etkisi en görünür iş budur.

Gelişmiş eşleştirme ne ekler, ne eklemez

Gelişmiş eşleştirme, sayfada zaten bulunan müşteri bilgisinin olayla birlikte gönderilmesini sağlar. Otomatik biçimi formlardaki ve ödeme adımındaki alanları okumaya çalışır, elle kurulan biçimde değerleri sen kendi kodunda parametre olarak geçirirsin. Elle kurulan yöntem daha güvenilirdir, çünkü hangi alanın nereden geldiğini sen bilirsin.

Ekleyemeyeceği şey de net: sayfada olmayan bilgiyi yaratamaz. Ziyaretçi anonimse gelişmiş eşleştirmeyi açmak o sayfada hiçbir şeyi değiştirmez. Kalıcı çözüm, olayı kendi veritabanından beslediğin sunucu tarafı gönderimidir; oradaki kurulum adımları ayrı bir konu, burada tek cümleyle geçiyoruz. Bu sinyaller aynı zamanda olay verisini girdi alan otomatik hedefleme katmanının hammaddesi; konuya o taraftan bakmak istersen yapay zeka destekli hedefleme sayfası bu katmanın ne iş yaptığını anlatıyor.

Shopify'da alanların kaybolduğu sayfalar

Shopify'da skorun düşük görünmesinin en sık nedeni, ödeme adımı dışındaki sayfalarda kimlik bilgisinin gerçekten var olmamasıdır. Ödeme ve teşekkür sayfasında e-posta, telefon ve adres alanları hazırdır; satın alma olayının yükü genelde en zengin olanıdır. Ürün ve koleksiyon sayfalarında ise ziyaretçi çoğu zaman anonimdir. Sayfa görüntüleme ve sepete ekleme olayları bu yüzden tarayıcı tanımlayıcısı, IP ve tarayıcı bilgisinden ibaret kalır.

Sonuç şu olur: hesap seviyesinde bakınca ortalama düşük görünür, oysa satın alma olayı gayet iyi durumdadır. Bu yüzden skoru olay bazında oku, tek bir hesap ortalaması üzerinden karar verme. Dikkat etmen gereken diğer üç nokta:

• Üye girişi yapmış müşteri ile misafir ziyaretçi aynı sayfada farklı yük üretir. Üyeliği teşvik eden bir akış, ödeme öncesi sayfalarda kimlik alanı kazandırır.
• Checkout Extensibility'ye geçişten sonra tema koduna eklenip formdan alan okuyan eski betikler ödeme adımında çalışmaz. Müşteri olayları üzerinden kurulan özel piksel yalnız kendisine sunulan yükü görür.
• Kendi pikselini kendi başına tetikleyen uygulamalar, içinde müşteri parametresi olmayan olaylar üretebilir. Bu olaylar ortalamayı aşağı çeker ve genelde kimsenin haberi olmaz.

Düzeltmeyi hangi sırayla yapmalısın

• Tek olay seç, tek zaman aralığı belirle, kapsama tablosunu çıkar.
• Biçim hatalarını kapat: normalizasyon, ülke kodu, çift hash, hash'lenmemesi gereken alanlar, yer tutucu değerler.
• Gelişmiş eşleştirmeyi aç ve test olaylarıyla hangi alanın gerçekten geldiğini gör.
• Sayfa bazında eksik kalan alanı sayfa bazında çöz; genel bir ayar aramaktan vazgeç.
• Değişiklikten sonra en az bir dolu veri periyodu bekle, skoru ertesi gün yargılama.

Son bir uyarı: eşleşme iyileştikçe panelde raporlanan satın alma sayısı da değişir. Bu yüzden düzeltmeden önceki ve sonraki dönemi karşılaştırırken ROAS hesaplamanı aynı yöntemle tekrarla. Aradaki farkın ne kadarı gerçek performans değişimi, ne kadarı daha önce zaten olmuş ama sayılamamış satış, ancak böyle ayırt edilir.