Skip to content
In this article

Personalization - Segmentation - Implementation

By Eric St-Pierre, 10/26/2021

This article is part of the Personalization serie.

This is the third article in a series about personalization. During this series, I will cover the different sides of personalization, from more general definitions of personalization to Optimizely cloud-based products offering and how to implement them. The first article was about building the foundation to help customers move along their personalization journey. In the second article, I explained what segmentation is and how it is translated in an Optimizely implementation through visitor groups. In this article, I will cover how to achieve personalization by implementing and using visitor groups.

Visitor Groups implementation

You might be developing a personalization strategy with a client, and you have defined some visitor characteristics on which we want to personalize some piece of content. Those user’s information will allow you to split users into groups or segments. So now that we have identify some visitor segmentations, how can we use them to personalize the user experience? Visitor groups can be used to conditionally render content on a page based on those segments.

Personalization using visitor group can be seen as a rule-base kind of personalization. You implement personalization by creating visitor groups based on criteria and apply those groups to target content for the segment. Visitor groups are using data from visitors incoming HTTP request to match against the criterion.

How to use visitor groups to personalize content

Visitor groups can be used to personalize many parts of the content, from content area, blocks and rich-text to products discounts and marketing campaigns.

To apply a visitor group to a piece of content, you need to open it in edition mode. Then, from the editor toolbar, you can choose the Personalized Content option.

You will then be prompted to choose one or more visitor groups to apply to the selected content.

You can also apply visitor groups to content area by using the Personalize option from the context menu.

To preview the impact of the visitor groups on the visitor experience, you can use the Preview option and choose for which visitor group you want to preview the experience.

For more details, you can visit the Optimizely Visitor Groups user guide

Custom visitor group criteria implementation

If the provided set of visitor groups doesn't fulfill your customer needs, you can implement your own visitor group criteria. Let’s say you want to personalize some content based on a value stored in a cookie. We will take this example to go through the steps to implement a custom visitor group. Let’s implement a visitor group that evaluates if a visitor has a specific cookie and value.

To develop custom visitor group criterion, you need to implement at least two classes which are a model class and a criterion class. The model class will be used to store and persist the configuration of the visitor group entered by an editor in the visitor group editing interface. The criterion class is used to evaluate the visitor context against the visitor group configuration data and check if the criteria are fulfilled.

The model class

The model class instances are persisted to the Dynamic Data Store, and they must implement the ICriterionModel. You can inherit from the CriterionModelBase class, which implement the ICriterionModel interface with standard behaviors. There is one method that needs to be overridden, which is Copy(). If the model has only simple value properties, then you can call the base.ShallowCopy() which will create a copy of the model. If your model has some reference type properties, then you must add logic to copy those properties.

To this model, you need to add public properties that will represent the criterion settings in the administration interface. Input fields will be created using suitable editing element. If you want to control parts of the rendering of the property, you can add the CriterionPropertyEditor attribute. PreText and AfterText can be used to add text before and after the element. If your Optimizely administrative interface is translated, you can add a translation for the labels with a xml localization file. You can also use the CriterionPropertyEditor attribute to set the input to be a dropdown list with predefined options. To do so, you would assign an implementation of the ISelectionFactory interface to the SelectionFactoryType attribute. If the options you want to use can be represent as an Enum in a dropdown list, you can use the EnumSelectionFactory included in the Content Cloud implementation. Visit the Using the CriterionPropertyEditor property attribute for more details on other attributes you can set for a property.

Validations rules can be assigned for required fields, range of values, length of a string or a matching regular expression by applying validation attributes to the properties. Custom server-side validation can also be applied by implementing the IValidateCriterionModel interface on your model.

Here is an example of the implementation of the model class for our cookie with value example.

using EPiServer.Personalization.VisitorGroups;

namespace Foundation.Personalization.Criteria.CookieExistsWithValue
    public class CookieWithValueModel : CriterionModelBase
        public string CookieName { get; set; }
        public string CookieValue { get; set; }

        public override ICriterionModel Copy()
            return ShallowCopy();

The criterion class

After we have the implementation of the model class, we must implement the criterion class to evaluate if the visitor context and the criterion data stored in the model match or not. To implement the criterion class, we must inherit from the CriterionBase class, passing it our implementation of the ICriterionModel. We then must override the IsMatch()method which is called to evaluate if a visitor is part of a visitor group. The last part is to decorate the criterion class with the VisitorGroupCriterion attribute to identify the class as a criterion. Category identify the group in which the criterion will be found. DisplayName and Description are used for the name and tooltip description.

If you have some requirements, you can override the event handling done for the following events, StartRequest, EndRequest, StartSession or VisitedPage. You can override the event handling by overriding the Subscribe and Unsubscribe methods to provide you specific handlers.

Following is the example of the criterion class for our example.

using EPiServer.Personalization.VisitorGroups;
using System.Security.Principal;
using System.Web;

namespace Foundation.Personalization.Criteria.CookieExistsWithValue
        Category = "Custom",
        DisplayName = "Cookie Exists with Value",
        Description = "Evaluates if a visitor has a cookie with a specific value")]
    public class CookieWithValue : CriterionBase<CookieWithValueModel>
        public override bool IsMatch(IPrincipal principal, HttpContextBase httpContext)
            return (httpContext.Request.Cookies[Model.CookieName] != null &&
                httpContext.Request.Cookies[Model.CookieName].Value == Model.CookieValue);

This would be the experience of an editor configuring an instance of our custom visitor group.

This implementation of a custom visitor group would be configured and used by an editor to personalize content as any other pre-package visitor groups.

In this article, I covered the steps to use a visitor group to personalize content and how to implement your own custom visitor groups. In the next article of the series, we will discuss another personalization step, which is content recommendation.