Vijf uitdagingen en voordelen van headless commerce

Het loskoppelen van de front- en backend zorgt ervoor dat je kunt definiëren welke functies binnen het e-commerce platform gebruikt worden. Functionaliteiten kunnen ook worden weggelaten om ze vervolgens door een meer specifieke tool te vervangen. De mogelijkheden op het gebied van content management en search & navigation worden vaak als eerste geëvalueerd, omdat dit meestal niet de sterkste punten zijn van e-commerce platforms. Ook is het mogelijk om personalisatietools transparanter in de frontend te integreren in plaats van erbovenop met een script-integratie.

Welke uitdagingen zijn er?

Naast de voordelen van headless commerce, brengt het ook een aantal uitdagingen met zich mee.

1. Organisatie mismatch

De mix van technologieën die samenkomt in de frontend betekent ook dat in meerdere tools gewerkt moet worden. Bijvoorbeeld een PIM-systeem voor het managen van productinformatie, een CMS voor het samenstellen van pagina’s en prijzen, winkelwagenregels en promoties binnen het e-commerce systeem zelf. Bij het lanceren van een campagne kan het zo zijn dat je door deze verschillende backends heen moet, hopend op het gewenste resultaat.

Dit impliceert dat een team meer technische kennis in huis moet hebben. Maar in de ideale situatie zou de tooling de organisatie moeten volgen, niet andersom. Wel kan headless dwingen om de manier van werken te veranderen en interne rollen te herdefiniëren.

Een tweede aspect van een organisatie mismatch is dat niet-zo-unieke e-commerce bedrijven profiteren van niet-zo-unieke templates. Of er moet ineens sterk nagedacht worden over de invulling van het witte canvas.

2. Nóg een andere technologie

Realiseer dat het ‘hoofd’ er niet voor niets is, het is een echt systeem. Wanneer je headless overweegt, is het niet alleen belangrijk om het e-commerce platform te selecteren (als je in dit stadium zit), maar ook met welke technologie je de frontend wilt gaan realiseren. Het mooie is dat dit twee aparte keuzes zijn, anderzijds moet er hoe dan ook een keuze gemaakt worden.

Het ontwikkelteam of webbureau moet ervaring hebben met de technologie (bijvoorbeeld React of VueJS) om de meeste waar voor je geld te krijgen. Met een bepaalde technologie werken betekent er ook continu zorg voor dragen. Als er nieuwere versies beschikbaar komen, moeten updates volgen.

Eén van de beloftes van headless is dat onderdelen gemakkelijk aangepast kunnen worden. Om dit te waarborgen moet de frontend niet alleen ontkoppeld zijn, maar in zekere mate ook agnostisch worden ontworpen. Uit ervaring weten we, dat hoezeer dit ook de doelstelling is, er toch altijd functies op een backend-specifieke manier worden ontwikkeld. De API’s van de backend (bijvoorbeeld Magento) volgen een bepaald patroon dat terugkeert in de frontend. Dit is niet persé slecht, maar het betekent dat de levenscyclus van de frontend technologie is gebonden aan die van het e-commerce platform. Natuurlijk, hoe meer je vasthoudt aan de basis, hoe minder extra werk het oplevert. Maar headless e-commerce blijft vaak nog steeds nauw verbonden met het gebruikte e-commerce platform.

3. Layercake

Wanneer je voor headless gaat, kun je ervoor kiezen om dit alleen te zien als een template wijziging en wat verschuiving van logica/code van de server naar de browser. Waarbij alle data uit bronsystemen (bijvoorbeeld PIM, ERP, CMS) nog steeds naar het e-commerce platform gestuurd wordt en deze functioneert als doorgeefluik. Op deze manier ontstaan meerdere systeemlagen met dito integraties, wat de beloofde snelheid van headless ontwikkelen niet ten goede komt.

Voorbeeld 1: productdata. Idealiter wordt alleen de hoeveelheid data die het e-commerce platform nodig heeft naar het e-commerce platform gestuurd. Bewaar de rest in een PIM-systeem en ontsluit het direct naar de frontend. Hetzelfde geldt voor het CMS.

Voorbeeld 2: omnichannel voorraad. Het e-commerce platform moet natuurlijk weten of een bepaald artikel op voorraad is, maar hoeft niet te weten wat het voorraadniveau in elke fysieke winkel is en welke levertijd hier aan vast hangt. Een ERP, WMS of OMS is wellicht in staat om deze data rechtstreeks naar de frontend te ontsluiten.

4. Routing issues

Door de combinatie van meerdere systemen zoals e-commerce en CMS, is het gevolg dat beiden op de één of andere manier dominant willen zijn wat routing betreft. Gebaseerd op de URL moet de headless frontend weten welke bronnen aangeroepen moeten worden en welke inhoud getoond moet worden. Vanuit SEO perspectief wil je echter geen technisch onderscheid. Op het ene moment kan een /valentine een blog post zijn en op een andere dag een landing page.

Om dit efficiënt te laten werken moet de frontend ergens hersens en geheugen hebben. Dit lijkt een antipatroon, maar je kunt er niet omheen. Je kunt niet meerdere tijdrovende API calls doen om te 'checken' of een systeem iets heeft voor deze view op basis van de URL.

5. Is Marketing er klaar voor?

Google is al lang voorstander van PWA (Progressive Web Apps), maar dit lijkt meer vanuit de theorie dan de praktijk te zijn. Als je headless gaat met een pure PWA, volledig in de browser (client-side), is dit nogal riskant. Het niet hebben van server-side rendered - indexeerbare cached pagina's - zorgt voor SEO minpunten die de commercie nadelig beïnvloeden.

Core Web Vitals/Lighthouse scores lijken ook een beetje traditionele scores te zijn, dus gebaseerd op initiële server-side rendered pagina’s. Wanneer je individuele Lighthouse tests uitvoert bij een nieuwe headless oplossing, valt op dat de ervaring veel beter is, maar de scores soms lager zijn. Headless oplossingen hebben de neiging om een grotere initiële belasting te hebben, gevolgd door veel kleinere belastingen op een later moment. Dus sessie gemiddelden zijn de juiste KPI om mee te werken.

Tracking van events voor Customer Data Platforms en Google Analytics is traditioneel ook gebaseerd op pageviews en dus URL's. Door over te schakelen naar headless en de navigatie in de browser af te handelen, is het belangrijk om na te gaan of de marketingtools en trackingoplossingen dit type kunnen verwerken. De URL moet daadwerkelijk wijzigen bij navigeren en/of er moeten specifieke events worden getriggerd.

En welke voordelen?

Als je in staat bent om deze uitdagingen te tackelen, dan kun je deze grote voordelen van headless ervaren:

1. Echt best-of-breed

Zoals gezegd zijn e-commerce platforms niet automatisch goed in alles. Nu kun je de beste tools kiezen die aan alle eisen voldoet.

2. Out-of-the-template-box

Er zijn geen grenzen aan creativiteit. Maak samen met het design- en ontwikkelingsteam specifieke productpresentaties en optimaliseer de customer experience.

3. Snellere development

Hoewel de features natuurlijk niet op een presenteerblaadje aangeboden worden, zien we dat het realiseren van de wensen sneller gaat binnen headless technologie (Javascript frameworks) dan in de standaard templates van het e-commerce platform. Wijzigingen zijn veel betrouwbaarder, omdat je niet meer gebonden bent aan de afhankelijkheden die een template based platform met zich meebrengt.

4. Naadloze ervaring

De meeste server-side-rendered en template based e-commerce platforms hebben zoveel code te verwerken dat dit effect heeft op de snelheid. Dit probleem wordt opgelost met een headless frontend.

5. Meer sales

Dit is natuurlijk het uiteindelijke doel. Wij zien dat de conversiepercentages van headless e-commerce platforms vrijwel altijd hoger liggen, zeker op mobiele devices.