Meta Pixel Gelişmiş Eşleştirme: Hash, fbc/fbp ve CAPI Dedup

Meta reklam hesaplarında en sık gördüğümüz sorun, olayların hiç gönderilmemesi değil, gönderilen olayların bir hesapla eşleşmemesidir. Satın alma tetiklenir, Events Manager olayı gösterir, ancak Meta o dönüşümü kime atfedeceğini bilemez. Bu yazıda gelişmiş eşleştirmeyi parametre normalizasyonundan başlayıp hash’leme, fbc/fbp çerez yaşam döngüsü, Conversions API tekilleştirmesi ve EMQ teşhisine kadar uçtan uca kuruyoruz.

Önemli Noktalar

• Gelişmiş eşleştirme, olayla birlikte hash’lenmiş müşteri bilgisi göndererek Meta’nın olayı bir hesaba bağlamasını sağlar.
• Normalizasyon hash’lemeden önce gelir; +905321541120 ile 905321541120 Meta için iki ayrı kullanıcıdır.
• Tekilleştirme penceresi 48 saattir ve hem event_id hem event_name eşleşmelidir.
• Meta, çakışmada ilk aldığı olayı tercih ettiğini söyler; tarayıcı olayı her zaman kazanır bilgisi yanlıştır.
• Safari, document.cookie ile yazılan _fbp ve _fbc çerezlerini 7 güne indirir; sunucu tarafı Set-Cookie bu sınırdan muaftır.
• EMQ bir teşhis aracıdır, ROAS vekili değildir; eşleşme kalitesini ölçer, olay kapsamını ölçmez.

Meta Pixel Gelişmiş Eşleştirme Nedir?

Meta Pixel gelişmiş eşleştirme (advanced matching), bir dönüşüm olayıyla birlikte e-posta, telefon numarası, ad, soyad, şehir, eyalet, posta kodu, ülke, doğum tarihi ve cinsiyet gibi müşteri bilgilerinin SHA-256 ile hash’lenmiş halinin Meta’ya gönderilmesidir. Meta bu hash değerlerini kendi kullanıcı kayıtlarındaki aynı yöntemle hash’lenmiş değerlerle karşılaştırır ve olayı bir Facebook veya Instagram hesabına bağlar. Ham veri Meta’ya hiçbir zaman ulaşmaz, karşılaştırma yalnızca hash değerleri üzerinden yapılır.

Bunun neden gerektiği tek cümleyle açıklanabilir: çerez tabanlı eşleştirme artık tek başına yetmiyor. _fbp çerezi okunamadığında, kullanıcı oturum açmamışken veya tarayıcı çerez ömrünü kırptığında Meta’nın elinde olayı bağlayacak bir kimlik kalmaz. Hash’lenmiş müşteri bilgisi, çerezden bağımsız ikinci bir eşleştirme yolu açar.

Gelişmiş eşleştirme üç ayrı biçimde çalışır ve bunları karıştırmamak gerekir:

• Otomatik gelişmiş eşleştirme (AAM): Events Manager üzerinden açılır, Pixel sayfadaki form alanlarını kendisi okumaya çalışır. Kurulumu kolaydır, güvenilirliği düşüktür.
• Manuel gelişmiş eşleştirme: Değerleri fbq('init', ...) çağrısına veya olay parametrelerine siz verirsiniz. Kontrol sizdedir.
• CAPI customer_data: Aynı parametre seti sunucunuzdan doğrudan Meta’ya gönderilir. Reklam engelleyicilerden ve tarayıcı çerez sınırlarından etkilenmez.

Üçü birbirinin alternatifi değildir. Doğru kurulum, manuel gelişmiş eşleştirme ile CAPI customer_data bileşimini aynı event_id altında birlikte çalıştırmaktır.

Hangi Parametreler Hash’lenir, Hangileri Hash’lenmez?

Bu ayrım kurulumların yarısında yanlış yapılır. Yanlış tarafta hash’lenen bir parametre sessizce eşleşmez, hata da vermez.

Parametre	Hash	Açıklama
em, ph, fn, ln	SHA-256 zorunlu	E-posta, telefon, ad, soyad
ct, st, zp, country	SHA-256 zorunlu	Şehir, eyalet, posta kodu, ülke
db, ge	SHA-256 zorunlu	Doğum tarihi, cinsiyet
external_id	Önerilir	Kanallar arası aynı format olmalı
client_ip_address	Hash'lenmez	Sunucu tarafında zorunlu
client_user_agent	Hash'lenmez	Sunucu tarafında zorunlu
fbc, fbp	Hash'lenmez	Çerezden ham değer gönderilir
fb_login_id, lead_id	Hash'lenmez	Meta tarafından üretilen kimlikler

Hash'leme sorumluluğu kanala göre değişir: tarayıcıda Pixel hash'ler, Conversions API tarafında hash'lemeyi siz yaparsınız.

Parametreleri Nasıl Normalize Etmeliyiz?

Normalizasyon, hash’lemeden önce değeri Meta’nın beklediği tek biçime indirgemektir ve atlanması gelişmiş eşleştirmenin en pahalı hatasıdır. Hash’leme bayt düzeyinde çalışır: Ahmet@Ornek.com ile ahmet@ornek.com farklı iki hash üretir ve Meta bunları iki ayrı kişi sayar. Tek bir boşluk karakteri eşleşmeyi sıfırlar.

Meta’nın dokümante ettiği kurallar şunlardır:

• em (e-posta): Baştaki ve sondaki boşlukları silin, tüm karakterleri küçük harfe çevirin.
• ph (telefon): Sembolleri, harfleri ve baştaki sıfırları kaldırın. Numara ülke kodu içermelidir.
• fn ve ln (ad, soyad): Yalnızca küçük harf, noktalama yok. Özel karakter kullanıyorsanız metin UTF-8 kodlanmalıdır.
• ct (şehir): Küçük harf, noktalama yok, özel karakter yok, boşluk yok.
• st (eyalet): ABD için iki karakterli ANSI kısaltması, küçük harf. ABD dışı için küçük harf, boşluksuz ve noktalamasız.
• zp (posta kodu): Küçük harf, boşluk ve tire yok. ABD’de yalnızca ilk 5 hane.
• country: ISO 3166-1 alpha-2, küçük harf. Tüm müşterileriniz aynı ülkedense bile alanı doldurun.
• db (doğum tarihi): YYYYMMDD biçimi.
• ge (cinsiyet): Tek karakter, küçük harf: f veya m.

Türkçe Karakter Tuzağı

Türkçe içerikli sitelerde ad, soyad ve şehir alanları neredeyse her zaman sorun çıkarır. Meta, Roma alfabesi karakterlerini önerir ancak özel karakter kullanılacaksa UTF-8 kodlamasını şart koşar. Buradaki asıl risk, uygulamanızın Türkçe karakterleri sessizce dönüştürmesidir.

İstanbul değerinin JavaScript tarafında toLowerCase() ile küçültülmesi, ortama göre birleşik noktalı i karakteri üretebilir ve bu değer istanbul ile aynı hash’i vermez. Şişli, Çankaya, Güngören gibi değerlerde de aynı risk vardır. Uygulamada karar verip tutarlı kalmak gerekir: ya tüm kanallarda Türkçe karakterler korunur, ya tüm kanallarda ASCII karşılığına indirgenir. Karışık kullanım, CRM’den giden CAPI olayı ile tarayıcıdan giden Pixel olayının farklı hash üretmesine ve eşleşmenin bölünmesine yol açar.

Türkiye Telefon Numarası Normalizasyonu

Meta kuralı iki ayrı işlemden oluşur: baştaki sıfırları kaldır ve ülke kodu ekle. Türkiye’deki 0 ön ek alışkanlığı bu iki işlemi birbirine karıştırır ve en sık görülen hata buradan doğar.

Girdi	Hash'lenecek değer	Sonuç
0532 154 11 20	905321541120	Doğru
+90 532 154 11 20	905321541120	Doğru
(0532) 154-11-20	905321541120	Doğru
532 154 11 20	905321541120	Doğru, 90 eklenir
0532 154 11 20	0905321541120	Yanlış, sıfır silinmemiş
+90 532 154 11 20	+905321541120	Yanlış, sembol silinmemiş

Doğru sıra: rakam dışı karakterleri sil, baştaki sıfırları kaldır, 90 ile başlamıyorsa 90 ekle, sonra SHA-256 uygula.

Türk CRM dışa aktarımlarında sık rastlanan bir başka biçim 00905321541120 uluslararası ön ekidir. Baştaki sıfırlar önce silindiğinde doğru sonuca ulaşır, ancak ülke kodu kontrolü sıfır silme işleminden önce çalışıyorsa numara bozulur. Bu yolu mutlaka test edin.

// Türkiye telefon normalizasyonu ve SHA-256
function normalizePhoneTR(raw) {
  let digits = String(raw).replace(/\D/g, ""); // sembolleri ve harfleri sil
  digits = digits.replace(/^0+/, ""); // baştaki sıfırları sil
  if (!digits.startsWith("90")) digits = "90" + digits; // ülke kodu
  return digits;
}

function normalizeEmail(raw) {
  return String(raw).trim().toLowerCase();
}

async function sha256(value) {
  const bytes = new TextEncoder().encode(value);
  const buffer = await crypto.subtle.digest("SHA-256", bytes);
  return Array.from(new Uint8Array(buffer))
    .map((b) => b.toString(16).padStart(2, "0"))
    .join("");
}

Tarayıcı ve Sunucu Kuralları Aynı Değildir

Bu, çoğu rehberin atladığı ve gerçek eşleşme kaybına yol açan bir ayrıntıdır. Meta’nın tarayıcı tarafı gelişmiş eşleştirme dokümantasyonu, Conversions API dokümantasyonundan daha gevşek kurallar verir. Tarayıcı tarafında zp yalnızca metin olarak tanımlanır ve em alanı için hem hash’lenmemiş küçük harfli hem SHA-256 hash’lenmiş değer kabul edilir.

Sonuç şudur: aynı kullanıcıyı iki kanaldan gönderiyorsanız, gevşek olan tarayıcı kuralına göre değil, katı olan CAPI kuralına göre normalize edin. Aksi halde iki kanal farklı hash üretir, tekilleştirmenin yedek anahtarları bozulur ve eşleşme kalitesi düşer.

fbc ve fbp Çerezleri Nasıl Çalışır?

_fbp ve _fbc, Meta’nın tarayıcı tarafı kimlik çapalarıdır. _fbp siteye gelen tarayıcıyı temsil eden rastgele bir tanımlayıcıdır; _fbc ise reklam tıklamasından gelen fbclid değerini saklayarak atıf sinyalini taşır. İkisinin de biçimi noktayla ayrılmış dört parçadan oluşur.

_fbc biçimi fb.1.1554763741205.IwAR2F4... şeklindedir ve parçalar sırasıyla sabit fb ön eki, alt alan adı indeksi, milisaniye cinsinden oluşturulma zamanı ve fbclid değeridir. _fbp biçimi fb.1.1596403881668.1116446470 şeklindedir; son parça fbclid yerine rastgele bir sayıdır. Alt alan adı indeksi com için 0, ornek.com için 1, www.ornek.com için 2 değerini alır. Sunucu tarafında kayıtlı çerez yoksa Meta bu değer için 1 kullanılmasını söyler; bazı kaynaklarda geçen 14 değeri yanlıştır. Meta her iki çerez için 90 günlük ömür önerir.

Safari 7 Gün Sınırı ve iOS Kayıpları

Meta’nın önerdiği 90 gün, tarayıcıda çoğu zaman gerçekleşmez. Pixel bu çerezleri document.cookie ile yazar ve Safari’nin izleme önleme mekanizması (ITP), JavaScript ile yazılan birinci taraf çerezlerini talep edilen ömürden bağımsız olarak 7 güne indirir. Kullanıcı fbclid taşıyan bir bağlantıyla geldiyse bu sınır 24 saate kadar inebilir.

Buna 2023’ten bu yana biriken kayıplar eklenir. iOS 17 ile gelen Link Tracking Protection, Safari gizli gezinti, Mail ve Messages üzerinden açılan bağlantılardan fbclid parametresini temizler. fbclid yoksa _fbc hiç oluşmaz ve tıklama atfı baştan kaybedilir. Eylül 2025’te yayınlanan Safari 26 ve iOS 26 ile Advanced Fingerprinting Protection tüm gezinti oturumlarında varsayılan hale geldi, parametre temizleme de gizli gezintiyle sınırlı olmaktan çıktı.

Çözüm tek bir mimari değişikliktir: çerezleri tarayıcıya yazdırmayı bırakıp sunucudan yazın. Birinci taraf Set-Cookie başlığıyla ve HttpOnly bayrağıyla sunucu tarafında yazılan çerezler ITP’nin 7 günlük sınırından muaftır ve talep edilen ömrü korur.

// Edge middleware: fbclid degerini yakala, fbc cerezini sunucudan kalici yaz
export default async function middleware(request) {
  const url = new URL(request.url);
  const fbclid = url.searchParams.get("fbclid");
  const response = await fetch(request);

  if (fbclid && !request.headers.get("cookie")?.includes("_fbc=")) {
    const subdomainIndex = 1; // kayitli cerez yoksa Meta 1 kullanilmasini soyler
    const fbc = `fb.${subdomainIndex}.${Date.now()}.${fbclid}`; // fbclid buyuk/kucuk harfe duyarlidir
    response.headers.append(
      "Set-Cookie",
      `_fbc=${fbc}; Path=/; Max-Age=7776000; HttpOnly; Secure; SameSite=Lax`,
    );
  }
  return response;
}

fbclid değerinin büyük ve küçük harfe duyarlı olduğunu unutmayın. Normalizasyon alışkanlığıyla bu değeri küçültmek atıf sinyalini bozar.

Conversions API ile event_id Tekilleştirmesi

Pixel ve Conversions API aynı satın almayı birlikte gönderdiğinde, Meta’nın bunları tek dönüşüm sayması gerekir. Bu işleme tekilleştirme (deduplication) denir ve iki koşula bağlıdır: Pixel’in eventID değeri ile CAPI’nin event_id değeri eşleşmeli, aynı zamanda Pixel’in event değeri ile CAPI’nin event_name değeri eşleşmelidir. Meta bu eşleşmeyi yalnızca ilk olayı aldıktan sonraki 48 saat içinde yapar.

En kritik nokta hangi olayın tutulduğudur. Meta’nın ifadesi nettir: içerikleri anlamlı biçimde farklılaşmıyorsa genellikle ilk alınan olay tercih edilir. Türkçe ve İngilizce kaynaklarda sıkça tekrarlanan “tarayıcı olayı her zaman önceliklidir” veya “5 dakikalık pencerede tarayıcı kazanır” bilgisi Meta dokümantasyonunda yer almaz. Pratik sonucu şudur: sunucu olayınız tarayıcıdan önce ulaşıyorsa, Events Manager’da tutulan kayıt sunucu olayıdır ve tarayıcıya özel parametreleriniz o kayıtta bulunmaz. Bu yüzden sunucu olayına da fbp, fbc, client_ip_address ve client_user_agent eklemek zorunludur.

event_id seçimi için tek kural vardır: rastgele UUID üretmeyin. Değerin tarayıcı ve sunucu tarafında bağımsız olarak aynı üretilebilmesi gerekir. Doğru kaynak, arka uçtaki sipariş numarası gibi kalıcı bir kimliktir.

// Sunucu tarafi: Conversions API olayi
const eventId = `purchase_${order.id}`; // tarayicidaki eventID ile birebir ayni

await fetch(`https://graph.facebook.com/v25.0/${DATASET_ID}/events`, {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
    data: [
      {
        event_name: "Purchase",
        event_id: eventId,
        event_time: Math.floor(Date.now() / 1000),
        event_source_url: order.checkoutUrl,
        action_source: "website",
        user_data: {
          em: [await sha256(normalizeEmail(order.email))],
          ph: [await sha256(normalizePhoneTR(order.phone))],
          external_id: [await sha256(String(order.customerId))],
          client_ip_address: order.clientIp, // hash'lenmez
          client_user_agent: order.userAgent, // hash'lenmez
          fbp: order.fbp, // hash'lenmez
          fbc: order.fbc, // hash'lenmez
        },
        custom_data: { currency: "TRY", value: order.total },
      },
    ],
    access_token: ACCESS_TOKEN,
  }),
});

action_source, event_source_url, client_user_agent ve client_ip_address alanları web olayları için gerçek anlamda zorunludur. Eksik gönderilen olaylar kabul edilir ancak eşleşme kalitesi belirgin şekilde düşer. Canlıya çıkarken test_event_code alanını yükten kaldırmayı da unutmayın; test kodu ile gönderilen olaylar raporlamaya dahil olmaz.

event_id Yoksa Ne Olur?

Meta, event_id bulunmadığında event_name ile birlikte fbp ve external_id değerlerini yedek tekilleştirme anahtarı olarak kullanabilir. Ancak bu yöntemin dokümante edilmiş bir sınırı vardır: son 48 saatte eşleşen bir tarayıcı olayı alınmadıysa sunucu olayı elenmez, sonradan gelen tarayıcı olayı bunu değiştirmez. Yani yedek anahtar yalnızca tarayıcıdan sunucuya yönde çalışır ve aynı kanaldan gelen iki olayı tekilleştiremez. Güvenilir tek yöntem her iki kanalda aynı event_id değerini göndermektir.

EMQ Skoru Neyi Ölçer, Neyi Ölçmez?

Event Match Quality, bir sunucu olayının içindeki müşteri bilgisinin bir Meta hesabıyla eşleşme etkinliğini 10 üzerinden gösteren kalite göstergesidir ve yalnızca web olayları için yayınlanır. Meta’nın eşleşme kalitesi için öne çıkardığı parametreler e-posta, IP adresi, ad ve soyad ile telefon numarasıdır.

Burada dürüst olmak gerekiyor: internette dolaşan 0-4 Zayıf, 4-5.9 Orta, 6-7.9 İyi, 8+ Çok İyi bant tablosu Meta’nın resmi tanımı değildir. Bu bantları yayınlayan kaynakların bir kısmı da bunun yazarın kendi çerçevesi olduğunu belirtir. Events Manager 0 ile 10 arası bir skor ve niteliksel etiketler gösterir; sektör pratiği 6 ve üzerini kabul edilebilir, 8 ve üzerini güçlü sayar. Bu bir uygulayıcı ölçütüdür, Meta taahhüdü değildir.

EMQ’nun ölçmediği şey daha önemlidir. EMQ eşleşme kalitesini ölçer, olay kapsamını ölçmez. Yüz satın almanın yalnızca onunu gönderiyorsanız ve o on olayın her birinde eksiksiz müşteri bilgisi varsa EMQ skorunuz mükemmel görünür. Gönderilmemiş doksan olay skorunuzu hiç etkilemez. EMQ’yu ROAS vekili gibi okumak, tam da bu yüzden yanlış kararlara götürür.

EMQ’nun Ötesi: Dataset Quality API

Meta’nın az bilinen ama teşhis için çok daha güçlü aracı Dataset Quality API’dir (eski adıyla Integration Quality API). graph.facebook.com/v25.0/dataset_quality uç noktasından EMQ’ya ek olarak dört metrik verir:

• Additional Conversions Reported: CAPI kurulumunuz sayesinde ölçülen ek dönüşüm tahmini.
• Event Coverage: Pixel olaylarının yüzde kaçının CAPI tarafından da kapsandığının 7 günlük ortalaması. EMQ’nun ölçmediği kapsam boşluğunu tam olarak bu metrik gösterir.
• Data Freshness: Olayın gerçekleşmesi ile Meta’ya ulaşması arasındaki gecikme.
• Event Deduplication: Pixel ve CAPI olaylarının hangi tekilleştirme anahtarıyla alındığının yüzdesi.

Son metrik, bu yazıdaki en pratik teşhis aracıdır: trafiğinizin ne kadarının gerçekten event_id üzerinden tekilleştiğini, ne kadarının fbp veya external_id yedeğine düştüğünü ölçmenizi sağlar. Yedek anahtar oranı yüksekse event_id kurulumunuzda bir yerde kopukluk vardır.

Eşleşme Kalitesini Yükseltmenin Adımları

1. E-postayı yakaladığınız anda gönderin, satın almayı beklemeyin.
2. Telefon numaralarını E.164 biçimine zorlayın ve Türkiye kuralını uygulayın.
3. _fbc ve _fbp çerezlerini sunucu tarafında kalıcılaştırın.
4. Oturum açmış kullanıcılar için external_id ekleyin ve aynı değeri her kanalda kullanın.
5. CAPI olaylarına client_ip_address ve client_user_agent eklemeyi zorunlu kılın.
6. Tarayıcı ve sunucu normalizasyonunu tek bir paylaşılan fonksiyonda toplayın.

Özgün gözlem: Denetlediğimiz kurulumlarda düşük EMQ’nun en yaygın nedeni eksik parametre değil, iki kanalın farklı normalize edilmesidir. Tarayıcıda İstanbul, sunucuda istanbul gönderen bir kurulum her iki olayı da başarıyla iletir, hiçbir hata vermez ve eşleşmeyi ikiye böler. Normalizasyonu tek fonksiyona indirmek, çoğu zaman yeni parametre eklemekten daha fazla puan kazandırır.

Rıza Yönetimi: Meta’yı Google ile Karıştırmayın

Google Consent Mode ile Meta’nın rıza mekanizması aynı şey değildir ve aynı etiket yöneticisinde yan yana çalıştıkları için sürekli karıştırılır. Meta tarafında iki ayrı katman vardır.

Birinci katman Pixel düzeyinde rızadır. Meta’nın kuralı iki maddedir: revoke çağrısı init çağrısından önce yapılmalıdır ve her sayfada tekrarlanmalıdır. İkinci madde uygulamaların çoğunda atlanır; tek sayfada verilen revoke sonraki sayfada geçerli olmaz.

fbq("consent", "revoke"); // init cagrisindan ONCE, her sayfada
fbq("init", "<DATASET_ID>");
fbq("track", "PageView");

// Kullanici onay verdiginde:
fbq("consent", "grant");

İkinci katman Limited Data Use’dur (LDU) ve burada kritik bir yanlış anlama vardır: LDU bir KVKK veya GDPR mekanizması değildir. LDU yalnızca ABD eyalet gizlilik yasaları için tasarlanmıştır ve dataProcessingOptions ile ayarlanır. Avrupa Birliği’nde geçerli tek yaklaşım, rıza alınmadan Pixel’i ve CAPI’yi hiç çalıştırmamaktır.

AB tarafında 2025 ve 2026 hareketli geçti. Nisan 2025’te Meta, öde veya onayla modeli nedeniyle DMA kapsamında 200 milyon euro para cezası aldı. Aralık 2025’te Avrupa Komisyonu, Meta’nın AB kullanıcılarına kişiselleştirilmiş reklamlar konusunda seçim sunma taahhüdünü duyurdu ve daha az kişiselleştirilmiş seçenek Ocak 2026’da kullanıma alındı. Reklamveren açısından sonucu, AB kullanıcılarının artan bir bölümünün davranışsal değil bağlamsal hedeflemeye düşmesi ve yeniden pazarlama erişiminin daralmasıdır. Modelin yeterliliği hâlâ tartışmalıdır, kapanmış bir konu değildir.

Birden Fazla Pixel Kullanıyorsanız

Bir sayfada birden fazla Dataset ID başlatıldığında, niteliksiz fbq('track', ...) çağrısı olayı başlatılmış tüm Pixel’lere gönderir. Ajans ve müşteri hesaplarının aynı sitede yan yana durduğu kurulumlarda bu, veri sızıntısına ve şişmiş dönüşüm sayılarına yol açar.

fbq("init", "<DATASET_ID_A>");
fbq("init", "<DATASET_ID_B>");

// Yanlis: her iki hesaba da gider
fbq("track", "Purchase", { value: 1200, currency: "TRY" });

// Dogru: yalnizca hedef hesaba gider
fbq("trackSingle", "<DATASET_ID_A>", "Purchase", { value: 1200, currency: "TRY" });
fbq("trackSingleCustom", "<DATASET_ID_B>", "IcSatis", { value: 1200, currency: "TRY" });

Gelişmiş eşleştirme verisi de Pixel bazında ayrışır. trackSingle kullanırken hangi hesabın hangi müşteri bilgisini almaya yetkili olduğunu sözleşme düzeyinde netleştirmek gerekir.

Kurulumu Nasıl Doğrularız?

Doğrulama üç araçla yapılır ve üçü farklı sorulara cevap verir.

Meta Pixel Helper tarayıcı tarafını gösterir: hangi olaylar tetiklendi, gelişmiş eşleştirme parametreleri gönderildi mi, external_id yerinde mi. Tarayıcıda ne olduğunu görmek için ilk duraktır, ancak sunucu tarafını görmez.

Events Manager Test Events sekmesi asıl doğrulama yeridir. Her olayın yanında Browser, Server veya Deduplicated etiketi görünür. Kurulumunuz doğruysa aynı satın alma için hem tarayıcı hem sunucu kaydı gelmeli ve Deduplicated etiketini almalıdır. Yalnızca Browser veya yalnızca Server görüyorsanız event_id eşleşmiyordur.

Diagnostics sekmesi, Meta’nın kendi tespit ettiği sorunları listeler: eksik parametreler, hatalı hash’lenmiş alanlar, geçersiz biçimler. Bu listeyi sıfırlamak, EMQ skorunu kovalamaktan daha somut bir hedeftir.

Sırasıyla şunu doğrulayın: Pixel Helper’da parametreler görünüyor mu, Test Events sekmesinde Deduplicated etiketi çıkıyor mu, Diagnostics temiz mi, Dataset Quality API tarafında Event Coverage kabul edilebilir mi.

Sunucu Tarafına Geçiş ve Signals Gateway

Tarayıcı kısıtları arttıkça ölçümün ağırlık merkezi sunucuya kayıyor. Meta’nın bu alanda iki ürünü var: uzun süredir bilinen Conversions API Gateway ve daha yeni Signals Gateway. Signals Gateway, işletmelerin olayları kendi altyapılarında alıp göndermelerini ve kaynak ile hedef tanımlı iletim hatları kurmalarını sağlar; bunu ayrı geliştirici kaynağı gerektirmeden yapmayı hedefler.

Burada bir düzeltme yapmak gerekiyor: Signals Gateway’in CAPI Gateway’i emekliye ayırdığı veya Meta Pixel’in kaldırıldığı iddialarının Meta dokümantasyonunda karşılığı yoktur. Her iki ürün de belgelerde yan yana durmaktadır ve yayınlanmış bir sonlandırma tarihi bulunmamaktadır. Gerçekte olan değişiklik terminolojiktir: Pixel artık bir Dataset içindeki veri kaynaklarından biridir ve eski Pixel ID artık Dataset ID olarak anılır.

Meta tarafındaki asıl mimari değişiklik reklam dağıtımında yaşandı. Aralık 2024’te duyurulan ve 2025 başında yaygınlaşan Andromeda, Advantage+ için yeni nesil aday getirme motorudur ve model karmaşıklığını büyük ölçüde artırmıştır. Bu tür sistemler girdi sinyalinin kalitesine daha duyarlıdır, dolayısıyla eşleşme kalitesi doğrudan dağıtım kalitesine dönüşür. Ancak ajans içeriklerinde dolaşan “Andromeda için EMQ 7 üzeri şart” gibi eşik değerleri Meta’nın açıklaması değil, uygulayıcı varsayımıdır.

Ölçüm altyapınızı bu standartta kurmak istiyorsanız Meta reklam ajansı ve Facebook reklam ajansı hizmetlerimizi inceleyebilirsiniz. Reklam ve organik tarafı birlikte kurgulamak için e-ticaret reklam yönetimi sayfamıza da göz atabilirsiniz.

Sonuç

Gelişmiş eşleştirme bir ayar değil, bir veri disiplinidir. Parametreleri normalize etmeden hash’lemek, tarayıcı ile sunucuyu farklı kurallarla beslemek veya event_id yerine rastgele UUID üretmek; hiçbiri hata vermeden çalışır ve hepsi eşleşmeyi sessizce yok eder.

Öncelik sırası nettir: önce normalizasyonu tek fonksiyonda birleştirin, sonra event_id tekilleştirmesini Events Manager’da Deduplicated etiketiyle doğrulayın, ardından _fbc ve _fbp çerezlerini sunucu tarafına taşıyın. EMQ skorunu son aşamada ve kapsam metrikleriyle birlikte okuyun. Skoru tek başına kovalamak, ölçülmeyen olayları görünmez kılar.