Meta Event Match Quality: jak podnieść wynik

Event Match Quality (EMQ) to wynik w skali do 10, który Meta nadaje każdemu zdarzeniu witryny wysłanemu przez Conversions API. Pokazuje, jak dobrze dane klienta przy tym zdarzeniu pozwalają dopasować je do konta Meta. Podnosisz go, wysyłając więcej właściwych identyfikatorów, sformatowanych i zahashowanych tak, jak oczekuje Meta.

Ten poradnik wyjaśnia, co mierzy wynik, które parametry danych klienta liczą się najbardziej, zasady hashowania i normalizacji, dlaczego zakupy z danych zamówienia niosą więcej identyfikatorów niż odsłony stron, do jakiego wyniku dążyć i gdzie go sprawdzić.

Co mierzy Event Match Quality?

Meta oblicza wynik z dwóch rzeczy: jakości danych klienta wysyłanych ze zdarzeniem server-side oraz odsetka tych zdarzeń, które Meta dopasowuje do konta. Dopasowane zdarzenie mówi Meta, kto kupił. Meta może wtedy przypisać zakup reklamie, którą ta osoba widziała lub kliknęła, i pokazywać twoje reklamy osobom, które chętniej kupią.

Kilka faktów z dokumentacji Meta wpływa na to, jak czytać wynik:

• Jest liczony dla każdego zdarzenia. Purchase, AddToCart i PageView mają własny wynik, zarówno dla zdarzeń standardowych, jak i niestandardowych.
• Obejmuje tylko zdarzenia server-side. Wynik jest dostępny dla zdarzeń witryny wysyłanych przez Conversions API z action_source ustawionym na website. Zdarzenia wysyłane wyłącznie przez piksel w przeglądarce nie mają wyniku.
• Używa ostatnich 48 godzin. Wysyłaj zdarzenia regularnie, bo inaczej wynik się zdezaktualizuje.

Meta zaznacza też, że lepsze dopasowanie może zwiększyć dodatkowe konwersje, które raportuje dla twojej konfiguracji Conversions API. Zakup, którego Meta nie może dopasować, to zakup, za który twoje reklamy nie dostają zasługi.

Które parametry danych klienta podnoszą wynik?

Meta publikuje priorytet dla każdego rodzaju danych klienta. Wysyłaj każdy parametr, który masz dla zdarzenia, i zacznij od tych o wysokim priorytecie.

Adres IP i user agent nie są na liście priorytetów Meta, ale dokumentacja dla deweloperów Meta mówi, że wysyłanie client_ip_address i client_user_agent może pomóc w dopasowaniu. User agent jest i tak wymagany dla zdarzeń witryny. Oba muszą być wartościami kupującego, a nie twojego serwera.

Jak hashować i normalizować dane klienta?

Meta wymaga, aby dane kontaktowe były zahashowane SHA-256 przed wysłaniem. Hashowanie działa tylko wtedy, gdy każdy system zapisuje tę samą wartość w ten sam sposób, więc Meta definiuje postać znormalizowaną dla każdego pola. Najpierw znormalizuj, potem hashuj.

W kodzie liczy się kolejność kroków:

import { createHash } from 'node:crypto';
const sha256 = (s) => createHash('sha256').update(s).digest('hex');

// Normalize first, then hash.
const em = sha256(' Anna.Berg@Example.com '.trim().toLowerCase());
// hashes "anna.berg@example.com"

const ph = sha256('+1 (415) 555-0134'.replace(/\D/g, ''));
// hashes "14155550134"

const ct = sha256('San Francisco'.toLowerCase().replace(/[^a-z]/g, ''));
// hashes "sanfrancisco"

// Sent as they are, never hashed:
// fbp, fbc, client_ip_address, client_user_agent

Uważaj na numery telefonów z zerem wiodącym. Holenderski numer zapisany jako +31 (0)6 1234 5678 zamienia się w 310612345678, jeśli usuniesz tylko symbole. Poprawna postać to 31612345678. Pułapką są też wartości zastępcze: adres e-mail taki jak noemail@example.com, który sklep wstawia przy zamówieniach gości, jest wspólny dla wielu klientów, więc nie identyfikuje jednej osoby. Zamiast tego pomiń to pole.

Dlaczego zdarzenia server-side z danych zamówienia niosą więcej identyfikatorów?

Wyświetlenie strony następuje, zanim odwiedzający cokolwiek ci o sobie powie. Przeglądarka zna id z cookie, może click id, adres IP i user agent. Opłacone zamówienie to co innego: kupujący wpisał adres e-mail, często numer telefonu, imię i nazwisko oraz adres.

Dlatego zdarzenie Purchase wysłane z twojego serwera może mieć wyższy wynik niż PageView lub ViewContent. Zdarzenie zakupu, które pochodzi tylko ze strony z podziękowaniem, ma identyfikatory przeglądarki, ale nie zawsze e-mail i telefon z zamówienia.

Nie każdy parametr może trafić do 100% zdarzeń i to jest normalne. W poniższym przykładzie click id jest przy 38% zakupów, bo mają go tylko kupujący, którzy przyszli z kliknięcia w reklamę Meta.

Jaki cel Event Match Quality jest realistyczny?

Dokumentacja Meta dla programistów podaje, że zazwyczaj zaleca wynik 6.0 lub wyższy, jeśli to możliwe. Traktuj to jako cel dla zdarzeń, które niosą dane kontaktowe, przede wszystkim Purchase. Purchase zbudowany z danych zamówienia zawiera e-mail, czyli jeden z dwóch parametrów o wysokim priorytecie, oraz większość parametrów o średnim priorytecie, więc to zdarzenie, w którym ten cel jest najbardziej realistyczny. Mierz to, zamiast zakładać: wynik zależy też od twoich klientów.

Nie oczekuj takiego samego wyniku w każdym zdarzeniu. PageView, ViewContent i AddToCart często nie mają danych kontaktowych, bo większość odwiedzających jest anonimowa aż do checkoutu. Niższy wynik jest tam czymś oczekiwanym i nie jest powodem, żeby zbierać adresy e-mail wcześniej, niż odwiedzający chcą je podać.

Nie goń też za wynikiem 10. Wynik zależy także od odsetka zdarzeń, które Meta dopasowuje, a część z tego jest poza twoją kontrolą: niektórzy twoi kupujący nie mają konta Meta albo użyli tam innego adresu e-mail. Znaczenie mają też zgody. W ROASaurus, gdy opcja Respect visitor consent jest włączona, odwiedzający, który odrzuci marketingowe cookie, nie ma zapisanego click id ani visitor id, więc opłacone zamówienie wychodzi z zahashowanymi danymi zamówienia oraz adresem IP i user agent z zamówienia, ale bez fbc i fbp. Im więcej odmów, tym mniej identyfikatorów na zdarzenie. Ustawienie opisuje nasza strona pomocy o zgodach.

Przydatne pytanie nie brzmi, czy twój wynik jest wysoki, tylko czy się zmienił. Porównuj każde zdarzenie z jego własną historią po każdej zmianie w motywie, checkoucie lub trackingu.

Jak sprawdzić Event Match Quality w Events Manager?

1. Otwórz swój zestaw danych

   Przejdź do Events Manager i wybierz nazwę oraz id swojego piksela lub zestawu danych.

2. Otwórz szczegóły zdarzenia

   Znajdź zdarzenie, na przykład Purchase, i kliknij View details.

3. Przeczytaj kartę Event matching

   Pokazuje wynik, odsetek zdarzeń z danymi klienta oraz wskazówki, jak poprawić dopasowanie.

4. Sprawdź Diagnostics

   Karta Diagnostics w Events Manager wymienia problemy ze zdarzeniami i zalecenia, jak je naprawić.

5. Sprawdź ponownie po dwóch dniach

   Wynik uwzględnia zdarzenia z ostatnich 48 godzin, więc poprawka jest w pełni widoczna po około dwóch dniach.

Pomagają też pozostałe karty na tej samej stronie. Event coverage porównuje twoje zdarzenia server-side ze zdarzeniami piksela, Event deduplication pokazuje odsetek zdarzeń, które mają klucz deduplikacji, taki jak event id, a Data freshness pokazuje, jak szybko docierają twoje zdarzenia server-side. Jeśli dopiero konfigurujesz stronę serwerową, zacznij od naszego poradnika Meta Conversions API.

Dlaczego mój Event Match Quality jest niski?

Gdy jedno zdarzenie ma niższy wynik, niż się spodziewasz, zwykle przyczyny są takie:

• Serwer wysyła własny adres IP. Jeśli zdarzenia przechodzą przez twój serwer lub serwer tagów, musi on przekazywać adres IP i user agent zarejestrowane od kupującego, a nie własne.
• fbclid ginie. Click id jest tylko w adresie URL strony docelowej. Jeśli nic go tam nie zapisze, do checkoutu już go nie ma. Zachowaj go dokładnie w takiej postaci, w jakiej przyszedł, bo rozróżnia wielkość liter.
• Dane kontaktowe są hashowane bez normalizacji, albo wysyłane niezahashowane.
• Identyfikatory przeglądarki są hashowane. Zahashowanego fbp lub fbc nie da się dopasować.
• Zakupy pochodzą tylko z przeglądarki. Zdarzeniu ze strony z podziękowaniem często brakuje e-maila i telefonu, które ma zamówienie. Wysłanie zakupu na podstawie zamówienia to naprawia.

Jak ROASaurus wysyła dane klienta

ROASaurus buduje zdarzenie Purchase z zamówienia w twoim sklepie, więc niesie ono dane kontaktowe z zamówienia. E-mail, telefon, imię i nazwisko, miasto, stan, kod pocztowy i kraj są normalizowane i hashowane algorytmem SHA-256. Id klienta ze sklepu i visitor id z ROASaurus trafiają zahashowane jako external_id. Adres IP, user agent, adres URL strony i fbp są dołączane z wizyty kupującego, a fbc jest budowane z fbclid, który skrypt sklepu zapisuje, gdy odwiedzający wejdzie na stronę.

Zdarzenie bez fbc, fbp, e-maila, telefonu i adresu IP jest pomijane, bo Meta nie może go dopasować. Strona integracji z Meta wymienia wszystkie wysyłane pola, a server-side tracking wyjaśnia, jak zamówienia są dopasowywane do kliknięcia w reklamę. Aby śledzić wynik, strona Tracking health codziennie odczytuje Event Match Quality każdego piksela Meta i zgłasza alert, gdy wynik dla Purchase spadnie poniżej ustalonego minimum, domyślnie 6,0.

Źródła

1. Meta Business Help Center: About Event Match Quality
2. Meta for Developers: Customer Information Parameters
3. Meta for Developers: Verifying Your Setup
4. Meta Business Help Center: View server event details in Meta Events Manager
5. Meta for Developers: Best Practices - Conversions API

W ROASaurus

• Integracja z Meta
• Server-side tracking
• Pomoc: połącz Meta

Czytaj dalej