Skip and go to main content

Design & Technology December 05, 2018

Why you need a Headless CMS to do Personalization right

Image

Personalization has been little more than a pipe dream in most organizations for many years. Many platforms claim to support it, but there has rarely been solid examples of how to approach it in practice. So often, the personalization dream can quickly become a false promise for marketing teams.

This hasn’t been helped by various technology vendors trying to offer an all-in-one style solution by acquiring marketing technologies and rushing a fragile integration. This usually results in a solution which demands integrating all of your data with the content manager. Often, it results in duplicating data, such as CRM, and creating challenges regarding how this duplicate data is kept in-sync.

Some thought-leaders would claim that the CMS has no place in modern marketing solutions, but we disagree. A CMS remains the best tool for managing and publishing content, but it should not be used to publish a website if you want to produce a dynamic and real-time personalized experience. The traditional CMS is being displaced by the headless CMS.

Image

Enter the headless CMS…

A headless CMS decouples the structured content from the presentation and allows us to treat content delivery as one of many providers. By thinking of content as a provider responsibility, we can create middleware to handle incoming requests from a channel, interrogate the appropriate providers (including content delivery), consolidate and transform the provider responses into a domain model, and return it accordingly.

Image

Utilizing Context 

Traditionally, we have requested content by a uri or id. By using a provider, we can request content by context instead. A context includes many properties relating to the channel, device, customer and geo-location. The provider is responsible for taking a context and using it to interrogate content delivery, which can include transforming the context into a format that can be used internally for personalization.

For example, suppose you include context properties that describe the content types the user has engaged with during the current and/or previous sessions (e.g. a given user may have engaged with video more than carousel types). This information can be re-formatted by the provider and included internally as it interrogates content delivery services to return content classified as ‘video’ instead of ‘carousel’ to the returning user.

Each CMS handles dynamic content differently, but there are mechanisms to classify content or provide variations based on customer characteristics that enable the content query to return different content accordingly. In addition, a special syntax can be used within the structured content itself to be replaced with context property values such as: %{context.user.firstName||Anonymous}%.

Introducing AI

This approach to delivery architecture and context-based interaction becomes really interesting when we consider the implications of personalizing the response from other providers such as DAM (Digital Asset Management) or PIM (Product Information Management). It’s conceptually identical to use a customer’s engagement history to influence the products they see or the attributes of a product. For example, a customer who engages with safety products sees attributes about safety, given precedence over the attributes relating to other categories.

By abstracting the provider interaction with a context, we can also introduce a convenient facade against which we can later introduce artificial intelligence to be involved in the decision making for what is returned from a provider, based on the context properties.

A similar provider model can be applied to conceptually separate layout (design) from content and treat them independently. By doing this, we could have AI influence the layout of the page but not the content or vice versa. This is an evolution of multi-variate testing that could potentially fully automate back-propagation based on engagement, to continually improve the personalized experience.

To maximize the potential for this approach, a CDP (customer data platform) should be used to handle the assignment of a persistent unique identity for all customers (including anonymous visitors), and the consolidation of multiple customer profiles for identified customers. This ensures that the providers can adhere to a customer profile that is consistent across the entire domain. Customers who interact via multiple channels get the same experience and don’t suffer from being segmented differently depending on which device they use, or which channel they interact with.

Personalization is powerful and, when teamed with an audience-first digital marketing strategy, can revolutionize customer experience, engagement and online revenue. Technology has reached a stage of maturity that makes this a very real possibility for businesses, but it’s important to select the right platform for your needs. Headless platforms are absolutely the way forward!

Questions? We're here to help!