16 października 2022 51:29 Odcinek 077

Zmiana sklepu internetowego – jak zrobić ją dobrze?

Z jednej strony migracja sklepu to fajna sprawa, zapowiada nowy (miejmy nadzieję bardziej dochodowy) etap w życiu Twojego e-Commerce’u. Z drugiej strony, zmiana platformy niesie ze sobą wiele wyzwań i problemów, z którymi będziesz musiał się zmierzyć. Prędzej czy później jednak, migracja sklepu internetowego czeka każdy e-biznes, bo albo zestarzeje się technologia, albo zmieni się model biznesowy Twojej firmy, albo obecna platforma przestanie być wystarczająco wydajna. Powody mogą być różne, ale jedno jest pewne – dobre przygotowanie może ułatwić cały ten proces i sprawić, że przyniesie on zamierzone rezultaty.

W tym odcinku podcastu opowiem Ci o najważniejszych zagadnieniach związanych z migracją platformy sprzedażowej. O tym, czy istnieje idealny moment na zmianę, na co powinieneś zwrócić szczególną uwagę i jak się do tego procesu przygotować.

Listen to „077 – Zmiana sklepu internetowego – jak zrobić ją dobrze?” on Spreaker.

Dodatkowe materiały

Jeśli zainteresował Cię odcinek, sprawdź również:

  1. Odcinek: Gdy przyjdzie czas na zmianę firmy wdrożeniowej, który pomoże Ci przeprowadzić ten proces bez zbędnego bólu głowy
    https://marekkich.pl/sztuka-ecommerce/061-gdy-przyjdzie-czas-na-zmiane-firmy-wdrozeniowej/
  2. Odcinek: Migracja SEO sklepu internetowego – Piotr Urbaniak, o tym co zrobić, żeby zmiana platformy e-Commerce nie zaprzepaściła Twojej pozycji w wyszukiwarce
    https://marekkich.pl/sztuka-ecommerce/033-migracja-seo-sklepu-internetowego-piotr-urbaniak/
  3. Odcinek: Zanim zatrudnisz agencję e-Commerce, dzięki któremu wybierzesz najlepszą firmę wdrożeniową dla Twojego projektu
    https://marekkich.pl/sztuka-ecommerce/016-zanim-zatrudnisz-agencje-e-commerce/
  4. Odcinek: Jak napisać dobry brief?, żeby wdrożenie Twojego sklepu internetowego było szybkie i sprawne
    https://marekkich.pl/sztuka-ecommerce/005-jak-napisac-dobry-brief/
  5. Odcinek: Jaki sklep internetowy wybrać?, który pomoże ci podjąć decyzję o wyborze platformy e-Commerce
    https://marekkich.pl/sztuka-ecommerce/004-jaki-sklep-internetowy-wybrac/

Transkrypcja odcinka

Z jednej strony migracja sklepu wydaje się być czymś całkiem fajnym. Ostatecznie odświeżysz sobie sklep, pozbędziesz się problemów starego rozwiązania, programiści będą zadowoleni, marketing będzie zadowolony, klienci będą zadowoleni, no i wszystko zapachnie świeżością, jak w łazience po sprzątaniu. Z czego tutaj się nie cieszyć? 

Z drugiej strony nowy sklep będzie przecież kosztował i to zazwyczaj niemałe pieniądze. Na domiar złego stary przecież też wcale nie był za darmo. Trzeba tutaj też dodać, że ci co bardziej straumatyzowani przedsiębiorcy mogą sobie teraz przypomnieć proces powstawania starego sklepu, który w wielu przypadkach był czymś, czego raczej nie chcemy powtarzać. Straszne historie przy ognisku o rozjechanych terminach i budżetach pewnie słyszał już każdy z nas i w tym wypadku trudno uśmiechnąć się na nadchodzące zmiany. 

Na domiar złego to wcale nie jest koniec potencjalnych problemów, bo przecież w związku z migracją wiążą się też inne ryzyka, jak chociażby spadek w wyszukiwarce, który może niejednemu biznesowi podciąć skrzydła w rozwoju, albo rozjazd na poziomie danych po migracji i późniejsze żmudne sprzątanie bałaganu. Trudno ostatecznie wytłumaczyć klientom, że cudze dane po zalogowaniu to nie bach, tylko feature i okazja do poznawania nowych osób. 

Podsumowując – z migracją sklepu jest trochę fajnie, trochę niefajnie, ale umówmy się, że niezależnie od emocji, które ci towarzyszą w związku z tym tematem, każdy biznes prędzej czy później to czeka. W tym odcinku opowiem ci na bazie moich doświadczeń o trzech najważniejszych składowych procesu zmiany sklepu na nowy, to znaczy – kiedy jest dobry moment na zmianę, jak się przygotować do tego procesu, na co powinieneś zwrócić szczególną uwagę przy golive, żeby spać spokojnie po całym tym zamieszaniu.

Kiedy jest dobry moment na migrację Twojego e-Commerce?

Pierwsza rzecz, to kiedy jest dobry moment na zmianę sklepu internetowego. Myślę, że nie będę mocno odkrywczy, bo przecież mało kto robi e-Commerce w czynie społecznym, w związku z czym tak naprawdę wszystko, co będziemy mówili dzisiaj o migracji, będzie się sprowadzało do pieniędzy. Z migracją jest dokładnie tak, jak z każdą inną inwestycją, że warto ją przeprowadzić wtedy, kiedy korzyści z niej płynące przewyższą te korzyści z obsługi i rozwoju sklepu internetowego, który posiadasz obecnie. Po prostu musi się to opłacać. 

Żebyśmy jednak nie rozmawiali o ogólnikach i nie uprawiali „paulocoelhizmów”, przepracujemy sobie te stwierdzenia kilku składowych, które trzeba wziąć pod uwagę w procesie decyzyjnym. Pierwszą sprawą jest backlog, czyli lista zadań, które masz do zrobienia w obrębie Twojego obecnego sklepu internetowego. Z backlogiem bywa tak naprawdę różnie, no bo jeżeli jesteś firmą, która stawia bardzo dużo na rozwój, to rzeczywiście może być on rozległy. Tych zadań może być w przód na kilka miesięcy czy nawet lat do przodu (przynajmniej na tym ogólnym poziomie), natomiast te małe sklepy czy takie, które nie chcą za bardzo inwestować obecnie w rozwój, ten backlog mogą mieć mały, taki typowo utrzymaniowy typu kilkanaście do kilkudziesięciu godzin pracy miesięcznie. W związku z tym warto pamiętać, czy raczej w najbliższym okresie planujesz utrzymanie tego sklepu, czy, na przykład, nadchodzą jakieś rewolucje typu redesign, zmiana modelu biznesowego, może uruchomienie nowego rynku czy jakichś dodatkowych funkcji, które będą angażowały wielu ludzi. Oczywiście, trzeba też sobie zadać pytanie, czy utrzymanie nie wynika z tego, że nie da się za bardzo rozwijać, ale to jest taki, powiedzmy sobie, szczególny przypadek. 

Drugą sprawą, którą warto wziąć pod uwagę przy tym procesie decyzyjnym, jest to, jaką technologię w tym momencie masz w sklepie internetowym, szczególnie pod kątem elastyczności. To jest właśnie ten aspekt backlogu, o którym mówiłem, że czasami jest mały, bo technologia też nie na wszystko pozwala. 

Warto też obecną technologię ocenić pod kątem optymalności rozwoju, czyli tego, czy ten dług technologiczny, który jest w obecnej platformie, jest na takim w miarę utrzymywalnym poziomie i takim, że programiści nie wyrywają sobie kłaków z głowy, i czy przypadkiem nie jest tak, że wyważasz otwarte drzwi, czyli każda z kolejnych rzeczy, którą sobie wymarzysz w sklepie, to jest kupę godzin niezależnie od tego, czy to jest rzecz bardzo rynkowa, na przykład integracje z paczkomatami, którą z grubsza większość technologii już obsłużyło, czy to rzeczywiście są jakieś customy. 

Ostatnią rzeczą jest policzenie czy oszacowanie szans i ryzyk związanych ze zmianą i z utrzymaniem tego, co jest obecnie. Tu warto wziąć pod uwagę takie rzeczy jak zmiana współczynnika konwersji, zmiana kosztów rozwoju utrzymania i znalezienie specjalistów na rynku, to znaczy, mówiąc trochę w inny sposób – co się stanie w momencie, kiedy zostanie tak, jak jest? 

Tym ryzykiem może być, na przykład to, że spadnie ci współczynnik konwersji, bo, na przykład, twój sklep jest coraz starszy, widać, że działa powoli i już nie wygląda tak, jak powinien, widać, że nie jesteś w stanie wdrożyć jakiejś nowej funkcji, która jest potrzebna Twoim klientom. Warto wtedy pamiętać i mierzyć się, i liczyć z takim ryzykiem, że po prostu ci klienci będą być może nawet dawać Ci ten sam ruch, ale współczynnik konwersji będzie coraz niższy, bo klienci będą porzucali koszyki. 

Jeżeli chodzi o zmianę kosztów rozwoju i utrzymania, to jakby znowu jest to trochę związane z tymi funkcjami, które będą się pojawiały w sklepie, ale również zarządzaniem długiem technologicznym. Jeżeli ta platforma jest coraz bardziej taka „rozbebeszona”, to może się okazać, że później wprowadzanie każdych kolejnych funkcji będzie kosztowało po prostu coraz więcej, bo będzie trudno wdrożyć coś bez, na przykład, zepsucia czegoś innego, w związku z czym to będzie taki kołowrotek zmian, z których po prostu niewiele wynika, poza tym, że sporo kosztują. 

Jeżeli chodzi o specjalistów na rynku, to niestety tak jest… Czy „niestety”, to każdy sobie sam oceni, czy mu się to podoba, czy nie, ale fakt jest taki, że specjaliści nie do końca chcą się grzebać ze starymi technologiami i z nieswoim kodem, ale przede wszystkim nie chcą grzebać się w kodzie, który jest obarczony dużym długiem technologicznym. W związku z tym może być tak, że jeżeli masz już jakąś taką platformę Legacy, która jest napisana w starej technologii, to tych specjalistów będzie na rynku coraz mniej, a też z tych specjalistów, którzy są, to zostaną na tym rynku i może się okazać, że akurat żaden nie chce pracować przy Twoim projekcie. 

Warto pamiętać, że ten problem niekoniecznie musi dotyczyć tylko starych technologii, bo jeżeli na przykład wdrażałeś sobie Magento 2 czy najnowszą wersję WooCommerce’a, ale dałeś to osobie, która, mówiąc najbardziej dyplomatycznie, jak potrafię, nie do końca znała się na swojej robocie, i mówiąc bardziej wprost, po prostu ci ten sklep spieprzyła, to może się okazać, że później nikt po prostu nie chce go rozwijać. Wtedy twój backlog może być naprawdę bardzo duży, możesz mieć świetne pomysły, a abstrahując od tego, że będzie to bardzo dużo kosztowało, możesz odbijać się od ściany w postaci firm, które po prostu nie będą chciały ci rozwijać tego sklepu. 

Mnie się w karierze zdarzyło parę takich świeżych sklepów, które zaraz do wdrożeniu przyszły do mnie z jakąś prośbą czy propozycją współpracy, a ja bardzo konsekwentnie i asertywnie odmawiałem, bo okazywało się, że tam właściwie zmuszanie programisty czy zespołu do pracy nad takim kodem było czymś, czego prawdopodobnie zakazuje też konwencja genewska. Trudno też się tym programistom dziwić. Ja oceniam, że to jest dobry objaw, że ludzie jednak chcą się rozwijać i bardziej lgną do technologii, które są przyszłościowe i rozwiązań, które są fajne w rozwoju, bo każdy chce po prostu wyciągać z pracy jak najwięcej. Jeżeli twój sklep nie podpada pod to, może się okazać, że będziesz miał w długim terminie po prostu problem, żeby utrzymywać zespół czy też zatrudniać firmę, która będzie miała stabilny zespół wokół Twojego projektu. 

Kiedy zmiana sklepu internetowego nie ma sensu?

Mamy więc tak naprawdę parę rzeczy, które warto sobie ocenić i też parę szans i ryzyk, które nas czekają w związku z utrzymaniem i ze zmianą tego, co w tym momencie u ciebie funkcjonuje. Powiem ci więc jeszcze, kiedy z mojego punktu widzenia ta zmiana nie do końca ma sens. Takim pierwszym przypadkiem, i on bardzo często, wbrew pozorom, funkcjonuje i występuje, przy czym nie mam statystyk, jak często dochodzi do skutku, ale rzeczywiście bardzo często klienci się rozglądają po rynku z takim podejściem, że to jest zmiana dla samej zmiany. Oceniam tak po tym, że firma kompletnie nie ma pomysłu na to, po co tę zmianę wykonuje, bo nie idzie za tym jakaś realna zmiana współczynnika konwersji, czyli nikt za bardzo nie przemyślał, czy mu to coś da. Nikt nie konfrontuje tego z kosztami, z udrożnieniem możliwości dalszego rozwoju czy jakiegoś istotnego usprawnienia dla klientów. Nie ma tam jakichś zmian modelu biznesowego. Często jest tak, że firmy rozglądają się za zmianą, a briefem (o tym też zresztą chwilę porozmawiamy), mówiąc, że tak właściwie ten sklep ma wyglądać tak samo, jak wyglądał, tylko ma być na nowej technologii i w zasadzie później nie chcą się rozwijać. 

Tutaj, jeżeli jest rzeczywiście tak, jak te firmy mówią, właściwie ta zmiana rzeczywiście nie do końca ma sens, bo z punktu widzenia biznesu będzie to kosztowało sporo. Z punktu widzenia klientów dostaną dokładnie to, co mieli, bo ma wyglądać i działać tak samo. Z punktu widzenia technologii jest to na pewno jakieś odświeżenie, ale z drugiej strony, skoro tam nic mądrego nie będzie w rozwoju, no to równie dobrze można utrzymywać tak, jak ma to miejsce obecnie. W zasadzie brak tego pomysłu trochę, według mnie, dyskwalifikuje w ogóle istnienie samej potrzeby. 

Innym przypadkiem, kiedy zmiana nie ma sensu, jest po prostu brak planów rozwojowych, bo to nie zawsze jest złe, nie zawsze rozwój e-Commerce musi się związać z rozwojem technologicznym. Czasami po prostu skupiasz się na marketingu czy budowaniu skali, a platforma Cię w żadnym wypadku nie ogranicza. Wtedy tak naprawdę ta zmiana platformy, jeśli nic w niej głębokiego nie planujesz zmienić, to po prostu jest coś, co możemy zrobić wtedy, kiedy ten backlog nam po prostu spuchnie. 

Jeżeli Twój sklep nie jest jakąś przestarzałą technologią i nie jest obciążony długiem technologicznym, to też często ta zmiana nie ma sensu, bo wystarczy po prostu pracować na tym, co mamy. Mały dług technologiczny oczywiście można zredukować. Duży też, ale nie zawsze się opłaca. Często więc po prostu w tym wypadku, jeżeli na przykład czujesz, że firma się zagrzebuje, i to jest Twój sygnał do zmiany, to lepszym rozwiązaniem może być po prostu zmiana na firmę, która będzie w stanie zarządzić tym długiem technologicznym i takim rozwojem twojego sklepu, który ci będzie dawał po prostu satysfakcję i jakąś korzyść biznesową w długiej perspektywie. 

Jeszcze raz przypominam: nie jest tak z tym długiem technologicznym, że jest on koniecznie zależny od tego, jak wiekowa jest platforma. Są platformy, które są rozwijane latami i aktualizowane na bieżąco i jest ten team leader, który rzeczywiście bardzo intensywnie pracuje nad tym, żeby one były superfajne i superoptymalne i takie dostosowane do nowoczesnych standardów, bo technologia jest czymś, nad czym można cały czas pracować. 

Z drugiej strony bywa tak, że nieodpowiednie użycie jakiegoś silnika sklepu internetowego powoduje, że później są problemy w rozwoju. Przypadkiem z mojego podwórka, o którym wiem najwięcej, bo najczęściej mam go przed oczami, to są na przykład wdrożenia Magento, w których firmy zbyt dosłownie wzięły do serca sobie tę budowę modułową i to, że rzeczywiście Magento w marketplace ma kupę modułów Mało kto powiedział, że jest to prawda, ale nie wszystkie te moduły są odpowiedniej jakości, a też nie ma takiej gwarancji, że wszystkie będą ze sobą współpracowały. Siłą rzeczy, jeżeli na przykład pięć modułów dotyczy jednej funkcji w koszyku, to prawdopodobnie nałożenie ich spowoduje, że koniec końców ten koszyk przestanie działać. Często więc jest tak, że to może być superfajne, nowe Magento, które zostało wdrożone po kosztach, w związku z czym jest tam 50 modułów i później, niestety, do rozwoju każdemu programiście w welcome packu trzeba dodawać różaniec, bo tam poza modlitwą naprawdę nic nas nie uratuje.

Jak przygotować się do migracji?

Mamy więc już odpowiedź na pytanie, w jakim przypadku ta migracja jest warta zachodu a w jakim nie. Pamiętaj, że na koniec dnia ROI to nie są żarty, tylko to skrót od bardzo poważnej rzeczy i za każdym biznesem stoją pieniądze. Ja więc zawsze rekomenduję po prostu dobrze to sobie policzyć, i o ile rzeczywiście jest dużo przypadków, gdzie ta zmiana ma sens, to jeszcze jest kwestia, na przykład, czy to jest najlepszy moment. Może lepiej wykorzystać marketing? 

Trzeba też pamiętać o tym, że dużo firm upatruje w migracji w ogóle szansę na poprawienie wyników sprzedażowych, co nie zawsze jest prawdą, bo czasami wydaje nam się, że to jest problem technologiczny, a problem leży w braku strategii czy w nieodpowiednim wykorzystaniu marketingu w firmie. 

Takich zależności jest więc kilka, my tymczasem przejdziemy do tego, w jaki sposób przygotować się do migracji. To też jest równie ważny krok, bo jeżeli się przygotujesz nieprawidłowo, będziesz miał na koncie kolejną historię ogniskową do opowiadania o tym, jak wdrożenie sklepu internetowego boli w serduszko i jak można później spędzić pół roku na kozetce u psychoterapeuty. 

Na szczęście jest tak, że firmy w procesie migracji mają troszeczkę lepiej, niż te, które wdrażają sklep po raz pierwszy. Tu ważna rzecz, którą warto zaadresować teraz, to że migracja z wdrożeniem ma bardzo duży wspólny mianownik. Tak naprawdę jest ona szczególnym przypadkiem wdrożenia, chyba że to jest taka migracja w cudzysłowie, czyli, na przykład, aktualizacja technologii z wersji troszeczkę starszej do nowszej. Tam, powiedzmy, jest to w jakimś stopniu migracja, ale umówmy się, że nie jakaś wielka, natomiast te prawdziwe migracje, gdzie jest przenoszenie danych i funkcji w sklepie, to bardzo blisko leży do tego procesu wdrożeniowego. 

Te firmy mają lepiej dlatego, że już kiedyś to wdrażały, w związku z czym wiedzą, co było w tym procesie dobre i złe, czyli na co by zwrócić w tym momencie szczególnie uwagę w całym procesie wdrożeniowym, na etapie przygotowania się, później odbierania zadań, uruchamiania sklepu. Odnoszę wrażenie, że rozmowy z takim firmami to jest już troszeczkę wyższy poziom świadomości i te pytania są trochę bardziej wycelowane w taki sposób, jakby rzeczywiście firma wiedziała, w co się pcha, mówiąc kolokwialnie. 

Kolejna rzecz, to możliwość częściowego wykorzystania logiki aplikacji, którą masz. Jeżeli, na przykład, był jakiś bardzo zaawansowany algorytm naliczania kosztów wysyłki czy wyliczania terminu dostaw, czy jakiś bardziej skomplikowany konfigurator, to jest coś, co oczywiście trzeba sobie wytłumaczyć, przepracować i rozpisać, ale faktycznie można też kawałek kodu będzie zmigrować czy przynajmniej odnieść się do tego kawałka kodu. Z jednej więc strony jest tego tłumaczenia trochę mniej, a z drugiej strony jest szansa, że obniży się ten koszt wdrożenia i migracji sklepu. To są takie smaczki, które możemy sobie po prostu zabrać ze starego sklepu i przenieść do nowego w jakimś przynajmniej stopniu. Możesz się też oczywiście lepiej przygotować do tego procesu, bo już wiesz, co poszło nie tak za pierwszym razem. 

Z mojego doświadczenia, firmy, które na etapie wdrożenia zawaliły, na przykład, brief, na etapie migracji radzą sobie już zdecydowanie lepiej. Często też te kompetencje są dużo lepsze, bo na etapie wdrożenia może, na przykład, nie być e-Commerce managera, a na etapie migracji już często taka osoba się pojawia. Firma ma też świadomość, że współpraca w projekcie wdrożeniowym (dlatego nazywa się współpracą, bo obie strony w niej uczestniczą, a nie ma tej takiej typowej relacji między klientem a dostawcą)… Jesteś też w stanie na pewno uniknąć błędów na etapie wyboru agencji czy takiego, nazwałbym to, pobocznego myślenia o tym, jak wygląda proces wdrożeniowy, szczególnie po Twojej stronie, ale też po stronie budżetu i terminu. Tutaj więc te takie lesson learned, jak to się mówi, to jest naprawdę bardzo naprawdę duża wartość dodana w tym procesie. 

Lepiej oczywiście też znasz technologie, jej możliwości i ograniczenia. Potrafisz też pewnie trochę lepiej konfrontować to, czego potrzebujesz, z budżetem, i w pewnym sensie samemu regulować twoje potrzeby, biorąc pod uwagę, jaki masz, na przykład, budżet albo terminy, trochę lepiej też o tych potrzebach mówić, bardziej konkretnie, na przykładach i na poziomie biznesu. Podsumowując: klienci po prostu są bardziej uświadomieni i przygotowani do tego procesu. Można popełnić parę błędów mimo wszystko, więc myślę, że warto, żebyśmy przeżyli to wspólnie jeszcze raz i przygotowali się krok po kroku. 

Co powinien zawierać dobry brief?

Pierwszym z nich, bez którego nie ma sensu nawet wychodzić na rynek, jest przygotowanie briefu. Pierwszym błędem, który można popełnić na tym etapie, jest nieprzygotowanie briefu, czyli wyjście na rynek z informacją, że chcielibyśmy taki sklep, jaki mamy, tylko, na przykład, na PrestaShop albo Magento, albo na innej technologii, ale benchmarkiem jest to, co mamy, bo przecież widać to, co mamy, i po co jakoś mocno się o tym rozpisywać. Warto, zdecydowanie warto, dlatego, że, po pierwsze, nie robimy tego samego. To już, mam nadzieję, wystarczająco wytłumaczyłem, że robienie tego samego, tylko w inny sposób, prawdopodobnie da te same efekty, a już je masz, więc pewnie nie trzeba na to wydawać kupy pieniędzy. 

Z drugiej strony, jeżeli nie rozpiszesz w briefie tego, co potrzebujesz, to trudno tak naprawdę wyłapać, co w tym sklepie funkcjonuje. Trudno złapać skomplikowaną logikę, która może stać za tym sklepem, bo są często, szczególnie w tych customowych rozwiązaniach, takie przypadki, o których nawet właściciel może już nie pamiętać. Napisanie więc tego w briefie mu może trochę przypomnieć, ale jeżeli są takie rzeczy, które raz na jakiś czas się pojawiają, to tym bardziej będzie trudne, żeby o tym wiedziała firma, która wycenia na podstawie tego sklepu, który masz, bo prawdopodobnie tych przypadków po prostu nie zobaczy. 

Z kolejnej strony, patrząc na Twój sklep, który masz aktualnie, to poza tym, że wiadomo, co warto zrobić, bo wynika to z konstrukcji sklepu i to trudno wyłapać, to trudno też wyłapać, czego nie robić, bo zakładam (myślę, że słusznie), że nie wszystko jest tym, co wyszło Ci najlepiej, jak się da, że są funkcje, z których warto by było zrezygnować albo które warto zrobić inaczej. Czasami jest cała logika do posprzątania, czyli tak jakby pozbycie się tego, co przez lata okazało się zbędne albo działające nie do końca tak, jak trzeba, tylko nigdy nie było czasu na posprzątanie tego. Patrzenie więc na stary sklep ma sens chociażby po to, żeby sobie, na przykład, przeklikać jakiś algorytm czy konfigurator i po prostu lepiej to rozumieć, a nie tylko w wersji teoretycznej na podstawie briefu. Ten brief jest jednak superkonieczny, bo samo klikanie tak naprawdę niewiele da. 

O briefie był jeden odcinek, będzie podlinkowany w notatkach, natomiast żeby nie skakać między odcinkami, to tak na szybko: pamiętaj, żeby w briefie było o biznesie, czyli tym, gdzie jesteś, dokąd zmierzasz, w jaki sposób ta platforma, którą chcesz wdrożyć i zmigrować ze starej, ma Ci w tej podróży pomóc, jakie masz plany rozwojowe – może są to dodatkowe rynki, uruchomienie sprzedaży dla nowej grupy docelowej. Te informacje biznesowe pomagają agencji trochę lepiej zrozumieć Twoje cele. 

Kolejną rzeczą są klienci, czyli skąd ich masz, w jakim systemie nimi zarządzasz, w jakim zakresie, czy oni jakoś się łączą w subkonta, czy mają jakieś specjalne uprawnienia, czy grupujesz ich ze względu, na przykład, na funkcje w sklepie, ceny produktów czy inne rzeczy, które się dzieją w związku z podziałem klientów. 

Następna rzecz to produkty. I znowu – skąd je bierzemy, jakie dane są przesyłane pomiędzy systemami, czy są produkty konfigurowalne, wirtualne, czy mamy jakieś opcje obsługi, jakie dane produktowe będą zarządzane w sklepie, no i ogólnie wszystko, co dotyczy produktów. 

W dalszej kolejności są zamówienia. Myślę, że nie ma sensu specjalnie się rozgadywać. Kwestie marketingowe, czyli wszelkiego rodzaju możliwości zarządzania promocjami, treścią na stronie, jakimiś bannerami, jakie placementy potrzebujesz, jakiego rodzaju promocje chcesz używać. 

Na koniec dwie superważne rzeczy, bo zawsze mówię, że na koszt sklepu składa się kilka bardzo dużych składników kosztotwórczych. To jest oczywiście wygląd, rozwiązania customowe, których dana platforma nie ma, no i integracje. Na koniec więc jeszcze opowiemy o procesach, które zachodzą w sklepie, czyli w jaki sposób obiekty przechodzą pomiędzy różnymi systemami, ile tych systemów jest, jakie są tam interwały, w jaki sposób zintegrować je z tymi poszczególnymi systemami, bo to będzie bardzo mocno rzutowało na wycenę i to zawsze tak po prostu jest. 

Na koniec ostatnia rzecz, i to jest taka zasadnicza różnica pomiędzy nowym wdrożeniem a migracją. Jest to po prostu migracja danych. Migruje się różnie, ponieważ do zmigrowania są te standardowe rzeczy, czyli produkty, zamówienia, klienci i treści, funkcje. Zakładam, że jest to proces wdrożeniowy, natomiast nie w każdym zakresie musimy to robić. Jeżeli w sklepie funkcjonują integracje, zwróć uwagę, że może być na przykład tak, że ogólnie rzecz ujmując, sklep nie jest źródłem prawdy i zarządzania miejscem i danymi. 

Symulując, może być tak, że masz system do zarządzania danymi produktowymi, z kolei klientami, zamówieniami zarządzasz w systemie ERP. Wszystko to, co jest w sklepie, będzie też w PIM-ie i będzie też w systemie ERP. W związku z tym, biorąc pod uwagę, że nowy sklep też będziesz integrować z PIM-em i z systemem ERP, to tak naprawdę ta sama, mówiąc bardziej obrazowo, rura, którą będą chodziły dane bieżące, może posłużyć jako rura, za pomocą której pobierzemy sobie historyczne dane. Wtedy rzeczywiście nie ma sensu migrować ich ze sklepu. Z tą oczywiście gwiazdką, że są rzeczy, którymi czasami zarządza się tylko po stronie sklepu. Jeżeli masz, na przykład, system ERP, z którego pobierasz sobie dane produktowe, bo nie masz PIM-a, to wiadomo, że w systemie ERP nie będzie za dużo mądrych danych, bo to są tylko jakieś podstawowe indeksy, atrybuty, nazwa, może kategoryzacja ceny i stan magazynowy, a wszelkie zdjęcia, opisy produktowe, jakaś zaawansowana atrybucja może być tylko w sklepie. Wtedy rzeczywiście te dane trzeba przenieść, ale warto mieć tego świadomość, bo rzeczywiście może się okazać, że tak naprawdę do zmigrowania są tylko treści i podstawowe informacje o sklepie. Tej pracy wtedy i tak jest dużo, ale plus jest taki, że możesz ją wykonać we własnym zakresie i wtedy jest też po prostu taniej, ale, tak czy inaczej, warto wiedzieć, jakie dane warto zmigrować, jakich nie i w jaki sposób to robić. 

Tutaj jeszcze ostatnia dygresja, która sprowadza się do tego, że firmy często decydują się świadomie pewnych danych nie przenosić i po prostu albo się od nich zupełnie odciąć, albo zrobić je od nowa. Szczególnie ma to zastosowanie w przypadku produktów i zamówień. Często firmy decydują się nie wykonywać migracji produktów, tylko pobrać z ERP-a podstawowe atrybuty, a resztę po prostu zrobić od nowa, bo te stare opisy nie do końca są jakościowe. No i historia zamówień – często jest tak, że firmy decydują, że jest im to po prostu niepotrzebne, utrzymują na przykład jeszcze jakieś archiwum zamówień na starym sklepie, żeby móc do tego wrócić, albo całkowicie się od tego odcinają, żeby po prostu nie brudzić w statystykach. 

Podsumowując, brief – i tutaj nie będę jakiś mocno odkrywczy – warto opisać tak samo, z takim samym zaangażowaniem i poświęcając tak samo dużo czasu, jak w przypadku tworzenia nowego sklepu, z dodatkiem migracji danych i zakresu tejże migracji. Plusem na pewno jest to, że poza tym, że jest to treść czysto literacka, to możesz też posiłkować się screenami ze starego sklepu, jakimś filmem czy po prostu wskazać miejsce, gdzie to jest zrobione. Jeżeli więc jesteś dumny z jakiegoś algorytmu, wtedy rzeczywiście może nie ma sensu jakoś go mocno opisywać, tylko po prostu wskazać na etapie pisania briefu, jak on funkcjonuje w obecnym sklepie, i to może być wystarczające, a często dużo lepsze, niż po prostu mówienie o tym w wersji czysto dokumentowej. 

Jak wybrać odpowiednią agencję do przeprowadzenia migracji e-Commerce?

Kolejnym krokiem w przygotowaniu jest wybór agencji. Biorąc pod uwagę, że odbywam mnóstwo rozmów z firmami, które przechodzą proces migracji, a nie kojarzę, żebym odpowiadał za wdrożenie starego sklepu, to wynika z tego, i rzeczywiście tak w praktyce jest, że migracja technologii jest tak naprawdę najlepszym momentem do zmiany agencji, jeżeli oczywiście sytuacja tego wymaga, bo można po prostu bez przyuczania do starego systemu, bez przejmowania spadków w postaci nie zawsze fajnie funkcjonującego sklepu pozbyć się po prostu tego bagażu, który narósł w toku lat współpracy z obecną agencją. 

Jeżeli chodzi o powody, dla których w tym wypadku zmienia się agencję, to bardzo często były to, z moich doświadczeń, niewystarczające kompetencje wdrożeniowe. To może być też zła organizacja w projekcie na etapie wdrożenia i po prostu nie chcesz tego powtarzać w przypadku kolejnego, de facto, wdrożenia z dodatkiem migracyjnym. To oczywiście może być niedowieziona jakość, termin, budżet lub wszystko na raz w takim skrajnym wypadku. To może być też słaba komunikacja, jakiś wysoki poziom rotacji w zespole, który zaczął ci doskwierać, brak wystarczającego wsparcia powdrożeniowego czy brak zrozumienia biznesu. 

Nie będziemy się tu mocno, myślę, rozwadniać na temat agencji. Na pewno jest tak, że warto poświęcić na to bardzo dużo czasu. Myślę, że czas poświęcony w ogóle na pisanie briefu i wyboru agencji to jest zawsze mniejszy koszt, niż później ten koszt związany z wymiksowaniem się z agencji czy naprawianiem po niewłaściwie napisanym briefie, ale o tym pewnie już wiesz. W przypadku agencji warto na pewno spoglądać na kompetencje, na poziom organizacji w projekcie, sposób komunikowania się z klientem, oczywiście portfolio, budżet też. Myślę natomiast, że coraz mniej jest firm, które patrzą tylko na budżet, i chwała im za to, bo właściwie budżet to mało reprezentatywny wskaźnik, który może posłużyć do wyboru agencji, ale, tak czy inaczej, o wyborze agencji też był osobny odcinek, w związku z czym też go, oczywiście, podlinkuję do notatek. 

Pamiętaj, że, po pierwsze, jeżeli chodzi ci po głowie zmiana agencji, to to jest świetny moment. Oczywiście, nie zawsze tak musi być. Jak to mówią: zwycięskiej drużyny i zwycięskiego składu się nie zmienia. W związku z tym, jeżeli jesteś zadowolony, warto przy tym układzie trwać, po prostu rozwijać się dalej z tą samą agencją, tylko z nową technologią. 

Jeżeli nie, a tych powodów może być dość dużo, wtedy warto rozejrzeć się po rynku. Ten proces powinien wyglądać tak, jak przy wyborze agencji do projektu wdrożeniowego, z tą różnicą, że, znowu, masz po prostu trochę lepsze kompetencje i lepsze rozeznanie na rynku, wiesz, czego unikać i o co pytać, więc ten wybór będzie troszeczkę, myślę, bardziej świadomy. 

Z mojego punktu widzenia, tak jak rozmawiam z firmami, które decydują się na migrację, to te spotkania przedwdrożeniowe i jeszcze przed rozpoczęciem projektu mają naprawdę dużo bardziej praktyczny wymiar. Firmy zadają bardzo wcelowane pytania, z których też często wynika, co było problemem, bo potrafią zapytać mnie o to, na przykład, w które miejsce wrzucamy kod do… Albo może inaczej: na jakim serwerze testujemy i czy klient ma dostęp do tego serwera. I wtedy już widać, że tak naprawdę klient nie miał prawdopodobnie dostępu do serwera z poprzednią agencją, co mogło rodzić na przykład takie problemy, że był kiedyś szachowany, że mu wyłączą serwer, jak nie zapłaci faktury, czy coś w tym stylu. To są więc takie rozmowy, które wskazują bardzo często na problemy. O tym warto pamiętać. Pamiętaj też o tym, żeby po tym odcinku posłuchać tych dwóch o wyborze agencji i jej zmianie oraz przygotowaniu briefu. Myślę, że to też trochę ci tej wiedzy rozwinie, a my idziemy dalej.

Co powinieneś zrobić kończąc proces migracji?

Dalej to już jest proces wdrożenia, ale o nim nie będę Ci dzisiaj opowiadał, dlatego że jest to temat nie na 10 minut, nawet nie na jeden odcinek, tylko prawdopodobnie moglibyśmy zrobić z tego całą serię. Myślę, że to jest też nawet niegłupi pomysł, żeby taka seria powstała o tym, jak krok po kroku wdraża się takie sklepy internetowe, żebyś mógł się lepiej poruszać w tym procesie, który często trwa bardzo, bardzo długo. Natomiast, biorąc pod uwagę, że masz tę przewagę w postaci tego, że raz już proces wdrożeniowy przechodziłeś, to pewnie wiesz, czego się spodziewać z w miarę dużym prawdopodobieństwem albo czego unikać, bo za pierwszym razem Cię bolało. 

My tym razem skupimy się na tym, co tak naprawdę po tym procesie zrobić, czyli jak zakończyć proces wdrożeniowy, proces migracji. Najpierw może o tym, co sprawdzić na koniec tego wdrożenia. Najczęściej momentem golive’u jest to, że wszystkie funkcje działają, sklep jest przygotowany od strony treści, więc możemy go uruchomić i pójść sobie na żywo i zbierać klientów, natomiast przy migracji jest troszeczkę więcej pracy do wykonania. 

Po pierwsze, po uruchomieniu warto sprawdzić wszystkie przekierowania adresów URL, czyli zadbać o to, żeby nowy serwis nie generował Ci masy „404″. One wynikają z tego, że tak naprawdę stare adresy są zaindeksowane w wyszukiwarkach internetowych, w związku z czym, jeżeli miałeś kiedyś, na przykład, stronę z butami, to ona była pod www.adres-twojego-sklepu.pl/produkty/buty.html, natomiast w nowym będzie to troszeczkę inny adres. Może to być, na przykład: /kategoria/buty czy jeszcze inaczej, natomiast, tak czy inaczej, te różnice prawdopodobnie będą, tym bardziej że każda technologia trochę inaczej podchodzi do adresacji. Zanim wyszukiwarka będzie miała te adresy już w nowej wersji, to stare będą funkcjonowały i będą generowały błędy „404”. 

Rozwiązuje się to w taki sposób, że wykonuje się mapy przekierowań. Mówi się wyszukiwarce czy botom, że tamten stary adres to tak naprawdę ten nowy adres i warto zadbać o to, żeby wszystkie adresy ze starego sklepu były odpowiednio przekierowane. Jest to praca żmudna, ale da się ją w pewnym sensie zautomatyzować, a jeżeli masz sidemapę starego sklepu, czyli taki plik .xml z pełną listą adresów w sklepie, to przynajmniej wiesz, co jest do zrobienia. 

Jest to niezwykle istotne, dlatego że już pomijając w ogóle wygodę użytkownika, która też jest ważna, ale przede wszystkim warto się skupić tutaj na wyszukiwarkach internetowych. Jeżeli Google przeleci sobie po starej sidemapie i zobaczy, że wszystkie adresy to jest „404”, to może dojść do wniosku, że Twoja strona po prostu zniknęła z sieci, więc wypnie Ci wszystkie wyniki wyszukiwania, jakie miałeś. 

Wypięcie wyników wyszukiwania z wyszukiwarki internetowej brzmi jak taki naprawdę bardzo duży i ostry gwóźdź do trumny, którą przybije wyszukiwarka internetowa Twojemu sklepowi internetowemu i tak najczęściej się dzieje – spadki widoczności równają się spadkom ruchu. Tego nie da się przeskoczyć, szczególnie spadku ruchu organicznego, który oznacza po prostu spadki w przychodach. Tego należy się bać, unikać i się przygotować na to. 

Większość agencji będzie o tym pamiętała, natomiast jest jeszcze plan B pod tytułem: „firma od SEO”. Jeżeli będziesz w takiej sytuacji, w której nie masz firmy od SEO i trafisz na bardzo niedoświadczoną agencję, a jednocześnie Ty tego nie przypilnujesz, bo na przykład zapomnisz, to będzie z tego, mówiąc językiem ulicy, straszny przypał. Tego trzeba po prostu unikać. Da się później to w jakimś stopniu uratować, ale lepiej temu zapobiegać i te przekierowania po prostu zrobić. 

Kolejną rzeczą do sprawdzenia są na pewno dane produktowe i kategorie. Warto na wyrywki posprawdzać, czy te dane są przeniesione jeden do jednego, czy produkty zgłaszają się pod odpowiednimi kategoriami, czy dobrze się wyszukują, czy nie pomieszały się jakieś atrybuty, czy wszystkie warianty produktowe są, czy dostępność na magazynie się zgadza, ceny się zgadzają, czy zdjęcia są dobrze popodpinane do produktów, czyli generalnie to wszystko, co mogło nam się rozjechać w trakcie. 

Podobnie, jeżeli chodzi o dane klientów i dane historyczne ich zamówień. Tutaj też mała dygresja: warto pamiętać o tym, że raczej haseł klientów nie przeniesiesz. Dzieje się tak dlatego, że każdy sklep ma trochę inny sposób szyfrowania i raczej nie ma sensu go zmieniać. Mam nadzieję, że nie znasz haseł swoich klientów i one nie są zapisane w bazie danych po prostu czystym tekstem, chociaż znam różne sytuacje. Miejmy nadzieję, że tak nie jest. W związku z tym masz w bazie danych hasło, które jest zaszyfrowane, więc nie wiesz, jakie jest prawdziwe. 

W nowej bazie byłoby to zupełnie inna wartość, bo to szyfrowanie by przebiegało w inny sposób, w związku z czym trudno jest z jednego zrobić drugie. Rozwiązuje się to w taki sposób, że robi się dużą akcję informacyjną na temat migracji, mówi się klientom, że ten sklep się zmienił, że trzeba zresetować swoje hasło, przypomina się o tym później na sklepie i tyle. Jest to jakaś tam dodatkowa czynność, którą musi wykonać klient, ale tak po prostu z migracją jest. 

Warto też zadbać o to, żeby te dane były spójne, bo z tym niestety różnie bywało. Znam sytuacje, że rzeczywiście popodpinały się nie te adresy, nie te zamówienia do klienta, i mógł sobie trochę poczytać, a RODO, tak jak ROI, mimo że ma cztery litery zamiast trzech, to żartem też absolutnie nie są i kary bywają dość dotkliwe, jeśliby to jakoś tam wyszło w dużej skali. Przede wszystkim warto też dbać o reputację sklepu i o to, żeby nie być bohaterem kolejnych wpisów na social mediach, jak to po procesie migracji posypały się dane. 

Kolejną rzeczą są oczywiście funkcje, które musimy sprawdzić, czyli warunki brzegowe dla algorytmu, warunki cenowe dla klientów, sposób naliczania kosztów dostawy, jakieś customowe funkcje, które działały. Oczywiście, także cały proces integracyjny – czy to wszystko nam działa, przeniosło się jeden do jednego, czy chociażby nie jest tak, że algorytm, który w starej wersji pięknie naliczał daty dostawy, w nowej robi to już nie tak do końca pięknie, bo, na przykład, nie wziął pod uwagę weekendów, świąt ruchomych, czy na przykład godziny są źle ustawione, i później będzie z tego chryja na poziomie realizacji zamówień. 

To wszystko więc, co powodowało o przewadze starego sklepu, po prostu trzeba zweryfikować porządnie, najlepiej w sposób porównawczy, jeżeli robimy to dokładnie tak samo w nowym sklepie, i upewniać się, że to po prostu działa zgodnie z przewidywaniem. Bardzo podobnie ma to miejsce w przypadku wdrożenia nowego sklepu, tylko tu jeszcze musimy to po prostu porównać ze starą wersją sklepu, czy na pewno jest to dokładnie tak, jak było. 

Ostatnia rzecz, i o tym się często zapomina (w sumie nie wiem czemu, może dlatego, że mało kto na to po prostu patrzy), to narzędzia zewnętrzne. Jeżeli masz jakiegoś Analytics, HotJar, narzędzie do marketing automation, obsługi klienta czy jakieś czaty – to wszystko trzeba poprzenosić. Nie tylko po prostu popodpinać w nowym sklepie, ale często też zmigrować te funkcje. Jeżeli Google, na przykład, w jakiś sposób mierzył Twój proces zakupowy i to było skryptowane, trzeba to oskryptować też na nowym wyglądzie sklepu i to często jest taka grubsza praca do wykonania, niż na pół godziny po tym, jak sobie przypomnisz po migracji, że to się nie udało. Warto więc też to sobie zaplanować. 

Po tym procesie teoretycznie wszystko powinno być OK. Jedyne, co Ci zostanie zrobić, to powiadomić klientów o tym, że ta migracja nastąpiła, pochwalić się o tym na social media, bo oczywiście warto i proces był skomplikowany, no i liczyć na to, że wyniki sprzedażowe będą dzięki temu coraz wyższe. 

Jakie błędy najczęściej popełniają firmy podczas migracji sklepu internetowego?

Zanim skończymy, opowiem Ci jeszcze o błędach, które można wykonać podczas migracji i na nie naprawdę polecam zwrócić szczególną uwagę. Tych błędów będzie sześć i w jakiś sposób też będą podsumowywały to, o czym sobie dzisiaj cały czas opowiadaliśmy. 

Pierwszym błędem jest przenoszenie sklepu jeden do jednego, czyli robienie tego samego w ten sam sposób i oczekiwanie innych efektów. Jest to według „internetów” definicja szaleństwa, którą chyba nawet przedstawił Einstein, chociaż nie sądzę, żeby to była prawda, a już na pewno nie jest tak, że ja w to tak bezgranicznie wierzę, bo to jest prawda, której źródłem jest „do trust me”, a jak wiadomo, „internetom” nie zawsze się wierzy, ale generalnie tak rzeczywiście jest, że nie bądźmy szaleńcami i nie róbmy tego samego, spodziewając się innych efektów. 

Drugim błędem jest lekceważenie SEO i to rzeczywiście może naprawdę poturbować porządnie biznes. Bardzo często tak jest, że migrację w ogóle ocenia się po tym, jak ona wpływa na SEO i powinno być tak, że raczej wpływa dobrze. W najgorszym przypadku nie wpływa wcale, a negatywny wpływ to w ogóle zostawiamy już dla odważnych i dla szaleńców. Często tak jest, że branża w ogóle faktycznie, jak gdzieś tam chce pojechać po konkurencji, to na przykład pokazuje im wykres z SEM Storm, jak im pozycje pospadały, więc warto temu zapobiec. 

Kolejną rzeczą jest zły termin wdrożenia. Tutaj jest to coś podobnego do procesu wdrożeniowego, mimo że migracja jest czymś, co już raz przechodziłeś, czyli nowym wdrożeniem plus paroma rzeczami organizacyjnym. Są lepsze i gorsze terminy na wdrożenie nowego sklepu. Raczej warto po prostu nie robić tego w środku sezonu. W takiej makro-, mikroskali nie warto tego robić w godzinach szczytu, kiedy ludzie kupują, bo to trochę będzie trwało. Sam proces przepinania w ogóle będzie trochę trwał i nie zawsze musi się udać, więc warto mieć plan B. 

Ten plan B na mikroskalę to jest po prostu odpowiednia godzina. Plan B na makroskalę to jest zrobienie tego w takim momencie, w którym, jeżeli by coś się wydarzyło z Twoją sprzedażą, na przykład chwilowe spadki w wyszukiwarce internetowej, które się oczywiście zdarzają (i tutaj nie ma się czym przejmować – ważne, żeby nie były to długotrwałe spadki), to żeby te krótkotrwałe spadki przypadały na okres, w którym ta sprzedaż jest po prostu mniejsza i jakoś tak nas specjalnie nie zaboli. 

Znowu – migracja to jest po prostu nowy sklep, więc tam mogą się pojawić innego rodzaju problemy – jakieś błędy na małym procencie użytkowników. To mogą być problemy wydajnościowe, które też nie wyszły na etapie wdrożeniowym. Warto więc zrobić to w takim terminie, żebyś Ty też miał czas, żeby tym później zarządzić i oszczędzić sobie frustracji z tytułu spadków sprzedaży w najważniejszym okresie Twojej sprzedaży rocznej. 

Kolejną rzeczą jest brak testów porównawczych, czyli wdrożenie bez patrzenia, jak to działało w starym sklepie. Można oczywiście tak zrobić, ale jeżeli to jest kluczowa funkcja dla klientów, na przykład algorytm wyliczania ich ceny dostawy, to, jeżeli będą mieli w starym sklepie lepsze ceny niż w nowym, będzie z tego problem, bo po prostu do nowego nie będą chcieli przejść. 

Jak już rozmawiamy sobie o tym, że coś może pójść nie tak i nie zadziałać, warto pomyśleć o tym, czy nie potrzebujesz pilotażu, czyli wpuszczenia, na przykład paru klientów do testu nowej platformy w taki sposób, żeby przetestowali to ze swojego punktu widzenia. Jeżeli masz takich zaufanych klientów, to umówmy się, że tydzień „wte i wewte”, pewnie Twojej platformie i Twojemu rynkowi nie zrobi dużej różnicy, a w tym czasie klienci mogliby sobie coś potestować i dać jakiś cenny feedback na temat tego, czy wszystko dobrze działa. W najgorszym wypadku będziesz miał po prostu trochę więcej pracy przed golive, a w najlepszym upewnisz się, że wszystko jest OK, więc w zasadzie czemu nie. 

Dużym błędem jest pominięcie czegoś istotnego. To się w sumie rzadko zdarza, ale może się okazać, że jest to coś istotnego, o czym mało kto pamięta, czyli na przykład jakaś funkcja, która jest używana raz w roku i ktoś po prostu o tym nie pomyśli, i później jest taki moment objawienia, że w sumie: „kurczę, my mieliśmy jakieś tam akcje specjalne z firmą zewnętrzną, jest to raz na jakiś czas, ale to jest superważne i zróbmy to na wczoraj”. To się niestety zdarza, ale też pokazuje, jak ważne jest to, żeby ten brief był dobrze napisany, jak ważne jest to, żeby też tę starą platformę wziąć tak porządnie pod uwagę. Na pewno bardzo dużą wartością jest dobra dokumentacja techniczna poprzedniej platformy czy, na przykład, historia rozwojowa, czy brief, który doprowadził do powstania nowego sklepu. Te wszystkie dokumenty warto więc sobie przesłać, bo z nich może po prostu dużo wynikać i im większa szansa, że ktoś to wyłapie, tym lepiej. 

Ostatnia rzecz, o której Ci dzisiaj powiem w kontekście błędów i w ogóle, o której Ci dzisiaj powiem, to jest pominięcie narzędzi zewnętrznych, czyli to, co mówiłem na sam koniec przy sprawdzaniu poprawności migracji. Często jest tak, że po prostu ktoś zapomni o tym, że Analytics to nie jest tylko to, co pokazuje użytkowników na żywo w sklepie i przez parę dni czy nawet może i tygodni będzie sytuacja, w której masz nieprawidłowe dane. 

To nie jest takie do końca fajne, bo później będzie trzeba pamiętać o tym, że to jest miesiąc do miesiąca. Jeszcze trzeba pamiętać, że w starym miesiącu były jakieś problemy, albo kwartał do kwartału, rok do roku. Niby tam rok do roku to nie jest jakoś dużo, bo, powiedzmy, jest to tylko jedna dwunasta problemów, jeśli przez cały miesiąc było coś nie tak, ale 1/12 no to dalej jest jakaś statystyka, której po prostu nie warto tracić. Warto więc te narzędzia też migrować razem ze sklepem i o tym pamiętać. 

Dochodzimy do końca migracji – procesu, który, tak spinając klamrą do kupy ten odcinek, czeka każdego z nas. Prawdopodobnie, jeżeli Cię nie czeka migracja, to znaczy, że Twój biznes po kilku latach od wdrożenia chyli się ku końcowi. W każdym wypadku raczej ta migracja będzie musiała kiedyś prędzej czy później nastąpić. Mam nadzieję, że po tym odcinku lepiej wiesz, kiedy ten moment jest. Mam nadzieję, że wiesz też, jak się do niego przygotować, a także czego unikać. Życzę Ci powodzenia.