Multiple index setups
Each index within Constructor acts as an isolated environment for storing a company’s data. This includes, but is not limited to, products, content, and search suggestions. Indexes also contain clickstream and behavioral data for shoppers.
Companies may choose to have more than one index for their organization, often based on language differences, catalog offerings, and/or consumer behavior. However, it is important to keep in mind that each index will only have a fraction of the overall traffic, clickstream, and behavioral data with which to train models and generate learnings.
For this reason, Constructor strongly recommends a minimum of 5,000 unique search queries and 5,000 unique browse visits per day per unique index. If an index it unable to generate this volume of traffic, then please speak with your Constructor Implementation Team about other options.
Index types within Constructor
Indexes primarily serve three purposes: dev indexes let developers experiment safely, staging indexes allow for testing and configuration before going live, and production indexes power the end-user experience. This article focuses on production indexes.
A note on dev and staging indexesWhile some companies may have multiple production indexes, it is not always necessary to have multiple dev and staging indexes. Please direct any questions you have to your Constructor Implementation team.
Considerations for additional production indexes
When considering additional production indexes, consider the below factors first. Each plays an important role in determining whether additional indexes are necessary.
Please note: While these are our recommended guidelines, the Constructor Implementation team works closely with each company to identify the appropriate number of production indexes for a company’s needs.
1. Language
When a company supports multiple languages for product data and shopper queries (e.g., English and French), a separate production index is necessary for each language.
This approach is critical for data models because Constructor uses language-specific processing to interpret queries, expand synonyms, and rank results. When two languages share an index, that processing can produce unpredictable results that are hard to fix solely through merchandising rules.
For example, some words are spelled the same across languages but have different meanings.
Take the word "Gift".
- In English (EN), it means a present or free item.
- In German (DE), it means poison.
German-language intent can be skewed by English-language merchandising phrases such as “Free Gift Included” and English queries like “gift for mom”, increasing the likelihood of irrelevant matches and unstable ranking.
2. Product offerings and availability
When a company operates multiple countries, regions, or storefronts with meaningfully different catalogs, more than one production index may be necessary.
For example, a company might have separate storefronts for the United States and Canada. Even when both are English, differences in product eligibility and availability can be large enough that a single index becomes difficult to tune and can surface irrelevant or unavailable items. However, when catalogs substantially overlap, a single index can be maintained by including an availability (or store/region) field and filtering results per storefront at query time.
3. Regional learnings
If a company operates multiple same-language storefronts (for example, several English sites), shopper behavior may differ by region enough that more than one production index may be necessary.
For example, a global athletic apparel brand sells in both the United States and Australia. Both markets use English, so a single index might appear sufficient. However, seasonality and promotional calendars differ (summer peaks occur in opposite months), and shoppers in each region exhibit different browsing and purchase patterns. In a shared index, those behavioral signals blend together, making it harder to optimize ranking and personalization for either market. Separate regional indexes keep each region’s clickstream learnings independent.
⚠️ Please note: Regions that lack sufficient traffic (i.e., less than 5,000 daily requests for Search and for Browse, separately) will not have the clickstream and behavioral data necessary to generate impactful learnings.
4. Searchandising
If a company has different merchandising and promotion strategies by country or region, and these strategies necessitate applying different sets of searchandising rules (e.g., boost, bury, or slotting rules), then more than one production index may be necessary.
For example, a global beauty retailer operates separate US and EU storefronts. The catalog overlaps and both experiences use English, but regions can have different compliance and brand-governance standards, such as stricter requirements to prevent discovery for queries that could be interpreted as marketing makeup to minors (e.g., “makeup for kids” or “teen makeup”). In a shared index, blocklist/allowlist and other searchandising rules can be created per region by applying user segments to the rule, but this can create operational risk for merchandising teams that are separated by region. Separate indexes allows each region's teams to naturally separate their instances and where they apply boost, bury, slotting, allowlist, and blocklist strategies without cross-region considerations.
5. Analytics granularity
If a company has a demonstrated business need to view detailed insights and analytics for specific regions, countries, and/or catalogs, then more than one production index may be necessary.
For example, a retailer operates US and Canada storefronts and wants to evaluate search performance separately for each market during different campaign windows. If regional attribution must be clean and unambiguous for downstream reporting, separate indexes can ensure analytics are captured and reviewed by region without additional interpretation.
⚠️ Please note: Indexes that lack sufficient traffic (i.e., less than 5,000 daily requests for Search and for Browse, separately) will not have the clickstream and behavioral data necessary to generate impactful learnings.
A note on currencySince currency does not impact clickstream learnings, recall, or ranking, it is not considered a key factor in the number of indexes a company maintains.
However, currency does play a key role in analytics and internal experiments for an index. If you have an index that supports multiple currencies, please contact the Constructor team to discuss available options for ensuring accurate reporting and experiment results.
Example setup with multiple indexes
To illustrate the considerations outlined in this article, we created the table below to show the number of recommended production indexes for four different companies based on their needs (e.g., number of languages served, regional presence, etc.).
| Languages | Regions/Countries | Searchandising Type | Recommended # of Indexes | |
|---|---|---|---|---|
| Company A | 1 (English) | 1 (US) | Standard | 1 (en_US) |
| Company B | 2 (English, French) | 2 (US, CA) | Unique per region | 3 (en_US, en_CA, fr_CA) |
| Company C | 3 (English, French, Spanish) | 5 (US, CA, MX, AU, NZ) | Unique per region | 6 (en_US, en_CA, fr_CA, es_MX, en_AU, en_NZ) |
| Company D | 8 (English, French, Spanish, Italian, German, Dutch, Swedish, Norwegian | 15 (US, CA, MX, AU, NZ, UK, FR, DE, IT, ES, NL, BE, CH, SE, NO) | Unique per region | 16 (en_US, en_CA, fr_CA, es_MX, en_AU, en_NZ, en_GB, fr_FR, de_DE, it_IT, es_ES, nl_NL, fr_BE, de_CH, sv_SE, no_NO) |
Updated about 2 hours ago