Czyszczenie danych produktowych przed migracją

Wyeksportuj pełną listę produktów i najpierw sprawdź dokładne duplikaty SKU — to zwykle błąd wprowadzania danych lub importu i są proste do scalenia po znalezieniu. Następnie poszukaj bliskich duplikatów: tego samego produktu odtworzonego pod innym SKU, często w wyniku ponownego importu feedu dostawcy, który nie dopasował się do istniejących rekordów, albo produktu ręcznie odtworzonego zamiast edytowanego po zmianie systemu.

Dla każdej pary duplikatów zdecyduj, który rekord jest tym „prawdziwym” — zwykle ten z bardziej kompletnymi danymi, większą historią zamówień lub lepszymi sygnałami SEO jak linki zwrotne czy opinie — i scal albo przekieruj drugi do niego, zamiast migrować oba i rozwiązywać to później na nowej platformie.

Osierocone media — obrazy i pliki wgrane do biblioteki mediów, do których nie odwołuje się już żaden produkt, kategoria czy strona treściowa — naturalnie narastają przez lata aktualizacji produktów, kampanii sezonowych i zmian platformy. Nie dodają żadnej wartości na nowej platformie, a jedynie wydłużają czas migracji i zwiększają zajętość miejsca, więc warto je zidentyfikować i wykluczyć.

Uważaj też na przypadek odwrotny: obrazy, do których się odwołuje, ale które są zepsute (brakujący plik, martwy zewnętrzny adres URL), warto wyłapać teraz, ponieważ zepsuty obraz na stronie produktu to mały, ale realny problem sygnału zaufania, dużo łatwiejszy do naprawienia przy Twoich obecnych, znanych danych niż po przenosinach.

Lata doraźnych dodatków mają tendencję do pozostawiania kategorii i atrybutów niespójnymi: to samo pojęcie zapisane lub napisane wielkimi literami inaczej w różnych produktach, kategorie, które się nakładają lub dublują, atrybuty używane w jednym celu w jednej linii produktowej i w innym celu w drugiej. Ta niespójność zwykle nie powoduje widocznych problemów na starej platformie, gdzie personel nauczył się jej obchodzić, ale staje się realnym obciążeniem, gdy zostanie mechanicznie zmapowana na model danych nowej platformy.

Zbuduj (lub potwierdź) czystą, uzgodnioną taksonomię przed migracją — zdefiniowane drzewo kategorii i zdefiniowaną listę atrybutów ze spójnym nazewnictwem — i zweryfikuj wobec niej swoje rzeczywiste dane. To też dobry moment, by zapytać, które atrybuty nadal mają znaczenie dla klientów lub operacji wewnętrznych, a które istnieją tylko dlatego, że nikt ich nie usunął.

Struktury wariantów (rozmiar, kolor, materiał i sposób ich łączenia w konkretne sprzedawalne SKU) są obsługiwane różnie na różnych platformach, a niespójne dane źródłowe pogarszają sytuację. Poszukaj produktów, w których opcje wariantów nie są spójne — niektóre warianty rozmiaru nazwane „S/M/L”, a inne „Small/Medium/Large” dla tej samej linii produktowej, albo produktów, w których kombinacja wariantów istnieje w Twoim systemie, ale nie ma za sobą ważnej ceny czy stanu magazynowego.

Zdecyduj o docelowym modelu wariantów przed migracją, nie w jej trakcie. Wiedza z wyprzedzeniem, czy nowa platforma obsługuje kombinacje wariantów tak samo jak stara — i gdzie tego nie robi — decyduje o tym, czy Twoje istniejące dane wariantów mogą mapować się bezpośrednio, czy najpierw wymagają restrukturyzacji.

Nie wszystko w Twoim obecnym katalogu zasługuje na miejsce na nowej platformie. Wycofane produkty bez pozostałego stanu magazynowego, wpisy testowe czy zastępcze oraz pola historyczne, których pierwotnego celu nikt nie potrafi wyjaśnić, to wszystko kandydaci do pozostawienia — z udokumentowaną decyzją, a nie cichym pominięciem. Migrowanie mniej, ale celowo, jest często lepsze niż migrowanie wszystkiego i rozwiązywanie tego później na nieznanym nowym systemie.

Dla wszystkiego, czego zdecydujesz się nie migrować, a co nadal ma zaindeksowany adres URL, upewnij się, że jest to uwzględnione w Twoim planie przekierowań (zobacz przewodnik po mapowaniu przekierowań), zamiast zostawić to przypadkowo jako błąd 404.