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.

🚧
Important
Choosing 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

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 and EXACT_MATCH for precise data (IDs, names, or codes).
Use LIKE and PREFIX for flexible text searches and autocomplete.
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

Users cannot modify the search configuration directly. Each search behavior (such as EXACT, LIKE, PREFIX, RANGE_MIN, RANGE_MAX, EXACT_MATCH, or FUZZY) is predefined to ensure consistent performance and relevance.

If adjustments are needed, for example, to prioritize certain fields, please contact our team to review and apply the necessary changes based on your specific needs.