In today’s fast moving, competitive world of ecommerce, content plays a critical role in driving results. For decades the only choice for managing content has been yesterday’s web Content Management System (WCMS), and using WCMS with an ecommerce platform has been fraught with danger. So, if content is so important what can you do to incorporate it into your ecommerce journeys?
While I was CTO of an agency I remember one particular engagement with a UK high street retailer: during a board meeting I was asked to work out how they could get more content into their ecommerce site, as they felt more content would increase their conversion and average order values. At the time they had two ways of getting content into the site, adding an image banners at the top of listing/category pages, and the free form method of developers creating HTML for selected pages such as the home page. The image banners, although well designed, were just not enough, and hand cranking HTML was slow, difficult to manage and not scalable without adding more and more developers. So, I put on my architect’s hat and went in search of a scalable solution that could allow the users to push more and richer content into their ecommerce customer experience.
After I reviewed several web CMS platforms, I had used many times before, I quickly realised this was not going to be easy, as Web CMSs are predominantly used for non-transaction websites and built to take full control of the whole website experience (control the glass). If the acknowledged approach was for the CMS to own-the-glass, I’d have to find a way of combining the ecommerce catalogue navigation with the CMS site navigation, incorporate the shopping cart and surface all the transaction elements of the system including checkout and order management. Not to mention dealing with account functionality, promotions, search, merchandising, recommendations and personalization.
From a technical point of view, I would have to somehow decouple the ecommerce platform from the site’s user experience and then try to rewire it into a Web CMS. This approach of open-heart surgery on the ecommerce site was just not feasible as it demanded at least a year of hardcore engineering to rebuild the web frontend using the CMS tech and reintegrate it back into ecommerce platform backend. Not only would this be an expensive high-risk venture, the final implementation would leave business users straddling two completely different systems, trying to negotiate complex functionality on both sides to even achieve the simplest tasks they already took for granted.
The next approach was to look at how I could get content from a Web CMS into the experience driven by the ecommerce platform. This would be simpler for users, as all the existing ecommerce functionality would not change, developers shouldn’t need to tinker with the sensitive transactional elements of the system, and it would reduce the difficulties dealing with compliance across systems.
Again, this was not straightforward, as despite most CMSs including tools and Software Development Kits (SDKs) to simplify development, defining modules of content that can be shared and reused across the site was tricky Web CMSs offer limited flexibility for modelling content, and the models that do exist are tightly coupled to the site and not designed to be used with external systems They require integration on the web server and that the technologies are fully compatible (e.g. Java/.Net).
During the discovery phase new requirements emerged for two native mobile Apps and a move towards a more responsive design. This is the real crux of the problem for Web CMS, ultimately, they generate HTML which burns the content into the presentation and makes it extremely difficult to use in native apps (iOS /Android) and integrate into other features such as search and merchandising. The web CMS templates, the method for producing HTML, often forces you to fuse the CMS and ecommerce systems together in web servers, so when implementing a responsive design, you need to develop and coordinate changes across both systems. Any changes or updates become very complicated and need specialist CMS template developers, front end developers and a full system design/build/deploy process.
Because HTML is useless to pure native mobile Apps, you need to buy or build a specialist CMS for mobile, creating silos of duplicated content. While the business team is looking to be more responsive and agile, this approach has now added an even slower process that is constrained by specialist technical resources and must tie into the IT operations plans.
When using a Web CMS with ecommerce you, you are left with an architecture of a difficult to maintain monolith for the ecommerce site, and silos of content appearing for new channels. One of the other big discoveries is that if you don’t use web CMS to control the glass you lose most of the other added features, they entice you with (personalization/AB testing etc), as they often rely on front end technologies such as cookies.
The total cost, risk, complexity, timescales and an unsatisfactory outcome meant the retailer decided at that point to wait and prioritise other initiatives.
What’s surprising is that this project was back in 2009 and yet retailers today are facing the exact same dilemma. Traditional Web CMS has not seen innovation in decades as they have really spent their time building adjacent addon functionality. Fortunately, a new breed of CMS technology is emerging that addresses all these issues and it’s what my team and I have been working on at Amplience.
The above example was in fact only one of many projects I worked on where I found the same problems. In fact before we built the Amplience Dynamic Content platform, there was a definite pattern emerging around these complexities of joining content with the commerce experience. This informed many of our technical decisions, the first of which was the architectural principles to separate content from its presentation and deliver the content as web services from the Amplience cloud platform. In the industry this method of delivering content is called Content as a Service (CaaS). What it enables you to do is push your content into an ecommerce platform or any other system without fighting over which system owns the glass. This avoids the inevitability of open-heart surgery on your ecommerce sites technology to get it all to work.
The lighter integration involved when you use services for content allows you to introduce content into your ecommerce journeys in a non-invasive way - content can be phased in to the experience by implementing the high value and simple areas first. What I have found after several implementations of integrating content with ecommerce using CaaS is that the lighter touch massively reduces the need in BAU for full design, build and deploy cycles and has significantly less dependencies for IT operations. It means that I have happy customers who can respond much more quickly to change and use their developers for building high value concepts instead of menial tasks.
From a technical architecture perspective, the CaaS model’s clean separation of functionality allows each ecommerce channel to take full control of how it will consume and present the content, avoiding a one size fits all monolith. Another added benefit is that front-end development is simplified for responsive web design and it opens exciting new avenues for front end development such as Single Page Applications (SPAs), Isomorphic (React) and progressive apps.
The key concept of the CaaS approach is to deliver structured content free of presentation, unlike the unstructured nature of HTML generated by the web CMS predecessors. Effectively I now think of content as data, which is perfect for integrating with all sorts of other systems, meaning at last you can inject content into search indexes, merchandising tools, marketing systems for email campaigns and personalization engines, as well as at last supporting native applications properly. I can now get rid of my second pet hate- Silos, as there’s no need for any specialist CMS systems to support.
Another benefit I came across this year of delivering content as services was the scenario of a customer who wanted to start effectively pushing content into commerce as soon as possible. They were looking at moving to a new commerce platform and had reservations about implementing a CMS because of migrating/ recreating content, integration costs and the compatibility of the technology. With the CaaS model the content does not need to be touched, there is no server-side dependency on the technology and the integration is much lighter, and therefore costs are relatively low.
Create once publish everywhere (COPE) is the philosophy that an item of content can be created for one purpose and then reused repeatedly in multiple channels for different purposes. Now that your content can be delivered as a service in an easy to consume data format like JSON, content becomes portable enough for you to insert it into any experience, regardless of the system or the device: including mobile Apps, websites, support tools, in-store Apps, Point of Sale and IoT devices. The fact that content is separated from presentation, making it completely display agnostic, reinforces the ideals of COPE as content can be refashioned into the most appropriate experience for the consuming device, app or channel. Building the Amplience content services as a cloud platform allowed us to create a system that delivers on the full potential of the COPE approach, not only can you reuse and repurpose content across multiple channels, you can also coordinate the delivery of this content to every single channel at a single moment in time.
A customer recently asked me “can I get the promotion banner we use on the website to also sync with our instore App to make sure our customers are getting the same message online and in store?” – the answer is yes that’s easy.
Many of the customers I talk to agree that a personalized experience would make a significant difference to their commerce performance. However, most ecommerce sites have either no personalization or very basic personalization that is usually not much more than product recommendations. Sites that personalize the experience beyond their products are limited to basic targeting of a small number of customer segments. After decades of product development in personalization technology, and with the big data revolution giving businesses the tools to process and analyse data in vast quantities, why should personalisation be so difficult?
Nearly everyone I speak to tells me their primary reason for not reaching their personalization aspirations for commerce is content. The reasons why content has been the issue so far include:
As with the other systems, it is difficult to integrate content if it is delivered as HTML. Because most personalization systems need to understand the content to make informed decisions about what content to show to which customer, a blob of HTML just doesn’t cut it. CaaS delivers the content in a machine-readable format. We deliver the content as data. Data is like candy to a personalization engine as it can consume the content, digest it and make inferences that connect it with customer data. This is why personalization so far seems so obsessed with products, because products have nicely organised packets of data that personalization engines love.
Customers tell me that one of the largest blockers to personalized experiences is the sheer volume of content required. The more segments you want to target, the more variants of content you are going to need, and if you then wish to do this in multiple channels the amount of content to produce is impossible. This does not even consider the challenges of the frequency of change required to keep content fresh and relevant, or shifting from targeting customer segments to personalised experiences for individuals. So how can CaaS help us to generate all these content variants we need without having to gather an army of content producers?
Although delivering the concept of ‘content as data’ is fundamental to integrating with personalization engines, providing an understandable structure of how the content is composed transforms how the personalization engine can use it. In the technology team at Amplience we came to this conclusion very early on in the development and decided to not only make the content data, but to also modularise the content and allow these modules to be combined in different ways to create larger more sophisticated content structures. Think of each piece of content as a building block that can be easily assembled by users into larger pieces of content - for example a carousel can be easily built by adding five slides that you have already created previously.
Personalization engines that understand and interpret these structures can alter the structure intelligently into a customised variant of content for a segment. You can even build entirely new content structures tailored to a customer based on the data the personalization engine has collected. The fact that the content is display agnostic means that it does not cause any of the technical issues you get from trying to merge odd shaped HTML fragments that ultimately breaks your site experience
I have found having a clear content strategy that can clearly model your content structure and personalization concepts is fundamental to achieving the goals of personalization. You also need a CaaS, as it the only system that can define, encode and deliver the content in a way that personalization engines can really take advantage of.
Imagine how annoying and difficult it would be if driving a car required two people because the steering wheel was on one side and the peddles were on the other. I found that this was exactly how users felt when trying to use a traditional Web CMS with an ecommerce platform. Even if you spent a huge amount of time and effort to get them to work together, the business users are left bouncing between the Web CMS and commerce platforms just to do their day to day. This happens when you need two systems to complete a task and they are just not integrated in a way that the functionality overlaps, so you can smoothly transition between using the platform in different contexts.
You’ll hear me say it again, but integration is the most important part of joining the functionality that different systems provide. During the design of the Amplience system as a cloud platform, this aspect was even more important and became the driving force to take the API first and micro services approach. We decided to build every single bit of functionality on the platform as a micro service, whether it’s creating, updating, scheduling or publishing content.
We built a user-friendly CMS UI, as we obviously didn’t expect business users to use an API client to manage all their content. But what is extremely interesting about using the micro services approach is the ability to decide where you went CMS functionality to materialize: stand alone, all in the ecommerce platform or shared. You now have a choice of how much overlapping functionality there is between the CMS and any other systems. Users can now spend all their time in one system or smoothly traverse across systems depending on the context of what they are doing.
Call toll free 866 623 5705
or +1 917 410 7189
Call +44 (0)207 426 9990