Poprawne przypisywanie zakupów w Meta: przygotowanie danych klientów i unikanie duplikatów

Co mierzy EMQ

Meta Pixel wysyła zdarzenia z przeglądarki, a Conversions API (CAPI) z serwera. Przy dwóch zgłoszeniach tego samego zakupu dopasowanie służy znalezieniu możliwego konta Meta. Deduplikacja rozpoznaje natomiast powtórzone zdarzenie. To dwa odrębne zadania.

Event Match Quality (EMQ) ocenia informacje o klientach przekazane w zdarzeniach internetowych w skali do 10. Wynik opisuje możliwą przydatność danych do dopasowania. EMQ 8 nie oznacza dopasowania 80% zakupów. Atrybucja przypisuje zakupy do kontaktów z reklamą. Dodatkowa sprzedaż oznacza zakupy, które bez reklamy nie nastąpiłyby. Wysoki wynik nie potwierdza poprawności przypisania, takiej dodatkowej sprzedaży ani zgodności przetwarzania z prawem.

Normalizacja zależy od pola

Normalizacja przygotowuje wartości we wspólnym formacie, np. usuwa spacje z początku i końca. SHA-256 oblicza na podstawie wartości skrót o stałej długości. Dodatkowa spacja zmienia wynik, dlatego Meta określa zasady przygotowania poszczególnych pól:

• em: usunięcie białych znaków z początku i końca oraz zamiana adresu e-mail na małe litery. Podejrzane znaki sterujące lub niewidoczne znaki formatowania wymagają kontroli zamiast cichej zmiany adresu.
• ph: najpierw ustalenie numeru międzynarodowego z potwierdzonym kodem kraju, następnie usunięcie formatowania. Samo usunięcie znaków innych niż cyfry nie dodaje kodu kraju i nie rozwiązuje kwestii krajowego prefiksu.
• Imiona i dane adresowe: obowiązują reguły konkretnego parametru. Usuwanie wszystkich znaków diakrytycznych jest błędem; przykład Meta zachowuje akcent w imieniu valéry.

Adresy e-mail, telefony oraz oznaczone pola imienia i adresu wymagają SHA-256. Adres IP klienta, user agent, fbp i fbc są przekazywane bez haszowania. Dla external_id Meta zaleca haszowanie, ale API nie ustanawia ogólnego obowiązku haszowania tego parametru. Haszowanie nie anonimizuje danych nadal umożliwiających powiązanie z klientem.

Przykład Node.js o ograniczonym zakresie

Poniższy moduł ES haszuje adres e-mail albo wcześniej zweryfikowany międzynarodowy numer telefonu. Kontrola e-maila jest podstawowym sprawdzeniem formatu, a nie pełną walidacją adresu. Rozpoznanie numeru i potwierdzenie kraju muszą nastąpić wcześniej. Wyrażenie regularne sprawdza tylko akceptowaną postać. Numery krajowe lub nadal zawierające formatowanie są odrzucane zamiast zgadywane. Zero należące do numeru po kodzie kraju pozostaje bez zmian.

import { createHash } from 'node:crypto';
const sha256 = value => createHash('sha256').update(value, 'utf8').digest('hex');
export function hashEmail(raw) {
  if (typeof raw !== 'string') return null;
  const email = raw.trim().toLowerCase();
  if (/[\p{Cc}\p{Cf}]/u.test(email) || !/^[^\s@]+@[^\s@]+\.[^\s@]+$/u.test(email)) return null;
  return sha256(email);
}
export function hashCanonicalPhone(e164) {
  if (typeof e164 !== 'string' || !/^\+[1-9][0-9]{6,14}$/.test(e164)) return null;
  return sha256(e164.slice(1));
}

Nieprawidłowe dane dają wynik null i muszą zostać pominięte w żądaniu. SDK to biblioteka programistyczna ułatwiająca korzystanie z usługi. SDK lub szablon tagu może już wykonywać normalizację i haszowanie. Podwójne haszowanie tworzy błędny identyfikator, dlatego znaczenie ma format wejściowy wymagany przez konkretną integrację.

Jedno zdarzenie, wspólny identyfikator

Pixel ID określa skonfigurowane źródło zdarzeń Meta, a identyfikator zdarzenia odróżnia poszczególne zakupy. Zalecane parowanie wymaga tej samej nazwy zdarzenia i identyfikatora dla tego samego Pixel ID. W przeglądarce parametr nazywa się eventID, a w CAPI event_id. Dla zakupu oba zdarzenia mają nazwę Purchase. Meta dokumentuje okno odbioru 48 godzin od pierwszego zdarzenia z daną identyfikacją.

Identyfikator może powstać w backendzie albo przeglądarce. Raz utworzona, stabilna identyfikacja zdarzenia zakupu trafia do obu kanałów. Ponowienia tego samego zdarzenia zachowują wartość; kolejny zakup otrzymuje nową. Wspólny identyfikator wszystkich zakupów prowadziłby do łączenia różnych zdarzeń.

Szybka wysyłka ogranicza problemy z kolejkami, ale nie gwarantuje natychmiastowej aktualizacji raportów. Dane serwerowe nie zawsze pozostają zachowane w całości. Meta opisuje kilka strategii i przy braku istotnych różnic zwykle preferuje zdarzenie odebrane jako pierwsze.

Cookies, identyfikatory klientów i zgoda

_fbp i _fbc są zapisywane pod własną domeną witryny, czyli jako ciasteczka pierwszej strony. Istniejące wartości mogą zasilać parametry fbp i fbc. Utworzenie fbc wymaga rzeczywiście zaobserwowanego fbclid. Wielkość liter w identyfikatorze kliknięcia pozostaje bez zmian. Zmyślone wartości nie poprawiają pomiaru.

external_id to identyfikator klienta nadany przez reklamodawcę. Po dopasowaniu na podstawie innych informacji Meta może powiązać identyfikator z kontem i ponownie wykorzystać powiązanie przy kolejnych zdarzeniach. Powiązania okresowo wygasają. Spójne identyfikatory mogą wspierać ciągłość pomiaru, ale nie gwarantują atrybucji między urządzeniami po wielu tygodniach ani nie wydłużają okna atrybucji.

Integracja reklamowa oparta na zgodzie wymaga odpowiedniej kontroli zarówno w przeglądarce, jak i na serwerze. Google Consent Mode nie blokuje automatycznie serwerowego tagu Meta: platforma zarządzania zgodami (CMP) przechowuje decyzje dotyczące zgody. Integracja serwerowa musi jawnie sprawdzać dostarczony sygnał. Wycofanie zgody musi również zatrzymać oczekujące wysyłki, jeżeli przetwarzanie przestaje być dozwolone. Haszowanie i transport serwerowy nie zastępują tych mechanizmów.

Kontrola przed oceną raportów

Kontrolowany zakup testowy powinien utworzyć zdarzenie przeglądarkowe i serwerowe z identyczną nazwą oraz identyfikatorem, a następnie oczekiwany wynik deduplikacji. Osobne próby obejmują brak zgody, wycofanie zgody, ponowienia, opóźnienia i brak identyfikatorów. Trend EMQ uzupełnia liczbę zdarzeń oraz błędy przetwarzania; pojedynczy wynik nie stanowi certyfikatu jakości.

Ścieżkę integracji przedstawia Meta Conversions API przez Server-Side GTM.