Vad syndikering av produktdata måste leverera per kanal
Kanaler är inte oense om själva produkten. De är oense om hur den ska beskrivas, och dessa meningsskiljaktigheter är vardagliga, specifika och precis där arbetet ligger.
- Fältstruktur: en kanal vill ha en enskild beskrivning, en annan vill ha punktlistor, en tredje vill ha korta och långa varianter med separata teckenbegränsningar
- Kategoritaxonomi: varje marknadsplats har sitt eget kategoriträd, och samma produkt hamnar i olika noder på varje ställe
- Obligatoriska attribut: en marknadsplats kan avvisa en listning som saknar ett specifikt certifieringsfält som ingen annan kanal efterfrågar
- Mediaspecifikationer: bilddimensioner, bakgrunder och hur många vinklar som är tillåtna eller krävs
- Enheter och format: dimensioner i centimeter eller tum, vikter i kilogram eller pund, datum i den ordning som destinationen förväntar sig
Inget av detta är svårt isolerat sett. Det blir dyrt eftersom det upprepas per kanal, vilket är anledningen till att PIM-integrationer sällan slutar vid själva systemet för produktinformationshantering. En ändring av den underliggande produkten innebär att man måste se över varje destination som innehåller den.
Varför slutar det med att en produkt har sex olika versioner?
Den första kanalen hämtar produktdata direkt från källan där den skapades. Den andra hämtar en kopia, oftast för att snabb lansering prioriterades framför att bestämma var produktdata faktiskt ska ligga. Från det ögonblicket finns det två källor och inga regler för vilken som gäller.
Rättelser görs sedan där felet upptäcks. En supportmedarbetare korrigerar ett felaktigt mått i webbshoppen för att en kund klagat. Ingen åtgärdar det på marknadsplatsen, eftersom ingen där har klagat än. Sex månader senare stämmer inte uppgifterna överens och ingen av dem är uppenbart felaktig.
Berikning gör splittringen permanent. Marknadsavdelningen skriver bättre texter för den kanal som har störst volym, eftersom det är där det ger bäst avkastning. Den bästa versionen av produktinnehållet hamnar på ett ställe medan de andra kanalerna behåller originalet, vilket gör att katalogen inte bara blir inkonsekvent utan också ojämnt bra.
Kostnaden för att underhålla en katalog per kanal
Att underhålla en katalog per kanal finns sällan med i budgeten, eftersom arbetet är utspritt på flera personer som var och en lägger ner en hanterbar mängd tid på det.
- Lanseringar som fördröjs: ett nytt sortiment når huvudbutiken enligt plan medan de andra kanalerna får vänta i veckor, eftersom varje kanal hanteras manuellt
- Listningar som avvisas eller döljs: en marknadsplats nekar produkter som saknar ett obligatoriskt attribut, och ingen märker det förrän försäljningen av dessa artiklar stannar av
- Returer orsakade av datan: ett felaktigt mått eller en föråldrad specifikation leder till en retur som produkten i sig inte förtjänade
- Kanaler som aldrig öppnas: en lönsam marknadsplats väljs bort eftersom ingen har kapacitet att ta på sig ytterligare en katalog att underhålla
Den sista punkten är den dyraste, eftersom den aldrig syns som en kostnad. Den framstår som en kanalstrategi som ser ut som ett aktivt val. Samma redovisning syns överallt inom marknadsplatsintegration, där utvecklingskostnaden offereras men underhållet inte gör det.
Tre upplägg är vanliga för att hantera distributionen, och alla har sina begränsningar. Ett PIM-system håller ordning på den auktoritativa datan och exporterar till ett fast antal destinationer, vilket innebär att ovanliga kanaler fortfarande kräver specialutveckling. Verktyg för flödeshantering hanterar marknadsplatser och prisjämförelsesajter effektivt, men når oftast inte in i affärssystemet för lager och prissättning. Att underhålla varje kanal manuellt är vad de flesta företag faktiskt gör, och det är anledningen till att kanallistan slutar växa.
Hur hanterar en integrationsplattform syndikering av produktdata?
En integrationsplattform som tjänst (iPaaS) bygger på en princip: produktposten lagras en gång och omformas på vägen ut. PIM- eller ERP-systemet förblir den auktoritativa källan, och varje kanal får den version den kräver utan att en separat katalog behöver underhållas för den.
Omformningen är det som betyder något, och det är mer än bara omformatering. En marknadsplatstaxonomi måste mappas nod för nod och dess obligatoriska attribut kontrolleras innan något skickas. Att göra detta per destination, och att fånga upp en avvisning innan kanalen gör det, är ett arbete som en schemalagd export inte kan utföra.
Alumio är en integrationsplattform av det slaget, byggd för att omforma en post per destination istället för att lagra flera. Alumios integrationsplattform gör detta på fyra sätt.
- En post, många former: en datatransformator i Alumio konverterar den auktoritativa produkten till varje kanals struktur, taxonomi och enheter, så att kanalformat aldrig dikterar hur katalogen lagras
- Uppdateringar som sker vid ändring: en händelsestyrd datarutt skickar en korrigerad specifikation till varje kanal som har den produkten, istället för att vänta på att någon ska komma ihåg vilka som behöver den
- Avvisningar som upptäcks tidigt: valideringsregler kontrollerar varje kanals obligatoriska attribut innan en produktlista skickas, så att ett saknat certifieringsfält fångas upp vid gränsen istället för att upptäckas som utebliven försäljning
- Spårbart per kanal: detaljerade loggar registrerar vilken version av en produkt som gick vart och när, vilket gör det möjligt att förklara avvikelser i produktlistor
Konfiguration hanterar mappnings- och taxonomiregler, och Alumio iPaaS tillhandahåller en kodtransformator för de fall där det är mer effektivt att skriva kod än att konfigurera. Vid den tredje eller fjärde kanalen finns det mesta av mappningen redan på plats, vilket är ett påstående värt att testa.
Syndikering av produktdata för 25 000 produkter och två försäljningsmodeller
Grossister stöter på syndikeringsproblemet tidigare än de flesta återförsäljare, eftersom de hanterar fler produkter och säljer dem via fler kanaler samtidigt.
AGU är en nederländsk cykelgrossist och återförsäljare baserad i Alkmaar, med över 160 anställda och mer än 25 000 produkter, som säljer både B2B och B2C. Deras IT-landskap använder Centric som ERP, Akeneo som PIM och Adobe Commerce som butiksplattform.
AGU kopplade samman Centric med Akeneo för produkter, kategorier, attribut och produktmodeller, samt Centric med Adobe Commerce för lager, priser och orderdata via Alumio iPaaS. Det som är avgörande för syndikeringen är vad som hände med datan under processen. Entiteterna normaliserades under överföringen, specifikt för att ytterligare kanaler skulle kunna läggas till senare utan att behöva göra om mappningsarbetet. Katalogen behövde aldrig struktureras om för att passa en enskild destination.
Vad syndikering av produktdata ger en återförsäljare
Syndikering av produktdata motiveras oftast med effektivitet, men effektivitet är bara den mindre delen av vinsten. Den större delen är vilka kanaler som överhuvudtaget blir möjliga att använda.
Tre roller upplever det på olika sätt. E-handelschefen ansvarar för butiken och märker av fördröjningen när ett sortiment anländer sent från annat håll. Produktinnehållsansvarig underhåller produktregistret och får hantera varje nytt format. Marknadsplats- eller kanalansvarig är den som i tysthet slutar föreslå nya kanaler, eftersom varje ny kanal innebär ett underhållsåtagande snarare än en enkel mappning.
När det att lägga till en marknadsplats istället kostar en mappning, blir beslutet affärsmässigt snarare än operativt. En integrationsplattform gör mappningen tillräckligt billig för att detta ska stämma. En kanalstrategi formas då av var kunderna finns, snarare än av vad produktkatalogen klarar av att hantera.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
