Migracja sklepu bez utraty pozycji w Google: 43 943 zamówienia, zero rozbieżności
Najczęstszy strach właściciela działającego sklepu brzmi: „przeniesiemy się i stracimy ruch z Google”. Ten strach jest uzasadniony — ale nie dlatego, że migracje z natury szkodzą pozycjom. Szkodzi to, o czym się przy nich zapomina.
Co właściwie się przenosi
Kiedy klient mówi „przenieśmy sklep”, zwykle ma na myśli produkty i zamówienia. To jest może jedna trzecia roboty. Sklep, który działa od kilku lat, zbudował wokół siebie warstwę rzeczy, które nie wyglądają jak dane, a decydują o tym, czy po migracji ruch zostanie.
W ostatniej dużej migracji, którą prowadziliśmy — sklep z opałem działający na trzech rynkach — przenieśliśmy z produkcji do nowej architektury komplet:
Zamówienia i klienci to oczywistość. Interesujące są dwie pozostałe pozycje, bo to one decydują o pozycjach w wyszukiwarce i o zaufaniu, z którym klient trafia na kartę produktu.
Przekierowania: 738 adresów, o których nikt nie pamięta
Każdy adres, pod którym coś kiedyś istniało, ma w Google swoją historię. Część z nich ma odnośniki z zewnątrz, część jest w zakładkach klientów, część siedzi w starych newsletterach. Jeśli po migracji adres zwraca „nie znaleziono”, cała ta historia przepada — nie stopniowo, tylko z dnia na dzień.
W tym sklepie takich adresów było 738. Nie były to adresy aktualnych produktów — te przenoszą się same razem z katalogiem. To były adresy z poprzednich przebudowań sklepu: stare kategorie, produkty wycofane, adresy z czasów, gdy sklep miał inną strukturę. Ktoś kiedyś ustawił dla nich przekierowania i o nich zapomniał, bo działały po cichu przez lata.
Prosty test przed jakąkolwiek migracją: wyeksportujcie listę wszystkich przekierowań, które ma dziś Wasz sklep. Jeśli w odpowiedzi słyszycie „a mamy jakieś?”, to znaczy, że są i że nikt ich nie policzył.
Przeniesienie tych przekierowań to nie jest praca twórcza — to praca do odhaczenia. Ale jeśli jej nie ma na liście, nikt jej nie zrobi, bo nie widać, że czegoś brakuje. Sklep po migracji wygląda dobrze, a ruch spada przez trzy miesiące i wszyscy zastanawiają się dlaczego.
Opinie: 375 recenzji, które łatwo zgubić
Opinie o produktach są zwykle w innej tabeli niż produkty i migrują osobno. Bardzo często nie migrują w ogóle, bo w napiętym terminie ktoś podejmuje decyzję: „opinie dorobimy później, klienci napiszą nowe”. Nie napiszą.
Przenieśliśmy 375 recenzji razem z 1 825 ocenami cząstkowymi — bo każda recenzja w tym sklepie oceniała pięć wymiarów osobno. Techniczna pułapka była w miejscu, którego nikt się nie spodziewa: recenzje wymagały wpisu wiążącego je ze sklepem o identyfikatorze zerowym. Bez tego wpisu dane były w bazie, ale panel administracyjny pokazywał pustą listę — czyli wyglądało to na utratę danych, choć dane były na miejscu.
Wspominam o tym, bo to typowy kształt problemów przy migracji: nic nie wybucha, wszystko wygląda na zrobione, a brakuje jednego wiersza w tabeli pomocniczej.
Trzy kraje, trzy waluty, jeden silnik
Ten sklep sprzedaje w Polsce, Austrii i Niemczech — w trzech walutach, z trzema stawkami podatku i z cenami prezentowanymi z podatkiem, bo kupują u niego osoby prywatne. Do tego dochodzi cennik zależny od producenta i od formy dostawy: paleta, całe auto, worek zbiorczy.
Przy takiej strukturze migracja nie polega na przepisaniu cen. Polega na tym, żeby po przeniesieniu ta sama osoba, wchodząca z tego samego kraju, zobaczyła tę samą cenę co przed zmianą. To brzmi banalnie, dopóki nie zobaczy się, ile miejsc w kodzie sklepu może tę cenę zmodyfikować.
Zostawiliśmy w bazie stare atrybuty cenowe, mimo że nowy mechanizm ich nie używa. Powód jest niepozorny: w chwili migracji ktoś może mieć koszyk w trakcie realizacji. Usunięcie starych danych zepsułoby dokładnie te zamówienia, które są w połowie drogi — czyli te, które najbardziej boli stracić.
Czego ta migracja nie zmieniła — i dlaczego to jest sukces
W opisach wdrożeń zwykle podaje się efekt: było tyle, jest tyle. Tutaj takiego zestawienia nie ma i nie może być, bo celem była wierność, nie zmiana. Metryką sukcesu jest bezstratność: 43 943 zamówienia przeniesione bez rozbieżności, wszystkie adresy odpowiadające tak samo jak przed migracją, opinie widoczne tam, gdzie były.
To jest ważne rozróżnienie przy wyborze wykonawcy. Firma, która przy migracji obiecuje Wam wzrost sprzedaży, albo miesza dwa różne projekty (migrację i optymalizację), albo nie przemyślała, ile rzeczy może przy okazji pójść nie tak. Migracja jest udana, kiedy klient jej nie zauważa.
Jak sprawdzić, że migracja się udała
Najgorszy moment na odkrycie błędu to trzy tygodnie po przełączeniu, gdy widać spadek ruchu i nie wiadomo, która z pięćdziesięciu zmian go spowodowała. Dlatego weryfikacja nie może polegać na klikaniu po sklepie.
Porównanie adresów całą listą
Przed przełączeniem robi się listę wszystkich adresów, pod którymi stary sklep odpowiadał — z mapy strony, z panelu, z raportu narzędzi Google. Po przełączeniu każdy z nich odpytuje się maszynowo i porównuje odpowiedź. Nie „czy strona się otwiera”, tylko: czy odpowiada tak samo jak przed zmianą, a jeśli przekierowuje, to czy w to samo miejsce.
Przy 738 przekierowaniach to jest kilka minut pracy maszyny i jedyny sposób, żeby mieć pewność. Klikanie w losowe dziesięć adresów daje złudzenie kontroli — jeśli zepsute jest pięć procent, prawdopodobnie żaden z nich w te dziesięć nie trafi.
Zgodność liczb, nie tylko obecność danych
Po migracji porównuje się sumy: liczba zamówień, suma wartości, liczba klientów, liczba opinii. Nie po to, żeby sprawdzić, czy dane są — one prawie zawsze są. Po to, żeby wychwycić sytuację, w której przeniosło się 43 900 z 43 943 zamówień, bo czterdzieści trzy miały coś nietypowego w strukturze i cicho wypadły.
Ta różnica nie jest widoczna w żadnym panelu. Widać ją tylko wtedy, gdy ktoś porówna dwie liczby z dwóch systemów. Jeśli w planie migracji nie ma punktu „porównanie sum kontrolnych”, to znaczy, że nikt tego nie zrobi.
Numeracja, o którą zapyta księgowość
Zamówienia i faktury mają ciągłą numerację i po migracji musi ona nie tylko zostać zachowana, ale też iść dalej od właściwego miejsca. Klasyczny błąd: dane historyczne przenoszą się poprawnie, a licznik nowych dokumentów startuje od jedynki i pierwsze zamówienie po przełączeniu dostaje numer, który już istnieje w księgowości.
Kiedy przełączać
Przełączenie ruchu na nową wersję to jedyny moment tego projektu, którego nie da się cofnąć bezboleśnie. Trzy rzeczy, które warto ustalić przed:
- Co się dzieje z zamówieniami w trakcie realizacji. Ktoś ma w tej chwili otwarty koszyk albo jest w połowie płatności. Plan musi przewidywać, że te zamówienia dojdą do końca — dlatego w opisywanej migracji zostawiliśmy w bazie stare pola cenowe, mimo że nowy mechanizm ich nie używa.
- Kto ma dostęp do starej wersji. Przez pierwsze dni stara instalacja powinna być osiągalna dla zespołu, żeby dało się cokolwiek porównać, gdy klient zadzwoni z pytaniem o zamówienie sprzed migracji.
- Kiedy dokładnie. Nie w piątek po południu. Nie w szczycie sezonu. W tym sklepie sezon na opał zaczyna się późnym latem — przełączenie w sierpniu byłoby decyzją kosztowną niezależnie od jakości przygotowania.
Pułapka, która nie dotyczy danych
Osobna kategoria problemów przy migracji nie dotyczy danych, tylko środowiska, w którym sklep działa. Dwa przykłady z tego wdrożenia, oba kosztowne w diagnozie, oba banalne w naprawie:
Serwer w innym stanie niż repozytorium. Ktoś włączył moduł bezpośrednio na serwerze, plik konfiguracyjny zmienił się poza kontrolą wersji, a przy kolejnym wdrożeniu zmiana zniknęła. Odtąd każde wdrożenie zaczyna się od sprawdzenia, czy serwer nie ma nic, czego nie ma repozytorium.
Zmiany, które nie wchodzą, mimo że wgrane. Sklep buforuje skompilowany kod i zwykły restart tego nie czyści. Objaw jest mylący: wgrywacie poprawkę, sprawdzacie, nic się nie zmienia, więc wgrywacie jeszcze raz. Rozwiązaniem jest usunięcie wygenerowanego kodu i ponowna kompilacja — jeden krok, który musi być na stałe w procedurze wdrożenia, bo inaczej co jakiś czas ktoś traci na tym pół dnia.
To jest argument za tym, żeby migrację prowadził ktoś, kto tę konkretną platformę zna z produkcji, a nie tylko z dokumentacji. Dane przeniesie każdy; różnica jest w tym, ile czasu zajmie diagnoza takich sytuacji.
Migracja Magento — co jest tu specyficzne
Powyższe dotyczy każdej zmiany platformy. Migracja Magento ma jednak trzy rzeczy, które w innych sklepach nie występują albo wyglądają inaczej — i to na nich najczęściej gubi się ruch.
Przepisane adresy żyją w bazie, nie w pliku konfiguracyjnym
Magento trzyma przepisania adresów w bazie i dopisuje je samo przy każdej zmianie nazwy produktu czy kategorii. Po kilku latach jest ich znacznie więcej, niż ktokolwiek pamięta — i żaden z nich nie jest widoczny w panelu jako lista do przeniesienia. W migracji, o której piszemy, było ich 738.
Wiele sklepów w jednej instalacji to wiele zestawów adresów
Jeśli obsługujecie kilka krajów z jednej instalacji, ten sam produkt ma inną końcówkę adresu w każdym z nich. Przy migracji trzeba przenieść nie tylko adresy, ale i powiązania między wersjami — inaczej wyszukiwarka zaczyna traktować wersję austriacką i niemiecką jako dwie osobne strony o tej samej treści.
W jednym z naszych sklepów wielokrajowych wymagało to 294 osobnych wpisów przekierowań tylko po to, żeby pary adresów austriackich i niemieckich z różnymi końcówkami nie kończyły się błędem.
Opinie i oceny leżą w kilku tabelach naraz
Jeśli klienci oceniają kilka wymiarów — jakość, wysyłkę, obsługę — dane o ocenach są rozbite na osobne tabele i eksport „opinii” zwykle obejmuje tylko część. Gwiazdki znikające z kart produktów po migracji to nie jest usterka wyświetlania, tylko brakujące wiersze.
Test przed migracją Magento: poproście o liczbę wierszy w tabeli przepisań adresów i liczbę wierszy w tabelach ocen. Dwie liczby, kilka minut pracy. Jeśli wykonawca nie potrafi ich podać przed rozpoczęciem, to znaczy, że planuje migrację bez wiedzy, co przenosi.
Lista, którą warto mieć przed rozmową z wykonawcą
- Ile macie przekierowań? Nie „czy”, tylko „ile”. Liczba jest do wyeksportowania w kilka minut.
- Gdzie są opinie i w ilu tabelach? Jeśli oceniacie kilka wymiarów, danych jest wielokrotnie więcej, niż widać na karcie.
- Co się dzieje z zamówieniami w trakcie? Czyli: czy plan migracji przewiduje moment, w którym ktoś ma otwarty koszyk.
- Czy numeracja zamówień i faktur zostaje zachowana? To pytanie księgowej, ale zadać je trzeba wykonawcy, i to przed startem.
- Kto sprawdzi, że stare adresy odpowiadają po migracji? Automatycznie, całą listą, a nie przez kliknięcie w trzy losowe.
Jeśli wykonawca odpowiada na te pięć pytań konkretnie, prawdopodobnie robił to wcześniej. Jeśli odpowiada, że „system to obsługuje”, warto dopytać, który dokładnie fragment systemu i co się dzieje, kiedy tego nie obsłuży.