Event Match Quality: jak podnieść jakość dopasowania zdarzeń w Meta

Czym jest Event Match Quality i gdzie go sprawdzić

Event Match Quality to wskaźnik jakości danych, a nie wskaźnik skuteczności kampanii. Mówi, jak dobrze parametry klienta przesłane w zdarzeniach Conversions API pozwalają Meta odnaleźć osobę, która wykonała akcję.

Wynik sprawdzisz w Menedżerze zdarzeń: wybierz zbiór danych, przejdź do przeglądu zdarzeń i kliknij konkretne zdarzenie, np. Purchase. W szczegółach zobaczysz ocenę liczbową z opisem słownym, listę przesyłanych parametrów klienta z odsetkiem zdarzeń, które je zawierają, oraz rekomendacje, które parametry dodać. Wynik zmienia się z opóźnieniem, więc efekt poprawek ocenisz po kilku dniach, a nie godzinach.

EMQ dotyczy zdarzeń serwerowych. Jeśli dopiero wdrażasz Conversions API, najpierw skonfiguruj kanał serwerowy i deduplikację – poradnik Meta Conversions API przez server-side GTM prowadzi przez cały proces.

Jakie parametry podnoszą Event Match Quality

Na wynik wpływa to, jakie parametry wysyłasz, jak często pojawiają się w zdarzeniach i czy są poprawnie sformatowane. Poniższa tabela zbiera parametry klienta obsługiwane przez Conversions API z zasadami przygotowania.

Kolejność ważności jest prosta: najpierw dane jednoznacznie identyfikujące osobę (e-mail, telefon, identyfikator klienta), potem identyfikatory Meta z przeglądarki (fbc, fbp), na końcu dane pomocnicze. Parametr fbc powstaje z identyfikatora fbclid, który Meta dokleja do linków z reklam. Jeśli w Twoim ruchu z urządzeń Apple brakuje go częściej niż kiedyś, przeczytaj tekst o tym, jak Safari 26 usuwa identyfikatory kliknięć.

Normalizacja i haszowanie danych krok po kroku

Najczęstszą przyczyną niskiego wyniku nie jest brak danych, tylko ich zły format. Hash SHA-256 z „[email protected]” i z „[email protected]” to dwa zupełnie różne ciągi, więc Meta nie dopasuje tego pierwszego.

Przykład przygotowania danych w Node.js, np. w backendzie sklepu wysyłającym zdarzenia Purchase:

const crypto = require('crypto');
const sha256 = (v) => crypto.createHash('sha256').update(v, 'utf8').digest('hex');

function normalizujEmail(email) {
  return email.trim().toLowerCase();
}

function normalizujTelefon(telefon, kodKraju = '48') {
  let cyfry = telefon.replace(/\D/g, '').replace(/^00/, '');
  if (cyfry.length === 9) cyfry = kodKraju + cyfry; // polski numer bez prefiksu
  return cyfry;
}

function normalizujImie(tekst) {
  return tekst.trim().toLowerCase().replace(/[\s.,'-]/g, '');
}

const userData = {
  em: [sha256(normalizujEmail(' [email protected] '))],
  ph: [sha256(normalizujTelefon('+48 600 123 456'))],
  fn: [sha256(normalizujImie('Łukasz'))],
  external_id: [sha256('klient-000123')],
  country: [sha256('pl')],
  client_ip_address: '203.0.113.10',
  client_user_agent: 'Mozilla/5.0 (...)',
  fbp: 'fb.1.1793080000000.1234567890'
};

Polskie znaki zostają w imieniu i nazwisku w kodowaniu UTF-8 – „łukasz” haszujesz w tej postaci, bez zamiany na „lukasz”. Wartości fbc, fbp, adresu IP i user agenta przekazujesz bez haszowania; zahaszowany fbp jest dla Meta bezużyteczny.

Po stronie przeglądarki te same dane możesz przekazać pikselowi przez ręczne rozszerzone dopasowanie. Piksel haszuje je przed wysłaniem:

fbq('init', '123456789012345', {
  em: '[email protected]',
  ph: '48600123456',
  external_id: 'klient-000123'
});

Ten sam external_id w pikselu i na serwerze pomaga Meta powiązać zdarzenia z obu kanałów, a przy okazji ułatwia deduplikację, opisaną w artykule o deduplikacji zdarzeń piksela i Conversions API.

Jak podnieść Event Match Quality: plan działania

Poprawa wyniku to zwykle kilka niewielkich zmian w różnych miejscach: w formularzach, w warstwie danych, w kontenerze serwerowym i w backendzie. Najlepiej przejść przez nie w stałej kolejności.

1. Zrób audyt. Dla każdego kluczowego zdarzenia zapisz obecny wynik i listę parametrów z odsetkiem pokrycia. To punkt odniesienia dla dalszych zmian.
2. Dodaj e-mail i telefon tam, gdzie je masz. Na stronie podziękowania i po wysłaniu formularza dane kontaktowe są już znane – przekaż je do warstwy danych i dalej do zdarzenia serwerowego.
3. Wysyłaj external_id dla zalogowanych. Identyfikator konta klienta, zahaszowany, dodawaj do wszystkich zdarzeń zalogowanych użytkowników, nie tylko do zakupu.
4. Zadbaj o fbc. Zapisuj fbclid ze strony docelowej i przekazuj fbc w kolejnych zdarzeniach sesji, zamiast budować go od nowa na każdej podstronie.
5. Przekazuj prawdziwy IP i user agent. Sprawdź, czy kontener serwerowy lub backend nie wysyła adresu własnego serwera, load balancera albo CDN.
6. Włącz automatyczne rozszerzone dopasowanie w ustawieniach zbioru danych, jeśli Twoja ocena prawna na to pozwala.
7. Sprawdź format. Porównaj kilka zdarzeń w narzędziu testowania zdarzeń: hash e-maila powinien mieć 64 znaki szesnastkowe, a telefon zaczynać się od kodu kraju przed haszowaniem.
8. Oceń efekt po kilku dniach i powtórz audyt dla każdego zdarzenia.

Jeżeli korzystasz z serwera do wzbogacania zdarzeń, możesz tam też dołączyć brakujące dane klienta z CRM, np. telefon do zdarzenia, które w przeglądarce miało tylko e-mail. Ten scenariusz opisujemy w tekście o wzbogacaniu zdarzeń po stronie serwera.

Jakie wartości Event Match Quality są realne dla różnych zdarzeń

Nie każde zdarzenie może osiągnąć wysoki wynik i nie ma potrzeby gonić maksimum wszędzie. O realnym poziomie decyduje to, jakie dane masz w danym momencie ścieżki zakupowej.

Zdarzenia z górnej części lejka, takie jak PageView czy ViewContent, dotyczą zwykle anonimowych użytkowników. Masz dla nich IP, user agenta, fbp, czasem fbc, ale nie masz e-maila, więc ich wynik będzie niższy. Zdarzenia Purchase, Lead i CompleteRegistration powstają w chwili, gdy klient podaje dane kontaktowe, dlatego to one powinny mieć najwyższą jakość dopasowania. Najwięcej uwagi poświęć zdarzeniom, pod które optymalizujesz kampanie.

W kampaniach leadowych jakość dopasowania jest szczególnie istotna, bo zdarzenia z CRM o zakwalifikowanych leadach wysyłane są z serwera, często z opóźnieniem. Jak połączyć je z kampaniami, opisujemy w artykule o kampaniach leadowych w Meta Ads.

Event Match Quality a RODO i zgody

Haszowanie SHA-256 to pseudonimizacja, a nie anonimizacja. Meta porównuje hash z hashami danych swoich użytkowników, więc dane nadal pozwalają zidentyfikować osobę i podlegają RODO. Przesyłanie ich do Meta wymaga podstawy prawnej, informacji w polityce prywatności i – w przypadku danych z przeglądarki – zgody zgodnej z Prawem komunikacji elektronicznej.

W praktyce oznacza to, że zdarzenia z danymi klienta wysyłasz tylko dla użytkowników, którzy zgodzili się na marketing. Podobną logikę stosuje Google przy konwersjach rozszerzonych, uzależniając je od sygnału ad_user_data – konfigurację opisujemy w poradniku Enhanced Conversions przez GTM. Strategię zbierania i wykorzystywania danych klientów, czyli danych first-party, omawiamy w tekście o danych first-party w reklamie. Zakres podstawy prawnej skonsultuj z prawnikiem.

Najczęstsze błędy obniżające Event Match Quality

Większość błędów da się wykryć w narzędziu testowania zdarzeń, porównując wysłane wartości z oczekiwanym formatem.

Te same zasady normalizacji obowiązują na innych platformach. Pola haszowane w OpenAI Pixel i Conversions API oraz w TikTok Events API wymagają takiego samego przygotowania e-maila i telefonu. Pozostałe poradniki znajdziesz w podtemacie Meta Pixel i Conversions API, a podsumowanie ustawień – na stronie Meta Conversions API.