Event Match Quality Nedir? Meta Olay Eşleştirme Kalitesini Artırma Yolları

Meta reklamlarında aynı bütçeyle iki hesabın bambaşka sonuç almasının sessiz nedenlerinden biri ölçüm kalitesidir. Event match quality, yani Olaylar Yöneticisinde gördüğünüz olay eşleştirme kalitesi puanı, sunucudan giden her dönüşümün gerçek bir kişiye ne kadar iyi bağlandığını gösterir. Bu yazıda puanın mantığını, hangi verilerin onu yükselttiğini ve gizliliği bozmadan nasıl iyileştireceğinizi anlatıyorum.

Anlattıklarımın hepsi Meta'nın resmi geliştirici belgelerine ve 2012'den beri reklam hesaplarında yaptığım ölçüm denetimlerine dayanıyor. Uydurma ortalama puanlar ya da "şu ayarı açın, satışlar ikiye katlansın" türü vaatler bulamayacaksınız. Bunun yerine her adımı neden yaptığınızı ve nasıl kontrol edeceğinizi göreceksiniz. Böylece yazılımcınızla ya da ajansınızla aynı dili konuşabilirsiniz.

Event match quality nedir?

Event match quality (EMQ), Meta'nın Conversions API ile sunucudan gönderdiğiniz bir olayı Facebook veya Instagram hesabıyla eşleştirme olasılığını 10 üzerinden puanlayan göstergedir. Puan; gönderdiğiniz müşteri bilgisi parametrelerine, bu verilerin kalitesine ve hesapla eşleşen olay oranına dayanır. Yüksek puan, daha doğru ilişkilendirme ve daha iyi optimizasyon demektir.

Meta'nın geliştirici belgelerine göre bu puan şu an yalnız web olayları için hesaplanır. Uygulama olayları ya da çevrimdışı olaylar için aynı ekranı görmezsiniz. Ayrıca puan tek bir olay türüne aittir; Purchase için 8 görürken Lead için 4 görmeniz son derece normaldir. Bu nedenle "hesabımın puanı" diye tek bir sayı yoktur, her olayı ayrı okumanız gerekir.

Kısacası EMQ, reklam sisteminin "bu satın almayı kim yaptı?" sorusuna ne kadar güvenle cevap verebildiğini ölçer. Cevap belirsizleştikçe reklam sistemi daha az sinyal alır. Sonuç olarak hem raporlarınız eksik kalır hem de algoritma yanlış kişilere daha çok bütçe harcar.

Event match quality puanı neden bu kadar önemlidir?

Meta, bir dönüşümü ancak onu bir hesaba bağlayabildiğinde reklama atfedebilir. Eşleşmeyen olay raporda görünmez ve öğrenme sürecine katkı vermez. Dolayısıyla düşük puan, siz satış yapsanız bile reklam sisteminin o satışı "görmediği" anlamına gelebilir.

Bu durumun üç somut etkisi vardır:

• Raporlama: Reklam yöneticisindeki dönüşüm sayısı, mağaza panelinizdeki gerçek sayının gerisinde kalır.
• Optimizasyon: Algoritma daha az örnekle öğrenir; bu yüzden reklam setleri öğrenme aşamasından geç çıkar.
• Kitleler: Satın alanları dışlama ya da onlara benzer kişileri bulma gibi işlemler eksik listeyle çalışır.

Sahada gördüğüm en yaygın tablo şudur: marka "Meta satış getirmiyor" der, oysa sorun satışın ölçülememesidir. Ancak burada dürüst olmak gerekir; EMQ yükselmesi tek başına daha fazla satış yaratmaz. Yalnız var olan satışların reklam sistemine daha net ulaşmasını sağlar. Böylece bütçe kararlarınızı daha sağlam bir zemine oturtursunuz.

Meta eşleşme puanını nasıl hesaplar?

Meta, hesaplama formülünü ayrıntılı paylaşmıyor. Buna karşılık belgelerinde üç bileşeni açıkça sayıyor: sunucudan hangi müşteri bilgisi parametrelerinin geldiği, bu verilerin kalitesi ve olayların yüzde kaçının bir Meta hesabıyla eşleştiği.

Parametrelerin ağırlığı eşit değildir. Meta'nın Conversions API en iyi uygulamalar sayfası e-posta, IP adresi, ad ve soyad ile telefon numarasını eşleşme kalitesini artıran yüksek değerli bilgiler olarak öne çıkarıyor. Öte yandan şehir, ülke, posta kodu ve cinsiyet gibi alanlar tek başına zayıf kalır. Hatta Meta, yalnız bu tür genel alanlardan oluşan bazı kombinasyonları geçersiz sayıyor.

Kalite kısmı da en az miktar kadar önemlidir. Örneğin e-postayı büyük harfle ya da boşlukla hash'lerseniz, parametre gönderilmiş görünür ama hiçbir hesapla eşleşmez. Yani puanı yükseltmenin yolu "daha çok alan" değil, "doğru biçimde daha çok güçlü alan" göndermektir.

Event match quality puanını nerede görürsünüz?

Puanı Meta Olaylar Yöneticisinde, ilgili veri kümesinin (piksel) genel bakış ekranında görürsünüz. Olay listesinde bir olayın satırını açtığınızda eşleşme kalitesi ayrıntısı, gönderdiğiniz parametreler ve bu parametrelerin olayların yüzde kaçında bulunduğu listelenir. Arayüz zaman zaman değiştiği için menü adlarına takılmayın; aradığınız şey olay ayrıntısındaki eşleşme kalitesi bölümüdür.

Teknik ekibiniz varsa aynı verilere Dataset Quality API üzerinden de ulaşabilirsiniz. Bu uç nokta; EMQ puanını, tanılama uyarılarını, olay kapsamını, veri tazeliğini ve tekilleştirme oranlarını tek yanıtta döndürür. Böylece puanı her hafta elle kontrol etmek yerine kendi panonuza çekebilirsiniz.

Ekranda gördüğünüz parametre listesinin yanında her alan için bir kapsama yüzdesi bulunur. Bu yüzde sıklıkla puandan daha öğreticidir. Örneğin e-postanın yalnız satın almaların yarısında geldiğini görürseniz, sorunun hangi ödeme akışında olduğunu hemen aramaya başlarsınız.

Hangi müşteri bilgisi parametreleri puanı etkiler?

Meta'nın müşteri bilgisi parametreleri belgesi her alanın anahtarını ve biçim kuralını listeliyor. Aşağıdaki tablo, sahada en çok işe yarayan alanları bir araya getiriyor.

Tabloyu okurken şu kuralı akılda tutun: bir alanın "gönderilmesi" yetmez, olayların büyük kısmında gelmesi gerekir. Örneğin telefon alanı formda isteğe bağlıysa ve çoğu kişi boş bırakıyorsa, Olaylar Yöneticisi bu alanın kapsamını düşük gösterir. Bu yüzden form tasarımı ile ölçüm kalitesi birbirinden ayrı düşünülmemelidir; bu konuya aşağıda döneceğim.

Meta Pixel tek başına neden yeterli olmuyor?

Pikselin nasıl kurulduğunu, standart olayları ve temel Conversions API farkını Meta Pixel kurulum rehberinde ayrıntılı anlattım. Burada yalnız eşleşme açısından kritik olan kısma odaklanıyorum.

Piksel tarayıcıda çalışır. Dolayısıyla reklam engelleyiciler, tarayıcıların izleme korumaları, yavaş sayfa yüklenmesi ve çerez rızası gibi etkenler olayın hiç çıkmamasına neden olabilir. Olay çıksa bile tarayıcıda e-posta ya da telefon genelde yoktur. Pikselin gelişmiş eşleştirme özelliği formlardaki bazı alanları yakalayabilir; ancak her ödeme sayfasında güvenilir çalışmaz.

Sunucu tarafında ise durum farklıdır. Sipariş veritabanınıza düştüğü anda e-posta, telefon, ad ve adres elinizdedir. Bu nedenle Meta, en güçlü eşleşme verisini tarayıcıdan değil sunucudan beklemektedir. Üstelik EMQ puanı da tam olarak bu sunucu olaylarını değerlendirir. Piksel olmadan yalnız sunucu, ya da sunucu olmadan yalnız piksel yerine ikisini birlikte çalıştırmak, Meta'nın da önerdiği yedekli kurulumdur.

Conversions API eşleşmeyi nasıl güçlendirir?

Conversions API, olayı sizin sunucunuzdan doğrudan Meta'ya gönderir. Böylece tarayıcıda kaybolan olayları geri kazanır ve her olaya sipariş anındaki müşteri bilgisini ekleyebilirsiniz. Eşleşme kalitesindeki büyük sıçramalar çoğu zaman bu adımdan gelir.

Kurulum yolu altyapınıza göre değişir:

• Hazır e-ticaret altyapıları: Birçok platform Meta ile resmi entegrasyon sunar. Önce bu entegrasyonun hangi parametreleri gönderdiğini Olaylar Yöneticisinde kontrol edin.
• Sunucu taraflı etiket yönetimi: Google Tag Manager sunucu kapsayıcısı, tek veri katmanıyla hem Google hem Meta olaylarını beslemenizi sağlar.
• Doğrudan API entegrasyonu: Özel yazılım kullanan sitelerde en esnek yol budur; sipariş kaydedildiği anda olayı sunucudan gönderirsiniz.

Hangi yolu seçerseniz seçin, olayı gerçek zamanlı ya da gerçek zamana yakın gönderin. Meta, olayları gerçekleştiği anda paylaşmanın kampanya sonuçlarına yardım ettiğini belgelerinde açıkça belirtiyor. Gece toplu gönderim, puanı değil ama optimizasyonun hızını olumsuz etkiler.

Verileri nasıl normalleştirip hash'lemelisiniz?

Hash, e-posta gibi bir veriyi geri döndürülemez bir karakter dizisine çeviren tek yönlü işlemdir. Meta, kişisel alanları SHA-256 ile hash'lenmiş biçimde bekler ve kendi tarafında aynı işlemi yaparak eşleştirir. Bu nedenle tek bir harf farkı bile eşleşmeyi bozar.

Hash'lemeden önce şu normalleştirme adımlarını uygulayın:

1. E-posta: Baştaki ve sondaki boşlukları silin, tüm harfleri küçültün.
2. Telefon: Boşluk, parantez, tire ve baştaki sıfırları atın; ülke kodunu ekleyin. Türkiye için numara 90 ile başlar.
3. Ad ve soyad: Küçük harfe çevirin, noktalama işaretlerini kaldırın. Türkçe karakterleri UTF-8 ile koruyun.
4. Şehir ve posta kodu: Küçük harf kullanın, boşluk ve özel karakter bırakmayın.
5. Ülke: İki harfli ISO kodunu küçük harfle yazın, örneğin tr.

IP adresini, tarayıcı bilgisini, fbp ve fbc değerlerini ise asla hash'lemeyin. Meta bu alanları ham hâliyle bekler. Sahada en sık gördüğüm hata budur: geliştirici "güvenli olsun" diye her şeyi hash'ler ve IP ile tarayıcı eşleşmesi tamamen çöker.

fbp ve fbc değerlerini nasıl korursunuz?

fbp, pikselin tarayıcıya yazdığı kimlik çerezidir. fbc ise reklam tıklamasında adres satırına eklenen fbclid değerinden türeyen tıklama kimliğidir. Bu iki alan, sunucu olayını tarayıcıdaki ziyaretle ve reklam tıklamasıyla aynı kişiye bağlar.

Sorun şu ki sunucu, bu değerleri kendiliğinden bilmez. Ziyaretçi sepete eklediğinde ya da ödeme yaptığında çerezleri okuyup siparişle birlikte saklamanız gerekir. Örneğin ödeme sağlayıcısına yönlenip geri dönen akışlarda çerez değeri kaybolabilir. Bu yüzden değerleri sipariş oluşturulmadan önce veritabanına yazın.

Ayrıca adres satırındaki parametreleri koruyun. Bazı yönlendirmeler ve kısa link servisleri fbclid değerini siler; böylece fbc hiç oluşmaz. UTM oluşturucu ile kurduğunuz etiketlerin fbclid ile çakışmadığını ve yönlendirmelerde düşmediğini test edin. Meta bu çerezlerin biçiminin değişebileceğini de belirtiyor; değerleri kendiniz üretmek yerine tarayıcıdan okuyun ve düzenli olarak yenileyin.

IP adresi ve tarayıcı bilgisi neden kritiktir?

IP adresi ile tarayıcı bilgisi (user agent), e-posta olmayan olaylarda bile eşleşmeye katkı verir. Meta, web olaylarında tarayıcı bilgisini zorunlu tutar ve IP adresini yüksek değerli alanlar arasında sayar. Buna rağmen bu iki alan en çok yanlış gönderilen alanlardır.

En yaygın hata, sunucu olayına ziyaretçinin değil sunucunun kendi IP adresini koymaktır. Özellikle CDN ya da yük dengeleyici arkasındaki sitelerde bu sık yaşanır. Dataset Quality API örneklerinde de IP kalitesi ve uyuşmayan IP adresi, tanılama uyarıları arasında yer alıyor. Çözüm için ziyaretçi IP'sini yönlendirme başlığından doğru okuyup olay anında kaydedin.

Öte yandan Meta, IPv6 adresini IPv4'e tercih ettiğini belirtiyor. Ziyaretçi IPv6 ile geliyorsa onu IPv4'e çevirmeye çalışmayın. Kısacası bu iki alanı "teknik ayrıntı" diye geçmeyin; e-posta toplamadığınız üst huni olaylarında eşleşmenin ana taşıyıcısı çoğu zaman bunlardır.

external_id eşleşmede ne işe yarar?

external_id, kendi sisteminizdeki müşteri numarasıdır. Meta bu değeri doğrudan bir Facebook hesabıyla eşleştirmez; ancak aynı kişinin farklı oturumlarını ve olaylarını birbirine bağlamasına yardım eder. Hash'lenmesi zorunlu değildir ama önerilir.

Pratik değeri şuradadır: üye girişi yapan bir müşteri bugün mobilde ürüne bakar, iki gün sonra masaüstünde satın alır. Her iki olayda aynı external_id giderse, sistem bu yolculuğu tutarlı biçimde okur. Ayrıca aynı değeri hem piksel hem sunucu olayında gönderirseniz, Meta'nın belirttiği alternatif tekilleştirme yöntemlerinden birini de kullanmış olursunuz.

Burada dikkat edilecek nokta tutarlılıktır. Pikselde bir biçim, sunucuda başka bir biçim kullanırsanız iki değer hiç buluşmaz. Bu yüzden müşteri numarasını tek bir kaynaktan üretin. Lead toplayan sitelerde bu kaynak genellikle CRM kaydıdır; CRM entegrasyonlu lead takibi kurduysanız aynı kimliği Meta'ya da taşıyabilirsiniz.

Tekilleştirme hataları sonuçları nasıl bozar?

Piksel ve Conversions API birlikte çalıştığında aynı satın alma iki kez gelir. Meta, aynı olay adı ve aynı event_id ile gelen tarayıcı ve sunucu olaylarını 48 saat içinde birleştirir ve sonraki kopyayı atar. event_id eşleşmezse satış iki kez sayılır.

Çift sayım EMQ puanını doğrudan düşürmeyebilir, ancak raporları şişirir ve ROAS'ı olduğundan iyi gösterir. Tam tersine, event_id'yi yanlış üretip farklı satışlara aynı kimliği verirseniz, gerçek satışlar silinir. İki hata da aynı kökten gelir: kimliği tarayıcı ve sunucu ayrı ayrı üretir.

Doğru yöntem, event_id'yi tek bir yerde üretip iki kanala da aynı değeri vermektir. Örneğin satın almada sipariş numarası mükemmel bir event_id'dir. Kontrol için Olaylar Yöneticisinde olay ayrıntısındaki tekilleştirme bilgisine bakın. Sonra reklam panelindeki satın alma sayısını mağaza panelinizle karşılaştırın; ROAS hesaplayıcı ile iki kaynaktan çıkan sonucu yan yana koymak farkı hızla gösterir.

Olay kapsamı ve veri tazeliği neden izlenmeli?

EMQ puanı tek başına resmin tamamını vermez. Meta, Conversions API kurulumunun sağlığını değerlendirirken iki yardımcı ölçüye daha bakar: olay kapsamı ve veri tazeliği.

• Olay kapsamı: Piksel olaylarının yüzde kaçının Conversions API tarafından da gönderildiğini gösterir. Dataset Quality API bunu 7 günlük ortalama olarak raporlar. Belgedeki örnekte bir olayın kapsamı %34,1 iken hedef eşiği %75 olarak görünüyor.
• Veri tazeliği: Olayın gerçekleştiği an ile Meta'ya ulaştığı an arasındaki farkı ölçer. Gerçek zamanlı gönderim ile saatlik gönderim aynı değerde değildir.
• Ek raporlanan dönüşümler: Meta, Conversions API kurulumunuz sayesinde ek olarak ölçülen dönüşümleri tahmin eder ve hangi eşleştirme anahtarlarını eklerseniz ne kadar fark oluşabileceğini gösterir.

Bu üç ölçüyü EMQ ile birlikte okuyun. Yüksek puan ama düşük kapsam, olayların yalnız küçük bir kısmının iyi eşleştiği anlamına gelir. Dolayısıyla kapsamı artırmadan puana odaklanmak yarım bir iyileştirmedir.

Gizlilik ve KVKK açısından nelere dikkat etmelisiniz?

Eşleşme kalitesini artırmanın yolu kişisel veri göndermekten geçtiği için bu konu hukuki sorumlulukla doğrudan bağlantılıdır. Hash, veriyi okunamaz kılar ama onu kişisel veri olmaktan çıkarmaz. Bu yüzden hash'i bir hukuki izin gibi görmeyin.

Türkiye'de faaliyet gösteren bir site için temel sorular şunlardır: aydınlatma metniniz Meta ile veri paylaşımını anlatıyor mu, pazarlama amaçlı paylaşım için açık rıza alıyor musunuz ve yurt dışına veri aktarımı konusunu değerlendirdiniz mi? Avrupa'ya satış yapıyorsanız GDPR tarafı da devreye girer. Genel çerçeveyi KVKK ve GDPR uyumlu web sitesi rehberinde anlattım; somut metinler için mutlaka bir hukukçuyla çalışın.

Meta'nın kendi yaklaşımı nettir: pikselde veri paylaşımını rızaya bağlayan bir mantığınız varsa, aynı mantığı Conversions API için de uygulayın. Yani sunucu tarafı, rızayı atlamanın arka kapısı değildir. Ayrıca ABD'deki bazı eyaletler için Meta, sınırlı veri kullanımı adında veri işleme seçenekleri sunar; hedef pazarınız buna giriyorsa bu parametreleri de değerlendirin.

Rıza vermeyen ziyaretçilerde ne olur?

Rıza vermeyen ziyaretçinin olayını göndermezsiniz. Bu, puanın ve dönüşüm sayısının bir kısmını kabul ederek kaybetmek demektir. Bence bu kayıp, hukuki riskle karşılaştırıldığında her zaman ödenmesi gereken bir bedeldir.

Ancak kaybı küçültmenin meşru yolları var. İlk olarak rıza bandınızı anlaşılır yazın; belirsiz ve korkutucu metinler ret oranını gereksiz yere yükseltir. İkinci olarak rıza veren ziyaretçilerin olaylarını eksiksiz gönderin; eşleşme kalitesini asıl bu grupta yükseltirsiniz. Son olarak rıza durumunu sipariş kaydında saklayın ki sunucu olayı gönderirken aynı kararı uygulayabilsin.

Sahada sık gördüğüm bir hata, rıza bandını pikselde doğru kurup sunucu olayında bu bilgiyi hiç kontrol etmemektir. Böylece site, farkında olmadan ret veren kişilerin verisini de sunucudan gönderir. Bu tür bir tutarsızlığı düzeltmek, EMQ puanını birkaç puan yükseltmekten çok daha önemlidir.

Formlar ve ödeme akışı puanı nasıl etkiler?

Eşleşme kalitesi yalnız kodla ilgili değildir; hangi veriyi topladığınızla da ilgilidir. Misafir ödemesinde yalnız e-posta soruyorsanız telefonu gönderemezsiniz. Lead formunuzda yalnız ad ve telefon varsa e-posta alanı boş kalır.

Bu, her forma yeni alan ekleyin demek değildir. Fazla alan, dönüşüm oranını düşürür. Bunun yerine zaten topladığınız verinin olaya eksiksiz aktarıldığından emin olun. Örneğin satın alma olayında adres bilgisi siparişte mevcut olduğu hâlde olaya eklenmiyorsa, bu ücretsiz bir iyileştirme fırsatıdır.

Ayrıca olay zamanlamasına bakın. Sepete ekleme gibi erken olaylarda ziyaretçi henüz kimliğini vermemiştir; bu yüzden bu olayların puanı doğal olarak düşük kalır. Ziyaretçi giriş yaptıysa, oturumdaki kimlik bilgisini bu olaylara da ekleyebilirsiniz. Kısacası her olayı kendi aşamasının imkânlarıyla değerlendirin, üst huni olaylarından satın alma puanı beklemeyin.

Lead toplayan sitelerde eşleşme nasıl iyileşir?

Hizmet sektöründe satış çoğu zaman bir form ya da telefon görüşmesiyle başlar. Bu sitelerde en değerli olay Lead olayıdır ve formda zaten ad, telefon ve çoğu zaman e-posta bulunur. Yani eşleşme için gereken veri elinizdedir; eksik olan genellikle bu verinin sunucu olayına aktarılmasıdır.

Pratikte şu yolu öneriyorum. Form gönderildiğinde kaydı önce kendi veritabanınıza ya da CRM'e yazın. Ardından aynı kayıttan Lead olayını sunucudan gönderin ve form alanlarını normalleştirip hash'leyerek ekleyin. Böylece tarayıcı olayı kaybolsa bile olay Meta'ya ulaşır.

Öte yandan Meta'nın kendi form reklamlarını kullanıyorsanız, formdan gelen lead kimliğini saklayın. Meta bu değeri lead_id adıyla ayrı bir müşteri bilgisi parametresi olarak kabul ediyor. Satış ekibi görüşmeyi kapattığında bu kimlikle sonraki aşama olayını göndermek, hangi reklamın gerçekten müşteri getirdiğini görmenizi sağlar.

Değişiklikleri Test Olayları ekranında nasıl doğrularsınız?

Her düzeltmeden sonra canlı veriyi beklemek yerine Olaylar Yöneticisindeki Test Olayları ekranını kullanın. Bu ekran, size özel bir test kodu verir. Bu kodu sunucu olayına geçici olarak eklediğinizde gelen olayları ve içindeki parametreleri anında görürsünüz.

Kontrol sırasında üç soruya cevap arayın. İlk olarak beklediğiniz tüm parametreler geliyor mu? İkinci olarak aynı işlem hem tarayıcıdan hem sunucudan geldiğinde tek olay olarak birleşiyor mu? Son olarak IP adresi gerçekten sizin bağlantınızın adresi mi? Bu üç soru, sahada gördüğüm hataların büyük kısmını yakalar.

Test bittiğinde kodu mutlaka kaldırın. Aksi halde canlı olaylar test akışına düşer ve raporlarda eksik görünür.

Event match quality adım adım nasıl artırılır?

Yeni bir hesabı devraldığımda ekibimle izlediğimiz sıra aşağıdaki gibidir. Adımları sırayla uygulamak, hangi değişikliğin ne kadar etki yaptığını görmenizi sağlar.

1. Durum tespiti: Her ana olayın EMQ puanını, parametre kapsamını ve olay kapsamını not alın.
2. Sunucu olaylarını kurun: Conversions API yoksa önce satın alma ve lead olaylarında başlatın.
3. Zorunlu alanları düzeltin: Ziyaretçi IP'si, tarayıcı bilgisi ve olay kaynağı adresi her olayda doğru gitsin.
4. Güçlü alanları ekleyin: E-posta, telefon, ad ve soyadı normalleştirip hash'leyerek gönderin.
5. Çerezleri taşıyın: fbp ve fbc değerlerini siparişe kaydedip sunucu olayına ekleyin.
6. Tekilleştirmeyi doğrulayın: Aynı event_id'nin iki kanalda da gittiğini Test Olayları ekranında kontrol edin.
7. Rıza mantığını eşitleyin: Piksel ve sunucu aynı rıza kararını uygulasın.
8. İzleyin: Değişiklikten sonra puanın ve kapsamın birkaç gün içindeki seyrini takip edin.

Bu sırada tanılama sekmesindeki uyarıları da tek tek kapatın. Meta'nın kendi uyarıları, çoğu zaman sorunun tam yerini gösterir.

Event match quality için hangi hatalar en sık yapılır?

Denetlediğim hesaplarda aynı hatalar tekrar tekrar karşıma çıkıyor. Bunların çoğu birkaç saatlik geliştirme işiyle düzelir.

• E-postayı büyük harf ya da boşlukla hash'lemek.
• Telefonu ülke kodu olmadan ya da baştaki sıfırla göndermek.
• IP adresini, tarayıcı bilgisini veya fbp değerini de hash'lemek.
• Ziyaretçinin değil sunucunun IP adresini göndermek.
• event_id'yi tarayıcıda ve sunucuda ayrı ayrı üretmek.
• Test olay kodunu canlıya geçtikten sonra kodda unutmak.
• Olayları saatler sonra toplu göndermek.

Bu listeyi bir kontrol formu gibi kullanabilirsiniz. Ancak her maddeyi kodda değil, Olaylar Yöneticisindeki gerçek olay örneği üzerinde doğrulayın. Çünkü kodda doğru görünen bir alan, eklenti çakışması yüzünden hiç gitmiyor olabilir.

Puan yükseldikten sonra sonuçları nasıl okumalısınız?

Eşleşme kalitesi iyileştiğinde reklam yöneticisindeki dönüşüm sayısı artabilir. Bu artışın bir kısmı yeni satış değil, önceden görünmeyen satışların artık ölçülmesidir. Dolayısıyla değişiklik haftasını performans karşılaştırmasında ayrı tutun.

Doğru okuma için iki kaynağı birlikte izleyin: mağaza ya da CRM paneliniz ve reklam paneliniz. Gerçek satış sayısı aynı kalırken reklam panelindeki sayı arttıysa ölçüm iyileşmiştir. Gerçek satışlar da artıyorsa, algoritmanın daha iyi sinyalle daha iyi kitle bulduğunu düşünebilirsiniz.

Ayrıca ilişkilendirme ayarınızın sayıları nasıl etkilediğini unutmayın. Tıklama sonrası ve görüntüleme sonrası pencereler farklı sonuç verir; bu konuyu Meta ilişkilendirme ayarları yazısında anlattım. Benzer bir ölçüm mantığı Google tarafında da var; gelişmiş dönüşümler de hash'lenmiş müşteri verisiyle eşleşmeyi güçlendirir.

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

Hazır bir e-ticaret altyapısı kullanıyor ve resmi entegrasyonu açtıktan sonra satın alma puanınız yüksek görünüyorsa, büyük ihtimalle ek işe gerek yoktur. Ancak özel yazılım, çoklu ödeme akışı, üye ve misafir karışık yapı ya da CDN arkasında çalışan bir site söz konusuysa, eşleşme sorunlarını kendi başınıza bulmak zaman alır.

Biz ekibimle bu işlere ölçüm denetimiyle başlıyoruz: her olayın gerçekten ne gönderdiğini, rıza kararının iki kanalda da uygulanıp uygulanmadığını ve tekilleştirmenin çalışıp çalışmadığını tek tek kontrol ediyoruz. Ardından düzeltmeleri önem sırasına göre uyguluyoruz. Reklam yönetimini de üstlenmemizi isterseniz sosyal medya yönetimi hizmetimiz kapsamında Meta kampanyalarını ölçüm altyapısıyla birlikte ele alıyoruz. E-ticaret sitelerinde ise bu çalışma e-ticaret danışmanlığı sürecinin doğal bir parçasıdır.

Özetle, EMQ puanı bir hedef değil bir sağlık göstergesidir. Puanı yükseltirken gizlilik kurallarından ödün vermeyin; doğru veriyi, doğru biçimde ve zamanında göndermeye odaklanın.