Deduplikacja zdarzeń Pixela i Conversions API: event_id, event_name i okno 48 godzin

Deduplikacja zdarzeń to sposób, w jaki Meta rozpoznaje, że zakup z Pixela i zakup z Conversions API to jedna i ta sama konwersja. Bez niej każde zamówienie zgłoszone obiema drogami liczy się podwójnie: raporty pokazują więcej sprzedaży, niż było, a algorytm uczy się na zawyżonych danych. Poniżej: jak Meta łączy zdarzenia, jak budować event_id, jakie błędy psują deduplikację i jak to sprawdzić.

Po co w ogóle wysyłać to samo zdarzenie dwa razy?

Bo Meta tak zaleca. Dokumentacja Meta wprost rekomenduje Conversions API obok Pixela, czyli konfigurację nadmiarową. Pixel czasem nie zadziała (blokada reklam, brak zgody, zamknięta karta), a serwer czasem nie ma danych z przeglądarki. Razem dają pełniejszy obraz.

Koszt tej nadmiarowości to ryzyko podwójnego liczenia. Deduplikacja je usuwa, ale tylko gdy obie strony mówią tym samym językiem. Jeśli dane zdarzenie wysyłasz wyłącznie jednym kanałem, deduplikacja z Pixelem go nie dotyczy, co Meta też zaznacza.

Jak Meta łączy zdarzenia: dwie metody

Meta opisuje dwie metody. Zalecana jest pierwsza.

Przy metodzie zalecanej Meta deduplikuje zdarzenia, jeśli dotrą w ciągu 48 godzin od pierwszego zdarzenia z danym event_id. Gdy wersje z przeglądarki i z serwera nie różnią się istotnie, Meta zwykle zachowuje tę, która przyszła pierwsza.

Z metodą alternatywną jest haczyk: serwerowe zdarzenie, które przyjdzie, gdy w ciągu ostatnich 48 godzin nie było zdarzenia z przeglądarki, nie zostanie odrzucone, nawet jeśli identyczne zdarzenie z przeglądarki dotrze później. W praktyce przy serwerowych zakupach, które często docierają szybciej niż Pixel, ta metoda zawodzi. Dlatego dalej skupiamy się na event_id.

Jak zbudować dobry event_id?

event_id to dowolny tekst wybrany przez Ciebie. Dokumentacja parametrów zaznacza, że pole jest formalnie opcjonalne, ale zalecane do deduplikacji. Dobry identyfikator spełnia trzy warunki:

1. Jeden na konwersję. Dwa różne zamówienia nigdy nie mają tego samego event_id.
2. Ten sam po obu stronach. Przeglądarka i serwer znają go niezależnie albo jedna strona przekazuje go drugiej.
3. Stały przy ponowieniach. Gdy serwer ponawia wysyłkę po błędzie, nie generuje nowego identyfikatora.

Najprościej oprzeć go na numerze zamówienia albo rekordu w CRM, który obie strony i tak znają:

purchase_ORDER-123

W Pixelu identyfikator przekazujesz jako czwarty argument:

fbq('track', 'Purchase', { value: 149.99, currency: 'PLN' }, { eventID: 'purchase_ORDER-123' });

Po stronie serwera to samo trafia do pola event_id, razem z event_name: "Purchase". Nazwa musi być identyczna. Jeśli Pixel wysyła standardowe Purchase, a serwer własną nazwę, np. Zakup, Meta potraktuje je jak dwa różne zdarzenia.

Obie wersje powinny mieć komplet danych

Skoro Meta zwykle zachowuje zdarzenie, które dotarło pierwsze, nie wiesz z góry, która wersja zostanie. Jeśli Pixel wysyła tylko ciasteczko _fbp, a serwer zahashowany e-mail i telefon, to po deduplikacji część informacji może przepaść. Dlatego:

• po stronie serwera dołączaj także fbp i fbc z przeglądarki, jeśli masz je zebrane za zgodą klienta,
• po stronie Pixela korzystaj z zaawansowanego dopasowania, jeśli Twoja polityka prywatności na to pozwala,
• w obu wersjach wysyłaj tę samą wartość i walutę zamówienia.

Różne kwoty w dwóch wersjach tego samego zakupu to sygnał, że coś jest liczone inaczej, np. z kosztem dostawy po jednej stronie i bez niego po drugiej. Warto to ujednolicić, zanim zaczniesz porównywać przychody w raportach. O tym, które dane klienta najbardziej pomagają w dopasowaniu, piszemy w tekście o Event Match Quality.

Najczęstsze błędy, które psują deduplikację

Większość problemów z podwójnymi konwersjami ma jedną z poniższych przyczyn.

Ostatni przypadek zdarza się częściej, niż się wydaje. Platformy sklepowe i menedżery tagów potrafią mieć własne połączenie z Conversions API. Jeśli dołożysz drugie, z innym schematem identyfikatorów, deduplikacja między nimi nie zadziała.

Jak sprawdzić, czy deduplikacja działa?

Meta pokazuje to w Menedżerze zdarzeń. Według instrukcji weryfikacji otwierasz Przegląd Pixela, przycisk szczegółów przy danym zdarzeniu i zakładkę deduplikacji. Widać tam odsetek zdeduplikowanych zdarzeń. Wyższy jest lepszy, a przy zbyt niskim pojawia się ostrzeżenie.

W tym samym miejscu jest zakładka świeżości zdarzeń ze średnim opóźnieniem. Jeśli serwerowe zdarzenia przychodzą z opóźnieniem liczonym w dniach, ryzyko przekroczenia okna 48 godzin rośnie.

Prosty test przed wdrożeniem:

1. Ustaw zdarzenia serwerowe w trybie testowym z kodem z Menedżera zdarzeń.
2. Złóż zamówienie testowe i zanotuj jego numer.
3. Sprawdź, czy zdarzenie z przeglądarki i z serwera mają ten sam identyfikator.
4. Po przejściu na produkcję obserwuj zakładkę deduplikacji przez kilka dni.

Jak Convs pilnuje identyfikatorów

Convs nie zmieni kodu Pixela w Twoim sklepie, ale dba o to, żeby strona serwerowa była przewidywalna:

• Stały event_id. Gdy źródło nie poda identyfikatora (np. wiersz z Arkusza Google), hub tworzy go z identyfikatora źródła, rekordu i statusu. Ten sam rekord w tym samym statusie zawsze dostaje ten sam event_id.
• Zakupy ze sklepu wymagają event_id. Źródło sklepowe odrzuca zamówienie bez identyfikatora, bo bez niego deduplikacja z Pixelem jest niemożliwa. Szczegóły w artykule o Shoperze i Conversions API.
• Ponowienia zachowują identyfikator. Kolejka działa w modelu „co najmniej raz”: po błędzie sieci czy limicie zapytań wysyła ponownie z tym samym event_id, więc Meta może to zdeduplikować.
• Własna deduplikacja przed wysyłką. To samo zdarzenie (źródło + identyfikator rekordu + status) jest przyjmowane raz. Do kolejki nie trafi też drugi raz ta sama kombinacja: zbiór danych, nazwa zdarzenia, event_id i tryb (test lub produkcja), nawet z dwóch różnych połączeń do tego samego zbioru danych.
• Etapy leadów z formularzy Meta mają stały identyfikator na lead i etap. Każdy etap zapisuje się raz.

Test i produkcja mają osobną deduplikację, więc zdarzenie wysłane w trybie testowym nie zablokuje późniejszej wysyłki produkcyjnej. Więcej o kolejce na stronie Meta Conversions API.

Ograniczenia

Deduplikacja nie naprawi wszystkiego:

• Hub nie dopisze eventID do Twojego Pixela. Jeśli instalacja Pixela w sklepie nie pozwala go ustawić, problem podwójnej wysyłki pozostaje. Wtedy uczciwiej jest wysyłać dane zdarzenie tylko jednym kanałem.
• Nie widzi innych integracji. Hub deduplikuje to, co sam wysyła. Zdarzenia z wtyczki sklepu czy menedżera tagów idą obok i Meta musi je połączyć sama.
• Model „co najmniej raz”. Hub nie obiecuje dostarczenia dokładnie raz; ostatnie słowo w deduplikacji ma Meta.
• Odbiór to nie atrybucja. Przyjęcie zdarzenia przez Meta nie dowodzi, że kampania optymalizuje się pod nie.

Następny krok

Spisz zdarzenia, które wysyłasz i z Pixela, i z serwera, a dla każdego sprawdź, skąd bierze się eventID. Jeśli chcesz, żeby serwerowa część działała w Convs, zacznij od odbiorcy w trybie testowym. Plany znajdziesz w cenniku, a podstawy w tekście Meta Conversions API: co to jest.