Multi-site Management
What is multi-site?
A multi-site is also called a multiple-version site. You have a multiple-version site if your site has different versions that have the same structure and similar product catalog for different regions, languages, or brands. For example, if you have a site that has a version for English and another version for French, then you have a multi-site.
As a merchandiser, you can manage multiple versions of your site in the Bloomreach Dashboard. You accomplish your tasks in the same way as for single-version sites, but with a few choices that single sites don't have. These choices let you propagate your merchandising changes across all site versions or a set of versions. You keep the flexibility of overwriting changes at the site-specific level. Before we go any further, let's define some basic terms that will help you understand multi-site management in the Bloomreach dashboard.
Account: used to define the primary account. All individual sites and site groups roll under this account.
Site group: used to define a group of sites under the global account. For example, let's say Homeoasis has 3 site groups: Canada, US and Switzerland. Under Canada, they have homeoasis_ca_fr (Homeoasis's Canadian site in French) and homeoasis_ca_en (Homeoasis's Canadian site in English). In this example, Canada would be considered a site group.
Individual site: used to define an individual site under a site group. In the above example, homeoasis_ca_fr and homeoasis_ca_en are considered individual sites.

Who may have multi-site support in the Bloomreach dashboard?
-
Large brands that may have multiple sites or domains for each sub-brand. Merchandisers want to be able to view data for each site individually or view data across all sites globally. Therefore, they support individual and global views of different domains or subdomains (e.g. homeoasis.com, shop.homeoasis.com, homesbyhomeoasis.com)
-
A regional retailer with a core UK site and several smaller country or language sites (eg: French, German, etc...). Merchandisers want to have a global and individual view of the country sites but may want to keep the UK site data separate. Merchandisers need the ability to:
- Support individual site-only views with a combination of global and individual site views (eg: I want to see homeoasis.co.uk separately, but have a global+individual view of homeoasis.fr and homeoasis.de)
- Support individual and global views of URLs with the same domain but different folders or paths (eg: .com/france or .com/language=german)
- Support individual and global views of URLs with the same domain but different TLDs (eg: homeoasis.co.uk vs homeoasis.fr)
- Support individual site-only views with a combination of global and individual site views (eg: I want to see homeoasis.co.uk separately, but have a global+individual view of homeoasis.fr and homeoasis.de)
-
Large brands with several micro-sites across different regions in Europe, who want to group these sites together and view data accordingly (eg: Group A (Site 1, Site 2 Site 3), Group B (Site 4, Site 5)).
-
Brands that have multiple product catalogs
What are some examples of how Bloomreach supports multi-site management?
Let's take a look at some example scenarios. You can use these scenarios to make merchandising changes that go beyond these scenarios.
Multi-site: Blocking a product across a set or all versions of your site
If your site has different versions that have the same structure and a similar product catalog for different regions, languages, or brands, we call this "Multi-site". For example, if you have a site that has a version for English and another version for French, then you have a multi-site.
As a merchandiser, you can manage multiple versions of your site in the Bloomreach Dashboard. You accomplish your tasks in the same way as for single-version sites, but with a few choices that single sites don't have. These choices let you propagate your merchandising changes across all site versions or a set of versions. You keep the flexibility of overwriting changes at the site-specific level.
Let's take a look at some example scenarios. You can use these scenarios to make merchandising changes that go beyond these scenarios.
Blocklist rules
Some sites offer merchandise that they don't necessarily want to show for particular search queries. Merchandisers can create blocklist rules to exclude these products from search results for specific queries.
Blocklist rules come in two forms: a search term rule and a global rule. A search term rule affects only search results for specific queries. An alternative to a search term rule is a global rule, which affects all search results on the entire site, regardless of the search query.
Create a global blocklist rule
Molly is a merchandiser at Homeoasis, a retail site that sells home supplies through many versions of the Homeoasis site. The site has different versions for languages as well as for major product lines. Molly wants to globally block the laundry detergent "ShineyClean" from all search results. She wants this blocklist rule to apply to all versions of the Homeoasis site.
She starts by selecting the global Homeoasis site from the dropdown list in the upper right corner of the Bloomreach Dashboard. The global site is at the top of the list.

She opens the Ranking Configuration page by navigating to Setup → brSM global configurations → Global ranking rules.

She clicks the Add Rule button and selects Global Search Ranking Rule, then continues creating her blocklist rule the same way as for a single-version site. When she's done, her new global search blocklist rule applies to all versions of the Homeoasis site.
Boost a product on a set of sites
Suppose Molly wants to boost the product, Very Shiny All-Purpose Surface Cleaner, on two versions of the Homeoasis site. These two versions are in a group called UK & Germany.
She starts by selecting UK & Germany from the dropdown list in the upper right corner of the Bloomreach Dashboard.

Ezra opens the Ranking page, which is the same starting point that single-version sites use: Setup → brSM global configurations → Global ranking rules. She clicks the Add Rule button and proceeds the same way as for a single version site with a few exceptions:
- She can check the Influence marker in the Product Grid view to confirm that she's making changes to the site or group that she wants.
- She can select a site from the Site Context dropdown list to preview how the rule affects a specific site within the group of versions (UK & Germany).

Searching for a site in the dashboard dropdown
If you have a long list of site versions or groups of site version, then you might find it easier to find the site or group with the search box rather than scrolling through the list.
Account Level Attributes/Facets Aggregation For Multiple Domains
If you’re using a multi-site account, you’ll have separate catalogs for each of your domains. Each catalog comes with its own set of attributes.
At the site level, creating ranking rules is straightforward as the attributes, attribute values and categories appear according to the site catalog.
The situation is a bit different for attribute values and categories at the account level.
Account Level Ranking & Facet Editors
At the account level, attributes/facets are aggregated across all catalogs (domains). But there is no such aggregation for attribute values.
Here we are using catalogs and domains synonymously since each catalog represents a domain and vice versa.
Let us understand this with an example.
Suppose you have 2 different sites for English and German languages.
The catalogs of these sites have the following attributes:
English catalog (domain):
is_new: Yes, No
color: black, green, blue
German catalog (domain):
is_new: Ja, Nein (translates to Yes, No)
size: S, M, L
All the attributes (is_new, color, and size) will appear in the ranking editor. This is because attributes/facets are aggregated from both catalogs.
However, attribute values are not aggregated.
In the above example, the attribute is_new is common between the English and German domains. It has the same attribute values but in different languages.
In the ranking editor, you may see either (Yes, No) or (Ja, Nein) as the values for the attribute is_new.
You will not see all the attributes values (Yes, No, Ja, Nein) in the editor. This happens because there is no attribute value aggregation.
There is no default catalog for attributes so the values are selected arbitrarily.
Category Aggregation
Categories are derived from the attribute values of the attribute "category". Just like attribute values in account level ranking & facet editors, categories are not aggregated.
Suppose there are the following categories at different levels:
English catalog (domain):
category: dresses, tops
German catalog (domain):
category: jeans, hoodies
In the category ranking editor, you may see any one of the categories (dresses, tops) or (jeans, hoodies).
As there is no aggregation for categories, you will not see all the categories (dresses, tops, jeans, hoodies) in the editor.
On the account level, the attribute values and categories displayed do not usually change over time.
Suggested Alternative
Since there is no attribute value/category aggregation, you might not be able to merchandise products with these attributes/categories on the account level dashboard.
To overcome this, we recommend that you create a site group to group sites based on your use case, and set up ranking rules on the site group level.
Updated 12 months ago