---
title: Connect multiple personalization accounts
slug: cms-12/docs/connect-multiple-personalization-accounts
docTags: 
createdAt: 2026-08-10T15:56:00.000Z
---

`EPiServer.Personalization` lets a single Optimizely Commerce Connect installation 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 [Multiple scopes](https://docs.developers.optimizely.com/commerce/v14.0.0-commerce-cloud/docs/multiple-scopes).

This example describes how to connect personalization accounts with scopes.

## Prerequisites

- An [Optimizely Commerce Connect site](https://docs.developers.optimizely.com/content-management-system/v1.1.0-search-and-navigation/docs/installing-optimizely-legacy-cms-11-and-commerce-13) version 12.4.1 to 13. For Optimizely Commerce Connect version 14, see [Install Optimizely (ASP.NET Core)](docId\:VuiU-K4aAR6ISGicFg4lk).
- Quicksilver sample site, version 12.4.1 or higher (optional).
- `EPiServer.Personalization.Common`, version 2.0.0 or higher.
- [Personalization BaseApiUrl, client token, admin token, and site](docId\:XAQQtrEw7kmy6HqVJAuK7).

## Scope settings

You can use scopes 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**. CMS versions 11.5.0 and higher show this value for each site. See [Muiltiple scopes](https://docs.developers.optimizely.com/commerce/v14.0.0-commerce-cloud/docs/multiple-scopes).

These are some examples of defining and using scopes.

![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/ok0GXzCJzmt4-VOHJC7dp_95e4d1e-find-controller-example.png)

![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/9m8ln2d-LABla1cZn1W20-20260722-164947.png "personalizationsettings-class-example.png")

![](https://api.archbee.com/api/optimize/BrbvVORKJ5iIeSMZye5kI/9pRaldG8jn8ZacBPwcUcG-20260722-164947.png "web_config_example.png")

## Scopeless settings

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

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

**Personalization with specific scope**

The following is an example of using personalization with a specific scope to score search results.

```csharp
public static IQueriedSearch<TSource, FunctionScoreQuery> 
UsingPersonalization<TSource>(this ISearch<TSource> search, string scope)
```

**Track with specific scope**

The following is an example of tracking search with a specific scope, only effective if you installed  the `EPiServer.Find.Personalization` package.

```csharp
public static ISearch<TSource> Track<TSource>(this ISearch<TSource> search, string scope)
```

## 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 (PaaS) catalog and one Personalization Engine instance. If this setup fits your needs, set it up using the configuration only. For a more specialized set up, 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 [Muiltiple scopes](https://docs.developers.optimizely.com/commerce/v14.0.0-commerce-cloud/docs/multiple-scopes).

## Modify the default behavior

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

Preference attribute data depends on the `CUID` and `SessionID`. The Personalization Engine creates this data, and is only valid for the Personalization Engine instance that created them. So, silo these values per scope.

The default implementation stores preference attribute data in cookies bound to the current domain. This implementation covers the common scenario where there are no shared domains 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. Do not use existing cookie values for the new scope in this case.

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`.