Wat productdata-syndicatie per kanaal moet opleveren
Kanalen zijn het niet oneens over het product zelf. Ze verschillen van mening over hoe het beschreven moet worden, en die verschillen zijn alledaags, specifiek en precies waar het werk in gaat zitten.
- Veldstructuur: het ene kanaal wil een enkele beschrijving, het andere wil opsommingstekens, een derde wil korte en lange varianten met aparte tekenlimieten
- Categorietaxonomie: elke marketplace hanteert een eigen categorieboom, waardoor hetzelfde product op elk platform in een ander knooppunt staat
- Verplichte kenmerken: een marketplace kan een aanbieding afwijzen zonder een specifiek certificeringsveld waar geen enkel ander kanaal om vraagt
- Mediaspecificaties: afbeeldingsafmetingen, achtergronden en het aantal hoeken dat is toegestaan of vereist
- Eenheden en formaten: afmetingen in centimeters of inches, gewichten in kilogram of pond, datums in de volgorde die de bestemming verwacht
Op zichzelf is niets hiervan moeilijk. Het wordt kostbaar omdat het per kanaal herhaald moet worden, en daarom PIM-integraties zelden eindigen bij het productinformatiebeheersysteem zelf. Een wijziging in het onderliggende product betekent dat elke bestemming die het product bevat, opnieuw moet worden bekeken.
Waarom eindigt één product met zes verschillende versies?
Het eerste kanaal haalt productgegevens rechtstreeks uit de bron. Het tweede kanaal gebruikt een kopie, meestal omdat een snelle lancering belangrijker was dan bepalen waar de productgegevens thuishoren. Vanaf dat moment zijn er twee bronnen van waarheid en is er geen regel over welke versie leidend is.
Correcties worden vervolgens doorgevoerd waar de fout wordt opgemerkt. Een supportmedewerker past een verkeerde afmeting aan in de webshop omdat een klant erover klaagde. Niemand past het aan op de marktplaats, omdat daar nog niemand heeft geklaagd. Zes maanden later spreken de twee records elkaar tegen en is het niet duidelijk welke versie fout is.
Verrijking maakt de splitsing definitief. Marketing schrijft betere teksten voor het kanaal met het hoogste volume, omdat dat het meeste oplevert. De beste versie van de productinhoud staat dan op één plek, terwijl de andere kanalen de originele versie bevatten. Hierdoor is de catalogus niet alleen inconsistent, maar ook ongelijk van kwaliteit.
De kosten van het onderhouden van een catalogus per kanaal
Het onderhouden van een catalogus per kanaal wordt zelden gebudgetteerd, omdat de werkzaamheden verspreid zijn over verschillende mensen die er elk een beheersbare hoeveelheid tijd aan besteden.
- Lanceringen die vertraging oplopen: een nieuwe collectie bereikt de hoofdwebshop op tijd, maar andere kanalen pas weken later, omdat elk kanaal handmatig moet worden bijgewerkt
- Aanbiedingen afgewezen of onderdrukt: een marktplaats weigert producten die een verplicht kenmerk missen, en niemand merkt het totdat de verkoop van die artikelen stopt
- Retouren veroorzaakt door de gegevens: een verkeerde afmeting of een verouderde specificatie leidt tot een retour die het product zelf niet verdiende
- Kanalen die helemaal niet worden geopend: een kansrijke marktplaats wordt afgewezen omdat niemand er nog een catalogus bij kan hebben om te onderhouden
De laatste is de duurste, omdat deze nooit als kostenpost verschijnt. Het presenteert zich als een kanaalstrategie die een bewuste keuze lijkt. Dezelfde boekhouding zie je terug bij marktplaatsintegratie, waarbij de bouw wel wordt gecalculeerd, maar het onderhoud niet.
Er zijn drie gangbare manieren om de distributie te regelen, en elk loopt ergens vast. Een PIM beheert het bronrecord goed en exporteert naar een vaste set bestemmingen, waardoor een ongebruikelijk kanaal nog steeds maatwerk vereist. Feedmanagementtools kunnen goed overweg met marktplaatsen en vergelijkingssites, maar reiken doorgaans niet tot in het ERP voor voorraad en prijzen. Elk kanaal handmatig onderhouden is wat de meeste bedrijven in de praktijk doen, en dat is de reden waarom de lijst met kanalen niet langer groeit.
Hoe gaat een integratieplatform om met de syndicatie van productgegevens?
Een integration platform-as-a-service (iPaaS) werkt volgens één principe: het productrecord wordt eenmalig opgeslagen en tijdens het verzenden aangepast. Het PIM- of ERP-systeem blijft de bron van waarheid en elk kanaal ontvangt de versie die het vereist, zonder dat daarvoor een aparte catalogus hoeft te worden bijgehouden.
Het aanpassen is het cruciale onderdeel, en dat is meer dan alleen herformatteren. De taxonomie van een marktplaats moet knooppunt voor knooppunt worden gekoppeld en de vereiste kenmerken moeten worden gecontroleerd voordat er iets wordt verzonden. Dit per bestemming doen en een afwijzing opvangen voordat het kanaal dat doet, is werk dat een geplande export niet kan uitvoeren.
Alumio is zo'n integratieplatform, gebouwd om één record per bestemming aan te passen in plaats van er meerdere op te slaan. Het Alumio-integratieplatform doet dit op vier manieren.
- Eén record, vele vormen: een data-Transformer binnen Alumio zet het bronproduct om naar de structuur, taxonomie en eenheden van elk kanaal, zodat kanaalformaten nooit bepalen hoe de catalogus wordt opgeslagen
- Updates die worden doorgevoerd bij wijzigingen: een event-driven data-Route pusht een gecorrigeerde specificatie naar elk kanaal dat dat product voert, in plaats van te wachten tot iemand zich herinnert welke kanalen deze nodig hebben
- Afwijzingen vroegtijdig in beeld: validatieregels controleren de vereiste kenmerken van elk kanaal voordat een vermelding wordt verzonden, zodat een ontbrekend certificeringsveld aan de grens wordt opgevangen in plaats van pas wordt ontdekt als gemiste verkoop
- Traceerbaar per kanaal: gedetailleerde logs leggen vast welke versie van een product waar en wanneer naartoe is gegaan, waardoor discrepanties in vermeldingen verklaarbaar worden
Configuratie regelt de mapping- en taxonomieregels, en de Alumio iPaaS biedt een Code Transformer voor gevallen waarin het schrijven van code efficiënter is dan het configureren ervan. Bij het derde of vierde kanaal bestaat het meeste van de mapping al, een bewering die het waard is om te testen.
Productdatasyndicatie voor 25.000 producten en twee verkoopmodellen
Groothandels lopen eerder tegen het syndicatieprobleem aan dan de meeste retailers, omdat zij meer producten voeren en deze via meer routes tegelijk verkopen.
AGU is een Nederlandse fietsgroothandel en retailer gevestigd in Alkmaar, met meer dan 160 medewerkers en ruim 25.000 producten, die zowel B2B als B2C verkoopt. Hun landschap draait op Centric als ERP, Akeneo als PIM en Adobe Commerce als webshop.
AGU verbond via de Alumio iPaaS Centric met Akeneo voor producten, categorieën, kenmerken en productmodellen, en Centric met Adobe Commerce voor voorraad-, prijs- en ordergegevens. Wat belangrijk is voor syndicatie, is wat er onderweg met de data gebeurde. De entiteiten werden genormaliseerd terwijl ze werden verplaatst, specifiek zodat er later extra kanalen konden worden toegevoegd zonder het mappingwerk opnieuw te hoeven doen. De catalogus hoefde nooit te worden geherstructureerd om aan een specifieke bestemming te voldoen.
Wat productdatasyndicatie een retailer oplevert
Productdatasyndicatie wordt meestal gerechtvaardigd op basis van efficiëntie, maar efficiëntie is slechts het kleinste deel van het rendement. Het grotere deel is welke kanalen überhaupt levensvatbaar worden.
Drie rollen ervaren dit op verschillende manieren. De e-commerce manager beheert de webshop en ziet de vertraging wanneer een assortiment elders te laat wordt gelanceerd. De product content manager onderhoudt de database en moet elk nieuw formaat verwerken. De marketplace of channel lead is degene die stilletjes stopt met het voorstellen van nieuwe kanalen, omdat elk kanaal een onderhoudslast met zich meebrengt in plaats van een eenvoudige koppeling.
Wanneer het toevoegen van een marketplace slechts een kwestie van koppelen is, wordt die beslissing commercieel in plaats van operationeel. Een integratieplatform maakt die koppeling goedkoop genoeg om dat waar te maken. Een kanaalstrategie wordt dan bepaald door waar de klanten zich bevinden, in plaats van door wat de catalogus aankan.
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
.svg)
