Have you come across the term “headless commerce?” It’s being used more and more, cited as the underlying reason for new shifts in commerce technology. I kept hearing it in meetings, and I wasn’t sure if any of us really understood what it meant. I wanted to grasp the concept better and decided to compile all of the information around headless commerce for marketers and technical teams, including what it is, where it came from, and why.
eCommerce hasn’t been around all that long – the web appeared in 1990, with eBay and Amazon launching in 1995. Since then, software development has evolved from monolithic and layered architectures to web services and microservices. As eCommerce technology stacks have become more sophisticated to incorporate personalization and support new digital touchpoints, eCommerce software is now following the same path. It is moving from monolithic platforms towards services and APIs, which headless commerce is taking advantage of.
So what does headless commerce mean?
The simplest definition of headless commerce is that it is a commerce platform without a frontend. Meaning, the frontend, which refers to the user’s web browser application, is separated from the back end platform running on a server somewhere. The interesting questions though, have to do with how it all works, why it’s a good idea, and the effect on teams buying, managing, and using the software.
First, though, some terminology.
Perhaps all industries are the same, but the more time spent in eCommerce, the more three-letter acronyms (TLAs) and jargon you encounter. To add to the confusion, the same words mean different things to different people.
“Because no endeavor is respectable these days without a TLA.” – Dijkstra, 1988
To help clarify, here are some that often come up regarding headless commerce:
As defined above, headless commerce works by separating the user interface (frontend) from the software, which does all the processing (backend). The headless commerce platform is just the backend part, with some way to connect one or more user interfaces. This connection is generally made through APIs, and because this provides a generic interface to the platform, any frontend can be built to connect to it.
A user then interacts with a frontend running in a web browser, a mobile application, kiosk, or any other digital interface, which then, in turn, communicates with the backend.
To demonstrate this, here is a simplified example user journey:
1. A user navigates to a product on an eCommerce website. The frontend is loaded in the user’s web browser and the product details are retrieved from the backend by API.
2. The user makes a purchase, causing the frontend to send a request to the backend making the purchase.
3. The backend does all of the processing and then responds to the frontend to tell it the purchase was successful.
By decoupling the frontend and backend, the backend can be far more generic. It is able to interact with anything that is willing to send the correct API requests. The frontend also becomes far simpler because it doesn’t have to deal with any of the processing, it is just displaying information to the user.
In describing how headless commerce works, some of the differences between headless and monolithic architectures have already been touched on. These advantages and disadvantages all come about because of the decoupling of the frontend and backend.
First, I’ll list the pros (mostly) and cons (limited) of the headless commerce architecture, and then explain why these come about.
A system based on a headless commerce architecture makes development easier because changes can be made to the front and backend independently. In a monolithic system, any change to the way information is displayed to the user requires knowledge of the entire system – an understanding of how that information is both accessed and processed. For any change which is made to one system could break the other. It is also more likely that a change could invalidate software warranties and cause issues with future upgrades.
In a headless commerce system, a front-end developer can make any change they like while only needing to understand the interface to the backend – the APIs – and back-end developers can enable new functionality by supporting new APIs. Due to the more simple nature of making changes, development can be quicker and more agile.
ICYMI, Dynamic Yield is offering a free 14-day exPerience APIs trial. Simply sign-up for access to a sandbox environment and start playing.
This separation of front and backend also allows developers to specialize. For smaller teams, this means new functionality can be developed more quickly. In the case of larger teams, it is easier to find qualified developers, and, in general, these individuals can more intimately understand their areas of expertise.
This decoupling also enables completely different teams to manage the various systems. Or systems even being managed by different companies – a new frontend could be licensed as SaaS, for example.
Because the headless commerce system only has to provide an interface (through APIs) to the frontend, this adds flexibility. Initially, the only user touchpoint connected to the back end might be a website, but with headless, a mobile application could be connected, PWAs, kiosks, smartwatches, voice interfaces, and so on.
Only one system has to process information with a decoupled headless commerce platform, so there is less development effort required to support all touchpoints, and consistency can be maintained across them. There is also an element of “future-proofing.” For example, Web technologies move very quickly – when something new comes along, it can just be plugged into the existing backend.
Following the theme of flexibility, having this generic interface through APIs allows for easier systems integration, both internal and external. For instance, a new payment gateway can be added by making calls to a new API.
This flexibility also extends to changing integrations, reducing vendor lock-in, and creating greater opportunities to trial and test new services. Want to determine if a new search provider is stronger than your current vendor? Now, you can experiment more readily.
The result is a more interesting toolset. In the two examples above, a testing and personalization provider can be used to optimize the search and payment systems or even tailor the experience. Perhaps more loyal customers are offered more payment options. Additionally, conversion rate may be improved by offering specific segments of customers different payment methods than others. The number of eCommerce tools available is growing exponentially, so being able to test and integrate these tools quickly can have a major impact on business results.
One requirement to take advantage of the possibilities listed above is that a team has the skills to implement these changes. There are notable differences between implementing one system that takes care of everything versus assembling a set of interconnected ones. The current trend in eCommerce is to partner with “best-of-breed” solutions, but this isn’t possible without additional skills, and if it is a requirement, then headless commerce solutions lessen the pain.
The team will need to involve similar members as in any tech-focused eCommerce company – front-end developers, back-end developers, architects, project managers, etc. – only now there must be close alignment with the marketing team.
Some headless commerce platforms come with both the back and front end, which will be seen as an advantage by some, and a disadvantage by others. It depends on your requirements – if you have a team of developers who want to build a custom site and app, you may not want a ready-made frontend website. However, even if both bits come together, you still have all of the advantages detailed above, including the future flexibility to change frontends, add new digital channels, integrations, and develop your eCommerce stack more easily.
If you already have requirements for integrations with existing or planned tools, then these need to be validated. This should be understood by the team who will need to build the integrations as there’s a big difference between an email service provider (ESP) having an available API integration and knowing that the API will work with your chosen ESP.
We don’t know what the future will hold, but it is almost certain that there will be significant changes. In eCommerce, we may not be able to plan beyond five to ten years, but the platform chosen needs to keep up with the more immediate needs. If bringing kiosks into the store is on your roadmap, then this support can be validated. For everything else that might happen, it is worth comparing how generic the APIs provided are – a well-designed interface should allow integration with a wide variety of tools in a variety of ways.
Because there is more technical involvement to get the most out of headless commerce, it is important that development teams have the required skills, access to the relevant code, and also that they can use the platform as efficiently as possible. This includes how well-designed the interfaces are, how good it’s documentation is, and what support and training are provided. Having your team review any available documentation would be a good place to start.
As well as the technical teams, business teams must be able to manage the solution: marketers to create content and merchandisers to serve the right products, all through the new system. As well as asking similar questions as above, it is important to consider what interface is provided for ongoing management, or if this will need to be developed.
All of the benefits of headless commerce listed above are of little value if the business can’t take advantage of them. A few questions to ask when determining if a company is ready:
Marketers are interested in delivering personalized, optimized, and synchronized experiences, so how do we combine these systems? I’ve already answered this to some extent when discussing integrations, but because everything in a headless commerce architecture has APIs, accomplishing these goals is far more attainable.
Both the headless commerce and personalization platform provide APIs, so if you want to test search providers, you can just run an A/B test between the two API endpoints. However, for such tests, it is more necessary to involve technical team members. Someone needs to understand the search interface and write the code to direct a portion of users to one search provider and another batch of users to the other.
It’s important to note that not all tests need to be run using APIs; they can be combined with client-side testing. With the headless commerce platform, you have the opportunity to build more interesting API-based use cases and take advantage of client-side’s ease of use to enable the marketing and business teams to iterate more quickly without heavy reliance on tech teams.
The APIs from the headless commerce platform are combined with those from the testing/personalization platform to build an experience. There are different approaches which can be taken, depending on the intricacies of each tool, but at a basic level, it follows this pattern:
1. Multiple variations are created in the headless commerce platform – this could be something simple, like a banner on the homepage, or something more systemic, such as the search provider.
Let’s say three variations are created: A, B, and C.
2. These variations are then referenced as variations in the personalization platform, allowing the configuration of testing and targeting. For example, variations A and B are configured to be tested for all users, apart from those in the south of the country., who are to be shown variation C.
The personalization platform doesn’t need to understand what the variations are – it just needs to know which variation should be shown to each user and measure what happens when the users interact with them.
3. When a personalized experience is to be shown to a user, the request the frontend makes is intercepted and made to the personalization API. The personalization API then returns a reference to the headless commerce platform’s variation, which is retrieved from the headless commerce platform and ultimately returned to the frontend.
4. The frontend shows the returned variation to the user.
5. Events are sent to the personalization platform to measure interactions with experiences and KPIs such as conversions, add-to-carts, and purchases.
Headless eCommerce solutions bring many benefits over traditional platforms due to decoupling the frontend and backend. Although a seemingly simple architectural change, the flexibility of developing on top of a headless commerce platform translates into greater experimentation with new features and integrations. And, more importantly, quickly and easily. As long as the company is set up to implement these changes, adopting a headless approach can be a true competitive differentiator.
Check out Dynamic Yield’s developer hub for information on how an A/B testing and experience optimization platform can be connected to a headless commerce platform via APIs, and then give them a test run with our free 14-day exPerience APIs trial.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。