Deduplikacja zdarzeń Pixel i Conversions API w Meta

Jak działa deduplikacja Conversions API w Meta

Conversions API wysyła zdarzenia z serwera niezależnie od piksela. Meta zaleca korzystanie z obu kanałów jednocześnie, bo piksel bywa blokowany przez przeglądarki i rozszerzenia, a serwer nie widzi wszystkich interakcji w przeglądarce. Skoro oba kanały raportują ten sam zakup, potrzebny jest sposób, by rozpoznać duplikat – to właśnie deduplikacja zdarzeń.

Zasady są następujące:

• Klucz deduplikacji to para event_name i event_id. Obie wartości muszą być identyczne w zdarzeniu z przeglądarki i z serwera, łącznie z wielkością liter.
• Okno czasowe wynosi 48 godzin od pierwszego zdarzenia z danym kluczem. Zdarzenie serwerowe wysłane później zostanie policzone osobno.
• Wynik to jedno zdarzenie w raportach i w optymalizacji, nawet jeśli dotarło dwiema drogami.
• Ten sam piksel: oba zdarzenia muszą trafić do tego samego identyfikatora piksela (zbioru danych).

Meta opisuje też mniej niezawodną metodę opartą na parametrach fbp lub external_id, ale działa ona tylko w ograniczonych sytuacjach i nie zastępuje wspólnego event_id. Jeśli wdrażasz Conversions API od podstaw, od razu przyjmij event_id jako standard dla wszystkich zdarzeń wysyłanych podwójnie.

Deduplikacja nie dotyczy zdarzeń, które wysyłasz tylko jednym kanałem. Jeśli PageView idzie wyłącznie z piksela, a Lead z CRM wyłącznie przez serwer, nie ma czego scalać.

Skąd wziąć event_id dla różnych zdarzeń

Dobry event_id jest unikalny dla zdarzenia i identyczny w obu kanałach. Sposób jego tworzenia zależy od typu zdarzenia i od tego, gdzie powstaje zdarzenie serwerowe.

Jeśli zdarzenie serwerowe powstaje w server-side GTM na podstawie żądania z przeglądarki, identyfikator wystarczy wygenerować w przeglądarce i przekazać razem ze zdarzeniem. Jeśli powstaje w backendzie sklepu, np. po potwierdzeniu płatności, identyfikator musi pochodzić z danych dostępnych po obu stronach, czyli zwykle z numeru zamówienia.

Najwygodniej, gdy sklep umieszcza identyfikator bezpośrednio w warstwie danych. Specyfikację zdarzeń e-commerce dla programisty znajdziesz w artykule o warstwie danych dla e-commerce GA4.

window.dataLayer = window.dataLayer || [];
dataLayer.push({ ecommerce: null });
dataLayer.push({
  event: 'purchase',
  event_id: 'ord-2026-104578',
  ecommerce: {
    transaction_id: '2026-104578',
    value: 349.00,
    currency: 'PLN',
    items: [
      { item_id: 'SKU-001', item_name: 'Buty do biegania', price: 299.00, quantity: 1 },
      { item_id: 'SKU-014', item_name: 'Skarpety sportowe', price: 50.00, quantity: 1 }
    ]
  }
});

Dla zdarzeń bez numeru z backendu możesz użyć w GTM zmiennej JavaScript niestandardowej. Łączy ona losowy identyfikator odsłony z numerem zdarzenia w kontenerze, więc wszystkie tagi odpalane na tym samym zdarzeniu dostaną tę samą wartość:

function () {
  window.__piPageId = window.__piPageId ||
    (Date.now().toString(36) + Math.random().toString(36).slice(2, 10));
  return window.__piPageId + '.' + {{DL - gtm.uniqueEventId}};
}

Zmienna {{DL - gtm.uniqueEventId}} to zwykła zmienna warstwy danych odczytująca klucz gtm.uniqueEventId.

Wdrożenie wspólnego event_id krok po kroku

Wdrożenie polega na tym, by ta sama wartość trafiła do tagu piksela i do zdarzenia serwerowego. Poniższe kroki zakładają GTM w przeglądarce i Conversions API wysyłane przez kontener serwerowy lub backend.

1. Dodaj event_id do każdego zdarzenia w warstwie danych albo utwórz zmienną generującą identyfikator w GTM.
2. W tagu piksela Meta przekaż identyfikator w czwartym argumencie funkcji fbq, jako eventID.
3. W tagu GA4 lub innym tagu, który przesyła dane do serwera, dodaj parametr event_id z tą samą zmienną.
4. W tagu Conversions API po stronie serwera przypisz tę wartość do pola event_id.
5. Sprawdź, czy nazwy zdarzeń są identyczne w obu kanałach, np. Purchase, a nie purchase w jednym z nich.
6. Wyślij testowe zamówienie z kodem zdarzeń testowych i porównaj wartości w Menedżerze zdarzeń.
7. Po publikacji obserwuj diagnostykę zbioru danych przez kilka dni.

Kod piksela z przekazaniem identyfikatora wygląda tak:

fbq('track', 'Purchase', {
  value: 349.00,
  currency: 'PLN',
  content_ids: ['SKU-001', 'SKU-014'],
  content_type: 'product'
}, { eventID: 'ord-2026-104578' });

A to odpowiadające mu zdarzenie wysłane przez Conversions API:

{
  "data": [{
    "event_name": "Purchase",
    "event_time": 1793095200,
    "event_id": "ord-2026-104578",
    "action_source": "website",
    "event_source_url": "https://twojsklep.pl/zamowienie/dziekujemy/",
    "user_data": {
      "em": ["<SHA-256 adresu e-mail>"],
      "client_ip_address": "203.0.113.10",
      "client_user_agent": "Mozilla/5.0 (...)",
      "fbp": "fb.1.1793080000000.1234567890"
    },
    "custom_data": {
      "value": 349.00,
      "currency": "PLN",
      "content_ids": ["SKU-001", "SKU-014"],
      "content_type": "product"
    }
  }]
}

Konfigurację tagu Meta w kontenerze serwerowym, wraz z mapowaniem nazw zdarzeń GA4 na zdarzenia standardowe Meta, opisujemy w poradniku Meta Conversions API przez server-side GTM.

Jak sprawdzić, czy deduplikacja działa w Menedżerze zdarzeń

Najpierw użyj narzędzia do testowania zdarzeń. Skopiuj kod testowy, dodaj go do zdarzeń serwerowych jako test_event_code, otwórz stronę z poziomu narzędzia i złóż testowe zamówienie. Zdarzenie z przeglądarki i z serwera powinno pojawić się z tym samym identyfikatorem, a narzędzie powinno wskazać, że zostały rozpoznane jako jedno.

Po publikacji zajrzyj do przeglądu zbioru danych. Przy zdarzeniu Purchase powinny być widoczne dwa sposoby połączenia: przeglądarka i serwer. W szczegółach zdarzenia oraz w karcie diagnostyki Meta sygnalizuje problemy z kluczami deduplikacji, np. brak event_id w części zdarzeń albo niską zgodność identyfikatorów między kanałami. Zakres wskaźników w interfejsie zmienia się co kilka miesięcy, więc kieruj się przede wszystkim komunikatami diagnostyki.

Trzecim testem jest porównanie z systemem sklepu. Załóżmy, że panel sklepu pokazuje 120 zamówień w tygodniu, a Menedżer zdarzeń pokazuje w tym samym czasie 230 zdarzeń Purchase. Taka różnica niemal na pewno oznacza brak deduplikacji. W Menedżerze reklam porównanie jest trudniejsze, bo Meta przypisuje tam konwersje kampaniom według własnych reguł atrybucji, które opisujemy w tekście o atrybucji w Meta od marca 2026 – pełnej zgodności z panelem sklepu tam nie oczekuj.

Najczęstsze błędy deduplikacji i jak je naprawić

Większość błędów wynika z tego, że identyfikator powstaje dwa razy albo trafia w złe miejsce. Poniższa tabela zbiera objawy, które widać w danych.

Ostatni błąd zdarza się szczególnie często w sklepach na popularnych platformach, gdzie oficjalna wtyczka Meta ma własną integrację Conversions API, a zespół dodatkowo wdraża kontener serwerowy. Ten sam mechanizm podwójnego zliczania dotyczy GA4, co opisujemy w artykule o duplikatach transakcji w GA4.

Deduplikacja, zgody i jakość sygnału dla kampanii

Poprawna deduplikacja to warunek wiarygodnych danych w kampaniach nastawionych na sprzedaż. Kampanie Advantage+ Sales optymalizują się pod zdarzenie zakupu, więc zawyżona liczba zakupów prowadzi do błędnych decyzji o budżecie i fałszywego obrazu ROAS.

Conversions API nie jest też sposobem na obejście decyzji w banerze. Jeśli użytkownik odmówił zgody na marketing i piksel się nie uruchomił, zdarzenie serwerowe dla tego użytkownika również wymaga właściwej podstawy prawnej. Jak skonfigurować blokowanie tagów, opisujemy w checkliście wdrożenia Consent Mode v2; te same zasady stosuj do tagów Meta.

Gdy deduplikacja działa, kolejnym krokiem jest jakość danych o kliencie przekazywanych w zdarzeniach serwerowych, którą Meta mierzy wskaźnikiem opisanym w tekście o Event Match Quality. Ten sam mechanizm wspólnego identyfikatora stosują też inne platformy – w TikTok Pixel i Events API oraz w OpenAI Pixel i Conversions API. Różnice w liczbie konwersji między systemami tłumaczymy w artykule o rozbieżnościach konwersji między GA4, Google Ads i Meta. Wszystkie poradniki o pikselach i API konwersji znajdziesz w podtemacie Meta Pixel i Conversions API oraz na stronie Meta Conversions API.