Event Match Quality: co to jest i jak poprawić jakość dopasowania zdarzeń w Mecie

Event Match Quality to podpowiedź Mety, ile z Twoich zdarzeń da się przypisać do konkretnych osób. Zdarzenie, którego Meta nie dopasuje do konta, nie pomoże w optymalizacji ani w atrybucji, nawet jeśli zostało poprawnie przyjęte. Dlatego EMQ warto traktować jak termometr: nie leczy, ale pokazuje, gdzie dane są za słabe. Poniżej wyjaśniamy, co mierzy wynik, które parametry mają znaczenie, jak je przygotować i dlaczego przy zdarzeniach offline w ogóle go nie zobaczysz.

Co to jest Event Match Quality?

Według dokumentacji Dataset Quality API EMQ to wynik w skali do 10, który wskazuje, jak skuteczne mogą być dane klienta wysłane z Twojego serwera przy dopasowaniu zdarzenia do konta w Mecie. Meta bierze pod uwagę:

• które parametry informacji o kliencie dostaje przez Conversions API,
• jakość tych parametrów,
• odsetek zdarzeń, które udało się dopasować do konta.

Wynik liczony jest na bieżąco i pokazywany osobno dla każdego zdarzenia, np. Purchase czy AddToCart. Obok niego Meta wyświetla diagnostykę (konkretne problemy z integracją i propozycje rozwiązań) oraz świeżość danych, czyli opóźnienie między zdarzeniem a chwilą, w której dotarło do Mety.

Dlaczego to ma znaczenie? Najlepsze praktyki Conversions API mówią wprost: tylko dopasowane zdarzenia mogą być użyte do atrybucji reklam i optymalizacji wyświetlania. Niedopasowane przydają się co najwyżej do podstawowego pomiaru.

Dla jakich zdarzeń Meta liczy EMQ?

Tylko dla zdarzeń z witryny. Meta zaznacza, że EMQ nie jest dostępny dla zdarzeń offline i ze sklepów stacjonarnych, zdarzeń z aplikacji ani dla integracji CRM dla leadów (conversion leads). To ważne, bo wiele firm szuka wyniku tam, gdzie go nie ma.

Jeśli wysyłasz głównie zakupy spoza strony (z arkusza albo zamówień telefonicznych), nie goń wyniku EMQ. Zadbaj o to, żeby każde zdarzenie miało e-mail lub telefon klienta i stały event_id, co opisujemy w artykule konwersje offline z Arkusza Google do Meta.

Które parametry klienta naprawdę pomagają?

Meta wymienia jako przykłady parametrów wysokiej jakości e-mail, adres IP, imię i nazwisko oraz telefon, a do tego zaleca wysyłanie external_id i event_id przy wszystkich zdarzeniach. Pełną listę pól i zasad ich przygotowania znajdziesz w dokumentacji parametrów informacji o kliencie.

Dwie reguły, o których łatwo zapomnieć:

• Zbyt ogólne zdarzenia są odrzucane. Jeśli zdarzenie ma tylko pola takie jak płeć, miasto, region i kraj, Meta uznaje je za nieprawidłowe. Miasto czy kod pocztowy pomagają tylko jako uzupełnienie.
• Zdarzenia testowe wysyłaj z własnymi danymi. Meta pisze, że zdarzenia testowe bez dopasowania do konta mogą zostać odrzucone, więc testuj na swoim e-mailu i telefonie, a nie na test@test.pl.

Najczęstsze przyczyny niskiego EMQ

Jak to wygląda w Basketly?

Basketly nie „podbija” wyniku sztuczkami, tylko pilnuje, żeby dane były kompletne i poprawne, zanim wyjdą do Mety:

• E-mail i telefon są normalizowane i hashowane na serwerze. Niepoprawny e-mail albo telefon bez prefiksu kraju zatrzymuje zdarzenie z czytelnym błędem, zamiast wysłać skrót, który niczego nie dopasuje.
• Kolektor w sklepie zbiera fbp i fbc dopiero po zgodzie z CMP. Korzysta z istniejącego _fbp albo tworzy własny identyfikator, a fbc bierze tylko z prawdziwego fbclid; nigdy nie tworzy go bez kliknięcia. Zapisuje też prawdziwy IP i User-Agent klienta, pomijając adresy prywatne.
• Zamówienie ze sklepu jest wysyłane jako zdarzenie z witryny ze stabilnym event_id, User-Agentem klienta i adresem strony z tej samej domeny co źródło. Parametry z adresu URL są usuwane przed wysyłką.
• Własny identyfikator klienta przekazany w polu user_id trafia do Mety jako zahashowany external_id.
• Zdarzenia wychodzą z trwałej kolejki sprawdzanej co minutę, więc dane docierają do Mety blisko czasu zdarzenia.

Jak przekazać identyfikator z kolektora do zamówienia i uniknąć podwójnego liczenia z Pikselem, opisujemy w artykułach Shoper i Meta Conversions API oraz deduplikacja zdarzeń Piksel i CAPI. Ogólny opis wysyłki jest na stronie Meta Conversions API.

Jak EMQ ma się do Piksela i deduplikacji?

EMQ ocenia zdarzenia wysłane z serwera, ale w większości sklepów to samo zamówienie wysyła też Piksel w przeglądarce. Jeśli oba źródła wysyłają Purchase, Meta musi wiedzieć, że chodzi o jedną transakcję. Najlepsze praktyki wymagają do tego event_id albo połączenia external_id i fbp w obu zdarzeniach, a w praktyce najprościej użyć tej samej nazwy zdarzenia i tego samego event_id po obu stronach.

To dobra wiadomość dla EMQ: te same identyfikatory, które pozwalają usunąć duplikat, pomagają też w dopasowaniu. Zdarzenie z serwera z fbp, fbc, IP i User-Agentem klienta jest jednocześnie lepiej dopasowane i łatwiejsze do zdeduplikowania. Odwrotnie też działa: jeśli zdarzenie z serwera nie ma żadnego identyfikatora z przeglądarki, Meta ma mniej danych i do dopasowania, i do usunięcia duplikatu.

Uwaga na skróty: nie twórz fbc z niczego, żeby „uzupełnić” dane. Meta oczekuje wartości z prawdziwego kliknięcia reklamy, a sztuczny identyfikator może zafałszować atrybucję. Szczegółowy opis deduplikacji jest w osobnym artykule.

Plan poprawy EMQ krok po kroku

1. Wybierz zdarzenia, które mają znaczenie. Najczęściej Purchase, AddToCart i InitiateCheckout z witryny. PageView ma zwykle mniej danych klienta i nie ma sensu go „naprawiać” na siłę.
2. Zapisz stan wyjściowy. Wynik i pokrycie każdego parametru z Menedżera zdarzeń, żeby było z czym porównać.
3. Napraw format danych, zanim dodasz nowe pola. Źle znormalizowany e-mail jest gorszy niż brak e-maila, bo daje złudzenie, że dane są wysyłane.
4. Uzupełnij identyfikatory z przeglądarki (fbp, fbc, IP, User-Agent) po zgodzie na cookies.
5. Dodaj external_id, jeśli klient ma konto w sklepie.
6. Skróć opóźnienie: wysyłaj zdarzenie zaraz po zamówieniu.
7. Sprawdź wynik po kilku dniach ruchu i porównaj z punktem wyjścia.

Zbieraj tylko dane, których potrzebujesz do obsługi zamówienia. Dodawanie pól do formularza wyłącznie po to, żeby podbić EMQ, kłóci się z zasadą minimalizacji danych. Więcej o tym w artykule RODO a Conversions API.

Ograniczenia: czego EMQ nie mówi

• EMQ nie mierzy poprawności liczby zdarzeń. Wynik 10 przy zdarzeniu Purchase, które odpala się dwa razy przy jednym zamówieniu, nadal oznacza zawyżone zakupy.
• EMQ nie dotyczy zdarzeń offline. Tam jakość danych zależy od e-maila, telefonu i regularnej wysyłki.
• Basketly wysyła e-mail, telefon, external_id oraz dane przeglądarki z kolektora. Nie wysyła imienia, nazwiska, miasta, kodu pocztowego ani daty urodzenia. Jeśli Twoja strategia opiera się na tych polach, potrzebujesz innego rozwiązania.
• Wyższy wynik nie gwarantuje lepszych kampanii. Daje Mecie więcej dopasowanych zdarzeń do nauki; efekt sprawdzisz w Menedżerze reklam.

Jeśli dopiero zaczynasz z wysyłką z serwera, przeczytaj najpierw, czym jest Meta Conversions API. Plany i limity znajdziesz w cenniku.