SXO po migracji sklepu: co GA4 mówi o konwersji w pierwszych 90 dniach

Nowy sklep poszedł na produkcję, przekierowania siedzą jak trzeba, ruch organiczny po kilku tygodniach wrócił do poziomu sprzed migracji, a sprzedaż nie. To jeden z najczęstszych obrazów po re-architekturze e-commerce i jednocześnie moment, w którym najłatwiej wyciągnąć fałszywy wniosek. Pokażę Ci, jak w GA4 odróżnić realny spadek konwersji od zepsutego pomiaru, gdzie w nowej ścieżce zakupowej użytkownicy gubią się najczęściej i co robić w pierwszych 90 dniach po wdrożeniu, zanim ktoś rzuci hasło „wracamy na starą platformę”.

Ruch wrócił, koszyk pusty – dlaczego to typowy obraz

Migracja sklepu ma w branży swoją własną mitologię i sprowadza się ona zwykle do jednego pytania: „czy nie stracimy widoczności?”. To dobre pytanie, tylko niepełne. Przekierowania, struktura URL-i, mapa witryny, dane strukturalne – to wszystko pilnuje, żeby Google nadal wiedziało, gdzie co jest. Ale widoczność to dopiero wejście. SXO zaczyna się w miejscu, w którym klasyczne SEO kończy: kiedy użytkownik już jest na stronie.

I właśnie tam po migracji dzieje się najwięcej.

Zacznijmy od punktu odniesienia. Średni współczynnik porzuceń koszyka to 70,22% – wartość z meta-analizy Baymard Institute obejmującej około 50 niezależnych badań. Warto zwrócić uwagę na dwie rzeczy. Po pierwsze, ta liczba nie drgnęła znacząco od ponad dekady, mimo lawiny „rewolucji w checkoucie”. Po drugie i to jest moja mała prywata analityka: ogromna część „statystyk 2026″ krążących po branżowych blogach to dokładnie ta sama meta-analiza Baymarda, przepisana kilkanaście razy w kółko. Kiedy widzisz gdzieś okrągłe „7 na 10 koszyków”, to najczęściej to samo źródło w nowym opakowaniu. Dobrze o tym wiedzieć, zanim zbudujesz na tym prezentację dla zarządu.

Baymard mierzy tu porzucenia wśród osób, które dodały coś do koszyka czyli po odfiltrowaniu czystego przeglądania. To ważne rozróżnienie, bo zaraz będzie kluczowe przy czytaniu lejka.

Orientacyjne benchmarki współczynnika konwersji w polskim e-commerce mieszczą się zwykle w szerokim przedziale 1–3%, jednak wartość silnie zależy od branży, ceny produktu, źródła ruchu, urządzenia i modelu sprzedaży. Shoper wskazuje m.in. 1,5–3% dla mody, 0,5–1,5% dla elektroniki oraz 2–5% dla żywności i napojów. Shopify przytacza szerszy punkt odniesienia na poziomie około 2,5–3%, jednocześnie pokazując, że średnia dla sklepów Shopify wynosiła 1,4%. Dlatego po migracji najważniejsze jest porównanie z własnym sklepem sprzed wdrożenia, przy zachowaniu tego samego miksu źródeł ruchu, urządzeń i sezonu.

Niezależne dane na temat typowej skali spadku konwersji po replatformingu są ograniczone. Materiały Noibu wskazują jednak, że największe ryzyko występuje w pierwszych 4–12 tygodniach po wdrożeniu, gdy ujawniają się ciche regresje w checkoutcie, integracjach, wydajności i ścieżkach zakupowych. Firma podaje m.in. przykład 6-procentowego spadku konwersji na etapie karta produktu -> koszyk, który pojawił się dwa dni po cutoverze. Należy traktować te dane jako obserwacje dostawcy narzędzia monitoringowego, a nie niezależny benchmark rynku.

I tu dochodzimy do sedna. Skoro spadek po wdrożeniu jest spodziewany, to najważniejsze pytanie nie brzmi „czy spadło”, tylko: czy spadło naprawdę, czy tylko w danych?

Częsty błąd: mylenie odzyskanej widoczności z odzyskaną sprzedażą Search Console pokazuje, że kliknięcia wróciły, więc migracja „się udała”. Tyle że Search Console kończy swoją opowieść na kliknięciu. Wszystko, co dzieje się potem: czy karta produktu ładuje się w 1,8 czy 4,5 sekundy, czy przycisk „Do koszyka” reaguje od razu, czy koszt dostawy pojawia się na pierwszym czy trzecim kroku jest poza jej zasięgiem. Dwa różne narzędzia, dwa różne pytania. Nie zastępuj jednego drugim.

Krok zero: sprawdź, czy nie mierzysz źle

Zanim zwołasz warsztat o UX, zrób rzecz mniej efektowną: zweryfikuj pomiar. To nudne i regularnie ratuje tygodnie pracy przy nieistniejącym problemie.

Punktem wyjścia jest porównanie zamówień w GA4 z zamówieniami w backendzie sklepu (albo w bramce płatniczej). Rozjazd rzędu 5–15% przy pomiarze po stronie przeglądarki jest w praktyce normą – biorą się na to blokery reklam, odmowy zgód i porzucone przekierowania. Rozjazd powyżej 20% to już sygnał, że coś jest konkretnie zepsute, a nie „takie życie”. To pierwsza liczba, którą powinieneś znać, zanim spojrzysz na cokolwiek innego.

Ważne, żeby ten rozjazd znać sprzed migracji. Jeśli stara konfiguracja gubiła 8% transakcji, a nowa gubi 25%, to Twoja „utrata konwersji o 17%” nigdy się nie wydarzyła w sklepie – wydarzyła się w Google Analytics.

Siedem rzeczy, które psują pomiar e-commerce po wdrożeniu

Lista rzeczy, które warto odhaczyć w pierwszej kolejności. Kolejność mniej więcej według tego, jak często się to zdarza:

1. Zdublowane źródła zdarzenia purchase. Nowe wdrożenie potrafi odziedziczyć stary hardkodowany skrypt z motywu, do tego dochodzi tag z Google Tag Managera, a czasem jeszcze wtyczka albo natywna integracja platformy. Zasada: jedno zdarzenie zakupu ma jednego właściciela, reszta milczy. Wypisz wszystkie ścieżki, które mogą wysłać purchase, i zostaw dokładnie jedną.
2. Brak lub zmiana transaction_id. GA4 deduplikuje transakcje właśnie po tym identyfikatorze. Jeśli parametr znika albo zmienia format przy migracji, dostajesz zawyżony przychód i lejek, który nie ma sensu. Objaw charakterystyczny: przychód w GA4 wyższy niż w backendzie.
3. Podwójne odpalenie na stronie podziękowania. Klasyk: klient odświeża „thank you page” albo wraca do niej z historii przeglądarki i zdarzenie leci drugi raz. Bez transaction_id nie masz jak tego wyłapać.
4. Zmienione nazwy zdarzeń. GA4 rozróżnia wielkość liter – Purchase to nie to samo co purchase. Nowa platforma potrafi wysyłać checkout_completed zamiast oczekiwanego zdarzenia albo odpalać je w innym momencie ścieżki niż stara. Efekt: zdarzenie leci, raporty e-commerce są puste.
5. Braki w parametrach. Zgubiony parametr waluty potrafi rozłożyć agregację przychodu, a błędnie zagnieżdżona tablica items po cichu wyłącza raporty produktowe — bez żadnego komunikatu o błędzie.
6. Consent Mode. To mój faworyt, bo psuje dane najbardziej podstępnie. Typowy wzorzec awarii: zdarzenia z góry lejka wyglądają normalnie, ale purchase znika lub przychodzi z opóźnieniem, bo narzędzie do zgód zmienia stan w trakcie checkoutu. Wygląda, jakby GA4 losowo gubiło przychód, a przyczyna leży w logice zgód, nie w pomiarze. Po migracji CMP jest prawie zawsze wdrażany od nowa – sprawdź go osobno.
7. Domeny w checkoucie. Jeśli nowa architektura wynosi płatność na zewnętrzną domenę, a konfiguracja cross-domain nie została przeniesiona, tracisz ciągłość sesji. Objaw: skokowy wzrost ruchu z „direct” i lejek urwany dokładnie na przejściu do płatności.

Narzędzia do tej weryfikacji są nudne i skuteczne: Tag Assistant do sprawdzenia, co i kiedy się odpala (i czy nie odpala się dwa razy), DebugView w GA4 do przejścia realnej ścieżki zakupowej krok po kroku, plus ręczne porównanie kilku konkretnych zamówień z backendem. Jedna uwaga, która potrafi zaboleć: GA4 nie pozwala wgrać zdarzeń e-commerce wstecz. Transakcja, która nie została zmierzona, jest stracona na zawsze. Dlatego ta weryfikacja jest zadaniem na pierwszy dzień po wdrożeniu, nie na trzeci tydzień, kiedy ktoś zauważy dziurę w raporcie.

Warto wiedzieć: raporty e-commerce w GA4 potrzebują czasu DebugView pokazuje zdarzenia w czasie rzeczywistym, ale standardowe raporty e-commerce stabilizują się z opóźnieniem. Jeśli dzień po wdrożeniu patrzysz na raport i widzisz zero to jeszcze o niczym nie świadczy. Weryfikuj na DebugView i danych z backendu, a raporty czytaj po kilkudziesięciu godzinach.

Jak czytać lejek w GA4 po migracji

Załóżmy, że pomiar jest czysty. Teraz można rozmawiać o zachowaniu użytkowników.

Standardowa ścieżka zakupowa w GA4 to sekwencja: view_item –> add_to_cart –> begin_checkout –> add_shipping_info –> add_payment_info -> purchase. Do tego dochodzą zdarzenia okołodrogowe, które przy analizie po migracji bywają cenniejsze niż sam lejek: view_item_list (czy listingi w ogóle się wyświetlają), select_item (czy ludzie klikają w produkty z nowych kart) i view_search_results (o tym za chwilę osobno).

Najważniejsza rzecz przy czytaniu lejka po wdrożeniu: nie interesuje Cię wartość bezwzględna, tylko to, który krok stracił najwięcej względem stanu sprzed migracji. Konwersja z 2,1% na 1,7% to informacja zerowa, która mówi, że coś jest nie tak, ale nie mówi gdzie. Natomiast przejście add_to_cart –> begin_checkout, które spadło z 48% na 31%, przy niezmienionych pozostałych krokach, wskazuje palcem na konkretny ekran.

W praktyce zbuduj to jako eksplorację ścieżki (funnel exploration) w GA4, z dwoma zakresami dat: 30 dni przed migracją i analogiczne 30 dni po. Analogiczne – nie „ostatnie 30 dni”, bo wtedy porównasz sierpień z lipcem i połowę różnicy wytłumaczy sezon, a nie Twój nowy checkout.

Segmentacja, bez której wnioski są nic niewarte

Zagregowany lejek dla całego sklepu prawie zawsze kłamie, bo uśrednia grupy, które zachowują się zupełnie inaczej. Minimum, które warto rozbić:

• Urządzenie. Mobile i desktop to dwa różne sklepy – do tego wrócę osobno, bo to najważniejszy podział na tej liście.
• Typ strony wejścia. Ruch wchodzący na karty produktowe zachowuje się inaczej niż ruch z listingów kategorii i inaczej niż ruch z bloga. Jeśli migracja zmieniła szablon tylko jednego z tych typów, zobaczysz to dopiero po rozbiciu.
• Źródło ruchu. Organic, direct, płatne i e-mail mają różną intencję. Spadek konwersji, który dotyczy wyłącznie ruchu organicznego, sugeruje coś innego (np. zmianę intencji trafiającego ruchu po przemapowaniu kategorii) niż spadek dotykający wszystkich kanałów równo.
• Nowi kontra powracający. To niedoceniany podział przy migracjach. Powracający klienci mieli w głowie mapę starego sklepu i nowa nawigacja bywa dla nich trudniejsza niż dla osoby, która widzi sklep pierwszy raz. Jeśli spadek koncentruje się u powracających to nie znaczy, że nowy UX jest zły, tylko że przyzwyczajenia kosztują. To dwie różne diagnozy i dwie różne reakcje.

I tutaj rzecz, którą powtarzam za każdym razem, bo naprawdę zmienia jakość wniosków: to, że dwie rzeczy zdarzyły się w tym samym tygodniu, nie znaczy, że jedna wynika z drugiej. Migracja, sezon urlopowy, zmiana budżetu w kampaniach, aktualizacja algorytmu, zmiana cennika dostawy u przewoźnika – to wszystko potrafi się nałożyć w tym samym oknie czasowym. Zanim ogłosisz, że „nowy checkout zabił konwersję”, sprawdź, co jeszcze zmieniło się w tym okresie. Jeśli spadek dotyczy wyłącznie jednego segmentu i jednego kroku lejka, masz mocną poszlakę. Jeśli wszystko spadło równomiernie o kilkanaście procent – szukałbym raczej przyczyny zewnętrznej albo, wracając do poprzedniej sekcji, błędu pomiaru.

Cztery miejsca, w których nowa ścieżka gubi użytkownika

Kiedy już wiesz, który krok się posypał, warto wiedzieć, czego tam szukać. To cztery obszary, w których re-architektura najczęściej wprowadza regresję, uszeregowane zgodnie z kolejnością na ścieżce zakupowej.

1. Karta produktu – LCP i to, co widać bez przewijania

Nowy szablon karty produktu to najczęstsze miejsce wprowadzenia cichej regresji. Nie dlatego, że jest brzydszy – zwykle jest ładniejszy. Dlatego, że przesuwa informacje.

Klasyczny scenariusz: w starym sklepie koszt i termin dostawy były widoczne obok ceny, w nowym wylądowały w zakładce niżej albo w rozwijanym panelu. Z perspektywy projektanta porządek. Z perspektywy użytkownika brak odpowiedzi na pytanie, które zadaje sobie przed dodaniem do koszyka. Efekt widać jako spadek przejścia view_item –> add_to_cart, choć nic się nie „zepsuło”.

Drugi wątek to wydajność. Google i Deloitte w badaniu „Milliseconds Make Millions” podali, że poprawa czasu ładowania o 0,1 sekundy przekładała się na wzrost konwersji w retailu o około 8%. To liczba z 2020 roku i jest w branży cytowana chyba częściej, niż na to zasługuje, ale kierunek potwierdzają nowsze przypadki z dokumentacji web.dev, jak Rakuten 24, gdzie osiągnięcie dobrych wyników Core Web Vitals szło w parze ze wzrostem konwersji o około 33% i przychodu na użytkownika o ponad 53%, czy Vodafone z 8% wzrostem sprzedaży po poprawie LCP o 31%.

Zwróć uwagę na sformułowanie „szło w parze”. To były testy A/B na dużym ruchu i wnioski są mocne, ale przenoszenie tych procentów na własny sklep jako prognozy jest nadużyciem. Traktuj je jako dowód, że zależność istnieje, nie jako kalkulator ROI.

Praktycznie: po migracji sprawdź LCP kart produktowych na danych polowych (raport Core Web Vitals w Search Console, CrUX), nie tylko w Lighthouse. Dane laboratoryjne po wdrożeniu wyglądają zwykle świetnie, bo testujesz z dobrego łącza na mocnym urządzeniu.

Więcej o Core Web Vitals napisał Wojtek Smolarek na swoim blogu.

2. Dodanie do koszyka – INP i brak informacji zwrotnej

To najbardziej niedoceniany punkt na całej liście, bo problem jest niewidoczny w klasycznych raportach.

INP zastąpił FID w marcu 2024 roku i zmienił obraz sytuacji. FID mierzył opóźnienie tylko pierwszej interakcji – próg, który przechodziła niemal każda strona. INP ocenia responsywność wszystkich interakcji w całym cyklu życia strony, w 75. percentylu realnych użytkowników. Efekt jest taki, że witryny, które komfortowo zdawały FID, przy INP wypadają dużo słabiej, a metryka mierzy dokładnie to, co dzieje się przy kliknięciu „Do koszyka” i przy przełączaniu filtrów.

Nowoczesne frontendy, szczególnie te zbudowane na cięższym JavaScripcie potrafią tu regresować mimo świetnego LCP. Użytkownik klika, nic się nie dzieje przez 400 milisekund, klika drugi raz. Czasem dostaje dwie sztuki w koszyku, czasem nic. Nikt tego nie zgłosi jako błąd, bo z technicznego punktu widzenia błędu nie ma.

W GA4 tego nie zobaczysz. Zobaczysz to w nagraniach sesji i w mapach kliknięć Microsoft Clarity czy Hotjar wyłapują tzw. rage clicks (serie szybkich kliknięć w to samo miejsce), które są najlepszym dostępnym wskaźnikiem frustracji. Po każdej migracji warto włączyć nagrania na pierwsze dwa–trzy tygodnie, choćby tylko po to, żeby obejrzeć dwadzieścia sesji zakończonych porzuceniem koszyka. To godzina pracy, która potrafi dać więcej niż tydzień grzebania w raportach.

3. Koszyk i checkout – koszty, rejestracja, długość formularza

Tu mamy najlepsze dostępne dane, choć z zastrzeżeniem, że zostały zebrane na podstawie ankietowanych w USA. W ankiecie Baymard Institute z 2026 roku wśród osób, które porzuciły koszyk z innego powodu niż zwykłe przeglądanie, dominowały trzy przyczyny:

Powód porzucenia	Odsetek wskazań
Dodatkowe koszty przy kasie (dostawa, podatki, opłaty)	40%
Wymuszone założenie konta	18%
Zbyt długi lub skomplikowany checkout	17%

Zastrzeżenie jest istotne: to rynek amerykański. Polska ma inny miks płatności (BLIK, szybkie przelewy) i inny model dostawy (paczkomaty jako domyślny wybór, nie opcja premium), więc rozkład u nas będzie inny. Ale hierarchia – najpierw zaskoczenie kosztem, potem przymus rejestracji, potem długość procesu jest na tyle uniwersalna, że traktuję ją jako punkt startowy przy każdym audycie checkoutu.

Baymard szacuje przy tym, że sama poprawa projektu checkoutu daje przeciętnie około 35% wzrostu konwersji – to średnia z ich testów użyteczności na dużych sklepach. Znowu: średnia z konkretnej próby, nie obietnica.

Co konkretnie zweryfikować po migracji:

• czy pełny koszt (produkt + dostawa) jest widoczny przed wejściem w checkout, a nie dopiero po podaniu adresu;
• czy zakup bez rejestracji nadal jest możliwy i czy nie schował się za mniej widocznym przyciskiem;
• ile pól ma formularz teraz, a ile miał przed migracją — policz je, dosłownie;
• czy walidacja pól działa na bieżąco, czy dopiero po wysłaniu formularza (to drugie generuje najwięcej porzuceń na ostatnim kroku);
• czy metody płatności są w tej samej kolejności i czy żadna nie wypadła po drodze.

Ostatni punkt brzmi banalnie, a widziałem go w praktyce wielokrotnie: przy migracji ginie jedna metoda płatności, bo integracja nie została przeniesiona. Dla części klientów to koniec zakupów, a w danych wygląda jak „spadek konwersji w checkoucie”.

Sprawdź to sam: przejdź własną ścieżkę zakupową Najprostsza diagnostyka SXO nie wymaga żadnego narzędzia. Weź telefon, dane komórkowe zamiast Wi-Fi, wejdź na sklep z wyszukiwarki i kup coś za własne pieniądze. Do końca, z płatnością. Notuj każdy moment, w którym musisz się zastanowić. Zrób to samo u dwóch konkurentów. To ćwiczenie na czterdzieści minut, które regularnie wykrywa rzeczy niewidoczne w GA4 i które zaskakująco rzadko ktokolwiek robi po wdrożeniu.

4. Płatność – ostatni krok, największa szkoda

Porzucenie na etapie płatności boli najbardziej, bo tracisz użytkownika o najwyższej intencji, po tym jak zapłaciłeś za jego pozyskanie. Po migracji sprawdź tu przede wszystkim stabilność wizualną: przeskakujące elementy (CLS) na ekranie z podsumowaniem zamówienia powodują kliknięcia w nie to, co trzeba. Przy formularzu płatności to nie jest kosmetyka to porzucona transakcja.

Druga rzecz: obsługa błędów. Co widzi użytkownik, gdy płatność zostanie odrzucona? Czy wraca do wypełnionego koszyka, czy do pustego? Nowe wdrożenia często gubią ten scenariusz, bo nikt go nie testuje, a QA sprawdza ścieżkę, która się udaje.

Nawigacja, filtry i wyszukiwarka – cichy problem re-architektury

Re-architektura z definicji zmienia strukturę. I tu jest pułapka, którą łatwo przeoczyć, bo jej skutki widać nie w checkoucie, tylko dużo wcześniej.

Kiedy zmieniasz taksonomię kategorii, zmieniasz też mapę, którą użytkownicy mieli w głowie. Powracający klient, który przez dwa lata trafiał do swojej kategorii dwoma kliknięciami, nagle potrzebuje czterech, albo nie trafia wcale i idzie do wyszukiwarki wewnętrznej. To zachowanie widać w GA4 jako wzrost zdarzeń view_search_results i skrócenie ścieżki nawigacyjnej. Jeśli po migracji udział sesji z użyciem wyszukiwarki wewnętrznej wyraźnie skoczył, to nie jest sukces „nowej, wygodnej wyszukiwarki”. To sygnał, że nawigacja przestała odpowiadać na potrzeby.

Zajrzyj też w to, czego ludzie szukają. Lista fraz z wyszukiwarki wewnętrznej po migracji to jedno z najbardziej niedocenianych źródeł wiedzy o UX, jakie masz za darmo. Jeśli w top 20 pojawiają się nazwy kategorii, które istnieją w menu to masz problem z nazewnictwem albo widocznością nawigacji. Jeśli pojawiają się zapytania zwracające zero wyników, sprawdź, czy to nie produkty, które po prostu nie przeszły migracji katalogu.

Warto też sprawdzić filtry. Nowe implementacje bywają zbyt szybkie w jedną stronę i za wolne w drugą: przeładowują całą listę przy każdym kliknięciu (co uderza w INP) albo aktualizują wyniki bez czytelnej informacji, że coś się zmieniło. Jedno i drugie kończy się tak samo – użytkownik nie ufa, że filtr zadziałał.

Mobile: tam koncentruje się strata

Jeśli po migracji miałbyś obejrzeć tylko jeden segment, obejrzyj mobile. Powody są trzy i wszystkie mają oparcie w danych rynkowych.

Po pierwsze – tam jest ruch. Urządzenia mobilne odpowiadają obecnie za mniej więcej 53% ruchu w sieci według Statcountera (dane na lipiec 2026).

Po drugie – tam jest najgorsza konwersja. Urządzenia mobilne odpowiadają dziś za ponad połowę globalnych odsłon stron, ale użytkownicy smartfonów nadal konwertują słabiej niż osoby korzystające z komputerów. Widać to szczególnie w przypadku porzuceń koszyka: według benchmarków Dynamic Yield odsetek nieukończonych zakupów wynosi około 80% na urządzeniach mobilnych, podczas gdy na desktopie jest to około 69%. To nie oznacza, że każdy sklep powinien przyjmować te wartości jako własny cel lub diagnozę – wyniki zależą m.in. od branży, źródeł ruchu, cen produktów i sposobu pomiaru. Dane wyraźnie pokazują jednak kierunek: mobile jest dziś najważniejszym źródłem ruchu, ale jednocześnie wymaga szczególnej uwagi na etapie koszyka i checkoutu, gdzie nawet drobne problemy z formularzem, płatnością, wydajnością lub prezentacją kosztów dostawy mogą prowadzić do utraty sprzedaży.

Po trzecie – tam najczęściej pęka wydajność. Według Web Almanac i danych CrUX odsetek origin-ów przechodzących wszystkie trzy Core Web Vitals na mobile jest o kilka punktów niższy niż na desktopie, a największa różnica dotyczy LCP. Do tego dochodzi INP, który, jak wspomniałem wyżej jest metryką bezlitosną dla ciężkiego JavaScriptu, a ciężki JavaScript na słabszym telefonie w zasięgu LTE to zupełnie inna historia niż na laptopie w biurze.

Praktyczna konsekwencja jest prosta: testuj i raportuj mobile osobno, od pierwszego dnia po wdrożeniu. Uśredniony raport dla obu urządzeń zamaskuje problem, który odpowiada za większość straty.

Plan na pierwsze 90 dni

Poniżej kolejność, która sprawdza się jako domyślna. Dopasuj tempo do skali sklepu, ale nie zmieniaj kolejności. Każdy etap zakłada, że poprzedni jest odhaczony.

Dzień 0–1: weryfikacja pomiaru Przejdź realną transakcję z DebugView. Sprawdź, czy purchase odpala się raz, z transaction_id, z walutą i z poprawną tablicą items. Porównaj liczbę zamówień w GA4 z backendem. Sprawdź, czy Consent Mode nie blokuje zdarzeń w checkoucie. To jest zadanie na pierwszy dzień, bo danych nie da się odzyskać wstecz.

Dzień 1–7: obserwacja bez reagowania Zbieraj dane, włącz nagrania sesji, notuj zgłoszenia z obsługi klienta. Nie wprowadzaj zmian. To najtrudniejszy punkt na tej liście, bo presja jest ogromna — ale zmiana wdrożona w trzecim dniu sprawia, że przez kolejny miesiąc nie wiesz, co właściwie mierzysz. Jedyny wyjątek: twarde błędy blokujące zakup. Te naprawiasz natychmiast.

Zgłoszenia z obsługi klienta w tym oknie są warte więcej niż jakikolwiek raport. To jedyne miejsce, gdzie dostajesz opis problemu ludzkim językiem, zanim zobaczysz go w liczbach.

Tydzień 2–4: diagnoza Zbuduj porównanie lejków na analogicznych zakresach dat. Rozbij na segmenty (urządzenie, typ strony wejścia, źródło, nowi/powracający). Zidentyfikuj jeden krok z największą stratą. Obejrzyj dwadzieścia nagrań sesji porzuconych na tym kroku. Dopiero teraz formułuj hipotezę.

Miesiąc 2–3: zmiany, pojedynczo Wprowadzaj poprawki po kolei, nie pakietem. Pakiet pięciu zmian, po którym konwersja rośnie o 12%, jest bezużyteczny poznawczo, nie wiesz, która zadziałała, a która działała przeciwko pozostałym. Jeśli masz wystarczający ruch na testy A/B – testuj. Jeśli nie masz (a większość polskich sklepów średniej wielkości nie ma na to ruchu w rozsądnym czasie), wdrażaj sekwencyjnie i pilnuj, żeby okna obserwacji nie zachodziły na siebie.

Przez cały czas: pilnuj sezonu Porównuj analogiczne okresy, nie sąsiadujące. Jeśli migracja wypadła na przełomie sezonu, dorzuć do analizy porównanie rok do roku — z pełną świadomością, że rok temu miałeś inny asortyment, inne budżety i inną widoczność. To słabszy dowód niż porównanie tydzień do tygodnia, ale lepszy niż nic.

Pięć błędów, które widuję najczęściej

1. Redesign na podstawie trzech dni danych. Pierwszy tydzień po migracji to najgorszy możliwy moment na decyzje. Dane są zaszumione przez cache, przez powracających klientów w szoku i przez indeksację, która jeszcze się układa.

2. Naprawianie objawu zamiast kroku. „Konwersja spadła, dorzućmy pop-up z rabatem.” To zasłania problem, zamiast go rozwiązać i psuje dane na kolejne tygodnie, bo od teraz mierzysz sklep z pop-upem.

3. Ignorowanie różnicy między nowymi a powracającymi. Powracający klient przechodzi przez koszt zmiany nawyku. To zwykle wyrównuje się w kilka tygodni. Nowy użytkownik, który się gubi, nie wyrówna się nigdy.

4. Uznanie danych GA4 za prawdę objawioną. GA4 mierzy po stronie przeglądarki i nie widzi wszystkiego. Backend widzi transakcje, ale nie widzi zachowania. Nagrania sesji widzą zachowanie, ale nie skalują się na cały ruch. Wniosek buduj na przecięciu trzech źródeł, nie na jednym.

5. Traktowanie SXO jako projektu, nie procesu. Migracja się kończy, optymalizacja ścieżki zakupowej nie. Wskaźnik porzuceń koszyka nie drgnął w skali rynku od dekady, nie dlatego, że nikt nad nim nie pracuje, tylko dlatego, że to praca bez końca linii.

Częste pytania

Po jakim czasie powinienem zobaczyć powrót konwersji do poziomu sprzed migracji?

Nie ma jednej odpowiedzi i uważaj na każdego, kto ją podaje. Realny horyzont zależy od skali zmian w ścieżce zakupowej, od udziału powracających klientów i od tego, ile regresji faktycznie weszło z wdrożeniem. Szacunki mówiące o kilkudziesięciu dniach (jak przywołany wyżej przedział 5–20% spadku w pierwszych 60 dniach) to obserwacje dostawców narzędzi, nie prawo natury. Zamiast pytać „kiedy wróci”, pytaj „który krok lejka wciąż odstaje od stanu sprzed migracji” – to pytanie ma odpowiedź.

Czy warto zostawić starą wersję sklepu na jakiś czas i puszczać część ruchu? 

Jeśli masz techniczną możliwość rozłożenia wdrożenia w czasie, to najlepsza forma ubezpieczenia, jaką znam i część większych migracji faktycznie jest prowadzona etapami. Zastrzeżenie: równoległe działanie dwóch systemów bardzo łatwo psuje pomiar (podwójne tagi, rozbite sesje, zdublowane transakcje). Jeśli idziesz tą drogą, ustal konfigurację analityki przed startem, nie w trakcie.

Mam mały sklep, testy A/B nie mają u mnie sensu. Co zamiast tego? 

Wdrażanie sekwencyjne z czystymi oknami obserwacji plus jakościowa analiza: nagrania sesji, mapy kliknięć, własne przejście ścieżki, rozmowy z obsługą klienta. Przy niskim ruchu dane jakościowe są po prostu lepszym narzędziem niż statystyka, która i tak nie osiągnie istotności w rozsądnym czasie. To nie jest rozwiązanie gorsze, to rozwiązanie adekwatne do skali.

Search Console pokazuje, że kliknięcia wróciły. Czy to znaczy, że migracja SEO się udała? 

To znaczy, że udała się jej pierwsza połowa. Widoczność wróciła — pytanie, czy wraca też ta sama intencja. Jeśli przy okazji migracji zmieniłeś strukturę kategorii i mapowanie treści, możesz zbierać porównywalną liczbę kliknięć od ludzi na innym etapie decyzji zakupowej. To dokładnie ten przypadek, w którym raport z Search Console wygląda dobrze, a sprzedaż nie.

Co z tym zrobić dalej

Jeśli miałbyś zapamiętać jedną rzecz z tego tekstu: zanim uznasz, że nowy sklep gorzej konwertuje, upewnij się, że w ogóle mierzysz to samo co przed migracją. Rozjazd między GA4 a backendem powyżej 20%, pojedyncze źródło zdarzenia purchase, obecny transaction_id i niezablokowane zdarzenia w checkoucie – te cztery rzeczy w pierwszej kolejności. Dopiero potem lejek, potem segmenty, potem UX.

A jeśli sprawdzisz i okaże się, że pomiar jest czysty, a jeden konkretny krok lejka faktycznie stracił kilkanaście punktów — napisz do mnie, jak wygląda ten wykres. Takie przypadki są najciekawsze, bo prawie zawsze stoi za nimi jakiś jeden konkretny, drobny element interfejsu, który przesunął się o dwa ekrany w dół.