HomeDev GuideAPI Reference
Dev GuideAPI ReferenceUser GuideGitHubNuGetDev CommunityDoc feedbackLog In

`EPiServer.Personalization` allows a single Optimizely Customized Commerce installation to connect to more than one Personalization Engine instance, that is, multiple personalization accounts. To support multiple personalization accounts, `EPiServer.Personalization` supports the concept of \_scope,\_see [Using Scopes in a Multisite Installation](🔗).

This example describes how to connect personalization accounts with scopes.

## Prerequisites

  • An [Optimizely Customized Commerce site](🔗) v12.4.1 to v13. For Optimizely Customized Commerce version 14, see [Installing Optimizely (.NET5)](🔗).

  • [Quicksilver sample site](🔗), v12.4.1 or higher (optional).

  • _EPiServer.Personalization.Common_, v2.0.0 or higher.

  • [Personalization API base URL, client token, admin token and site](🔗).

## Scope settings

Scopes are useful for example in scenarios where you have personalization on multiple sites. If you only have one site with personalization features, you can use _scopeless_ settings.

If you need to configure multiple scopes, the scope name must be the site's **SiteDefinitionID**. To find that value, log into the Optimizely Content Management System (CMS) and go to **Admin** mode > **Config tab** > **Manage Websites**. In CMS versions 11.5.0 and higher, this value is shown for each site. See [Using Scopes in a Multisite Installation](🔗).

These are some examples of defining and using scopes.

## Scopeless settings

Settings with no alias suffix are called "scopeless". You can consider all settings in earlier versions of the configuration schema as scopeless.

Scopeless settings are used as a fallback if a requested setting is not defined for a specific scope, meaning that the configuration schema is backwards compatible.

**Personalization with specific scope**

Example of using personalization with a specific scope to score search results.

**Track with specific scope**

Example of tracking search with a specific scope, only effective if the _EPiServer.Find.Personalization_ package is installed.

## Default implementation

You get a default implementation of the scope feature with the _EPiServer.Personalization_ and _EPiServer.Find.Personalization_ packages. This implementation assumes that each CMS site uses one Commerce catalog and one Personalization Engine instance.  If this setup fits your needs, set it up using the configuration only. For a more specialized setup, you need to write custom code.

The default implementation stores preference attribute data in cookies in the same way as earlier versions. If you have a single site using Personalization, you do not need to modify this behavior. To add additional scopes, you probably need to implement your own `IPreferenceRepository` and modify CUID and SessionID storage behavior. See [Using Scopes in a Multisite Installation](🔗).

## Modify the default behavior

If your installation differs from what is supported by the default implementation, you can write custom code as described in the following.

Preference attribute data depends on the CUID and SessionID.  This data is created by the Personalization Engine and is only valid for the Personalization Engine instance that created them. So, these values need to be siloed per scope.

The default implementation stores preference attribute data in cookies bound to the current domain. This implementation covers the common scenario where domains are not shared between scopes. To support the sharing of two scopes with a single domain, write custom code.

Another possible scenario is splitting an existing scope in two. In this case, make sure that existing cookie values are not used for the new scope.

To control how cookies are created and read for a scope, replace the default IPreferenceRepository implementation with your custom implementation. You also need to change the default ICookieService implementation used in _EPiServer.Personalization_.