Productdata – het meest onderschatte deel van een webshop

Het belang van goede productdata is duidelijk:

• Verbeterde klantenervaring.
• Snellere go-to-market. Door eenvoudige integraties met bestaande ERP, PIM, CMS, … kunnen nieuwe producten sneller en efficiënter online verkocht worden via eigen e-commerce en/of marktplaatsen.
• Meer verkoop. Goede data leidt tot betere vindbaarheid, via externe zoekmachines en intern op de shop zelf. Verder zorgt goede data voor meer duidelijkheid, dus meer verkoop.
• Meer up– en cross-selling. Via een goede datastructuur kan je bezoekers relevante producten tonen.
• Minder customer service. Meer duidelijkheid voor de klant betekent minder vragen bij de klantendienst.
• Single source of truth. Ook voor interne medewerkers en sales is het een bron van informatie.

Elke ambitieuze ondernemer begrijpt deze voordelen, maar stelt de belangen niet altijd centraal in de organisatie. Een dataverantwoordelijke kan samen met alle interne medewerkers en de feedback van de klanten zorgen voor een compleet, accuraat en consistent geheel. De data moet leven binnen de organisatie.

We vragen aan elke ondernemer om stil te staan bij de volgende 7 stappen voor hij of zij een webshop laat ontwikkelen. Oók voor B2B-portalen, want een businessgebruiker verdient dezelfde kwaliteit als een consument. Sommige B2B-shops leveren ook data feeds aan hun klanten/retailers, en dan wordt de kwaliteit des te belangrijker.

Stap 1: Verzamel en bereid je productdata voor

Stap 2: Bepaal de databronnen en hoe vaak je daarmee wilt synchroniseren

Stap 3: Classificeer attributen en definieer de datafilters

Stap 4: Schrijf krachtige beschrijvingen om relevant en impactvol te zijn

Stap 5: Bundel samenhorende producten

Stap 6: Denk aan de gewenste webshopfunctionaliteiten en de daarvoor nodige data

Stap 7: Structureer de complexiteit van de prijzen

Stap 2: Bepaal de databronnen en hoe vaak je daarmee wilt synchroniseren

Moderne databronnen voorzien allerlei manieren om te connecteren met de buitenwereld. De meest gebruiks- en budgetvriendelijke wijze van integratie is dat de databron een data-export ter beschikking stelt voor de webshop. De frequentie van datasynchronisatie is een balans tussen businessnood, overbelasting en snelheid van het systeem. Een afbeelding of productomschrijving kan bijvoorbeeld eenmaal per nacht worden uitgewisseld, en de voorraad elke minuut of real-time via API. Alles hangt af van de dynamiek van de data, en de impact op de business. Voor een bedrijf met een statische prijzenpolitiek, heeft het geen zin om de data in real time op te halen, omdat dit het budget onnodig vergroot, de website vertraagt, én ook de afhankelijkheid van de technische bridge tussen de webshop en het ERP invoert.

De frequentie van voorraadsynchronisatie hangt ook af van het volume van de offline sales. Hoe meer offline sales, hoe meer risico op voorraadbreuken, en hoe sneller deze in de webshop moeten bekend zijn. Voor een pure onlinespeler is een voorraadsync in feite enkel nuttig om magazijncorrecties te synchroniseren omdat de webshop op zich de voorraad bij elke verkoop in rekening brengt. Een voorraadsync doen voor een pure online speler, met nog onverwerkte orders in het ERP, kan zelfs negatieve gevolgen hebben op de correctheid. Sneller is niet altijd een synoniem voor nauwkeuriger.

Technisch gezien komt het er voor eWings op neer dat we een of meerdere XML’s of CSV’s met een gestructureerde dataset ter beschikking gesteld krijgen met een bepaalde frequentie. We hebben een data mapping-tool die de beschikbare data overbrengt naar Magento-attributen. Voor de meeste projecten is dit geen één-op-één-mapping, maar wordt er met scripts gewerkt om de data om te vormen en/of te combineren.

Meer informatie vind je in deze videoreeks van eWings

De XML of CSV kan worden opgehaald via een API (web service), (S)FTP, Dropbox, Onedrive of HTTP(S) locatie. Voor 90% van onze projecten is dit SFTP, aangezien de meeste databronnen dit als kant-en-klare interface hebben ‘ingebakken’ en het de meest kostefficiënte manier is van integreren.

eWings prefereert om tijdens de opbouw van het project dezelfde data-interfaces te gebruiken die ook in de toekomst zullen worden ingezet voor update en creatie van nieuwe producten. Op deze wijze zijn de interfaces goed getest en stabiel, en wijzigt er bij de livegang van het project op interfacevlak in feite niets.

Stap 3: Classificeer attributen en definieer de datafilters

Het is van cruciaal belang dat potentiële klanten de producten op de website vinden. Dat kan via zoekfunctie, categoriepagina, merkenpagina, contentpagina, maar last but not least de filters. Het is evident dat elk product een of meerdere categorieën, een merk en een uitgebreide omschrijving nodig heeft om gevonden te worden. Maar de impact van data op filters wordt zwaar onderschat.

Om een filter te kunnen inzetten moet de data consistent en volledig zijn en soms worden gebundeld. De meeste shops bieden een slechte tot matige filter-kwaliteit. Sommigen doen het goed, maar waarschijnlijk niemand perfect. Laat ons even toelichten wat we bedoelen met perfectie.

Een voorbeeld van onvolledige data: Coolblue is één van de betere van de klas, maar problemen vind je overal. Ze bieden 171 printers aan, en de som van de in oranje omcirkelde filters is niet 171. Dat wil dus zeggen dat de data niet volledig is. Als ik als klant dus “snelheidklasse=uitstekend” selecteer, bestaat de kans dat een uitstekende printer niet tevoorschijn komt. Dit is een probleem, want deze printer zit in het gamma, maar wordt niet gevonden door de klant.

Een voorbeeld van inconsistentie én onvolledige data op het internet zoeken neemt letterlijk 2 minuten. Hieronder nemen we de webshop van Kruidvat als voorbeeld. Als klant heb ik geen boodschap aan een filter in stuk, milliliter én gram in de categorie shampoo. Elke leverancier drukt de data op een andere manier uit, en er is geen data-allignatie voorzien bij de webshopbeheerder.

Om dit te vermijden kan je ervoor zorgen dat de eenheid geen deel is van de data (zoals 60g, 60ml), maar van het attribuut zodat de waarde 60 voldoende is (uitgedruk in eenheid ml als eigenschap van het attribuut). Uiteraard kosten dergelijke dataconversies tijd en energie.

Welke type velden bestaan er? Een vrij invulveld: Het schoolvoorbeeld hiervan is de omschrijving. Technisch gezien hoeft er geen correlatie te bestaan tussen een vrij veld over verschillende producten heen. Op vlak van design en coherentie is het echter wel aangewezen dat er een bepaalde structuur in de data wordt afgesproken, zodat de potentiële klant een transparant overkoepelend geheel aantreft. Een vrij invulveld in een bepaalde eenheid. Een schoolvoorbeeld hiervan is het gewicht. De ondernemer kan intern bepalen dat het gewicht altijd in kg wordt uitgedrukt, en dan is het gewicht een digitaal getal uitgedrukt in die eenheid. Een filterbaar veld dat kan gebruikt worden om producten te groeperen en sneller terug te vinden. Bijvoorbeeld het attribuut ‘kleur’. Om velden te kunnen benoemen van dit type is het van belang dat er datacoherentie is, de data volledig is ingevuld én er is nagedacht over het nut van de filter voor de klant. eWings kan niet coherente data (bv roos, roze, pink) omvormen tot coherente data via de beschibare datamapping-tool en conversiescripts. Als onderneming kan je het ook aan de bron aanpakken, of beslissen er geen filter van te maken. Dit maakt een groot verschil in de te investeren resources, dus we maken daar vooraf goede afspraken over.