HomeDev GuideRecipesAPI Reference
Dev GuideAPI ReferenceUser GuideLegal TermsGitHubNuGetDev CommunityOptimizely AcademySubmit a ticketLog In
Dev Guide

Disable personalized content

Describes how you can disable personalization, such as Visitor Groups, within Optimizely Content Management System (CMS).

📘

Note

This content applies to Optimizely Content Management System (CMS) versions 11.8.0 and higher.

When you enable personalization and a requested content item uses visitor group personalization, CMS evaluates the visitor against the used visitor groups and visitor groups criteria. The content displayed to the visitor is selected depending on which visitor groups match the request. CMS may store tracking data in cookies or a session state, depending on the criteria used.

When personalization is disabled, no matching occurs, and you do not consider the visitor to be part of any visitor group. Instead, the visitor is displayed the "fallback content" if you have it defined on the personalized content. When personalization is disabled, no state is stored in cookies or for the visitors' sessions.

IPersonalizationEvaluator

As shown, you can implement an interface to control whether personalization should occur.

/// <summary>
/// Signature for a component that determine if personalization should be performed or not for the current request
/// </summary>
/// <remarks>
/// Registration of an implementation is done by register the implementation in IOC container
/// </remarks>
public interface IPersonalizationEvaluator {
  /// <summary>
  /// Determines if current request should be personalized or not
  /// </summary>
  bool Personalize();
}

Examples

CMS includes an implementation that checks for a Do Not Track header presence. If the header is present, personalization does not occur for the request and no cookies are stored. You can register it in ConfigureServices in the startup, as in this example:

public class Startup {
  public void ConfigureServices(IServiceCollection services) {
    services.AddTransient<IPersonalizationEvaluator, DoNotTrackPersonalizationEvaluator>();
  }
}

Another example could be to check for a certain cookie, which specifies that the visitor has agreed that visitor group personalization could occur. In that case, the site could have a field where the visitor can enable personalization. When the visitor selects that field, a cookie is added for the visitor. Such an example could look like:

[ServiceConfiguration(typeof (IPersonalizationEvaluator), IncludeServiceAccessor = false)]
public class CookiePersonalizationEvaluator: IPersonalizationEvaluator {
  public
  const string PersonalizeCookieKey = "Personalize";
  private readonly ServiceAccessor<HttpRequestBase>_requestaccessor;
  public CookiePersonalizationEvaluator(ServiceAccessor<HttpRequestBase>requestAccessor) {
    _requestaccessor = requestAccessor;
  }
  public bool Personalize() => _requestaccessor()?.Cookies[PersonalizeCookieKey] != null;
}

Check if personalization is enabled

Use the IAggregatedPersonalizationEvaluator component to check whether personalization is enabled for a request. The signature is similar to IPersonalizationEvaluator and it returns an aggregated result from registered IPersonalizationEvaluator instances. If any personalization evaluator states that personalization should be disabled, then the aggregated evaluator states that no personalization should occur.