Najděte a vyřešte duplicitní SKU a téměř duplicitní produkty
Nejdřív exportujte celý seznam produktů a zkontrolujte přesné duplicity SKU — obvykle jde o chybu při zadávání dat nebo importu a jakmile je najdete, je snadné je sloučit. Pak hledejte téměř duplicitní produkty: stejný produkt znovu vytvořený pod jiným SKU, často výsledek opětovného importu dodavatelského feedu, který se nespároval s existujícími záznamy, nebo produkt, který byl po systémové změně ručně znovu vytvořen místo upraven.
U každé dvojice duplicit rozhodněte, který záznam je ten „skutečný“ — obvykle ten s kompletnějšími daty, delší historií objednávek nebo lepšími SEO signály jako zpětné odkazy či recenze — a ten druhý do něj sloučit nebo na něj přesměrovat, místo abyste migrovali oba a řešili to až později na nové platformě.
Vypátrejte osiřelé obrázky a média
Osiřelá média — obrázky a soubory nahrané do vaší knihovny médií, na které už žádný produkt, kategorie ani obsahová stránka neodkazuje — se přirozeně nahromadí za roky aktualizací produktů, sezónních kampaní a změn platforem. Na nové platformě nepřinášejí žádnou hodnotu a jen prodlužují čas migrace a zabírají úložiště, takže se vyplatí je identifikovat a vyloučit.
Pozor si dejte i na opačný případ: obrázky, na které se odkazuje, ale které jsou nefunkční (chybějící soubor, mrtvá externí URL adresa), stojí za odhalení už teď, protože nefunkční obrázek na stránce produktu je malý, ale reálný problém pro důvěryhodnost — a je mnohem snazší ho opravit u vašich současných, dobře známých dat než až po přechodu.
Sjednoťte kategorie a atributy
Roky nahodilých přidávání mají tendenci nechat kategorie a atributy nekonzistentní: stejný pojem napsaný nebo psaný velkými písmeny jinak u různých produktů, kategorie, které se překrývají nebo duplikují, atributy používané pro jeden účel u jedné produktové řady a pro jiný účel u jiné. Tato nekonzistence obvykle na staré platformě nezpůsobuje viditelné problémy, protože se ji zaměstnanci naučili obcházet, ale stává se skutečnou zátěží, jakmile se mechanicky namapuje na datový model nové platformy.
Před migrací sestavte (nebo potvrďte) čistou, odsouhlasenou taxonomii — definovaný strom kategorií a definovaný seznam atributů s konzistentním pojmenováním — a svá skutečná data proti ní sesouhlaste. Je to také chvíle, kdy stojí za to se zeptat, které atributy jsou pro zákazníky nebo interní provoz stále smysluplné a které existují jen proto, že je nikdo neodstranil.
Sesouhlaste neshody ve struktuře variant
Struktury variant (velikost, barva, materiál a to, jak se kombinují do konkrétních prodejných SKU) řeší každá platforma jinak a nekonzistentní zdrojová data to jen zhoršují. Hledejte produkty, kde variantní možnosti nedodržují konzistentní vzorec — u některých variant velikosti pojmenovaných „S/M/L“ a u jiných v rámci stejné produktové řady „Small/Medium/Large“, nebo produkty, kde kombinace variant v systému existuje, ale nemá za sebou platnou cenu ani skladovou dostupnost.
Rozhodněte cílový model variant před migrací, ne během ní. Vědět předem, zda nová platforma řeší kombinace variant stejně jako ta stará — a kde ne — určuje, jestli se vaše stávající data o variantách dají namapovat přímo, nebo je nejdřív potřeba restrukturalizovat.
Rozhodněte, co se skutečně musí přenést
Ne všechno ve vašem současném katalogu si zaslouží místo na nové platformě. Ukončené produkty bez zbývající skladové zásoby, testovací nebo zástupné záznamy a starší pole, u nichž už nikdo nedokáže vysvětlit původní účel, jsou vhodnými kandidáty na to zůstat vzadu — s zdokumentovaným rozhodnutím, ne tichým vypuštěním. Migrovat méně, ale záměrně, je často lepší než migrovat všechno a řešit to až později na neznámém novém systému.
U čehokoli, co se rozhodnete nemigrovat, ale co má stále indexovanou URL adresu, se ujistěte, že je to zahrnuté ve vašem plánu přesměrování (viz průvodce mapováním přesměrování), místo aby to omylem skončilo na chybě 404.
Časté otázky
Kolik času máme vyhradit na čištění dat před migrací?
Hodně záleží na velikosti katalogu a tom, jak nepořádná data skutečně jsou — malý, dobře udržovaný katalog potřebuje mnohem méně času než katalog s desítkami tisíc SKU a roky importů z dodavatelských feedů. Skutečný rozsah vám řekne až audit dat; přeskočení auditu a odhad je způsob, jak se čas na čištění podcení.
Máme čistit data před projektem migrace, nebo během něj?
Před ním, nebo přinejmenším jako výslovnou samostatnou fázi s vlastním krokem kontroly — ne smíchané s technickým přenosem dat. Rozhodnutí o čištění (co je duplicita, co je bezpečné vypustit, k čemu bylo záhadné vlastní pole) obvykle vyžadují vstup od někoho, kdo zná historii katalogu, a to je jiný druh práce než samotné technické mapování a přenos.
Co když si nejsme jistí, jestli je duplicita skutečně duplicita?
Označte to, místo abyste hádali jedním nebo druhým směrem. Téměř duplicitní produkt s odlišnou cenou, odlišnými variantními možnostmi nebo odlišnou historií objednávek může být legitimní samostatný produkt, který jen vypadá podobně. V nejistotě ponechte oba a vraťte se k tomu po dokončení auditu, místo abyste je slučovali na základě odhadu.
Může čištění dat probíhat, když starý obchod stále běží a přijímá objednávky?
Ano, u většiny práce na auditu a plánování — kontrola exportů, rozhodování o sloučeních a stavba cílové taxonomie nevyžadují zásah do živého obchodu. Skutečné provedení změn (sloučení záznamů, mazání osiřelých médií) je obvykle bezpečnější dělat na kopii nebo exportu a vyčištěnou sadu dat pak přinést do migrace, ne upravovat živý katalog uprostřed auditu.