Umów się na darmowy audyt e-commerce ↗
ANALITYKA & ATRYBUCJA • INŻYNIERIA DANYCH E-COMMERCE

Dlaczego Twoje GA4 zakłamuje ROAS z Adsów? 6 krytycznych błędów konfiguracji śledzenia e-commerce

Raporty agencji mediowej deklarują ROAS rzędu 800%, algorytmy Google Ads raportują setki konwersji, a na firmowym koncie brakuje gotówki na pokrycie bieżących faktur. To powszechna w e-commerce iluzja atrybucji. Zobacz, jak standardowe wdrożenia gubią dane i jak poprawnie zabezpieczyć analitykę.

Architektura danych: Dawid Śliwiński • Head of Growth PUSH / Standard: GA4 E-commerce & Server-Side Tracking
⏱ 8 min lektury wdrożeniowej

Większość właścicieli sklepów i dyrektorów e-commerce traktuje Google Analytics 4 jak bezobsługowy licznik wejść. W rzeczywistości GA4 zainstalowane domyślną wtyczką w WooCommerce, PrestaShop czy Magento w 9 na 10 sklepów generuje zafałszowane dane.

„Jeśli karmisz algorytmy Smart Bidding i Performance Max zafałszowanymi danymi o konwersjach, sztuczna inteligencja zoptymalizuje Twoje budżety pod przypadkowy ruch, a nie realny zysk netto.”

— Zasada Czystości Danych PUSH

Oto 6 newralgicznych punktów w architekturze śledzenia, przez które kampanie reklamowe tracą atrybucję, a zarząd podejmuje błędne decyzje budżetowe.

01
BŁĄD #1: ZŁODZIEJE ATRYBUCJI (REFERRAL OVERWRITE)

Bramki płatności i banki kradnące sukces kampaniom płatnym

Użytkownik klika reklamę Google Ads lub Meta Ads, dodaje produkt do koszyka i przechodzi do kasy. Wybiera płatność przez szybki przelew lub bramkę zewnętrzną. Zostaje przekierowany na domenę bankowości elektronicznej, a po zatwierdzeniu transakcji wraca na podstronę podziękowania (Thank You Page). W tym momencie domyślnie skonfigurowane GA4 zamyka poprzednią sesję i otwiera nową – przypisując 100% wartości zamówienia bankowi lub bramce płatniczej jako źródłu referral.

Zasady inżynierii danych dla atrybucji źródeł:
  • Bezwzględna lista wykluczeń (Unwanted Referrals): Konfiguracja reguł wykluczających domeny bramek płatności (PayU, Autopay, Przelewy24, Tpay, BLIK) bezpośrednio w strumieniu sieci Web.
  • Ochrona domen bankowych: Wykluczenie domen logowania największych banków w Polsce (mBank, PKO BP, Santander, ING, Alior, Pekao), które przejmują sesje klientów po autoryzacji 3D Secure.
  • Ciągłość sesji: Zachowanie pierwotnego źródła wejścia (cpc / organic) i prawidłowe zasilenie atrybucji Data-Driven w Google Ads.
Lista niechcianych witryn odsyłających w GA4
Analiza wdrożenia PUSH w GA4: Precyzyjnie zdefiniowana lista niechcianych witryn odsyłających w panelu administracyjnym. Czerwona ramka wskazuje wykluczone bramki płatnicze oraz domeny bankowości internetowej, które bez tej reguły bezpowrotnie niszczą atrybucję kampanii Google Ads i Meta Ads.
02
BŁĄD #2: WADLIWY CONSENT MODE V2

Ślepota algorytmów na użytkowników odrzucających ciasteczka

Od marca 2024 roku Google bezwzględnie wymaga wdrożenia mechanizmu Consent Mode v2 pod rygorem zablokowania list remarketingowych i degradacji algorytmów Smart Bidding. Wdrożenie trybu podstawowego (Basic) całkowicie wycina tagi do momentu kliknięcia zgody, tracąc 30–45% danych. Jeszcze gorszym błędem są błędy synchronizacji (race condition), w których tag odpala się zanim baner CMP zadeklaruje stany domyślne.

Zasady inżynierii danych dla trybu zgody v2:
  • Obsługa nowych parametrów v2: Poprawna inicjalizacja parametrów ad_user_data oraz ad_personalization obok klasycznych ad_storage i analytics_storage.
  • Zaawansowany Consent Mode (Advanced): Zezwolenie na wysyłkę zanonimizowanych pingów bezciasteczkowych, umożliwiających modelowanie konwersji przez uczenie maszynowe Google.
  • Kolejność wywołań w kodzie: Skrypt zgody musi zadeklarować stan domyślny na samej górze sekcji <head>, przed kontenerem GTM.
Weryfikacja Consent Mode v2 w Tag Assistancie
Analiza wdrożenia PUSH w Google Tag Assistant: Weryfikacja sygnałów zgody dla platformy e-commerce. Czerwona ramka potwierdza poprawną rejestrację parametrów Consent Mode v2 (ad_user_data i ad_personalization) w stanie domyślnym.
03
BŁĄD #3: DUPLIKACJA ZDARZEŃ PURCHASE

Fantomowy przychód: Odświeżanie strony z potwierdzeniem zakupu

Klient opłaca zamówienie, trafia na stronę z podziękowaniem, po czym odświeża stronę na smartfonie, wraca do niej po kilku godzinach lub klika link ze statusu zamówienia w mailu. Jeśli zdarzenie zakupu nie posiada mechanizmu deduplikacji, za każdym razem wysyła do GA4 zdarzenie purchase z tą samą kwotą, pompując raportowany przychód o 15–25% ponad stan w ERP.

Zasady inżynierii danych dla deduplikacji transakcji:
  • Unikalny transaction_id: Każde zamówienie musi mieć unikalny identyfikator powiązany z numerem z bazy sklepu.
  • Walidacja w GA4: Sprawdzanie relacji metryki Liczba zdarzeń do Transakcje w raportach eksploracji swobodnej — wzorzec musi wynosić dokładnie 1:1.
  • Blokada w SessionStorage / Cookies: Skrypt po stronie przeglądarki lub serwera oznacza przetworzone ID i uniemożliwia ponowne odpalenie tagu przy kolejnych wejściach na Thank You Page.
Deduplikacja transakcji w GA4 - identyfikator transakcji
Analiza wdrożenia PUSH w GA4 (Eksploracja swobodna): Twardy dowód unikalności transakcji. Czerwona ramka wskazuje, że dla każdego unikalnego numeru zamówienia liczba zarejestrowanych zdarzeń i transakcji wynosi dokładnie 1 — całkowity brak duplikatów i czysty pomiar finansowy.
04
BŁĄD #4: OGRANICZENIA CLIENT-SIDE I ADBLOCKI

Śledzenie serwerowe (sGTM): Ochrona przed restrykcjami Safari i blokadami przeglądarek

Śledzenie oparte wyłącznie na kodzie JavaScript w przeglądarce klienta (Client-Side) jest bezbronne wobec wtyczek blokujących reklamy (AdBlocki, uBlock) oraz mechanizmu Apple Safari ITP, który drastycznie skraca żywotność plików cookies. W efekcie klient kupujący po 3 dniach od kliknięcia w reklamę na telefonie iPhone jest rejestrowany jako ruch bezpośredni (Direct), a kampania traci zasłużony ROAS.

Zasady inżynierii danych dla architektury Server-Side:
  • Dedykowany kontener Server-Side GTM: Środowisko serwerowe pośredniczące w przesyłaniu danych pomiędzy sklepem a serwerami Google i Meta.
  • Własna subdomena first-party: Konfiguracja endpointu we własnej domenie (np. data.twojsklep.pl), która omija filtry blokujące domeny firm trzecich.
  • Wydłużona retencja ciasteczek: Utrzymanie identyfikatorów sesji i atrybucji na urządzeniach z systemem iOS przez tygodnie, a nie godziny.
Wdrożenie Server Side GTM dla e-commerce
Analiza wdrożenia PUSH w Google Tag Manager: Konfiguracja serwerowego kontenera sGTM v2 wdrożonego dla marki e-commerce. Czerwona ramka wyodrębnia dedykowane środowisko Server-Side instrumentation, chroniące atrybucję przed blokadami adblockerów i ograniczeniami Safari ITP.
05
BŁĄD #5: CHAOS W DATA LAYERZE

Warstwa danych: Standaryzacja parametrów i separacja wartości

Gdy warstwa danych (Data Layer) sklepu jest wdrożona niedbale, zdarzenie purchase często przesyła do GA4 wartości brutto z wliczonym kosztem dostawy, podczas gdy panel Google Ads kalkuluje koszty w wartościach netto. Taki rozdźwięk powoduje, że sztucznie zawyżona marżowość pojedynczego zamówienia zaciemnia rzeczywistą rentowność działań mediowych.

Zasady inżynierii danych dla warstwy Data Layer:
  • Struktura JSON zgodna ze standardem GA4: Precyzyjne zadeklarowanie obiektu zdarzenia zakupu z rozbiciem na parametry klienta i transakcji.
  • Przygotowanie pod haszowanie: Bezpieczne przekazywanie danych kontaktowych (np. customerBillingEmailHash) pod kątem rozszerzonych konwersji.
  • Spójność walutowa i podatkowa: Ścisłe rozgraniczenie wartości netto towaru od podatków i spedycji w parametrach analitycznych.
Warstwa danych dataLayer dla zdarzenia purchase
Analiza wdrożenia PUSH w Tag Assistancie: Obiekt Data Layer zdarzenia purchase na podstronie kasy. Czerwona ramka akcentuje czystą strukturę parametrów transakcyjnych oraz zahaszowane dane użytkownika przygotowane do zasilenia algorytmów reklamowych.
06
BŁĄD #6: BRAK ENHANCED CONVERSIONS

Rozszerzone konwersje w Google Ads: Domykanie atrybucji cross-device

W erze wygaszania ciasteczek stron trzecich (3rd party cookies), standardowy piksel Google Ads traci możliwość połączenia użytkownika, który kliknął reklamę w smartfonie, z późniejszym zakupem sfinalizowanym na laptopie. Brak aktywacji Enhanced Conversions skutkuje trwałym niedoraportowaniem sprzedaży w panelu Google Ads o 8–15%, co sztucznie zaniża kalkulowany ROAS.

Zasady inżynierii danych dla Enhanced Conversions:
  • Aktywacja konwersji rozszerzonych w panelu: Formalne włączenie modułu z akceptacją warunków przetwarzania danych klienta.
  • Jednokierunkowe haszowanie SHA-256: Bezpieczne szyfrowanie adresów e-mail i numerów telefonów przed wysyłką do serwerów Google.
  • Domykanie ścieżek wielourządzeniowych: Zasilenie algorytmów Smart Bidding pełnymi danymi o powracających konsumentach.
Konfiguracja konwersji rozszerzonych w panelu Google Ads
Analiza wdrożenia PUSH w Google Ads: Globalna aktywacja modułu konwersji rozszerzonych z wykorzystaniem tagu Google. Czerwona ramka wskazuje prawidłowo włączoną metodę przekazywania danych, która stabilizuje algorytmy licytujące i odzyskuje utracone atrybucje.

Czy Twoje kampanie optymalizują się na prawdziwych danych?

Skalowanie budżetów reklamowych na dziurawej analityce to najprostszy sposób na przepalenie budżetu operacyjnego. Zanim zwiększysz stawki w Adsach, uszczelnij fundament pomiarowy.

Kontakt

Porozmawiajmy o współpracy

Wypełnij formularz. Dawid, Główny Architekt PUSH, przeanalizuje Twój sklep i skontaktuje się z Tobą w ciągu 24 godzin z konkretnym planem działania.

„Zamiast szukać przypadkowych freelancerów do każdej usterki, oddaliśmy im pełną kontrolę nad technologią i kampaniami. Sklep w końcu działa bezawaryjnie, koszty pozyskania klienta drastycznie spadły, a my możemy skupić się wyłącznie na logistyce i realizacji zamówień.”

Martyna - współzałożycielka Rolexpress.pl