Duplikaty transakcji w GA4: skąd się biorą i jak je wyeliminować

Jak GA4 deduplikuje transakcje i dlaczego to nie wystarcza

GA4 automatycznie usuwa duplikaty zdarzeń purchase z tym samym identyfikatorem transakcji, ale ochrona ma wyraźne granice. Dokumentacja Google wskazuje, że działa tylko dla danych ze strumieni internetowych i dotyczy transakcji tego samego użytkownika.

Z tego wynikają sytuacje, w których deduplikacja po stronie GA4 nie zadziała:

Ostatni wiersz to pułapka odwrotna do duplikatów. Google ostrzega, że przy transaction_id="" GA4 zdeduplikuje wszystkie zakupy z pustym identyfikatorem, więc zaniżysz liczbę transakcji. Identyfikator musi być dynamiczny i unikalny dla każdego zamówienia, nie może zawierać danych osobowych i nie powinien być współdzielony między użytkownikami.

Nawet gdy deduplikacja zadziała w raportach, duplikat jest sygnałem błędu we wdrożeniu, który zwykle dotyka też Google Ads i Meta. Zawyżony przychód oznacza zawyżony ROAS, a jeśli importujesz zakupy z GA4 jako konwersje, strategie stawek uczą się na nieprawdziwych wartościach. Jak to wpływa na wybór strategii, opisujemy w tekście o docelowym ROAS i maksymalizacji wartości konwersji.

Skąd biorą się duplikaty transakcji w GA4 – 7 przyczyn

Duplikaty powstają albo dlatego, że ta sama strona wysyła zdarzenie kilka razy, albo dlatego, że zakup wysyłają dwa różne mechanizmy. Odstęp czasu między zdublowanymi zdarzeniami zwykle zdradza przyczynę.

W polskich sklepach często pojawia się przypadek bramek płatności. Klient płaci przez PayU, Przelewy24 albo BLIK, wraca na stronę podziękowania, a po chwili sklep przekierowuje go ponownie po potwierdzeniu statusu płatności. Jeśli tag zakupu jest uruchamiany na podstawie adresu strony podziękowania, oba wejścia wysyłają zdarzenie.

Drugi typowy scenariusz to migracja. Ktoś wdraża GA4 przez GTM, ale nie wyłącza oficjalnej integracji platformy sklepowej, która też wysyła zakupy. Na stronie działają wtedy dwa źródła tego samego zdarzenia, często z tym samym identyfikatorem usługi.

Jak wykryć duplikaty transakcji w GA4 i BigQuery

Duplikaty najprościej wykryć, grupując zakupy według identyfikatora transakcji i szukając identyfikatorów, które wystąpiły więcej niż raz. W GA4 zrobisz to w eksploracji, ale pełny obraz da eksport do BigQuery.

W GA4 utwórz eksplorację dowolną z wymiarem identyfikatora transakcji i metryką zakupów e-commerce. Posortuj malejąco według liczby zakupów i przejrzyj wiersze z wartością większą niż 1. Sprawdź też wiersz „(not set)” – oznacza zakupy bez identyfikatora. Raporty pokazują dane już po przetworzeniu, więc część duplikatów może być w nich niewidoczna.

W BigQuery eksport zawiera zdarzenia w postaci zbliżonej do surowej, dlatego to najlepsze miejsce diagnozy. Poniższe zapytanie znajdzie zdublowane identyfikatory z ostatnich dni i pokaże, czy duplikaty pochodzą od jednego, czy od kilku użytkowników:

SELECT
  ecommerce.transaction_id,
  COUNT(*) AS liczba_zdarzen,
  COUNT(DISTINCT user_pseudo_id) AS liczba_uzytkownikow,
  MIN(TIMESTAMP_MICROS(event_timestamp)) AS pierwsze_zdarzenie,
  MAX(TIMESTAMP_MICROS(event_timestamp)) AS ostatnie_zdarzenie,
  TIMESTAMP_DIFF(MAX(TIMESTAMP_MICROS(event_timestamp)),
                 MIN(TIMESTAMP_MICROS(event_timestamp)), SECOND) AS odstep_s,
  SUM(ecommerce.purchase_revenue) AS przychod_lacznie
FROM `twoj-projekt.analytics_123456789.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20261001' AND '20261026'
  AND event_name = 'purchase'
GROUP BY 1
HAVING COUNT(*) > 1
ORDER BY liczba_zdarzen DESC;

Odstęp poniżej sekundy wskazuje na dwa tagi lub podwójny wpis do warstwy danych. Odstęp liczony w minutach lub godzinach to zwykle ponowne wyświetlenie strony podziękowania. Dwóch różnych użytkowników przy jednym identyfikatorze to najczęściej wysyłka z przeglądarki i serwera. Jeśli dopiero zaczynasz pracę z eksportem, przydadzą się pierwsze zapytania do danych GA4 w BigQuery.

Porównanie z systemem sklepu to trzeci test. Zestaw dzienną liczbę zamówień i przychód z panelu sklepu z danymi GA4. Różnica w górę oznacza duplikaty, różnica w dół – braki, np. przez odmowę zgody lub blokery. Typowe przyczyny rozbieżności między narzędziami omawiamy w artykule o różnicach w konwersjach GA4, Google Ads i Meta.

Jak wyeliminować duplikaty transakcji krok po kroku

Duplikaty eliminujesz u źródła, a dopiero potem dokładasz zabezpieczenia w GTM. Kolejność ma znaczenie, bo blokada w przeglądarce nie naprawi problemu dwóch mechanizmów wysyłki.

1. Usuń drugie źródło zakupu. Sprawdź w Tag Assistant, ile tagów i identyfikatorów GA4 działa na stronie podziękowania. Jeśli wysyła je wtyczka sklepu i GTM, wyłącz jedno z nich.
2. Uruchamiaj tag na zdarzeniu, a nie na adresie. Reguła oparta na zdarzeniu purchase z warstwy danych jest pewniejsza niż reguła „odsłona strony /dziekujemy/”.
3. Wysyłaj zdarzenie ze sklepu tylko raz. Najlepsze rozwiązanie to flaga w bazie zamówień: platforma przekazuje zakup do warstwy danych przy pierwszym wyświetleniu strony podziękowania i oznacza zamówienie jako wysłane. Specyfikację takiego wpisu znajdziesz w artykule o warstwie danych dla e-commerce GA4.
4. Używaj jednego identyfikatora. Ten sam numer zamówienia trafia do GA4, Google Ads, Meta i CRM. Nie używaj numeru płatności w jednym miejscu i numeru zamówienia w drugim.
5. Wybierz jedną ścieżkę przeglądarka–serwer. Jeśli zakup wysyła serwer, przeglądarka nie powinna wysyłać go bezpośrednio do tej samej usługi GA4, chyba że oba zdarzenia mają ten sam identyfikator klienta i transakcji.
6. Dodaj blokadę w GTM jako drugą linię obrony, zgodnie z przykładem poniżej.
7. Sprawdź efekt w BigQuery po tygodniu tym samym zapytaniem.

Blokada w GTM składa się z dwóch elementów. Pierwszy to zmienna typu JavaScript niestandardowy, która zwraca true, jeśli dany identyfikator już został wysłany:

function() {
  try {
    var id = {{DLV - ecommerce.transaction_id}};
    if (!id) return false;
    var sent = JSON.parse(localStorage.getItem('pi_tx_sent') || '[]');
    return sent.indexOf(String(id)) > -1;
  } catch (e) {
    return false;
  }
}

Na jej podstawie tworzysz regułę wyjątku dla tagu zakupu (zmienna równa true blokuje tag). Drugi element to tag uruchamiany w sekwencji po tagu zakupu, który zapisuje identyfikator:

<script>
(function () {
  try {
    var id = {{DLV - ecommerce.transaction_id}};
    if (!id) return;
    var key = 'pi_tx_sent';
    var list = JSON.parse(localStorage.getItem(key) || '[]');
    if (list.indexOf(String(id)) === -1) {
      list.push(String(id));
      localStorage.setItem(key, JSON.stringify(list.slice(-20)));
    }
  } catch (e) {}
})();
</script>

Ta blokada działa tylko w obrębie jednej przeglądarki i nie pomoże, gdy klient otworzy potwierdzenie na innym urządzeniu. Zapis w pamięci przeglądarki to także przechowywanie informacji na urządzeniu użytkownika, więc uruchamiaj go zgodnie z ustawieniami zgód (np. razem z tagiem analitycznym), a w razie wątpliwości co do wymogów Prawa komunikacji elektronicznej skonsultuj rozwiązanie z prawnikiem.

Duplikaty w Google Ads i Meta: osobne mechanizmy deduplikacji

Google Ads i Meta deduplikują konwersje według własnych zasad, więc poprawka w GA4 nie wystarcza. Każda platforma potrzebuje identyfikatora przekazanego we właściwym polu.

• Google Ads odrzuca konwersje z tym samym identyfikatorem transakcji w obrębie tej samej akcji konwersji. Przekaż numer zamówienia w polu identyfikatora transakcji w tagu konwersji. Jeśli importujesz zakupy z GA4 i jednocześnie masz tag Google Ads, upewnij się, że tylko jedna z tych akcji jest konwersją podstawową, bo inaczej Smart Bidding policzy zakup dwa razy.
• Meta deduplikuje zdarzenia z piksela i Conversions API na podstawie pary event_name i event_id. Identyfikator zdarzenia musi być identyczny w obu kanałach; szczegóły opisujemy w artykule o deduplikacji Pixel i Conversions API.

Zawyżone konwersje w platformach reklamowych szczególnie mocno zniekształcają wskaźniki rentowności. Jak liczyć ROAS i POAS na wiarygodnych danych, pokazujemy w tekście o ROAS, POAS i MER.

Co zrobić z historycznymi duplikatami

Danych już przetworzonych w GA4 nie da się poprawić ani usunąć, ale możesz oczyścić je w raportach opartych na BigQuery. Do oceny historycznych okresów używaj danych po deduplikacji, a nie surowych raportów.

Najprostszy sposób to widok, który zostawia tylko pierwsze zdarzenie dla każdego identyfikatora transakcji:

SELECT * EXCEPT(nr)
FROM (
  SELECT *,
    ROW_NUMBER() OVER (PARTITION BY ecommerce.transaction_id
                       ORDER BY event_timestamp) AS nr
  FROM `twoj-projekt.analytics_123456789.events_*`
  WHERE event_name = 'purchase'
)
WHERE nr = 1;

Nie wysyłaj zdarzeń refund dla zdublowanych zamówień. Zwrot z identyfikatorem transakcji odejmuje przychód tego zamówienia, a nie tylko duplikatu, więc pogorszysz dane zamiast je poprawić. Okres z błędem opisz w dokumentacji wdrożenia, żeby osoby porównujące wyniki rok do roku wiedziały, skąd skok.

Duplikaty to częsty punkt kontroli przed okresami szczytowej sprzedaży – sprawdzamy je w audycie tagów przed Black Friday. Nagły wzrost liczby zakupów bez wzrostu zamówień w sklepie może też wywołać automatyczny alert, co opisujemy w tekście o monitoringu tagów. Pozostałe poradniki diagnostyczne, w tym listę problemów z DebugView w GA4, znajdziesz w podtemacie Debugowanie tagów.