event_id (ang. event ID) to unikalny identyfikator pojedynczego zdarzenia, który wysyłany jest równocześnie z przeglądarki (np. przez Piksel Meta) i z serwera (przez Conversions API), aby platforma reklamowa zliczyła tę samą konwersję tylko raz. Bez poprawnie ustawionego event_id każdy zakup lub lead trafia do Meta dwukrotnie, co zawyża wyniki kampanii i psuje optymalizację. Dla marketera to fundament wiarygodnego pomiaru przy przejściu na server-side tagging.
Jak działa deduplikacja zdarzeń przez event_id?
Deduplikacja to proces, w którym platforma reklamowa łączy dwa zgłoszenia tego samego zdarzenia w jeden rekord. Meta porównuje parę event_name + event_id: jeśli w określonym oknie czasowym otrzyma zdarzenie „Purchase” z identycznym event_id z piksela i z Conversions API (CAPI), zachowa tylko jedno z nich. Jeżeli identyfikatory się różnią albo jednego brakuje, oba zdarzenia zostaną policzone jako osobne konwersje.
Z punktu widzenia Meta pierwsze przychodzące zdarzenie jest zapisywane, a duplikat odrzucany. Dlatego oba kanały muszą generować event_id w tym samym miejscu (zwykle w przeglądarce) i przekazywać go dalej bez modyfikacji. Szczegóły mechanizmu opisuje dokumentacja Meta dotycząca deduplikacji.
| Zdarzenie z piksela | Zdarzenie z CAPI | Wynik w Meta |
|---|---|---|
| Purchase, event_id = ord-10482 | Purchase, event_id = ord-10482 | 1 konwersja (deduplikacja działa) |
| Purchase, event_id = ord-10482 | Purchase, event_id = 1717000123 | 2 konwersje (zawyżony wynik) |
| Purchase, brak event_id | Purchase, event_id = ord-10482 | 2 konwersje (zawyżony wynik) |
| Purchase, event_id = ord-10482 | brak zdarzenia (serwer nie wysłał) | 1 konwersja, ale bez korzyści CAPI |
Jak skonfigurować event_id w Google Tag Manager?
- Wygeneruj identyfikator w przeglądarce. Najlepiej, gdy zdarzenie wpada do dataLayer już z event_id (np. numer zamówienia dla Purchase, a dla innych zdarzeń unikalny ciąg oparty o timestamp i losową część). Alternatywnie utwórz zmienną Custom JavaScript, która zwraca unikalną wartość dla każdego wywołania.
- Przekaż event_id do Piksela Meta. W tagu piksela dodaj parametr
eventIDjako czwarty argument wywołaniafbq('track', …)lub użyj pola „Event ID” w szablonie tagu. - Przekaż ten sam identyfikator do kontenera serwerowego. Zdarzenie GA4 wysyłane do server-side GTM powinno zawierać parametr
event_id; tag Conversions API w kontenerze serwerowym odczyta go automatycznie lub przez mapowanie. - Zweryfikuj w Events Manager. W zakładce diagnostyki Meta pokaże, czy zdarzenia są deduplikowane i jaki jest wskaźnik Event Match Quality.
Więcej wskazówek o strukturze tagów i zmiennych znajdziesz w kategorii Google Tag Manager.
Kiedy event_id jest niezbędny, a kiedy nie?
- Niezbędny: gdy to samo zdarzenie wysyłasz jednocześnie z przeglądarki i z serwera (setup hybrydowy piksel + CAPI). To najczęstszy i rekomendowany model.
- Niezbędny: gdy zdarzenia serwerowe generuje backend sklepu (webhook po płatności), a piksel dalej działa na stronie podziękowania.
- Zbędny: gdy całkowicie wyłączasz piksel i wysyłasz zdarzenia wyłącznie przez CAPI — nie ma czego deduplikować, ale tracisz też sygnały przeglądarkowe, które podnoszą Event Match Quality.
- Zbędny: dla zdarzeń, które celowo wysyłasz tylko jednym kanałem (np. PageView tylko z piksela).
Najczęstsze błędy przy deduplikacji
- Generowanie event_id osobno po stronie piksela i osobno na serwerze — identyfikatory nigdy się nie spotkają.
- Użycie identyfikatora sesji lub użytkownika zamiast identyfikatora zdarzenia — kilka różnych zakupów w jednej sesji zostanie zdeduplikowanych do jednego.
- Różne nazwy zdarzeń w obu kanałach (np. „Purchase” z piksela i „purchase” z serwera) — Meta wymaga zgodności
event_name. - Utrata event_id przy przejściu przez Consent Mode lub odpalanie piksela dopiero po zgodzie, gdy serwer już wysłał zdarzenie z innym identyfikatorem.
- Brak testów po wdrożeniu — duplikaty widać dopiero po kilku dniach w rozjeżdżających się liczbach między Ads Managerem a systemem sklepowym.
event_id w praktyce ICBM
Przy wdrożeniach server-side tagging zaczynamy od audytu warstwy danych: sprawdzamy, czy sklep przekazuje stabilny identyfikator transakcji i czy każde zdarzenie niższego rzędu (AddToCart, InitiateCheckout, Lead) ma własny, jednorazowy event_id. Następnie konfigurujemy przekazywanie tego samego parametru do piksela i do tagu CAPI w kontenerze serwerowym, a po wdrożeniu porównujemy liczbę konwersji w Events Manager z liczbą zamówień w panelu klienta. Dopiero gdy obie liczby są spójne, a diagnostyka Meta nie zgłasza duplikatów, uznajemy setup za produkcyjny.
Najczęściej zadawane pytania
Czy event_id musi być numerem zamówienia?
Nie, ale dla zdarzenia Purchase numer zamówienia jest najwygodniejszym wyborem, bo naturalnie jest unikalny i dostępny zarówno w przeglądarce, jak i na serwerze. Dla pozostałych zdarzeń wystarczy dowolny ciąg, który nie powtórzy się między wywołaniami — np. połączenie timestampu z losową liczbą.
Co się stanie, jeśli zdarzenie z serwera dotrze później niż z piksela?
Meta deduplikuje zdarzenia w oknie czasowym liczonym w godzinach, więc kilkusekundowe czy kilkuminutowe opóźnienie nie stanowi problemu. Zachowane zostaje pierwsze odebrane zdarzenie, a drugie jest odrzucane jako duplikat — pod warunkiem zgodności event_id i event_name.
Czy event_id wpływa na Event Match Quality?
Bezpośrednio nie — Event Match Quality zależy od jakości danych identyfikujących użytkownika (e-mail, telefon, fbp, fbc, IP). Pośrednio jednak poprawna deduplikacja pozwala bezpiecznie wysyłać zdarzenia oboma kanałami, dzięki czemu Meta otrzymuje bogatszy zestaw parametrów i wskaźnik dopasowania rośnie.
