Five challenges and benefits of headless commerce

Decoupling the front and backend allows you to define which functions are used within the e-commerce platform. Functionalities can also be omitted and then replaced by a more specific tool. Content management and search & navigation capabilities are often evaluated first, as these are usually not the strongest points of e-commerce platforms. It is also possible to integrate personalization tools more transparently into the frontend instead of on top of it with a script integration.

What are the challenges?

In addition to the benefits of headless commerce, it also comes with some challenges.

1. Organizational mismatch

The mix of technologies coming together in the front end also means working in multiple tools. For example, a PIM system for managing product information, a CMS for composing pages and pricing, shopping cart rules and promotions within the e-commerce system itself. When launching a campaign, you may have to go through these different backends, hoping for the desired results.

This implies that a team should have more technical knowledge in-house. But in the ideal situation, the tooling should follow the organization, not the other way around. However, headless can force you to change the way you work and redefine internal roles.

A second aspect of an organizational mismatch is that not-so-unique e-commerce companies benefit from not-so-unique templates. Or there is a sudden need to think strongly about filling in the white canvas.

2. Yet another technology

Realize that the "head" is there for a reason; it's a real system. When considering headless, it is not only important to select the e-commerce platform (if you are at this stage), but also what technology you want to use to realize the frontend. The beauty is that these are two separate choices, on the other hand, a choice must be made regardless.

The development team or web agency must have experience with the technology (React or VueJS, for example) to get the most value for money. Working with a particular technology also means continually caring for it. As newer versions become available, updates must follow.

One of the promises of headless is that components can be easily modified. To ensure this, the frontend must not only be decoupled, but also designed agnostic to some extent. We know from experience, that however much this is the objective, functions are always developed in a backend-specific way anyway. The APIs of the backend (Magento, for example) follow a certain pattern that recurs in the frontend. This is not necessarily a bad thing, but it means that the life cycle of the frontend technology is tied to that of the e-commerce platform. Of course, the more you stick to the basics, the less extra work it creates. But headless e-commerce often still remains closely tied to the e-commerce platform being used.

3. Layercake

When you go headless, you can choose to think of this only as a template change and some shifting of logic/code from the server to the browser. Whereby all data from source systems (e.g. PIM, ERP, CMS) is still sent to the e-commerce platform and it functions as a conduit. This creates multiple system layers with ditto integrations, which does not help the promised speed of headless development.

Example 1: product data. Ideally, only the amount of data the e-commerce platform needs is sent to the e-commerce platform. Store the rest in a PIM system and unlock it directly to the frontend. The same goes for the CMS.

Example 2: omnichannel inventory. The e-commerce platform obviously needs to know if a particular item is in stock, but it does not need to know what the stock level is in each physical store and the delivery time associated with it. An ERP, WMS or OMS may be able to unlock this data directly to the frontend.

4. Routing issues

With the combination of multiple systems such as e-commerce and CMS, the result is that both want to be dominant in some way in terms of routing. Based on the URL, the headless frontend needs to know which resources to call and which content to display. From an SEO perspective, however, you don't want technical distinctions. A /valentine might be a blog post one day and a landing page the next.

For this to work efficiently, the frontend must have brains and memory somewhere. This seems like an anti-pattern, but you can't get around it. You cannot do multiple time-consuming API calls to "check" if a system has something for this view based on the URL.

5. Is Marketing ready for it?

Google has long been a proponent of PWA (Progressive Web Apps), but this seems to be more from theory than practice. Going headless with a pure PWA, entirely in the browser (client-side), is rather risky. Not having server-side rendered - indexable cached pages - creates SEO minuses that adversely affect commerce.

Core Web Vitals/Lighthouse scores also seem to be somewhat traditional scores, i.e., based on initial server-side rendered pages. When you run individual Lighthouse tests on a new headless solution, you notice that the experience is much better, but the scores are sometimes lower. Headless solutions tend to have larger initial loads, followed by much smaller loads later on. So session averages are the right KPI to work with.

Event tracking for Customer Data Platforms and Google Analytics has also traditionally been based on pageviews and thus URLs. By switching to headless and handling navigation in the browser, it is important to consider whether the marketing tools and tracking solutions can handle this type. The URL must actually change when navigating and/or specific events must be triggered.

And what benefits?

If you are able to tackle these challenges, then you can experience these great benefits of headless:

1. Truly best-of-breed

As mentioned, e-commerce platforms are not automatically good at everything. Now you can choose the best tools that meet all the requirements.

2. Out-of-the-template-box

There are no limits to creativity. Together with the design and development team, create specific product presentations and optimize the customer experience.

3. Faster development

Although the features are obviously not offered on a silver platter, we see that the realization of requirements is faster within headless technology (Javascript frameworks) than in the standard templates of the e-commerce platform. Changes are much more reliable, because you are no longer bound by the dependencies that a template-based platform entails.

4. Seamless experience

Most server-side-rendered and template-based e-commerce platforms have so much code to process that it affects speed. This problem is solved with a headless frontend.

5. More sales

This, of course, is the ultimate goal. We see that the conversion rates of headless e-commerce platforms are almost always higher, especially on mobile devices.