Meta liczy zakupy podwójnie: skąd dubel i jak go znaleźć w 15 minut

Fakty w skrócie (stan na 2026-10-29)

• Meta łączy zdarzenia z Pixela i z serwera, gdy mają tę samą nazwę i ten sam identyfikator (eventID / event_id) i dotrą w ciągu 48 godzin.
• Bez wspólnego identyfikatora to samo zamówienie liczy się dwa razy lub więcej.
• Alternatywna metoda (fbp / external_id) zwykle działa tylko, gdy przeglądarka jest pierwsza.
• Basketly wysyła jeden zakup do jednego zbioru danych raz; duble z innych dróg wymagają wspólnego identyfikatora albo wyłączenia jednej drogi.
• Przyjęcie zdarzenia przez Metę nie dowodzi optymalizacji ani przypisania zakupu reklamie.

Sklep ma 22 zamówienia, a Meta pokazuje 60 zakupów. Takie rozbieżności opisują właściciele sklepów: „We’re using the native Shopify integration and the purchase events are massively overblown. Like 3x.” (tłum.: używamy natywnej integracji Shopify i zdarzenia zakupu są mocno zawyżone, jakieś 3 razy; r/FacebookAds, wątek). Albo w skrócie z polskiej agencji: równoczesny Pixel, wtyczka i GTM Server-Side wysyłają to samo zdarzenie bez wspólnego event_id, a efekt to „zdublowane konwersje i raporty, którym nikt nie ufa” (KC Mobile).

Poniżej: skąd się bierze dubel, jak go policzyć i naprawić. Jeśli problem jest odwrotny (Meta pokazuje mniej niż sklep), zacznij od tekstu Dlaczego Meta pokazuje mniej zakupów niż sklep.

Cztery źródła dubla

1. Kilka dróg wysyłających ten sam zakup

Pixel wklejony w kod sklepu, wtyczka platformy sklepowej, menedżer tagów i GTM Server-Side potrafią każdy osobno wysłać Purchase. Meta dostaje trzy zdarzenia o jednym zamówieniu. To najczęstszy przypadek w sklepach, które z czasem „dokładały” kolejne narzędzia.

2. Brak wspólnego identyfikatora

Nawet gdy chcesz mieć dwa kanały (Meta zaleca Pixel obok Conversions API), muszą się zgadzać dwie rzeczy: eventID w Pixelu równe event_id w API oraz ta sama nazwa zdarzenia. Gdy przeglądarka i serwer losują identyfikator osobno, para nie pasuje. Ktoś na Reddicie ujął to tak: „constant problem with event deduplication as capi and browser ID are always different” (wątek).

3. Odświeżenie strony podziękowania

Kod zakupu siedzi na stronie podziękowania. Klient odświeża ją, wraca z zakładki albo otwiera link z maila i zdarzenie odpala się ponownie. Poradniki agencji wymieniają to jako osobną przyczynę „podwójnego Purchase”.

4. Dwa Pixele naraz

Stary i nowy zbiór danych w kodzie sklepu, albo Pixel dodany raz przez wtyczkę i raz ręcznie. Każdy wysyła swoje zdarzenie, a dedupe między dwoma Pixelami o różnych identyfikatorach nie zadziała.

Jak policzyć, czy masz dubel

1. Wybierz jeden pełny dzień sprzed co najmniej dwóch dni. Policz opłacone zamówienia w sklepie.
2. Otwórz Menedżer zdarzeń, swój zbiór danych, zdarzenie Purchase i sprawdź, ile zdarzeń odebrano tego dnia oraz z jakich źródeł (przeglądarka, serwer).
3. Wynik: zdarzeń wyraźnie więcej niż zamówień oznacza dubel. Mniej niż zamówień to inny problem, opisany w tekście o brakujących zakupach.
4. Zakładka deduplikacji. W szczegółach zdarzenia Meta pokazuje odsetek zdeduplikowanych zdarzeń. Wyższy jest lepszy, a przy zbyt niskim pojawia się ostrzeżenie. Meta opisuje niski odsetek jako „Low Overlap”: wysyłasz nieunikalne klucze deduplikacji albo klucz tylko z jednego źródła.
5. Podejrzyj identyfikatory. Dla jednego zamówienia sprawdź, jaki event_id mają zdarzenie z przeglądarki i z serwera. Różne albo brak jednego z nich to przyczyna.

Naprawa w trzech krokach

1. Wypisz każdą drogę, którą idzie Purchase: Pixel w kodzie, wtyczka, tagi, GTM Server-Side, własny adapter, narzędzie takie jak Basketly. Dla każdej zapisz, czy wysyła z przeglądarki, czy z serwera.
2. Zostaw jedną drogę na zdarzenie albo połącz je identyfikatorem. Jeśli potrzebujesz dwóch kanałów, ustaw w obu tę samą nazwę zdarzenia i ten sam identyfikator zbudowany z numeru zamówienia, np. purchase_ORDER-123. W Pixelu przekazujesz go jako eventID, na serwerze jako event_id. Powtórzenia tego samego zamówienia muszą dostawać ten sam identyfikator. Pełny opis: deduplikacja zdarzeń Pixela i Conversions API.
3. Sprawdź po kilku dniach. Zakładka deduplikacji i porównanie zdarzeń z zamówieniami. Jeśli sklep ma jednak dwie integracje serwerowe, zostaw jedną.

Nie poprawiaj danych wstecz: duble już policzone zostają w raportach. Ważne jest, żeby od teraz nowe zakupy liczyły się raz.

Jak uniknąć dubla przy następnej zmianie

Duble wracają zwykle po dołożeniu narzędzia. Zanim włączysz kolejną wtyczkę, kolejny tag albo kolejną integrację, która wysyła zakupy, zadaj trzy pytania:

1. Czy ono wysyła Purchase, a jeśli tak, to z przeglądarki, czy z serwera?
2. Jaki identyfikator zdarzenia ustawia i czy da się go zrobić taki sam jak w pozostałych drogach?
3. Czy mogę wyłączyć zakup w którymś z istniejących narzędzi, zamiast dokładać kolejny kanał?

Po każdej takiej zmianie wróć na dwa dni do porównania zdarzeń z zamówieniami. To pięć minut, a oszczędza tygodnie raportów, które trzeba potem tłumaczyć klientowi lub szefowi.

Jak Basketly nie dubluje zakupów

W Basketly jeden zakup to jedna wysyłka do danego zbioru danych. Dwa mechanizmy to pilnują:

• Ten sam zakup przyjmujemy raz. Zdarzenie jest rozpoznawane po źródle, identyfikatorze zamówienia i statusie. Zamówienie odczytane drugi raz (np. przy kolejnym odczycie sklepu) nie tworzy drugiego zakupu.
• Ta sama wysyłka nie powstanie dwa razy. Do kolejki nie trafi drugi raz ta sama kombinacja: zbiór danych, nazwa zdarzenia, identyfikator zdarzenia i tryb (testowy lub produkcyjny), nawet z dwóch połączeń do tego samego zbioru danych. Ponowienia po błędzie sieci używają tego samego identyfikatora, więc Meta może je zdeduplikować.

Zakupy ze sklepu mają stały identyfikator zbudowany z numeru zamówienia (np. shoper-order-<numer>). Widzisz go w System → Zdarzenia → Historia wysyłek (opcjonalna kolumna z identyfikatorem zdarzenia). To ułatwia porównanie z tym, co wysyła Twój Pixel.

Pozostaje jedna rzecz, której Basketly nie zrobi za Ciebie: nie zmieni kodu Pixela ani wtyczki w sklepie. Jeśli Pixel i Basketly wysyłają ten sam zakup, Meta połączy je tylko przy wspólnej nazwie i identyfikatorze. Gdy Twój Pixel nie pozwala ustawić eventID, uczciwsze jest wysyłać Purchase tylko z jednej strony: najczęściej z serwera, a Pixel zostawić dla zdarzeń z przeglądarki (wyświetlenie produktu, dodanie do koszyka).

Pomocne po wdrożeniu: Konwersje → Bilans zakupów pokazuje, ile zakupów Basketly wysłał i przyjął, dzień po dniu, a Autodiagnostyka → Wysyłka do Meta porównuje statystyki Twojego zbioru danych (od Mety) z wysyłkami Basketly. Dwa razy więcej zdarzeń u Mety niż w Basketly to wskazówka, że zakupy płyną jeszcze innym kanałem. Opisujemy to w tekście o bilansie zakupów.

Czego Basketly nie rozwiąże

• Duble z cudzych kanałów. Basketly deduplikuje to, co sam wysyła. Zdarzenia z wtyczki, menedżera tagów i GTM idą obok.
• Dostarczenia „dokładnie raz”. Kolejka działa w modelu „co najmniej raz”, a ostatnie słowo w deduplikacji ma Meta.
• Duble już policzone. Raporty z przeszłości zostają takie, jakie były.
• Przypisania do reklamy. Przyjęcie zakupu przez Metę nie dowodzi optymalizacji ani atrybucji.

Następny krok

Zrób punkty 1 i 2 z listy „Jak policzyć” dla wczorajszego dnia. Jeśli chcesz zobaczyć Historię wysyłek z identyfikatorami zdarzeń, otwórz demo. Aby podłączyć własny sklep, załóż konto; limity planów są w cenniku. Jak działa wysyłka z serwera, opisuje strona Meta Conversions API.

Źródła

• Meta for Developers: Deduplicate Pixel and Server Events (event_id + event_name, okno 48 godzin, metoda fbp / external_id, jej ograniczenia)
• Meta for Developers: Verifying Your Setup (zakładka deduplikacji, „Low Overlap”)
• Meta for Developers: Server Event Parameters (event_id jako zalecany do deduplikacji)
• KC Mobile: Ile kosztuje Conversions API na Facebooku (cytat o zdublowanych konwersjach)
• r/FacebookAds: wątek o zawyżonych zakupach (Shopify), wątek o różnych identyfikatorach CAPI i przeglądarki