Pixel i Conversions API: deduplikacja zdarzeń

Jeżeli ten sam zakup lub lead jest wysyłany przez Meta Pixel i Conversions API, dwa przesłania nie muszą oznaczać dwóch konwersji. System musi jednak rozpoznać, czy są to dwie wersje jednego zdarzenia, czy dwa niezależne eventy. W podstawowym wariancie służą do tego zgodne wartości event_id i event_name.

Deduplikacja to mechanizm zapobiegający podwójnemu uwzględnieniu tego samego zdarzenia przesłanego z przeglądarki i serwera.^[2] Nie wyjaśnia jednak automatycznie każdej różnicy między wynikami raportowanymi przez Meta a danymi z systemu sprzedażowego.

Skąd bierze się podwójne liczenie konwersji?

Meta Pixel rejestruje aktywność po stronie przeglądarki, a Conversions API może przesłać odpowiadające jej zdarzenie z serwera. Jeżeli oba kanały raportują ten sam zakup, lead lub inną akcję, Meta musi ustalić, czy są to dwa przekazania jednego eventu.

Problem pojawia się wtedy, gdy odpowiadające sobie zdarzenia nie zostaną prawidłowo rozpoznane jako duplikaty. W takim przypadku raport może uwzględnić je osobno, mimo że odnoszą się do jednej akcji użytkownika.^[4]

Sam fakt, że liczba konwersji w Meta różni się od liczby zamówień lub zgłoszeń, nie przesądza jeszcze o błędzie deduplikacji. Do diagnozy potrzebne jest prześledzenie konkretnego zdarzenia oraz porównanie jego wersji przeglądarkowej i serwerowej.

Jak Meta rozpoznaje, że Pixel i CAPI dotyczą tego samego zdarzenia?

W podstawowym mechanizmie deduplikacji odpowiadające sobie eventy powinny mieć ten sam identyfikator oraz zgodną nazwę. Przeglądarkowy parametr eventID i serwerowy parametr event_id muszą odnosić się do tej samej instancji zdarzenia.^[2][3]

• Zgodny identyfikator: Pixel i CAPI przekazują tę samą wartość event_id dla konkretnej akcji.
• Zgodna nazwa: oba kanały używają tego samego event_name, na przykład Purchase albo Lead.
• Unikalność zdarzenia: identyfikator dotyczy pojedynczej instancji akcji, a nie wszystkich eventów tego samego typu.

Nie chodzi więc o nadanie jednego stałego identyfikatora wszystkim zakupom. Każda osobna akcja wymaga własnego ID, ale dwa przekazania tej samej akcji powinny korzystać z tej samej wartości.

event_id: jeden identyfikator dla jednej akcji

Identyfikator pozwala powiązać wersję przeglądarkową z wersją serwerową. Jeżeli frontend i backend utworzą różne wartości dla tego samego działania, podstawowa ścieżka rozpoznania duplikatu zostaje przerwana. Meta może wtedy potraktować oba przekazania jako osobne zdarzenia.^[4]

event_name: zgodna nazwa po obu stronach

Sam wspólny identyfikator nie powinien zastępować zgodności nazwy eventu. Jeżeli przeglądarka raportuje jedno zdarzenie, a serwer inne, nie jest to poprawnie opisana para dwóch wersji tej samej akcji.

Jak wdrożyć wspólny event_id bez generowania duplikatów?

Najbezpieczniejsza logika polega na utworzeniu identyfikatora raz dla konkretnego zdarzenia, a następnie przekazaniu tej samej wartości do Pixela i Conversions API.^[5]

W poprawnym modelu kolejność wygląda następująco:

1. Dochodzi do konkretnej akcji, na przykład zakupu albo wysłania formularza.
2. Dla tej instancji zdarzenia powstaje jeden unikalny event_id.
3. Ta sama wartość trafia do eventu wysyłanego przez Pixel.
4. Identyczna wartość trafia do odpowiadającego mu eventu serwerowego.
5. Oba przekazania używają zgodnego event_name.

Błędny wariant powstaje wtedy, gdy przeglądarka i serwer niezależnie generują własne identyfikatory. Choć oba eventy mogą opisywać ten sam zakup, ich różne ID nie wskazują Meta, że są dwiema wersjami jednej akcji.

Sposób utworzenia i przekazania identyfikatora zależy od architektury sklepu, formularza albo połączenia z systemem CRM. Nie istnieje więc jedna warstwa techniczna, która w każdym wdrożeniu musi odpowiadać za generowanie ID. Kryterium pozostaje niezmienne: dla jednej instancji zdarzenia oba kanały powinny otrzymać tę samą wartość.

Procedura kontroli deduplikacji w Events Managerze

Kontrolę najlepiej oprzeć na pojedynczym, możliwym do rozpoznania zdarzeniu. Zamiast zaczynać od łącznej liczby konwersji w raporcie kampanii, należy porównać dane przesłane dla jednej akcji.

1. Wybierz event do testu. Może to być konkretne zdarzenie Purchase, Lead albo inny event objęty równoległym pomiarem.
2. Wykonaj jedną kontrolną akcję. Celem jest odnalezienie odpowiadających sobie przekazań z przeglądarki i serwera.
3. Odszukaj oba źródła w Events Managerze. Ustal, czy Meta widzi wersję browser oraz wersję server.
4. Porównaj event_name. Nazwa zdarzenia powinna być zgodna po obu stronach.
5. Porównaj event_id. Oba przekazania tej samej akcji powinny zawierać identyczną wartość.
6. Oceń status deduplikacji. Dopiero po porównaniu parametrów przejdź do interpretacji danych zbiorczych.

Po wdrożeniu takie kontrolne zdarzenie pozwala ocenić, czy Meta widzi źródło przeglądarkowe, źródło serwerowe i ich deduplikację.^[6] Układ panelu i nazwy jego elementów mogą zmieniać się wraz z aktualizacjami platformy, dlatego ważniejsza od położenia konkretnej opcji jest kolejność kontroli danych.

Gdy Meta nadal liczy dwa razy: mapa najczęstszych przyczyn

Jeżeli raport nadal wygląda na zawyżony, diagnozę można uporządkować według objawu i obszaru kontroli.

Widać wersję browser i server, ale mają różne identyfikatory

Najpierw trzeba sprawdzić miejsce generowania event_id. Różne wartości po stronie Pixela i CAPI mogą prowadzić do podwójnego zliczania, ponieważ nie tworzą podstawowej pary do deduplikacji.^[2]

Jedna akcja uruchamia więcej niż dwa przekazania

Należy ustalić, czy tego samego eventu nie wysyła dodatkowy tag albo kolejna integracja. Poprawna para browser–server nie wyjaśni nadmiarowych wywołań pochodzących z innych ścieżek.

Parametry są zgodne, ale raporty nadal się różnią

Nie należy automatycznie zmieniać event_id. Rozbieżność może dotyczyć konfiguracji źródła danych, opóźnienia lub innego problemu pomiarowego. Deduplikacja jest jednym z obszarów kontroli, a nie wyjaśnieniem wszystkich różnic.

Widoczne jest tylko jedno źródło zdarzenia

W takiej sytuacji nie ma jeszcze podstaw do oceny pary browser–server. Najpierw trzeba ustalić, czy drugie przekazanie w ogóle dociera do właściwego źródła danych.

Taka kolejność ogranicza ryzyko poprawiania niewłaściwego fragmentu integracji. Najpierw identyfikuje się liczbę przekazań i ich źródła, później porównuje nazwę oraz ID, a dopiero na końcu interpretuje wynik raportowy.

event_id a fbp, fbc i external_id — czego nie należy ze sobą mylić

event_id identyfikuje konkretną instancję zdarzenia. Parametry takie jak fbp, fbc i external_id odnoszą się natomiast do przeglądarki, kliknięcia albo użytkownika. Pełnią więc inną funkcję i nie powinny zastępować synchronizacji identyfikatora eventu.^[4]

• event_id: odpowiada na pytanie, czy dwa przekazania opisują tę samą instancję zdarzenia.
• fbp, fbc i external_id: są parametrami związanymi z dopasowaniem, a nie zamiennikami identyfikatora konkretnej akcji.

Artykuł opisuje podstawowy wariant deduplikacji oparty na zgodnym event_id i event_name. Meta może stosować dodatkowe mechanizmy dopasowania w określonych konfiguracjach, ale nie jest to powód, aby pomijać poprawne przekazanie wspólnego identyfikatora.

Dobrze przeprowadzona kontrola zaczyna się od jednej akcji i jej dwóch wersji: przeglądarkowej oraz serwerowej. Zgodne event_name i event_id tworzą podstawę deduplikacji, natomiast różne identyfikatory mogą prowadzić do podwójnego zliczania. Jeżeli te pola są poprawne, diagnostykę należy rozszerzyć na dodatkowe wywołania, konfigurację źródła i inne przyczyny rozbieżności.

+Artykuł Sponsorowany+