This post was originally published on Medium, February 4th 2020.
In part 1 we identified a problem with the ‘whole product’ for headless retail ecommerce. We found that when moving from a legacy ecommerce platform to a headless commerce stack, the ecommerce team lose some of the key Experience Management’ functionality they use daily to market and merchandise the storefront.
At Amplience we’ve been working hard to address this shortfall in capability so that ecommerce teams can confidently proceed with their headless projects.
But before we get to the solution we will dig a little deeper on the problem so that we can properly define the technical and business user experience challenges we need to solve for.
Architecting the new headless commerce stack
There are five main types of roles involved in the management and operation of the storefront experience:
1. Merchants: responsible for product merchandising (sales) and typically organised by category.
2. Marketers: responsible for customer acquisition and retention, as well as brand metrics.
3. Site ops: general management of the storefront.
4. Content managers: management of non-product content, storefront structure and UX.
5. Developers: core template functionality, integrations, feeds and data.
When migrating to a headless architecture, solution architects need to map these roles, tasks and tools together into a coherent system that supports experience delivery and management.
At first glance this seems relatively straightforward. New headless vendors, with business friendly admin tools exist for most of the key capabilities that are required by the teams, and the mapping seems to be complete (with the exception of storefront management, which really describes the configuration of the ‘head’).
However, as soon as you try to do this with a sophisticated retail ecommerce team you quickly realise there is a problem. From a customer’s perspective, the storefront experience is not composed of individual silos of brand content, product content, search, promotions etc but is instead a set of user journeys from landing pages, through search and browse, to product detail pages and checkout.
So for merchants and marketers there is a bigger workflow at play, one that comes together at the level of the customer experience itself, and that transcends the functional silos and the production and operational processes that live within each capability. They want somewhere that they can create future versions of the experience, and view the entire customer journey to check for coherence before any changes are committed to the live storefront.
To do this, merchants and marketers need to be able to combine product and non-product content with functional components like search and the basket into pages or views.
With this in mind, the cross-functional workflow table looks a little different:
There are four new rows in our table: Application Delivery, API Aggregation, Experience Delivery and Experience Management, which are the key capabilities that support a headless PWA architecture (note that storefront administration has moved into the Experience Management layer).
The Application Delivery and API Aggregation capabilities are typically packaged together into Frontend-as-a-Service (FaaS) offerings. These FaaS vendors (Mobify, Moovweb etc.) provide a range of capabilities from PWA development and deployment frameworks through to Backend-for-the-Frontend (BFF) or Graph QL style API aggregation, application caching, reporting and basic analytics.
They solve for the complexity of building and managing a PWA based front-end and help to optimise for performance by reducing the number of API calls made from the PWA to the back-end microservices, and through aggressive pre-loading and caching.
But it’s not at all obvious where the Experience Management and Experience Delivery capabilities live, i.e. where navigation, taxonomy, workflow and preview services along with their business tools reside in the new headless model.
Headless means no more web-CMS templates
Headless means to decouple the presentation layer i.e. move the logic that builds the user’s view of the storefront from out of the underlying systems, and enforce a strict separation of concerns. The front-end storefront interacts with APIs which return content and functionality as data, generally in JSON format.
Headless architectures break the web CMS pattern, dispensing with the template and redistributing its responsibilities as follows:
As the table demonstrates, the front-end rendering of the view moves to the PWA itself, where the interactions, formatting and styling (via CSS) are coded into the application, while the data describing the content, products and basket status, account details etc is called from the headless APIs. In essence the PWA has become the template, but now the template lives as code written using a JavaScript framework like React, Vue or Angular, which is inaccessible to business users and requires developers to effect change.
So while a PWA delivers improvements to mobile performance: less bounce and more conversion, we’ve lost some of the capability that business users rely on to make changes without resorting to developers. And that’s a real problem for proponents of headless approaches to retail ecommerce.
And although the web-CMS template code can in principle be engineered to deliver content-as-data in a form suitable for the PWA, it still comes in large page sized chunks, which negate the performance benefits of the PWA model.
Ideally we want great performance and simple manageability, and to that end I’ve introduced a new term, Headless Experience, in the table above. It categorises the template’s capabilities somewhat differently to the pure headless column.
But if the architecture is truly headless how can this be achieved?
The answer is to further tease apart the presentation layer and separate the configuration of the experience from the presentation rendering, abstracting the structure of the experience from the PWA and storing that configuration data as content in the headless CMS, in the content graph.
In this way we can retain the benefits of the PWA and headless architecture by moving the key experience configuration data into content, not code, which makes it manageable by merchants, marketers and content mangers.
Headless experience management
In order that we can define what is required for headless experience management, we must first understand what is required for headless experience delivery from the PWA’s point of view, as that is where the live customer experience resides.
To build an experience the PWA needs to be able to ask the content delivery APIs for:
1. The structure of the experience i.e. navigation-as-a-service.
2. The types of page / view layout that the PWA will display i.e. layouts-as-a-service.
3. The actual configuration, content, data and components of specific screens i.e. a definition of all of the content types needed in the experience, including content that is not native to the CMS such as product and customer data.
We also want to be able to do this in a way that does not create too many fixed dependencies between the PWA and the underlying systems, enables the maximum of content reuse, and allows the PWA to be developed iteratively without constant reference to the system doing the experience delivery.
To that end we need somewhere to store experience configuration and a way of retrieving just the content and data we need to build a view in the PWA at run time, and ideally a way to do this via a query, rather than a hardwired relationship. This is so that the PWA can respond to user interaction and request the precise content to drive the user experience, without in advance knowing what those specific queries might be.
Structuring the experience in the content graph
The content graph is one of the key innovations inherent in most natively headless content platforms and is a flexible way of storing not just the content of an experience, but the relations between that content which define that experience. It can model structures like navigation, slots, pages, views and so on.
For a full PWA experience that performs tasks analogous to legacy web storefronts, the graph needs to hold many related objects. Some are hierarchical (navigation and taxonomy), others are sets of related entities (layouts and views), others are pointers to external data sources that might contain related content (ratings and reviews, customer segmentation or product data).
The flexibility of the graph is that it stores schema-defined content as data, not in a database as relational tables. There is no n-tier abstraction in the headless model. This means it deals with the problems of experience in useful ways that transcend the old web CMS model.
The principle benefit is that a set of linked graphs can describe the totality of the storefront experience. So one graph might define the navigation, with each navigation node (menu item) linked to the graph containing the content and data for that linked view via a content reference. Other graphs can contain data about products, customer segments and campaign content to facilitate the whole storefront experience.
However, lots of complex graph data would be unwieldy to use in the PWA. Ideally we would have ways to query various linked graphs to retrieve only the data we need. Enter taxonomies.
Taxonomies drive the modern digital experience
Taxonomies consist of hierarchical organisations of concepts (e.g. a product catalogue) that organise products into multiple categories and sub-categories. A product might live in /men/jeans/slimfit and can also live in /sales/january/jeans/ and /styledits/menscollections/jeans/. Several different taxonomies often apply simultaneously to the same piece of content, enabling the experience to flex by useful criteria such as looking for end of sale bargains, or just finding the right pair of jeans in the right fit. Additional filters (taxonomies) commonly used in fashion retail include price, colour, availability and brand.
One of the key benefits of a headless CMS is that content can be reused in many different places. But to make this a reality requires a classification structure, aka taxonomies, so that content can be categorised against the taxonomy for later retrieval. In this way taxonomies provide for external use cases such as building and managing dynamic navigation, content collections, campaigns, integrated search results (featuring products and relevant content). They also help content managers to organise and categorise content to eliminate duplication and enable automation of the experience, wherever possible.
Which leads us neatly on the more dynamic elements of experience delivery.
Querying the graph
This is where a queryable content delivery API comes in, as it enables content and data that is stored in the graph to be retrieved by key or path, which means that PWA developers don’t need to know in advance what the structure of the experience is, relying instead on a rules based naming convention to construct the query. The PWA can ask the content delivery API to return the right content or data to render the experience, without having to load the whole graph (which be several layers deep and quite large) before parsing it in the app.
Given that rendering a specific view in the PWA may require multiple parallel content and data requests it is important to be able to service the request as fast as possible, so that even multiple graph queries complete in less than 200ms, an acceptable latency (literally the blink of an eye) for most applications. This is a key engineering challenge, as latency on this kind of request can quickly grow to > 1 second (resulting in high mobile bounce rates) because the multiple, parallel API calls required to build a view suffer from over fetching (too much data), or result in many requests for missing data, a phenomenon known as under fitting.
The challenge of latency is one of the key reasons why legacy web CMS and ecommerce platforms are unsuited to driving a modern PWA storefront. Even when these legacy platforms are configured headless, their APIs are just too slow to deliver the kinds of virtually instantaneous load speeds that customers demand. This is why the Amplience queryable content delivery APIs are engineered to return data (time to first byte) in less than 35ms, globally.
Putting it all back together as a whole product
We’ve identified that there are missing tools for business users when moving to a headless commerce solution (as currently defined). And we’ve identified that one of the key reasons for this is because, in the process of removing the head of the monolithic ecommerce platform or implementing a purely headless platform, the web CMS that is an integral part of the software and provides experience management tools for marketers and merchants is removed as well.
We’ve also shown that the missing configuration data (the layouts, views, taxonomies and navigations that define the structure of the experience) can be modelled in a headless CMS like Amplience and stored as data in the content graph, and that with the right sorts of content delivery APIs, content and data can be retrieved from the graph very efficiently and be used to drive PWAs to create rich, high performance mobile and desktop storefront experiences.
But how can we also solve for the missing elements of the business user experience?
To create a coherent solution that satisfies the expectations of merchants, marketers and business managers requires three things:
Suitable tools for defining storefront structure, including navigation menus.
Tools similar to page designer type tools that enable the visual configuration of a PWA screen or view.
Workflows that transcend the CMS and join up experience management and content production tasks.
At first glance the first two challenges seem to be insoluble with a headless CMS as many of them lack content visualisation and preview capability, and they typically use a forms based interface for content authoring which is not suited to the visual merchandising and marketing requirements of the ecommerce team.
At Amplience we not only feature robust visualisation and preview, using the PWA itself to render the experience side-by-side in the authoring interface so that content authors can see exactly what is happening at any given moment when they make changes to content or configuration, but we can also get past the form and build more intuitive authoring controls by way of User Interface (UI) Extensions (eXtensions).
An eXtension is a small application built to enable content authors with content entry tools that are fit for purpose for the kinds of content and data they are working on. By way of example, we have an eXtension that makes it simple to create a nested navigation menu:
Conclusion
We’ve shown that the main challenges of PWA storefront experience management and delivery can be solved by a headless CMS like Amplience, provided that the Content Delivery APIs are queryable and high-performance and that the content graph can be extended to include references to external data like Products.
These capabilities can be configured and managed in content, not code by by creating content controls that make sense for authors and editors via UI eXtensions.
In this way, we at Amplience are closing the Experience Management gap for headless commerce and paving the way for a high-performance PWA based storefront future in which everyone has the freedom to do more.
