Śledzenie konwersji w WooCommerce — dlaczego się psuje i jak je sprawdzić

Dlaczego WooCommerce zaniża konwersje

Sprawdź poniższe miejsca awarii. Dotyczą różnych elementów systemu, więc przeniesienie jednego żądania na serwer nie rozwiąże ich wszystkich.

• Piksel jest zablokowany. Blokery treści i ochrona przed śledzeniem w Safari oraz

Firefoksie zatrzymują żądanie, zanim wyjdzie. Zamówienie dochodzi do skutku, zdarzenie nie.

• Strona podziękowania zostaje pominięta. Bramki płatnicze, które wracają na sklep

asynchronicznie, albo klienci zamykający kartę zaraz po potwierdzeniu z banku, nigdy nie wczytują strony, na której siedzi skrypt konwersji. Zamówienie i tak jest w twojej bazie.

• Wtyczka zepsuła zdarzenie. Checkout WooCommerce to powierzchnia dla wtyczek. Cokolwiek

dotyka procesu zamówienia, może zablokować skrypt albo zmienić DOM, z którego on czyta — i nic cię o tym nie ostrzeże.

• Blokowy checkout to nie klasyczny checkout. Trackery napisane pod

woocommerce_checkout_create_order odpalają się w klasycznym procesie i po cichu nie odpalają w blokowym, a ten jest już domyślny w nowych instalacjach.

• Ustawienia zgody ograniczają zbieranie danych. Sprawdź zaakceptowane kategorie i reakcję każdego tagu. Prawidłowo zablokowane zdarzenie reklamowe nie jest awarią pomiaru.

Przetestuj wdrożenie przed wyborem poprawki. Ograniczenia przeglądarki, hooki checkoutu i reguły zgody wymagają osobnych kontroli.

Jak rozpoznać, który przypadek masz

Użyj checkoutu testowego albo transakcji testowych w istniejącym procesie. Nie przełączaj checkoutu działającego sklepu tylko po to, żeby porównać liczniki.

1. Zdefiniuj zbiór zamówień. Ustal zamknięte okno obserwacji, strefę czasową oraz sposób rozliczania płatności i zwrotów. Statusy processing i completed pomagają filtrować, ale niestandardowe bramki i refundacje wymagają uzgodnienia.
2. Sprawdź odebrane zdarzenia zakupu. Porównaj zdarzenia przeglądarkowe i serwerowe, identyfikatory zamówień i zdarzeń, czas oraz deduplikację. Odbiór w Events Managerze nie jest atrybucją reklamową.
3. Osobno porównaj zakupy przypisane reklamom. Dopasuj daty raportowania, okna atrybucji i definicje konwersji, zanim zinterpretujesz różnicę.

To kierunki diagnostyki, nie jednoznaczne rozpoznania. Odtwórz ścieżkę testowym zamówieniem i śledź jego identyfikator od sklepu do odbiorców danych. Dokumentacja WooCommerce wskazuje hooki klasycznego checkoutu nieobsługiwane przez Blocks.

Co naprawdę naprawia przeniesienie zapisu na serwer

W lokalnym kodzie wtyczki sprawdzonym 24 września 2026 zapis wejścia działa na hooku template_redirect z priorytetem 5. To przechwycenie wizyty, nie potwierdzenie płatności. Cookie loyalz_tp mieści najwyżej 20 punktów kontaktu z limitem retencji 90 dni. Ma HttpOnly i SameSite=Lax, a flaga Secure zależy od HTTPS. Przegląd kodu nie potwierdza konfiguracji każdego wdrożonego sklepu.

W każdym punkcie styku zapisujemy id reklamy, pięć parametrów utm i cztery identyfikatory kliknięcia gclid, fbclid, ttclid i msclkid, a do tego referrer, adres wejścia i znacznik czasu ISO-8601 w UTC.

Wizyta bez żadnego z nich nie jest odrzucana. derive_channel() klasyfikuje ją po referrerze jako direct, organic albo referral, więc te kanały widać w ścieżce, zamiast żeby były niewidoczne — i zwraca null dla referrerów z tej samej domeny, żeby nawigacja wewnątrz sklepu nie tworzyła punktu styku przy każdej odsłonie.

Wtyczka przypina ścieżkę do zamówienia przez woocommerce_checkout_create_order w klasycznym checkoucie i woocommerce_store_api_checkout_order_processed w Blocks. Przetestuj ścieżki używane przez sklep. Sam hook przetwarzania zamówienia nie potwierdza zapłaty; raport zakupu musi stosować uzgodnione reguły statusu płatności.

Luka pierwszej wizyty związana z momentem zgody

Nawet przy poprawnych hookach serwerowych może wystąpić luka czasowa przy pierwszej wizycie.

Przy pierwszej wizycie z reklamy ciasteczko zgody jeszcze nie istnieje. Baner nie został jeszcze obsłużony. Zapis po stronie serwera wykonuje się na template_redirect, sprawdza zgodę, nie znajduje jej i słusznie odpuszcza — a zanim odwiedzający zaakceptuje, żądanie niosące parametry utm jest już zakończone.

Bez kolejnego zapisu po akceptacji początkowe parametry kampanii mogą zniknąć po opuszczeniu strony wejścia.

Po akceptacji zgody skrypt w przeglądarce może wysłać parametry wejścia do endpointu, który ponownie sprawdza zgodę. W sprawdzonej wtyczce służy do tego loyalz_tp_capture. Przetestuj akceptację na stronie wejścia, przejście dalej przed akceptacją i wycofanie zgody. Cache lub błąd skryptu nadal może przerwać zapis.

Czego to wszystko nie naprawia

Wysyłka serwerowa nie znosi obowiązków dotyczących zgód ani nie dowodzi, że każde zamówienie pochodzi z reklamy. Domyślna bramka zapisu wtyczki odczytuje zgodę reklamową CookieYes; konfigurowalne źródła zgód i ścieżka zapisu na newsletter wymagają osobnej kontroli.

Operacyjny zapis zamówienia i reklamowy punkt kontaktu służą różnym celom. Google rozróżnia też podstawowy i zaawansowany Consent Mode. Sprawdź poradnik o zgodach , zanim uznasz każdą różnicę za usterkę pomiaru.

Sprawdzona ścieżka w cookie ma limit 20 wpisów i 90 dni. Usunięcie danych przeglądarki, zmiana urządzenia i brak zgody mogą skrócić zaobserwowaną historię. Nie traktuj jej jako kompletnego zapisu zachowania klienta.

Dalsze wskazówki opisują analityka WooCommerce, pomiar reklam i pomiar pozyskania klientów w Loyalz.

Częste pytania