Search configuration
This guide outlines how search is configured to deliver relevant product results.
Searchable Fields
Search covers the following fields. Each field contributes to how products are matched and ranked in search results:
| Field | Description |
|---|---|
| Brand | The product’s brand or manufacturer name. |
| Product ID | The internal identifier assigned to the product. |
| Product SKU | The product’s stock keeping unit (SKU). |
| Product External ID | The product identifier used in external systems or imports. |
| Product Name | The main display name of the product. |
| Product Description | The detailed description of the product. |
| Variant Name | The display name of a specific product variant |
| Variant SKU | The stock keeping unit (SKU) specific to a variant. |
| Variant Description | The description associated with a product variant. |
| Variant EAN | The European Article Number (EAN) for the variant. |
| Variant MPN | The Manufacturer Part Number (MPN) for the variant. |
| Variant External ID | The external identifier of a variant used in third-party systems. |
| Attribute Values | Values of indexed product attributes (e.g., color, material, size). |
| Custom Field Values | Values from custom fields defined at the offer level. |
OpenSearch provides several configuration options to control how search queries are interpreted and matched against indexed data. In simpler words, the search system uses different ways to compare what users type with the data in the catalog.
Each configuration type defines a different level of precision and flexibility, allowing you to adapt the search behavior to your use case, whether it’s a typo-tolerant product search, an exact lookup, or an autocomplete feature.
ImportantChoosing the right configuration for each field is essential to balance relevance, accuracy, and performance.
Search Matching Options
EXACT_MATCH
Finds results that are an exact match to the user’s query, with no differences or variations allowed.
Example:User types: “SKU12345”
Results: only the product with ID SKU12345
Effective in contexts where detailed accuracy is key:
- Product IDs
- Reference numbers
- Codes
Warning:EXACT_MATCHcan no longer be assigned to free-search text fields (such as product name or description). On those fields its behavior was misleading — it is case-sensitive and matches on a single token of a multi-word value, producing counter-intuitive results. For an exact match on text, use EXACT instead (case-insensitive full-phrase match).EXACT_MATCHremains available on non-editable system fields, where its semantics are appropriate.
EXACT
Finds results that exactly match a full phrase or a specific combination of words, in the same order.
Example:User types: “leather jacket”
Results: “Men’s leather jacket”, “Women’s leather jacket”
It will not return “jacket made of leather.”
Effective in contexts where phrases must appear exactly as typed:
- Product names
- Titles
LIKE
Finds results that contain the search term anywhere inside the field.
Example:User types: “coat”
Results: “Raincoat”, “Winter Coat”, “Coat Hanger"
Effective in contexts where partial text matches are needed:
- Descriptions
- Titles
- Tags
PREFIX
Finds words that start with the same letters typed by the user.
Example:User types: “snea”
Results: “sneakers”, “sneaker cleaner”, “sneaker bag"
Effective in contexts where partial text matches are needed:
- Product names
- Brands
- Titles
FUZZY
Finds results that are close to what the user typed, even if there are small typos or spelling mistakes.
For more information on how to use the FUZZY, click here : Fuzzy search
Example:User types: “sneker”
Results: “sneakers”, “sneaker cleaner”
Effective in text fields where users are likely to make typing mistakes:
- Product names
- Brands
- Titles
Warning:Use carefully. Applying FUZZY to too many fields can reduce accuracy.
Best Practices
- Use EXACT for precise, full-phrase matches on text fields such as product names or titles.
- Use PREFIX for autocomplete and partial matches on names, brands, and titles.
- Use LIKE for flexible "contains" text searches on descriptions and tags.
- Use RANGE_MIN and RANGE_MAX for numeric or date filters.
- Use FUZZY only where user typos are common.
Combine different types thoughtfully to balance precision and flexibility.
Configuration Management
Search configuration is self-service: from the Back Office, you can list the searchable fields and adjust how each one behaves — without contacting the DJUST team.
For each field you can configure:
- Matching mode (
searchType) — how the field is matched against the query (see the matching options above). - Relevance boost (
score) — the weight applied to matches on that field when ranking results. Higher-boost fields push their matches toward the top of the list. The value is bounded in the interface to avoid extreme settings. - Search activation (
searchable) — whether the field is used by the catalog search at all.
Note: On free-search text fields, only the safe matching modes (EXACT,PREFIX) can be selected. More expensive modes are hidden or flagged with an explicit warning to protect the shared search cluster.
Two points to keep in mind when you change the configuration:
- Changes take effect within ~5 minutes (the configuration cache TTL).
- No reindexing is required — the change only affects how queries are evaluated at query time.
Under the hood, the configuration is read with GET /v2/settings and updated with PUT /v2/settings. A server-side validation bounds the relevance boost value.
Updated 13 days ago