I've occasionally seen the requirement for tokenised content in Episerver. By tokenised I mean the ability to insert a token such as [ContactUsEmail] or [Telephone] site wide and have it populated based on values set at a site/section level. This allows site editors to set the value of a token once and have it populated across the site.
A new version of the Visitor Group Usage Viewer is now available on the Episerver Nuget feed that is compatible with Episerver 10.
The visitor group usage viewer adds a new component that shows the visitor groups that are used on the current content item when in Episerver edit mode. It also separately shows any content that's referenced on the current content item (such as blocks or pages in a content area) as this could also affect the rendering of the current piece of content:
This post describes how to use Episerver A/B testing and Episerver Visitor Groups to test an entire customer journey against a Episerver A/B test KPI.
Why would you want to personalise based on a running A/B test?
Sometimes A/B testing an individual piece of content isn’t enough to really prove an outcome. A simple example could be does the text “Continue” or “Next” work best on a button on a checkout path. The button exists on multiple content items so would need to be changed in multiple places. By using Episerver Visitor Groups it should be possible to test multiple pieces of content on a site using visitor groups based on a running A/B test.
Episerver Digital Experience Cloud service (DXC-S) can host multiple customer sites in a single Episerver instance running on a single codebase. This is run on the cloud as a managed service delivered by Episerver and costed on a consumption based model. This is a good approach for organisations that want to share the consumption and managed service offered by DXC-S across brands/sites/countries/anything they wish. However it's not always possible to migrate multiple sites to Episerver Digital Experience Cloud Service (DXC-S) in one go and customers often may need or want to take a phased approach. It may not also be possible to run all sites off a single codebase. So this post describes some approaches when migrating to DXC-S.