Migrera produktdata: fältmappning, varianter och kategorier

Att migrera produktdata är den del av ett plattformsbyte som avgör hur butiken fungerar dagen efter lansering. Design går att justera i efterhand och integrationer går att felsöka — men om produktdatat kommer över fel står du med tomma attribut, trasiga varianter och kategorier som inte hittar sina produkter, mitt i en nylanserad butik. Det här är också den del av projektet som oftast underskattas, eftersom den ser ut som en exportfil och en importknapp men i själva verket är ett översättningsarbete mellan två olika datamodeller.

Den här guiden går igenom de tre momenten som avgör resultatet: fältmappningen, varianthanteringen och kategoristrukturen — plus det förarbete som gör alla tre enklare.

Migrera produktdata i rätt ordning: städa först

Varje produktkatalog som levt några år bär på sediment: utgångna artiklar, testprodukter, dubbletter, attribut som fylls i på tre olika sätt beroende på vem som lade upp produkten. Att flytta det rakt över till en ny plattform är att betala för att flytta skräp.

Gör en gallring innan mappningsarbetet börjar:

• Arkivera produkter som utgått och inte ska säljas igen.
• Slå ihop dubbletter och bestäm vilken post som är sanningen.
• Enhetliga attributvärden: ”Blå”, ”blå” och ”BLÅ” ska bli ett värde, inte tre.
• Identifiera vilka fält som faktiskt används i butiken — och vilka som bara följt med.

Städningen är också rätt tillfälle att fundera på var produktdatat ska bo framöver. Underhålls det i dag i kalkylark vid sidan av plattformen är det ett tecken på att butiken saknar ett riktigt produktinformationsflöde — mer om det längre ner.

Fältmappning: översättningen mellan två datamodeller

Fältmappningen är kärnan i arbetet: en tabell där varje fält i källplattformen får en motsvarighet i målplattformen. Namn, SKU, priser, lagersaldon, beskrivningar, attribut, bilder, SEO-fält, relationer som tillbehör och reservdelar — allt ska ha en rad.

Tre typer av fält kräver särskild uppmärksamhet:

1. Fält som inte har någon självklar motsvarighet. Plattformar delar inte datamodell. Ett fritextfält i källan kan behöva bli ett strukturerat attribut i målet, eller tvärtom. Varje sådant fall är ett beslut — dokumentera det.
2. Fält med olika format. Priser med och utan moms, mått i olika enheter, HTML i beskrivningar som ska renderas annorlunda. Här behövs transformeringsregler, inte bara mappning.
3. B2B-datat. Kundspecifika priser, staffling, avtalssortiment och kundgrupper är ofta det mest affärskritiska datat och det som skiljer sig mest mellan plattformar. Kör ni både B2B och B2C är det värt att välja en plattform som har båda affärerna i samma kärna så att datat inte behöver dubbleras.

Gör en testmigrering med ett representativt delsortiment — några enkla produkter, några komplexa, några med specialfall — och låt de som kan sortimentet granska resultatet innan hela katalogen körs. Räkna med flera vändor; det är så det ska gå till.

Varianter: där de flesta migreringar går snett

Varianthantering är den punkt där plattformarnas datamodeller skiljer sig som mest. Magento bygger konfigurerbara produkter av fristående enkla produkter, WooCommerce har variationer under en huvudprodukt, Shopify bygger varianter av ett begränsat antal alternativ. Samma tröja i fem storlekar och tre färger representeras alltså på tre helt olika sätt — och din migrering ska översätta mellan dem.

Frågorna som måste besvaras innan varianterna flyttas:

• Vilka attribut styr varianterna — och finns de som strukturerade värden i källan, eller ligger de inbakade i produktnamnen?
• Har varje variant egen SKU, eget pris, eget lagersaldo och egna bilder som ska följa med?
• Finns det varianter som i källan lagts upp som separata produkter och nu bör slås ihop — eller tvärtom?
• Hur ska variantstrukturen synas i butiken: en produktsida med väljare eller separata sidor?

Glöm inte heller mediat. Variantbilder, måttabeller, säkerhetsdatablad och andra filer ska följa med sina produkter, och bildernas filnamn och alt-texter har ofta ett SEO-värde som är värt att bevara. Bestäm tidigt om bilderna flyttas fysiskt eller länkas om från ett befintligt medialager.

Verifiera varianterna särskilt noga i testmigreringen. En katalog kan se komplett ut på ytan medan hälften av storlekarna saknar koppling till sina huvudprodukter — det upptäcks först när en kund inte kan välja sin storlek.

Kategorier: flytta strukturen, inte bara etiketterna

Kategoristrukturen är både navigation och SEO. Ett plattformsbyte är rätt tillfälle att se över den — men gör det medvetet. Varje kategorisida som rankar i sök är en tillgång, och ändrar du strukturen måste gamla kategori-URL:er omdirigeras till sina nya motsvarigheter med 301-redirects.

Bestäm också hur produkterna kopplas till kategorierna i målet: följer kopplingarna med i migreringen eller styrs de av regler baserade på attribut? Regelstyrda kategorier kräver att attributdatat är rent — vilket är ännu ett skäl att städa först.

Rätt hem för produktdatat: inbyggd PIM

Det bästa med en väl genomförd datamigrering är att den bara behöver göras en gång — om datat får ett riktigt hem. HDL Commerce har inbyggd PIM: produktinformationen underhålls strukturerat på ett ställe, med attribut, varianter och kategorier i samma modell som butiken använder, i stället för i kalkylark och sidosystem. Flöden från ERP och leverantörer kopplas via färdiga integrationer, och samma produktdata driver både B2B och B2C eftersom båda bor i samma kärna.

Det förändrar kalkylen för själva migreringen också: mappningsarbetet ni lägger ner blir startpunkten för en varaktig datastruktur, inte en engångsövning inför nästa flytt.

Nästa steg

Osäker på hur ert produktdata skulle klara en flytt? Det är precis vad vår fria migreringsanalys svarar på: vi går igenom er katalog, era varianter, era attribut och era integrationer och ger er en konkret bild av mappningsarbetet innan ni fattar något beslut. Boka analysen här — svar inom 4 timmar.