The Optimizely brand has always featured personalisation as one of its primary objectives.
In recent years more product offerings have been added to the Optimizely line-up as a result of business acquisitions and continuous development efforts. Some of these products have broadened the personalisation capabilities by adding new and improved features, while others seemingly offer somewhat similar features.
The product names, and how they are presented to customers, have seen numerous iterations to help unify the platform. It has created a lot of ambiguity when talking about personalisation and the Optimizely platform in general. As an Optimizely MVP, I often get asked to explain what personalisation features are available in the platform, and what it takes to get them up and running. It has motivated me to write this article and give a clear explanation of the Web Personalization and CMS Personalization solutions offered by Optimizely.
Personalisation means showing users content that is relevant to them specifically. Data needs to be collected about each individual user to identify what content is relevant to them. Platforms that offer personalisation will provide various user tracking capabilities and features to segment content based on the collected data. In this article I will give examples of how this works in Optimizely's products.
If you see any terms that are not familiar, you can look them in up in Optimizely’s glossary. Note that this blog is written in UK English and the Optimizely website and products are in US English, so there will be a lot of ‘s' vs 'z’.
The benefit of this type of integration is that it requires very little time to set up and it works practically for any website — regardless of its underlying platform and tech stack.
The personalisation can be targeted towards audiences, which are users grouped together based on certain conditions. The audience conditions are powered by the data that is collected for each individual user. There are configurable options called pages, events and tags that help to identify content and track specific user behaviour.
For example, you can set up a tag that identifies the price on a product page, and then an event can be configured to track if the add-to-cart button is clicked.
The GIF below displays how that data can then be used to create an audience condition which will only include users that have added a product to their cart with a price greater than 500. It's a very effective and easy-to-configure way of targeting users for personalisation.
The personalisation is driven by a framework that's based on creating and running Personalization Campaigns. A campaign acts as a container for personalised experiences and is focused on certain pages. Inside the campaign we can create variations of those pages and target each variation towards an audience.
For example, we can create a variation and make changes to the hero banner on the homepage, and only show that variation to a specific audience. The visual editor gives us the on-page editing features needed to make almost any changes to the hero banner — thanks to its smart integration with the website.
Besides making basic content edits, it's possible to inject or update HTML and CSS. There is a code editor feature that will help tech-savvy people to make more advanced changes.
Another interesting feature of the visual editor its interactive mode. This mode gives you the ability to interact with the site and trigger otherwise hidden content, such as a popup modal, so that it can then be edited. Very useful for the dynamic websites and especially for Single-Page Applications (SPA).
Source: Visual Editor in Optimizely
One of the core purposes of Web Personalization is to measure and monitor the performance of campaigns. The Stats Engine is a feature that can calculate statistics based on the data collected during a campaign.
Metrics need to be configured to specify the data points that will determine the campaign's success. For example, you can set up a metric for add-to-cart button clicks, which will then be shown as a statistic in the campaign's Results page.
A holdback is also required in order to accurately measure the performance. The holdback is a percentage of the users in the campaign that will see the default experience instead of the personalised experience. The percentage is configurable, but it is set to five percent by default.
There is a lot more to talk about when it comes to the results page and the Stats Engine. If you are interested in learning more, this page gives a good overview of the range of features that are available in the Results page.
The Optimizely CMS comes with personalisation features out of the box. Content editors can use this to easily personalise any of the content fields that are made available by developers. It also means that a developer needs to add a field for something like the background colour of a component if that’s what you wish to personalise.
Our strategy at Luminary is to provide enough flexibility for editors to freely make changes to the content, the page structure, and certain visual aspects. It ensures that practically any of the content can be personalised from the start — avoiding overhead in the later stages of development.
In the CMS there is a section to configure visitor groups and add criteria to them, which is very similar to audiences and conditions in Web Personalization. There are a number of configurable criteria available such as number of site visits, URL referrers and geolocation area. They are what you would expect from visitor grouping and will get the job done for a basic personalisation setup.
For the more in-depth personalisation strategy, developers can create custom criteria and tailor them to specific requirements. The benefit of these custom criteria is that they have access to any data and integrations inside the CMS because they are developer-driven.
Pages in the CMS are mostly separated into multiple sections called blocks. Each block has personalisation options to show or hide it based on the visitor groups.
For example, a hero banner has been created by a developer as a block and we want to display a different hero banner for first time visitors to the site. The image below shows two hero banner blocks that are configured to display for different visitor groups.
The same can be applied to media, forms, and products in Customised Commerce. This is made possible by the consistent editing experience between the different types of content. Pages are personalised differently though, because you have to use the permissions feature to restrict access to the page. It's very straightforward, you simply select which visitor group is allowed to view the page.
There is also a feature in the text editor that makes it possible to personalise specific parts of a piece of text. The image below shows a simple example of how the heading of the text is personalised. Therefore, we don’t need to duplicate the entire text in order to create a content variation.
Comparing the two solutions
When comparing CMS Personalization and Web Personalization there are a lot of similarities in what they bring to the table. Taking a high-level view at the two products, Web Personalization goes the extra mile with detailed analytics and measurement tools to experiment with content and understand the impact of personalisation on user engagement, while the CMS offers a flexible and robust solution that is fully integrated with your content management. Let's delve deeper into some of the important differences between the two.
Optimizely offers a range of options to get the best performance, but it can definitely make things more complicated than it initially seems. The way personalisation works in the CMS is a lot more straightforward because it operates at the source of the content.
The benefit of Web Personalization's client-side integration is that it does not rely on direct integrations with other web content systems or compatibility with particular development frameworks. If you are looking to add personalisation to your website without re-platforming entirely to a new CMS, then Web Personalization could be the perfect answer.
Content – The benefit of personalising content directly in the CMS is that it keeps your content organised and in one place.
Web Personalization is an extra layer on top of the content platforms that you are already using. It can lead to inconsistent content management, because you need to switch between platforms at times to find the content. When editing a page in your CMS, the content can be overwritten by Web Personalization, which can lead to confusion for editors.
Results and analytics – Web Personalization is the clear winner when it comes to gathering data about your personalisation strategy and analysing the results. The CMS relies on third party integrations to gather analytics in order to understand the changes in user behaviour.
Visitor groups vs audiences – Both solutions are very similar in what they are trying to achieve but have what can be considered as a customisability vs configurability approach to achieving it.
Web Personalization offers audience conditions that are very advanced and easy to manage, whereas the CMS offers basic visitor group criteria that will require developer-driven customisations to meet more advanced requirements. In the end, audiences are considerably more capable and advanced than anything else in the industry.
Updates and features – In recent years, CMS Personalization has seen very few updates and newly added features. I'd like to see Optimizely extend on the great personalisation framework in the CMS and use integrations to bring it more in line with Web Personalization.
CMS Personalization is now somewhat overshadowed by Web Personalization, understandably so because it does not really compete with a product that has personalisation as a primary goal. That said, personalisation is still considered a core and staple feature of the Optimizely CMS.
Headless – Amazingly, Web Personalization will work for headless websites on any platform because it operates on the client-side. That also means it technically does not support applications other than websites. Optimizely's Feature Experimentation sub-product is the answer to that, but it requires a developer-driven integration with your application. It also may not support all of your favourite features from Web Personalization.
The CMS does have omni-channel capabilities due to its headless APIs, but visitor groups only support browser-based tracking. Optimizely's Data Platform (ODP) can be integrated with the CMS (and also Web Personalization) to provide a robust user data tracking solution that can support headless personalisation strategies.
Even though it can seem like a lot, there is still more to discover about personalisation. Optimizely offers multiple AI-based solutions for automatically suggesting content to users – known as Optimizely Recommendations. Feature Experimentation (previously called Full Stack Experimentation) is an experimentation sub-product that can provide a developer-driven approach to rolling out new features to a percentage of your users.
Then there is the Optimizely Data Platform (ODP) that can tie together data about your users and drive personalisation by integrating with either Web or CMS Personalization — powering headless personalisation capabilities. That said, all of the above solutions are deserving of dedicated articles – stay tuned!
Want to tap into the expertise of Optimizely's APAC Solution Partner of the Year?Get in touch
Want more? Here are some other blog posts you might be interested in.