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 leadach z CRM 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 etapy leadów z formularzy, nie goń wyniku EMQ. Zadbaj o to, żeby każde zdarzenie miało oryginalny lead_id, a etapy były dobrze zaprojektowane, co opisujemy w artykule etapy leada w CRM a 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 Convs?

Convs 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 i Lead 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 jakości leadów ani poprawności liczby zdarzeń. Wynik 10 przy zdarzeniu Lead, które odpala się przy każdym spamie, nadal oznacza optymalizację pod spam.
• EMQ nie dotyczy etapów leadów z CRM. Tam jakość danych zależy od lead_id i regularnej wysyłki etapów.
• Convs wysyła e-mail, telefon, external_id, lead_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.