Meta Pixel Dönüşümler API Yinelenen Etkinlik: Çift Sayım Çözümü

Meta Pixel Dönüşümler API yinelenen etkinlik sorunu nedir ve önce ne yaparsınız?

Meta Pixel Dönüşümler API yinelenen etkinlik sorunu, aynı satın alma ya da potansiyel müşteri olayının tarayıcıdan (Pixel) ve sunucudan (Dönüşümler API) ayrı ayrı gelip iki kez sayılmasıdır. Önce iki kaynağın aynı olayda ortak bir event_id ve aynı event_name gönderip göndermediğine, sonra Pixel'in sitede iki kez yüklenip yüklenmediğine bakarsınız.

Panik gerekmez, çünkü bu sorun çoğunlukla kurulumdan doğar ve sırayla ayıklanır. Ekip olarak ilk baktığımız yerler şunlardır:

1. Etkinlik Yöneticisi'nde ilgili veri kümesini açın ve olay sayılarını tarayıcı ile sunucu kaynağına göre ayırın.
2. Aynı satın alma için iki kaynağın da ortak bir event_id gönderdiğini doğrulayın.
3. event_name değerinin iki kaynakta birebir aynı yazıldığına bakın.
4. Pixel temel kodunun sayfada yalnız bir kez çalıştığını kontrol edin.
5. Düzeltmeden sonra test etkinlikleri aracıyla bir deneme siparişi gönderin.

Bu yazıda tek bir durumu ele alıyoruz: Pixel ve Dönüşümler API birlikte kurulduğunda aynı olayın iki kez sayılması. Pixel kurulumunu ve eşleşme kalitesini başka yazılarda anlattık. Bu yüzden Meta Pixel kurulumu rehberine ve Event Match Quality yazısına yalnızca değinip geçiyoruz.

Pixel ile Dönüşümler API arasındaki fark nedir?

Pixel, ziyaretçinin tarayıcısında çalışan ölçüm kodudur. Sayfada ne olduğunu görür ve Meta'ya bildirir. Dönüşümler API ise bilgiyi tarayıcıdan değil, sizin sunucunuzdan Meta'ya iletir. İki yol aynı olayı farklı yerden gördüğü için birbirini tamamlar.

Tarayıcı, çerez ve gizlilik ayarlarından etkilenebilir. Sunucu ise siparişin gerçekten oluştuğunu kesin bilir. Bu nedenle birçok işletme ikisini birlikte kurar. Meta bu kurulumu yedekli (redundant) kurulum diye tanımlar.

Ancak iki kanal aynı olayı bildirdiği için Meta'ya bir ipucu vermeniz gerekir: bu iki mesaj aynı satışa aittir. Bu ipucu verilmezse yedek kanal, çift kanala dönüşür. Çift sayımın temel nedeni de budur.

Kısacası sorun kanalların kendisinde değildir. Sorun, kanalların birbirini tanımamasındadır.

Aynı satış raporda neden iki kez çıkar?

Bir müşteri sipariş verdiğinde tarayıcıdaki Pixel satın alma olayını Meta'ya gönderir. Aynı anda sunucunuz da Dönüşümler API üzerinden aynı siparişi bildirir. Meta'nın bu iki mesajın aynı siparişe ait olduğunu anlaması için ortak bir kimlik görmesi gerekir. Kimlik yoksa iki ayrı satış gibi okur.

Örneğin gerçekte 40 sipariş aldığınız bir günde raporda 80 satın alma görebilirsiniz. Bu bir örnek hesaptır, ancak mantık gerçek hesaplarda da aynıdır.

Sonuçta kampanya olduğundan iyi görünür. Üstelik reklam sistemi de şişmiş sinyalle öğrenir. Yani yanlış ölçüm yalnızca bir rapor sorunu değildir, aynı zamanda optimizasyon sorunudur.

Çift sayımın iki ana kaynağı vardır. Birincisi, tekilleştirme anahtarlarının eksik ya da uyumsuz olması. İkincisi, aynı Pixel'in sitede iki kez çalışması ya da sunucunun aynı olayı iki kez göndermesi. Bu ikisini ayırmadan düzeltmeye girişirseniz yanlış yerde vakit kaybedersiniz.

Meta tekilleştirmeyi (deduplication) nasıl yapar?

Tekilleştirme, aynı olayın iki kaynaktan gelen kopyalarından birini saymamaktır. Meta for Developers belgesine göre sistem olayları kimlik ve ada göre eşleştirir. Pixel'deki olay kimliği Dönüşümler API'deki event_id ile, Pixel'deki olay adı da event_name ile aynı olmalıdır.

Eşleşme olduğunda Meta genellikle önce aldığı olayı tercih eder. Belge ayrıca tekilleştirmenin yalnızca belirli bir zaman penceresi içinde gelen olaylar için çalıştığını söyler. Bu süre değişebileceği için güncel değeri resmi tekilleştirme belgesinden kontrol etmenizi öneririz.

Kimlik kurmadıysanız yedek bir yol vardır: fbp ve external_id değerleri ile aynı olay adı. Ancak belgeye göre bu yöntem yalnızca olay önce tarayıcıdan, sonra sunucudan geldiğinde çalışır. Tek kaynaktan gelen kopyaları da temizlemez.

Pratikte bu, iki kaynağın hangisinin önce ulaşacağını planlamaya gerek olmadığı anlamına gelir; ama ikisinin de kimlik taşıması şarttır. Biri kimliksiz giderse Meta onu eşleştirecek bir şey bulamaz ve ayrı olay olarak sayar.

event_id ve event_name eşleşmesi nasıl olmalıdır?

Eşleşmenin üç şartı vardır ve üçü de aynı anda sağlanmalıdır. Biri eksik kalırsa Meta iki kaydı farklı olay sayar.

• Aynı olay için tarayıcı ve sunucu aynı event_id değerini göndermelidir.
• event_id her olay için benzersiz olmalıdır, farklı siparişler aynı kimliği paylaşmamalıdır.
• event_name iki kaynakta aynı yazılmalıdır, yazım farkı eşleşmeyi riske atar.
• Kimlik yalnız bir kaynakta bulunuyorsa eşleşme oluşmaz.

En sağlam yaklaşım, kimliği iki tarafın da bildiği bir değerden üretmektir. Örneğin satın alma için sipariş numarasına bağlı bir değer kullanırsınız. Potansiyel müşteri olayında form gönderim kaydının numarası işe yarar. Bu bir örnek senaryodur, kendi altyapınıza göre uyarlamanız gerekir.

Tarayıcı ve sunucu kimliği birbirinden habersiz, ayrı ayrı rastgele üretirse eşleşme asla olmaz. Bu, en sık gördüğümüz hatalardan biridir. Bu nedenle kimlik üretimini tek bir yerde yapıp diğer tarafa aktarmak gerekir.

Yeniden deneme durumunda da aynı kuralı izleyin. Sunucu bir isteği tekrar gönderiyorsa aynı olay için aynı kimliği kullanmalıdır. Her denemede yeni kimlik üretirseniz her deneme yeni bir olay gibi görünür. Kimlikleri sabit tutmak, hem eşleşmeyi hem de sonradan yapacağınız incelemeyi kolaylaştırır.

Meta Pixel Dönüşümler API yinelenen etkinlik kaynağını nasıl ayırırsınız?

Belirtiye bakarak nedeni daraltırsanız gereksiz ayar değişikliğinden kurtulursunuz. Aşağıdaki tablo bunun için hızlı bir başlangıç noktasıdır. Etkinlik Yöneticisi'nde olay sayısını kaynağa göre ayırdıktan sonra tabloya dönün.

Bu tablo kesin teşhis değildir, yalnızca yönlendirir. Yine de nedenin hangi kaynakta olduğunu bulmak, düzeltmenin yarısıdır.

Pixel kodu iki kez yüklenmiş mi, nasıl anlarsınız?

Pixel iki kez yüklenirse tarayıcı her olayı iki kez gönderir. Bu durumda sorun, tarayıcı ile sunucu arasındaki eşleşme değildir. Kaynağın kendisi çiftlenmiştir. Dönüşümler API'yi hiç kurmamış bir sitede bile çift sayım yaşayabilirsiniz.

Bunu anlamak için Meta'nın sunduğu tarayıcı tanılama aracını kullanın ve sipariş sayfasını açın. Aynı Pixel kimliğinin birden fazla kez çalıştığını görürseniz kurulum çiftlenmiştir. Ayrıca etiket yöneticisi önizlemesinde aynı olayı iki etiketin tetikleyip tetiklemediğine bakın.

Bu iki durumu karıştırmayın. Kaynak çiftlenmişse ortak kimlik göndermek sorunu çözmez, çünkü iki kopya da aynı kaynaktan gelir. Belgenin de belirttiği gibi tek kaynaktan gelen kopyaları tekilleştirmeye güvenemezsiniz. Önce fazla kurulumu kapatırsınız, sonra kimlik eşleşmesine geçersiniz.

• Temaya elle eklenmiş Pixel kodu ve aynı Pixel'i yükleyen bir eklenti.
• Etiket yöneticisindeki Meta etiketi ve sitedeki ayrı bir kurulum.
• Aynı Pixel kimliğini iki ayrı olay kaynağında kullanan çoklu entegrasyonlar.
• Eski bir kurulumdan kalan ve unutulmuş bir kod parçası.

Etiket yöneticisi kullanıyorsanız Google Tag Manager nedir yazımız tetikleyici mantığını anlamanıza yardımcı olur.

CMS ve eklenti kaynaklı çift kurulumu nasıl yakalarsınız?

Çift kurulumun en yaygın nedeni, aynı Pixel'in birden fazla yerden eklenmesidir. Tema ayarı, bir eklenti, etiket yöneticisi ve platformun kendi Meta entegrasyonu aynı Pixel kimliğini ayrı ayrı kullanabilir. Bunların bazıları sunucu tarafı olay da gönderebilir.

Bu yüzden önce envanter çıkarın. Pixel kimliğinin sitede geçtiği her yeri listeleyin:

• Tema veya sayfa oluşturucunun ayar ekranı.
• Kullandığınız mağaza ya da pazarlama eklentileri.
• Etiket yöneticisindeki Meta etiketleri.
• Platformun kendi Meta entegrasyonu ya da kanal bağlantısı.
• Geliştiricinin elle eklediği özel kurulumlar.

Her maddeyi tek tek açıp kapatarak sonucu test edin. Hangisinin hem Pixel hem sunucu olayı gönderdiğini kullandığınız eklentinin belgesinden öğrenirsiniz. Sonunda her olay türü için tek bir sorumlu kurulum bırakın.

Mağaza (Shops) reklamlarında Pixel'in çoğalmasıyla ilgili ayrı bir Meta yardım sayfası da vardır. Bu tür bir kurulumunuz varsa ona da bakın.

Etkinlik Yöneticisi'nde tekilleştirmeyi nasıl kontrol edersiniz?

Meta'nın doğrulama belgesine göre Etkinlik Yöneticisi'nde tekilleştirmeye ayrılmış bir bölüm yer alır. Bu bölüm iki ölçüt gösterir: kaynak başına tekilleştirilen olayların oranı ve olaylarda tekilleştirme anahtarının kullanım oranı. Arayüz adları değişebilir, bu yüzden panelde ilgili bölümü arayın.

Bir ayrıntıya dikkat edin. Meta'nın yardım içeriğine göre Etkinlik Yöneticisi'ndeki toplam olay sayısı tekilleştirmeyi yansıtmaz. Yani toplamın iki kat çıkması, tek başına raporlarınızın da iki kat olduğu anlamına gelmez. Tekilleştirme bölümüne bakmadan yorum yapmayın.

Bölümü şöyle okursunuz:

• Anahtar kullanım oranı düşükse olayların bir kısmı kimliksiz gidiyordur.
• Anahtar oranı yüksek ama tekilleştirme oranı düşükse kimlikler birbirini tutmuyordur.
• Yalnız tek kaynak varsa ortada eşleştirecek bir çift yoktur.

Bu okumalar yön gösterir, kesin hüküm vermez. Kesin sonuç için aşağıdaki test aşamasını da uygulayın.

Test etkinlikleri aracıyla ne doğrularsınız?

Test etkinlikleri aracı, deneme siparişinin Meta'ya nasıl ulaştığını canlı izlemenizi sağlar. Araç bir test kimliği üretir. Sunucu tarafında bu kimliği test kodu parametresi olarak göndermeniz gerekir, aksi halde sunucu olayları test penceresinde çıkmaz.

Bir deneme siparişi verin ve şunlara bakın:

1. Aynı sipariş için hem tarayıcıdan hem sunucudan kayıt geliyor mu?
2. Gelen kayıtların olay adları aynı mı?
3. Her kaynaktan kaç kayıt geldi, beklediğinizden fazla mı?
4. Sayfayı yenilediğinizde ya da sipariş durumunu değiştirdiğinizde ek kayıt doğuyor mu?

Testi yalnızca mutlu yolla sınırlamayın. Şu senaryoları da deneyin: sayfayı yenilemek, ödeme sonrası geri dönmek, sipariş durumunu değiştirmek ve aynı formu iki kez göndermek. Çift sayım çoğu zaman bu kenar durumlarda ortaya çıkar.

Önemli bir uyarı daha var. Meta belgesine göre test kodu yalnız test içindir ve canlı yükten silmeniz gerekir. Üstelik bu kodla gönderilen olayları Meta atmaz; Etkinlik Yöneticisi'ne akar ve hedefleme ile ölçümde işe yarar. Yani test kodunu canlıda unutmak başlı başına bir kirlilik yaratır. Ayrıntı için doğrulama belgesine ve API kullanım belgesine bakabilirsiniz.

Teşekkür sayfası yenilenince satın alma neden tekrar sayılır?

Satın alma olayı çoğu kurulumda sipariş onay (teşekkür) sayfası yüklenince tetikler. Müşteri sayfayı yenilerse, geri tuşuyla dönerse ya da e-postadaki bağlantıdan tekrar açarsa olay yeniden çalışabilir. Sonuç aynı kaynaktan gelen kopyadır.

Bu durum kimlik eşleşmesiyle çözülen bir sorun değildir. Tarayıcı ile sunucu arasındaki eşleşme doğru olsa bile tarayıcı tarafı aynı siparişi iki kez bildirmiştir. Çözüm, olayı sipariş başına yalnız bir kez çalışacak şekilde sınırlamaktır.

Bunun için geliştiricinizden şunu isteyin: sipariş onay sayfası, siparişin olayını daha önce gönderip göndermediğini bilsin. Örneğin sipariş kaydında bir işaret tutabilirsiniz. Kodu biz yazmıyoruz, çünkü her altyapı farklıdır. Kavramı net aktarmanız yeterlidir.

Kendi testinizde de sayfayı birkaç kez yenileyin. Kayıt sayısı artıyorsa nedeni bulmuşsunuz demektir.

Sunucu aynı olayı neden iki kez gönderir?

Sunucu tarafında çift gönderimin birkaç tipik nedeni vardır. Hepsi sipariş akışındaki tetikleyicilerle ilgilidir ve çoğu zaman beklenmedik bir tekrar yüzünden ortaya çıkar.

• Sipariş durumu her değiştiğinde (ödendi, hazırlanıyor, tamamlandı) satın alma olayını yeniden göndermek.
• Ağ zaman aşımından sonra aynı isteği otomatik olarak tekrar denemek.
• Ödeme sağlayıcısının bildirimi iki kez iletmesi.
• Hem bir eklentinin hem özel entegrasyonun aynı olayı göndermesi.
• Form gönderiminde hem sayfa hem arka plan tetikleyicisinin çalışması.

Çözüm yaklaşımı hepsinde aynıdır: her siparişe tek bir olay hakkı tanırsınız. Gönderdiğiniz kimlikleri kayıt altında tutarsanız tekrarı yakalamak kolaylaşır. Ayrıca aynı kimlikle gelen ikinci bir istek tekilleştirme penceresi içindeyse Meta tarafında da elenebilir. Ama buna güvenip kaynağı düzeltmemek yanlış olur.

Sonuçta amaç, Meta'nın kopyaları ayıklamasına bırakmak değil, en baştan kopya üretmemektir.

Potansiyel müşteri olaylarında çift sayım nasıl fark edilir?

Potansiyel müşteri (Lead) olayında durum satın almadan biraz farklıdır. Çünkü form gönderimi bazen sayfa yenilenmeden, arka planda gider. Aynı form hem bir tarayıcı etiketi hem bir sunucu bağlantısı tarafından bildirilebilir.

İşaretlerden biri, form sayınızla Meta'daki potansiyel müşteri sayısının tutmamasıdır. Örneğin sitenize 25 form düştüğü halde Meta 50 potansiyel müşteri gösteriyorsa kaynak dağılımına bakın. Bu bir örnek senaryodur.

Kontrol sırası satın almadakiyle aynıdır. Önce form tetikleyicilerini sayın, sonra kimlik ve olay adını eşleştirin. Form kaydının numarasını ortak kimlik olarak kullanmak çoğu kurulumda mantıklı bir seçenektir.

Ayrıca spam gönderimler gerçek çift sayım gibi görünebilir. Bu yüzden sayıları yalnızca Meta ile değil, form kayıtlarınızla da karşılaştırın.

Dönüşümler API ve Pixel birlikte kullanılmalı mı?

Meta, iki kaynağı birlikte kullanan yedekli bir kurulumda mutlaka bir tekilleştirme yöntemi kurulmasını ister. Gerekçe basittir: tarayıcı sinyali eksik kalırsa sunucu sinyali tamamlar. Ancak bu yarar, yalnızca olaylar doğru eşleşirse gerçek olur.

Bu yüzden karar tamamen kurulumu yönetebilme gücünüze bağlıdır. Kimlik üretimini ve olay adlarını kontrol edebiliyorsanız iki kaynak birlikte iyi çalışır. Edemiyorsanız önce tek kaynakla sağlam bir ölçüm kurmak, çift sayımdan daha az zarar verir.

Hangisini seçerseniz seçin ölçümü rakamla sınayın. Sipariş sisteminizdeki gerçek sayıyla Meta'nın saydığı sayıyı yan yana koyun. Bu karşılaştırmayı aşağıdaki bölümlerde ayrıntılandırıyoruz.

Meta Pixel Dönüşümler API yinelenen etkinlik düzeltmesini hangi sırayla uygularsınız?

Sıra önemlidir, çünkü her adım bir sonrakinin ön koşuludur. Ekip olarak şu akışı izliyoruz:

1. Olay sayılarını kaynağa göre ayırıp hangi kaynağın şiştiğini bulun.
2. Pixel kimliğinin geçtiği her yeri listeleyin ve fazla kurulumları kapatın.
3. Tek kaynaklı kopyaları (sayfa yenilemesi, tekrar eden tetikleyici) giderin.
4. Tarayıcı ve sunucu için ortak bir event_id üretme yöntemi belirleyin.
5. İki kaynakta event_name yazımını birebir eşitleyin.
6. Test etkinlikleri aracıyla deneme siparişi gönderin ve kayıtları sayın.
7. Test kodunu canlıdan kaldırın.
8. Birkaç gün boyunca gerçek siparişlerle karşılaştırın.

Bu listeyi tek seferde değil, bölüm bölüm uygulayın. Böylece her değişikliğin etkisini ayrı görürsünüz. Aynı anda beş şeyi değiştirirseniz hangisinin işe yaradığını bilemezsiniz.

Çift sayımı çözerken en sık hangi hatalar yapılır?

Sahada gördüğümüz hataların çoğu, sorunu kaynağında çözmek yerine rakamı kozmetik olarak düzeltme çabasından doğar. Bunlardan kaçınmak zaman kazandırır:

• Raporu elle ikiye bölmek. Bu, rakamı düzeltir ama optimizasyon sinyalini düzeltmez.
• Pixel'i tamamen silmek. Böylece tarayıcı sinyalini de kaybedersiniz.
• Kimlik üretimini iki tarafta ayrı ayrı yapmak.
• Olay adlarını eşleştirmek için isimleri keyfi biçimde değiştirmek.
• Test kodunu canlıda bırakmak.
• Düzeltmeden hemen sonra rakamı yorumlamak.

Bu hataların ortak noktası, kaynağı aramadan sonuca atlamaktır. Oysa yukarıdaki sıra, kaynağı bulmayı öne alır. Böylece yaptığınız her değişiklik bir hipotezi sınar.

Düzeltmeden sonra rakamlar neden hemen oturmaz?

Düzeltmenin ardından ilk saatlerde rakamları yargılamayın. Eski kayıtların geriye dönük silineceğini varsaymayın; yeni olaylar düzgün sayılırken geçmiş dönem raporlarında eski şişkinlik kalabilir. Bu nedenle karşılaştırmayı düzeltme tarihinden sonraki günlerle yapın.

Ayrıca raporlama gecikmeleri ve atıf penceresi farkları kısa sürede dalgalanma yaratır. Aynı günün rakamını sipariş sistemiyle birebir tutturmaya çalışmak yanıltır. Daha doğru yöntem, birkaç günlük toplamlarda oranın sabitlenip sabitlenmediğine bakmaktır.

Oran iki katından makul bir farka inmişse düzeltme işe yaramıştır. Küçük fark normal olabilir, çünkü Meta ile sipariş sistemi aynı şeyi aynı kurallarla ölçmez. Kalıcı büyük fark sürüyorsa listeye dönüp kaynağı yeniden arayın.

İzleme planı için basit bir düzen yeterlidir:

• Düzeltme gününü not alın, böylece öncesi ve sonrası ayrı okunur.
• İlk günlerde Meta ile sipariş sayısını her gün karşılaştırın.
• Sonraki haftalarda aynı karşılaştırmayı haftada bir yapın.
• Büyük bir fark çıkarsa son değişiklikleri geri sarıp kaynağı yeniden arayın.

Raporlardaki her fark çift sayım mıdır?

Hayır, her fark çift sayım değildir. Meta'nın kendi yardım sayfası, Reklam Yöneticisi, reklam raporları ve Etkinlik Yöneticisi'ndeki olay sayılarının neden birbirinden ayrıldığını ayrıca açıklar. Bu üç yer aynı şeyi aynı biçimde saymaz. Ayrıntı için Meta yardım sayfasına bakın.

Örneğin atıf ayarları, hangi dönüşümün hangi reklama yazılacağını belirler. Bu yüzden iki ekranda farklı toplam görmeniz mümkündür. Konuyu atıf ayarlarını anlatan yazımızda ayrıntılı işledik.

Çift sayımı normal farktan ayırmak için basit bir kural işe yarar. Fark tam iki kata yakınsa ve kaynak başına dağılım çiftse tekilleştirme şüphesi güçlenir. Fark değişken ve küçükse atıf ya da zamanlama etkisini düşünün.

Çift sayım ROAS'ı ve optimizasyonu nasıl bozar?

Çift sayılan satın alma, gelirin olduğundan yüksek görünmesine yol açar. Örnek hesap yapalım: reklamda 10.000 TL harcadınız ve gerçekte 30.000 TL gelir elde ettiniz. Gerçek ROAS 3 olur. Her satış iki kez sayılırsa raporda 60.000 TL gelir ve ROAS 6 çıkar.

Bu şişkin değer birkaç sorun doğurur. Bütçeyi yanlış kampanyaya kaydırırsınız, çünkü iyi görünen kampanya aslında ortalamadır. Hedef maliyet temelli stratejiler de yanlış sinyalle çalışır. Böylece sistem, gerçek performansı yansıtmayan bir hedefe doğru öğrenir.

Kendi rakamlarınızla denemek için ROAS hesaplayıcımızı kullanabilirsiniz. ROAS'ın neden düştüğünü ya da yükseldiğini yorumlamak için ROAS düşüşü yazımıza göz atın. Düzeltme sonrası ROAS düşerse korkmayın; bu, ölçümün gerçeğe yaklaştığını gösterebilir.

Aynı mantık dönüşüm başına maliyet için de geçerlidir. Örnek hesap: 10.000 TL harcama ve 100 gerçek satış, dönüşüm başına 100 TL eder. Satışlar iki kez sayılırsa rapor 200 satış ve 50 TL gösterir. Yani maliyetiniz yarıya inmiş gibi görünür, oysa hiçbir şey değişmemiştir.

Çift sayımı sipariş kayıtları ve GA4 ile nasıl çaprazlarsınız?

En güvenilir kontrol, Meta'nın saydığı satın alma sayısını sipariş sisteminizdeki gerçek sipariş sayısıyla karşılaştırmaktır. Aynı tarih aralığını seçin ve iptal olan siparişleri ayrı düşünün. Oran bire yakınsa tekilleştirme çalışıyordur.

İkinci bir referans olarak GA4'ü kullanabilirsiniz. GA4 de kendi içinde farklı sayabilir; bu yüzden onu hakem değil, ikinci bir göz olarak görün. Dönüşümlerin GA4'te eksik çıkması ayrı bir konudur. Onu GA4 dönüşümleri eksik yazımızda anlattık.

Bu kontrolü haftalık bir alışkanlığa çevirmek istiyorsanız rapor üretimini otomatikleştirebilirsiniz. Yapay zeka ile raporlama çözümümüz bu tür karşılaştırmaları düzenli çıkarmak için bir örnektir. Önce elle kontrol edip mantığı oturtmanızı öneririz.

Meta Pixel Dönüşümler API yinelenen etkinlik bir daha yaşanmasın diye hangi alışkanlıkları edinirsiniz?

Kalıcı çözüm, ölçüm kurulumunu bir kerelik iş değil, düzenli bakım olarak görmektir. Sitede her büyük değişiklikten sonra (tema, eklenti, ödeme sağlayıcı, form) ölçümü yeniden test edin. Çoğu çift sayım, kimsenin ölçümü hatırlamadığı bir güncellemeden sonra başlar.

• Her olay türü için tek bir sorumlu kurulum belirleyin ve bunu yazılı tutun.
• Yeni eklenti eklemeden önce Meta ile ilgili özelliklerini kapatın ya da kontrol edin.
• Her sürüm değişikliğinden sonra bir deneme siparişi gönderin.
• Haftalık olarak Meta ile sipariş sayısını karşılaştırın.
• Test kodunu canlıdan kaldırdığınızı not edin.

Benzer ölçüm ve doğrulama sorunları başka platformlarda da çıkar. Örneğin sitenizi Pinterest'te sahiplenemiyorsanız Pinterest web sitesi doğrulama yazımıza bakabilirsiniz. Ürün kataloğunuz WhatsApp'ta görünmüyorsa WhatsApp Business katalog yazımız işinize yarar.

Meta arayüzü veya belge adları değişirse ne yaparsınız?

Platformlar menü adlarını ve ekran düzenini zaman zaman değiştirir. Bu yazıda buton metnine yaslanmamamızın nedeni de budur. Mantık ise sabit kalır: iki kaynak, ortak kimlik, aynı olay adı ve tek sorumlu kurulum.

Arayüz farklı görünüyorsa önce Meta'nın güncel yardım ve geliştirici belgelerindeki tekilleştirme sayfasına bakın. Ardından aynı üç soruyu sorun: olay iki kaynaktan mı geliyor, kimlikler tutuyor mu, kaynak çiftlenmiş mi? Bu üç soruya verdiğiniz yanıt, ekran nasıl görünürse görünsün doğru adımı gösterir.

Ne zaman uzman desteği almanız mantıklı olur?

Kimlik üretimi, sunucu tetikleyicileri ve eklenti çakışmaları teknik bilgi ister. Siz yukarıdaki kontrolleri yapıp nedeni daralttıysanız ama sunucu tarafını değiştirecek kişiye ulaşamıyorsanız destek almak mantıklıdır. Sorunu kendi başınıza çözmek zorunda değilsiniz.

Talha Aslan ve ekibi olarak Meta reklam ölçümünü ve raporlamayı sosyal medya yönetimi çalışmalarımızın bir parçası olarak ele alıyoruz. İhtiyacınız varsa sosyal medya yönetimi sayfamızdan bize ulaşabilirsiniz. Ölçüm düzeltmesinde kesin sonuç sözü vermeyiz, çünkü sonuç sitenizin altyapısına ve eklentilerinize bağlıdır.

Not: Bu yazı genel bilgi içerir. Menü adları ve belge ayrıntıları zamanla değişebilir, bu yüzden uygulamadan önce Meta'nın güncel belgelerini kontrol edin.