Pomiar konwersji w e-commerce: dlaczego dane się nie zgadzają i jak to naprawić

Sierpień. W panelu sklepu 1 043 zamówienia. W GA4 812. Meta Ads mówi, że dowiozła 640 zakupów, Google Ads liczy 410. Suma z paneli reklamowych to 1 862 zamówienia, czyli o 819 więcej, niż faktycznie sprzedałeś. Żaden z tych systemów nie kłamie. Każdy liczy coś innego, w innym oknie czasowym i na innej próbce użytkowników.

Problem zaczyna się wtedy, gdy na podstawie tych liczb podejmujesz decyzje budżetowe. Wyłączasz kampanię, która “nie dowozi”, bo GA4 nie widzi jej konwersji. Skalujesz kampanię z ROAS 8, który w rzeczywistości wynosi 3. Ten tekst wyjaśnia, skąd biorą się różnice, jak sprawdzić, gdzie dokładnie gubisz dane, i co trzeba zrobić, żeby liczby zaczęły się spinać.

Pięciominutowa diagnoza: co dokładnie się nie zgadza

Zanim zaczniesz cokolwiek naprawiać, ustal, z którym problemem masz do czynienia. To trzy różne awarie, które wymagają trzech różnych działań.

Praktyczny próg, którego używamy w audytach: różnica do 3% między GA4 a panelem sklepu to szum, z którym da się żyć. 3 do 10% to konfiguracja do poprawy. Powyżej 10% to błąd wdrożenia, a powyżej 25% coś jest po prostu zepsute i nie wolno na tych danych optymalizować kampanii.

Dlaczego GA4 pokazuje mniej zamówień niż panel sklepu

Kolejność jest tu ważna, bo przyczyny mają bardzo różną wagę. Wypisujemy je od tych, które w polskich sklepach zabierają najwięcej danych.

1. Zgody na cookies. Jeśli użytkownik nie kliknie “akceptuję”, a Ty nie masz wdrożonego Consent Mode v2, tag GA4 w ogóle się nie odpala. Nie ma zdarzenia, nie ma zamówienia w raporcie. To zwykle największa dziura, bo dotyczy każdego kanału, nie tylko płatnych.

2. Blokery reklam i przeglądarki dbające o prywatność. uBlock Origin, AdGuard, Brave, Firefox z ETP. Zależnie od branży blokuje się od kilku do kilkudziesięciu procent ruchu. W sklepach z asortymentem technologicznym potrafi to być ponad 20%, w branży beauty zwykle poniżej 10%. Blokowany jest zarówno gtm.js, jak i endpointy zbierające dane.

3. Powrót z bramki płatniczej. Użytkownik płaci przez BLIK w aplikacji banku, a potem zamyka kartę i nie wraca na stronę podziękowania. Zamówienie w sklepie jest, zdarzenia purchase nie ma, bo nikt nie załadował strony, która je wysyła. Do tego dochodzi utrata sesji przy przekierowaniu na domenę operatora płatności, jeśli nie masz skonfigurowanego pomiaru między domenami. To typowo 5 do 15% transakcji i najczęściej niedoceniana przyczyna.

4. Checkout Shopify. Po przejściu na Checkout Extensibility Google Tag Manager nie ma dostępu do kroku zakupowego. Kod trzeba wpiąć przez Zdarzenia klienta (Customer Events), a podgląd GTM tam nie działa. Przy pobieżnym wdrożeniu purchase odpala się tylko dla części zamówień. Opisaliśmy to szerzej we wpisie o Checkout Extensibility i problemach z raportowaniem konwersji.

5. Zamówienia, których w przeglądarce nigdy nie było. Telefon, e-mail, panel administratora, marketplace, odnowienia subskrypcji. GA4 nie ma jak ich zobaczyć, bo nie ma sesji użytkownika. W sklepach subskrypcyjnych to potrafi być większość przychodu i wtedy porównywanie GA4 do panelu sklepu bez tego filtra nie ma sensu.

6. Techniczne drobiazgi, które sumują się do kilku procent. Błąd JavaScript na stronie podziękowania blokujący dalsze skrypty, użytkownik zamykający kartę zanim tag zdąży wysłać dane, wewnętrzne filtry ruchu w GA4, inna strefa czasowa usługi GA4 niż sklepu (przy porównaniu dzień do dnia potrafi to przesunąć 1 do 3% zamówień na sąsiednią dobę), zwroty i anulacje odejmowane w sklepie, a nieodejmowane w GA4.

Ważne: w interfejsie GA4 zobaczysz mniej niż w eksporcie do BigQuery, bo raporty standardowe podlegają progom prywatności i próbkowaniu. U jednego z naszych klientów e-commerce pokrycie zamówień wynosiło 95,8% w eksporcie BigQuery i 91,4% w tym samym okresie w interfejsie GA4. To ta sama implementacja i te same dane, różni się tylko sposób raportowania.

Dlaczego GA4 pokazuje inne przychody niż Shopify

Tu liczba zamówień może się zgadzać co do sztuki, a przychód i tak będzie inny. Powodów jest zwykle kilka naraz.

• VAT. Sklep raportuje netto, tag wysyła brutto (albo odwrotnie). Przy stawce 23% to od razu rozjazd rzędu 18,7% w dół albo 23% w górę. Uwaga na sklepy z mieszanymi stawkami, na przykład suplementy z 8% obok kosmetyków z 23%.
• Wysyłka. Standard Google Analytics mówi, że value w zdarzeniu purchase to wartość zamówienia razem z wysyłką i podatkiem. Panel sklepu często pokazuje “sprzedaż produktów” bez wysyłki. Różnica rośnie przy niskim koszyku.
• Rabaty. Rabaty naliczane na poziomie zamówienia i rabaty na poziomie pozycji to dwa różne pola. Jeżeli tag czyta cenę katalogową pozycji, a nie cenę po rabacie, przychód w GA4 będzie zawyżony dokładnie o wartość kodów rabatowych.
• Waluta. Sklep wielowalutowy bez przekazanego pola currency powoduje, że GA4 traktuje wszystko jako walutę domyślną usługi. Sprzedaż za 100 EUR ląduje w raporcie jako 100 PLN.
• Zwroty. Jeśli nie wysyłasz zdarzenia refund, GA4 nigdy nie odejmie zwróconych zamówień, a panel sklepu odejmie.

Naprawa zaczyna się od decyzji biznesowej, nie technicznej: ustalasz jedną definicję przychodu (na przykład netto, po rabatach, bez wysyłki), zapisujesz ją i wymuszasz w każdym systemie. Dopiero potem poprawia się dataLayer.

Dlaczego Meta Ads raportuje więcej konwersji niż Google Analytics

To pytanie wraca w co drugim audycie i prawie zawsze odpowiedź brzmi tak samo: oba systemy mierzą co innego.

Konsekwencje są konkretne. Meta zaliczy sobie zakup osoby, która obejrzała reklamę na Instagramie, nic nie kliknęła, a dzień później weszła z wyszukiwarki i kupiła. GA4 przypisze tę sprzedaż do Google. Meta pokaże konwersję w dniu kliknięcia, więc kampania z 20 sierpnia “dostanie” sprzedaż z 26 sierpnia i raport dzienny nigdy nie zgodzi się ze sklepem. Do tego dochodzi Conversions API: jeżeli piksel i CAPI wysyłają to samo zdarzenie bez wspólnego event_id, Meta policzy je dwa razy.

Zasada praktyczna: nie porównuj konwersji Meta z konwersjami GA4, bo to dwie różne definicje. Porównuj sumę wszystkich kanałów do rzeczywistej sprzedaży w sklepie i patrz na wskaźnik blended, czyli przychód całkowity podzielony przez całkowity wydatek reklamowy. Rozwinięcie metryk znajdziesz w słowniczku ROAS, CPA, CAC i LTV.

Dlaczego w Google Ads brakuje konwersji

Google Ads też ma własną logikę i własne pułapki.

• Data kliknięcia, nie data konwersji. Google domyślnie pokazuje konwersje w dniu kliknięcia. Jeśli patrzysz na wczoraj, brakuje Ci wszystkich transakcji, które dopiero się wydarzą. Przy dłuższym procesie zakupowym raport “dojrzewa” jeszcze przez tydzień lub dwa.
• Okno konwersji. Domyślnie 30 dni, można ustawić do 90. Krótsze okno to mniej konwersji w raporcie, ale też szybsza informacja zwrotna dla algorytmu.
• Brak gclid. Bez automatycznego tagowania albo przy przekierowaniu, które gubi parametry z adresu, Google nie ma jak dopiąć kliknięcia do transakcji. Klasyk: przekierowanie z www na wersję bez www, które ucina query string.
• Ustawienie “każda” kontra “jedna”. Dla zakupu powinno być “jedna” konwersja na kliknięcie. Przy “każdej” jedno zamówienie potrafi się rozmnożyć.
• Kilka akcji konwersji liczonych naraz. Jeżeli w kolumnie “Konwersje” masz jednocześnie zakup, dodanie do koszyka i zaangażowanie użytkownika, ROAS w tym raporcie nie znaczy nic. Do rozliczenia powinien wchodzić wyłącznie zakup.
• Konwersje modelowane. Przy Consent Mode część konwersji Google modeluje statystycznie. To liczby prawdziwe w sensie estymacji, ale nie znajdziesz ich pojedynczo w bazie sklepu.
• Import z GA4 zamiast pomiaru własnego. Konwersje importowane mają inne okno, inne modelowanie i docierają z opóźnieniem. Do licytacji lepiej działa własna akcja konwersji, najlepiej wysyłana serwerowo.

Która liczba konwersji jest prawdziwa

Żadna z tych z paneli reklamowych. Prawdziwa jest liczba zamówień w systemie transakcyjnym: w sklepie, w ERP, w bazie. Panele nie mierzą sprzedaży, tylko swój udział w sprzedaży, i robią to według własnych reguł.

Dlatego przy pracy z klientami rozdzielamy trzy poziomy i nigdy ich nie mieszamy:

Systemy reklamowe mają dostawać jak najwięcej i jak najdokładniejsze sygnały, bo to poprawia algorytmy. Ale ich raport nigdy nie będzie raportem finansowym i nie ma sensu tego wymuszać.

Zdublowane transakcje: kiedy jedno zamówienie liczy się dwa razy

Jeśli GA4 ma więcej zamówień niż sklep, przyczyna prawie zawsze jest na tej liście:

1. Dwa kontenery GTM albo GTM plus gtag wpięte równolegle, na przykład z motywu i z aplikacji.
2. Odświeżenie strony podziękowania. Użytkownik wciska F5 albo wraca do zakładki, purchase leci ponownie. GA4 nie deduplikuje transaction_id automatycznie w raportach.
3. Aplikacja sklepowa dokładająca własny piksel obok Twojego. Częste w Shopify (Google & YouTube, aplikacje marketingowe) i w WooCommerce (wtyczki typu “Facebook for WooCommerce” obok tagów w GTM).
4. SPA i checkout jednostronicowy, gdzie zdarzenie odpala się przy każdym przerenderowaniu widoku.
5. Reguła uruchamiania oparta o fragment adresu, na przykład “URL zawiera thank-you”, która łapie także powroty do zamówienia z maila lub z historii.
6. Piksel i Conversions API bez wspólnego event_id. Meta ma wtedy dwa niezależne zdarzenia i liczy oba.
7. Brak transaction_id w ogóle. Bez identyfikatora żaden system nie ma jak stwierdzić, że to ta sama transakcja.

Naprawa jest prosta koncepcyjnie: jedno zamówienie, jeden identyfikator, jedno wysłanie. Technicznie oznacza to zawsze wysyłany transaction_id równy numerowi zamówienia, blokadę powtórnego wysłania (znacznik w localStorage albo w ciasteczku po stronie serwera), wspólny event_id dla pary piksel plus CAPI i regułę uruchamiania, która odpala się raz na transakcję, a nie raz na wyświetlenie strony.

Piksel nie rejestruje zakupów, purchase nie wysyła się w GTM

Diagnozę robi się od dołu, warstwa po warstwie. Na którym punkcie się zatrzymasz, tam jest awaria.

1. Czy zdarzenie w ogóle jest w dataLayer? Wpisz dataLayer w konsoli przeglądarki na stronie podziękowania i poszukaj obiektu z event: "purchase". Jeśli go nie ma, problem jest po stronie sklepu, nie GTM.
2. Czy dataLayer.push nie leci przed kontenerem? Jeżeli sklep wysyła zdarzenie zanim GTM się załaduje, reguła uruchamiania go nie zobaczy. Kolejność ma znaczenie.
3. Czy reguła łapie zdarzenie? Tryb podglądu GTM, zakładka Tags, sprawdzasz czy tag jest w “Tags Fired”.
4. Czy zmienne mają wartości? Najczęstszy błąd to value jako tekst z przecinkiem dziesiętnym (“129,00”) zamiast liczby (129.00) i brak currency.
5. Czy tag nie jest blokowany przez zgody? W trybie podglądu GTM zakładka Consent pokazuje, czy tag został wstrzymany przez brak zgody.
6. Czy żądanie faktycznie wychodzi? W karcie Network filtr collect dla GA4, /tr? dla piksela Meta, google.com/pagead dla Google Ads. Brak żądania przy odpalonym tagu to najczęściej bloker w przeglądarce.
7. Czy dane docierają? GA4 DebugView, Meta Events Manager i zakładka Test Events, w Google Ads diagnostyka akcji konwersji.

Jeśli wszystko działa u Ciebie, a danych nadal brakuje, znaczy że gubisz je u części użytkowników. Wtedy przechodzi się na pomiar serwerowy, bo w przeglądarce nie ma już czego naprawiać.

Ile danych naprawdę tracisz: zgody, blokery, iOS i ITP

Trzy niezależne straty, które się mnożą, a nie dodają.

Zgody. W Europie odsetek odmów potrafi sięgać 60 do 70%, a w polskich sklepach częściej widzimy 20 do 40%, zależnie od tego, jak zaprojektowany jest baner. Bez Consent Mode v2 każda odmowa to zdarzenie, które nie powstaje. Z Consent Mode v2 w wersji Advanced dostajesz przynajmniej sygnały bez ciasteczek i modelowanie konwersji.

Blokery. Od kilku do ponad 20% ruchu, zależnie od branży i grupy docelowej. Blokada dotyczy skryptu i domeny zbierającej dane, więc traci się całe sesje, nie pojedyncze zdarzenia.

ITP i ograniczenia przeglądarek. Safari kasuje ciasteczka ustawiane w JavaScript po 7 dniach, a w niektórych scenariuszach po 24 godzinach. Skutek: użytkownik, który wrócił po dwóch tygodniach, jest nowym użytkownikiem, atrybucja się rozjeżdża, listy remarketingowe topnieją, a Twoje okno konwersji jest w praktyce krótsze niż to ustawione w panelu.

Te straty nakładają się na siebie. Sklep z 30% odmów zgód, 15% blokerów i dużym udziałem ruchu z iOS realnie widzi około połowy tego, co się dzieje. Nie da się tego naprawić jednym przełącznikiem, ale każdą z warstw da się odzyskać częściowo.

Jak sprawdzić, czy tracking działa poprawnie

Trzy kroki, każdy do zrobienia bez programisty.

Krok 1: jedno zamówienie testowe. Wejdź z reklamy, dodaj produkt, zapłać prawdziwą metodą płatności i przejdź do strony podziękowania. Potem sprawdź, czy to zamówienie widać w GA4 (DebugView albo raport w czasie rzeczywistym), w Meta (zdarzenia testowe) i w Google Ads (diagnostyka akcji konwersji). Zwróć uwagę, czy zakup pojawia się raz, a nie dwa razy, i czy ma poprawną wartość oraz walutę.

Krok 2: porównanie pełnego miesiąca. Weź liczbę zamówień z panelu sklepu i liczbę transakcji z GA4 za ten sam miesiąc. Od liczby ze sklepu odejmij zamówienia, które nigdy nie przeszły przez przeglądarkę: telefoniczne, z panelu administratora, odnowienia subskrypcji. Podziel jedno przez drugie i masz swoje pokrycie w procentach. Przychód porównuj w jednej definicji: netto do netto, z wysyłką albo bez, zawsze po rabatach.

Krok 3: dwa wskaźniki jakości. Sprawdź Event Match Quality w Meta (skala 0 do 10) i status Enhanced Conversions w Google Ads. To najszybszy sygnał, jak dobre dane dostają dziś Twoje kampanie. Przy okazji zobacz w GA4 udział źródła “(direct) / (none)”. Jeśli przekracza 20 do 25% przychodu, prawdopodobnie gubisz parametry na przekierowaniach albo na bramce płatności.

Jeżeli po tych trzech krokach wychodzi różnica większa niż 10%, dalej nie ma sensu zgadywać. Trzeba zejść warstwa po warstwie i sprawdzić, gdzie znika sygnał.

Jak naprawia się pomiar: sześć warstw

Kolejność nie jest przypadkowa. Wdrażanie warstwy piątej bez pierwszej to najdroższy sposób na zebranie tych samych złych danych, tylko szybciej.

Warstwa 1. Definicje. Co liczymy jako konwersję, jaki przychód raportujemy, jak traktujemy zwroty i subskrypcje. Jedna kartka, do której odwołują się wszyscy.

Warstwa 2. dataLayer i zdarzenia. Pełny schemat e-commerce: view_item, add_to_cart, begin_checkout, add_payment_info, purchase, z transaction_id, value, currency, items i identyfikatorami zgodnymi z feedem produktowym. To fundament, na którym stoi wszystko inne, łącznie z remarketingiem dynamicznym.

Warstwa 3. Zgody. CMP plus Consent Mode v2 w wersji Advanced, poprawnie przekazujący ad_storage, analytics_storage, ad_user_data i ad_personalization. Szczegóły opisaliśmy w poradniku Consent Mode v2.

Warstwa 4. Warstwa serwerowa. Server side GTM na własnej subdomenie, ciasteczka first party ustawiane przez serwer, zdarzenia wysyłane z serwera do GA4, Google Ads, Meta i TikToka. To tu odzyskuje się większość strat z blokerów i z ITP.

Warstwa 5. Wzbogacanie danych. Enhanced Conversions w Google Ads, Conversions API w Meta z deduplikacją, dane z backendu sklepu (potwierdzone zamówienie, marża, status subskrypcji, wartość klienta), konwersje offline.

Warstwa 6. Weryfikacja i monitoring. Cykliczne porównanie sklep kontra GA4 kontra panele, alert gdy pokrycie spada poniżej progu, raport, który ktoś naprawdę czyta. Bez tego pomiar psuje się po cichu przy pierwszej aktualizacji szablonu sklepu.