Duplikacja eventów purchase w Shoper - przyczyna i 3 sposoby naprawy

ROAS w Google Ads skoczył w nocy z 4,2 do 8,7. Bez zwiększenia budżetu, bez zmiany kampanii, bez wzrostu rzeczywistej sprzedaży w panelu sklepu. Klient marketingu dzwoni - “co się stało, czy to naprawdę?”.

W 9 na 10 przypadków odpowiedź brzmi: duplikacja eventów purchase. Coś w trackingu zaczęło liczyć ten sam zakup dwa razy (czasem trzy). ROAS rośnie matematycznie - dzielimy te same przychody przez ten sam koszt, ale licznik się zdublował. Smart Bidding dostaje sygnał “świetnie idzie”, podnosi stawki, koszt rośnie. Sklep traci pieniądze.

W Shoperze to klasyk. Trzy mechanizmy odpowiadają za 90% przypadków duplikacji, które widzę przy audytach. Ten artykuł pokazuje jak rozpoznać każdy z nich i jak naprawić - krok po kroku. Pełna architektura wdrożenia, w której deduplikacja jest częścią procesu, opisana w kompletnym przewodniku Server-side GTM na Shoper.

Jak rozpoznać że masz duplikację

Sygnały, które powinny zapalić czerwoną lampkę:

Liczba purchase w GA4 > liczba zamówień w panelu sklepu. Najprostszy test. Jeśli sklep zarejestrował 100 zamówień w lutym, a GA4 pokazuje 145 zdarzeń purchase - masz 45% duplikatów.

ROAS w Google Ads znacząco wyższy niż realny ROAS z panelu sklepu. Policz: (przychód z panelu - koszt Google Ads) / koszt Google Ads. Jeśli Google Ads pokazuje ROAS 6, a Twoje policzenie 3 - liczy 2x.

Meta Events Manager → Event Quality → Duplikaty. Meta sama wskazuje duplikaty. Jeśli widzisz “Deduplication impact: high” - masz problem.

Atrybucja jednego zakupu do wielu kampanii. Jeśli ten sam transaction_id pojawia się w atrybucji 2-3 razy - duplikat.

Wartość konwersji per akcja sztucznie wysoka. Średnia wartość purchase w Google Ads vs faktyczna średnia sprzedaży w sklepie. Jeśli Google liczy 2x wyższą - duplikacja po stronie wartości.

Czas między pojawieniem się duplikacji a jej wykryciem to typowo 2-6 tygodni. To wystarczy żeby Smart Bidding podniósł stawki, sklep przepalił budżet, a raporty z miesiąca wyglądały na świetne. Wykrywanie wcześnie = oszczędność realnego budżetu.

Trzy najczęstsze źródła duplikacji w sklepie Shoper

W audytach Shoper widzę je w niemal każdym przypadku duplikacji. Często więcej niż jedno źródło naraz.

Wtyczki marketingowe + GTM równocześnie

Shoper ma własne wbudowane integracje z Google Ads, GA4 i Meta. Jeśli równocześnie masz wpięty kontener GTM z tymi samymi tagami - każdy zakup liczy się dwa razy: raz przez integrację Shoper, raz przez tag w GTM.

Jak rozpoznać: w panelu Shoper sprawdź Integracje → Marketing (klasyczny RWD) lub Integracje → Analytics & Marketing (Storefront). Jeśli widzisz aktywną integrację Google Ads / GA4 / Meta Pixel oraz dodatkowo wpięty kontener GTM z tymi samymi tagami - masz duplikator.

Reload thank-you page lub powrót przyciskiem

Zakup się odbywa, użytkownik trafia na stronę podziękowania /zamowienie-zlozone/12345. Tag purchase strzela. Wszystko OK.

Ale potem użytkownik:

• Odświeża stronę (F5) - bo nie pojawił się oczekiwany komunikat, bo internet się zaciął, bo z przyzwyczajenia. Tag strzela drugi raz.
• Wraca przyciskiem “wstecz” - i wraca przyciskiem “dalej”. Każda nawigacja może odpalić tag jeśli nie ma idempotencji.
• Zapisuje stronę do zakładek i wraca później - na sklepach które trzymają thank-you page bez wygaśnięcia, użytkownik może wrócić za tydzień i odpalić ten sam purchase.

To źródło daje 5-20% duplikacji w zależności od UX sklepu i zachowań klientów.

Browser pixel + server CAPI bez event_id

Klasyk w server-side. Wdrożyłeś Meta Pixel przez GTM w przeglądarce + Conversions API przez server-side GTM. Oba liczą zakup. Jeśli dopiero migrujesz na server-side, sama architektura warstw i kolejność prac dla Shopera jest w przewodniku Server-side GTM na Shoper. Meta otrzymuje dwa eventy:

• Z Pixela: event_name=Purchase, event_id=null albo różny
• Z CAPI: event_name=Purchase, event_id=null albo różny

Meta widzi dwa różne eventy → liczy zakup dwa razy.

Identyczny mechanizm działa dla Google Ads, jeśli masz uruchomione client-side Google Ads tag + server-side równocześnie bez deduplikacji.

To źródło jest najczęstsze w sklepach, które niedawno przeszły na server-side. Daje 30-50% duplikacji - czyli ROAS Google Ads / Meta nagle wygląda 1,5-2x lepszy niż rzeczywistość.

Sposób 1: Wyłącz duplikat źródeł pomiaru

Najprostszy fix, najtańszy w realizacji, najlepszy do zrobienia w pierwszej kolejności.

Zasada: każdy system reklamowy ma być wpięty w sklep tylko jednym kanałem. Nie przez dwa naraz.

Audyt:

1. W panelu Shoper → Integracje → wyłącz wbudowane integracje z Google Ads, GA4 i Meta jeśli te same tagi masz w GTM. Pozostaw tylko jedną wersję pomiaru per system.
2. W GTM Preview Mode wejdź na thank-you page i zobacz listę tagów które się odpaliły. Powinno być po jednym tagu dla:
   • Google Ads Conversion (lub Server-side Google Ads w server container, jeśli używasz)
   • GA4 purchase event (lub Server-side GA4)
   • Meta Pixel Purchase (lub Server-side Meta CAPI)
3. Jeśli widzisz po dwa tagi tego samego typu - jeden z nich pochodzi z duplikatu źródła (wtyczka Shopera albo zapomniany stary tag w GTM). Wyłącz duplikat.

Pułapka, którą widzę często: właściciel sklepu boi się wyłączyć “stary tag” bo “może coś przestanie działać”. Efekt - tag siedzi miesiącami i podwaja pomiar. Lepsza taktyka: zostaw jeden, sprawdź po tygodniu. Jeśli wszystko działa, drugi był zbędny.

Czas wdrożenia tego fixa: 1-2 godziny audytu + 15 minut zmian w panelu Shoper i GTM.

Sposób 2: Idempotencja thank-you page

Reload thank-you page wymaga innego podejścia - tu wszystkie tagi są poprawne, problem leży w tym, że odpalają się więcej niż raz dla tego samego zamówienia.

Rozwiązanie: idempotencja - tag wykrywa, że dla tego konkretnego transaction_id purchase już został wysłany, i odmawia wysłania ponownego.

Mechanizm: zapisuj wysłane transaction_id w sessionStorage albo localStorage po pierwszym wysłaniu, sprawdzaj przed kolejnymi.

W GTM zrobisz to przez Custom HTML tag który strzela przed właściwym purchase tagiem:

<script>
  (function() {
    var orderId = {{transaction_id_dataLayer}};
    if (!orderId) return;
    
    var key = 'purchase_sent_' + orderId;
    if (sessionStorage.getItem(key)) {
      // Już wysłaliśmy - przerwij dataLayer.push i nie odpalaj purchase tagów
      window.dataLayer.push({'event': 'purchase_blocked_duplicate'});
      return;
    }
    sessionStorage.setItem(key, '1');
  })();
</script>

Następnie purchase tagi (Google Ads, GA4, Meta) ustawiasz na trigger purchase z dodatkowym warunkiem: event NIE jest purchase_blocked_duplicate.

Dla cyklu zakupowego dłuższego niż sesja używaj localStorage (przeżyje zamknięcie przeglądarki). Dla sklepów z silnym RODO compliance używaj sessionStorage z czyszczeniem po godzinie.

Alternatywa serwerowa (server-side GTM): w server container dodaj zmienną która sprawdza czy event z tym transaction_id już został przetworzony w ostatnich X minutach (przez Firestore, Redis albo lokalny cache). Bardziej skomplikowane, ale działa nawet jeśli użytkownik wrócił z innej przeglądarki.

Czas wdrożenia: 2-4 godziny dla wdrożenia client-side, dzień dla server-side.

Sposób 3: Spójny event_id dla deduplikacji browser/server

Najważniejsze dla hybrydowych wdrożeń (browser pixel + server CAPI). Tu rozwiązanie ma jeden punkt krytyczny: event_id musi być wygenerowany RAZ i wysłany w obu kanałach.

Mechanizm dla Meta:

1. W momencie purchase wygeneruj unikalny event_id (zwykle: transaction_id lub transaction_id_timestamp).
2. Wyślij go w Pixel jako eventID:

   fbq('track', 'Purchase', {value: 299, currency: 'PLN'}, {eventID: 'order_12345'});

3. Ten sam event_id wyślij w Conversions API (server-side). W server GTM mapuj event_id z dataLayer:

   event_id: {{transaction_id}}

4. Meta porówna oba eventy po event_id, zobaczy że to ten sam zakup, zaliczy tylko raz.

Test po wdrożeniu: Meta Events Manager → Test Events → wyślij testowe zamówienie → sprawdź czy event pokazuje “Deduplicated” status (nie “Counted twice”).

Dla Google Ads server-side analogicznie: ustaw transaction_id w obu wersjach tagu (client-side i server-side). Google deduplikuje konwersje po transaction_id. Przy okazji warto dorzucić Enhanced Conversions w wariancie server-side - z transaction_id i deduplikacją działa wyraźnie lepiej niż samo browser-side.

Najczęstsze pomyłki:

• Event_id wygenerowany dwa razy (raz w przeglądarce, raz w serwerze) - są różne, deduplikacji nie ma.
• Pixel wysyła event_id, CAPI nie wysyła - Meta widzi jeden event z ID i jeden bez, nie łączy ich.
• Format event_id niespójny (raz string, raz number) - tak samo.

Czas wdrożenia: 3-6 godzin dla pełnej konfiguracji client + server.

Jak zweryfikować że duplikacja zniknęła

Po każdej z 3 napraw zostaw 7-14 dni na zebranie danych, potem sprawdź:

Google Ads:

• Conversions → konkretna akcja → wartość zostawała stabilna lub spadła? Jeśli ROAS spadł o 30-50% to znak, że duplikat się skończył i widzisz realny obraz.
• Tools → Audit logs → sprawdź czy żadne kampanie nie zmieniły strategii sami z siebie po fixie.

GA4:

• Reports → Realtime → odpal testowe zamówienie i sprawdź czy purchase pojawia się raz.
• Reports → Acquisition → Conversions → porównaj liczbę purchase z liczbą zamówień w panelu Shoper za ten sam okres. Powinny się zgadzać z dokładnością do 5%.

Meta:

• Events Manager → Event Quality → Deduplication impact → powinno spaść do “Low” albo “None”.
• Test Events → sprawdź na testowym zamówieniu czy events są oznaczone jako deduplicated.

Panel sklepu vs analityka:

• Eksportuj zamówienia z Shopera za ten sam okres co GA4 purchase.
• Liczba zamówień: identyczna do 95-100%.
• Suma wartości: identyczna do 95-100% (różnice mogą wynikać z anulowanych zamówień).

Jeśli po wszystkich 3 sposobach naprawy te wartości się nie schodzą - jest jeszcze czwarte, rzadsze źródło: zazwyczaj webhook integracji, który wysyła dane do GA4 z innego momentu niż tag GTM. To wymaga audytu API.

Podsumowanie

Duplikacja eventów purchase to najczęstszy ukryty problem w sklepach Shoper, które zaczynają wdrażać poważniejszy tracking. Najgorsze w niej jest to, że przez pierwsze tygodnie wygląda jak sukces - ROAS rośnie, sprzedaż “lepiej się atrybuuje”, Smart Bidding się rozkręca. Dopiero gdy budżet ucieka szybciej niż realne przychody rosną, ktoś zaczyna zadawać pytania.

Trzy główne źródła - wtyczki + GTM, reload thank-you, browser/server bez event_id - pokrywają 90% przypadków. Każdy ma konkretny, technicznie prosty fix. Wymagają tylko dyscypliny w wdrożeniu i regularnego porównywania danych GA4 z panelem sklepu.

Sklep nie może wierzyć panelowi reklamowemu, jeśli liczby w nim są wyższe niż w jego własnym systemie zamówień. Pierwsze pytanie przy każdym podejrzeniu wzrostu ROAS - czy konwersje się nie dublują?

Pełny audyt duplikacji + naprawa to standardowy element pakietu Ads Tracking Cleanup GTM (2 000 zł netto, 3-5 dni). Dla bardziej zaawansowanych przypadków - Server-Side Start z hybrydowym pomiarem i deduplikacją na poziomie serwera.