Multisite Implementation Strategy
Marketing Cloud Personalization accounts are similar to Marketing Cloud tenants - customers typically sign up for a single account for their license and can have multiple datasets associated with each account.
Each dataset in Personalization is a separate, siloed data environment. As datasets do not share data among themselves, the same user could have an independent profile in each dataset. Campaigns, segments, statistics, and integrations are also not shared between datasets. Personalization customers can also set permissions levels for their teams, ensuring that each team has access to the datasets they need to use Personalization for their business needs.
It is common to have a single dataset associated with one web domain. However, it is possible to have more than one domain on a Personalization license or a domain serving multiple countries in multiple languages. In these cases, dataset design during the discovery process is essential in a successful Personalization implementation.
- How many web domains does the license include? Are they all the same brand, or are they different brands?
- How many countries (or locales) does the domain support?
If there are multiple domains on one Personalization license, either maintain a separate dataset for each domain or combine the domains into a single dataset. Often, it is best to have a single dataset per domain, but there are good reasons to combine multiple domains into a single dataset. The following sections provide guidance on using a single dataset for multiple domains.
Depending on the catalog differences between the different sites, there are some things to consider when designing the catalog data model. If the sites do share products with identical IDs, it is advisable to differentiate between these products by making the IDs unique per site. You could do so by prefixing the IDs that a unique identifier for the site would capture.
For example, consider two sites, foo.example and bar.example. These two sites share a product with the ID
abc123. When importing and capturing catalog data, you could prefix this product ID based on the site to differentiate the product in the Personalization Catalog since it could have different attributes depending on the site. On foo.example, the ID could become
foo_abc123, and on bar.example, the ID could become
To help differentiate products that exist on different sites in the same dataset, it is a good idea to track a related catalog object for the site the product appears on. This related catalog object would allow for differentiating products available only on the site the user is on in recipes. Consider the two sites foo.example and bar.example. When viewing a product on foo.example you could set this related catalog object to
foo.example and when viewing a product on bar.example you could set this related catalog object to
bar.example. Having this related catalog object available would allow adding a recipe exclusion to any recommendations so that only products available on the site the user is on would be recommended.
When mapping multiple sites to the same dataset, these sites share the Web SDK and Sitemap integration.
Setting the Cookie Domain
By default, the current domain is set as the
cookieDomain when initializing the Web SDK. To configure the
cookieDomain setting, you must dynamically determine which domain to set the cookie on since different sites share the initialization.
The following example shows how to dynamically determine and set a custom
cookieDomain based on the site where the Web SDK is initializing. The Personalization Web SDK anonymous user IDs are generated separately for each domain. When integrating multiple domains in the same dataset, users tracked anonymously are tracked as separate users across the different domains.
Initializing the Correct Sitemap
When mapping multiple domains to the same dataset, it is good practice to have separate Sitemap configurations for each domain. Doing so allows you to configure unique Page Types for each site. After you have built the Sitemap configurations for each domain, you will need to initialize the correct Sitemap configuration based on the domain the user is visiting currently.
The following example depicts a configuration that initializes the correct Sitemap for the domain a user is visiting currently.
Page Types and Content Zones
Make sure that the
pageType names are consistent between the domains. A product detail page on foo.example and a product detail page on bar.example shares the same
product_detail page type. Actions and catalog items can differentiate which site the user is visiting.
While Content Zone selectors could differ between two domains, ensure that Content Zone names are consistent across domains to facilitate sharing templates and campaigns.