With your commerce store data model, not only do you translate your product catalog into a structured forma, but also lay the groundwork for the Empathy Platform to consume your data during the search and discovery experiences. A data model is a template with a list of sample fields—also called document attributes—and their relations with the different Empathy Platform features and tools. This way, the Index, Search, and rest of microservices will identify the fields they must consume within your product catalog.

Some fields are, in fact, directly consumed by the Search engine to feed data to its features and tools (such as Faceting, Sorting, Pagination, Equalize, Product Ranking, etc.). Therefore, you need to understand how the fields serve Empathy Platform within the search and discovery experiences first, and then plan a feed file's structure accordingly before you build your feed file.

The data model maps the fields of the feed file and the Empathy Platform feature or tool they serve. Using the data model as a guideline to build your feed file is a key step to guaranteeing an enjoyable search and discovery experience that you surely want to provide in your commerce store.

Data model mapping

note

In the table below, the features listed refer to backend behaviors in Empathy Platform. Each backend feature can indeed serve one or more features enlisted in the Description column.

interact

The Sample fields column shows the entire hierarchy of each field. For the details about the field labels, see the feed file guidelines.

Feature	Description	Sample fields
Search EQ	The field is searchable. When the query matches a searchable field, the search service returns all products containing the field. Otherwise, it returns no results. It can also be used in Equalize, where you can determine the weighting given to this field when calculating the product score.	name description shortDescription categories.category.name categories.category. children.name type colours.colour.name brand collection tags.tag.name
SKU Search	The field is searched by a reference SKU (stock-keeping unit) or a similar product ID (see ID Results).	externalId
Facet	The field can be used as a navigation facet. It's used in the search UI to narrow down query results.	categories.category.name categories.category. children.name type price.current.value colours.colour.name sizes dimensions.width dimensions.heigh dimensions.depth stores
Sort	The field is a filter for sorting product results in the UI (for example, relevance, A-Z, Z-A, price low to high, etc.).	name price.current.value price.previous.value price.future.value stores
Search response	The field is returned by the Search microservice in the query responses. These responses are displayed in the search UI.	in name shortDescription externalId categories.category.name categories.category. children.name images url price.current.value price.previous.value price.future.value colours.colour.name sizes brand collection
Front view	The field can be displayed in the search UI (see Interface X Components).	name images url price.current.value price.previous.value price.future.value sizes brand collection
Ranking / Sorting rules	The field is a tiebreaker. The field can be used to boost the product's ranking when the query results have equal weighting, overriding their organic product scoring.	stock
Ranking - Query Context	The field is used to improve result relevance by adding a score dynamically. The score is calculated based on the shoppers' interactions with the product (see Contextualize microservice).	categories.category.name
Boosting attributes	The field influences the product's ranking on the SERP (search engine results page) based on product attributes. Products whose attributes match a specific attribute for this field are moved up or down in position on the SERP, overriding their organic product scoring.	categories.category.name type colours.colour.name

Custom fields mapping

To enrich your data model, you can index custom fields in support of Search EQ and Search response features. At indexing time, custom fields are only processed to be stored in the search engine. For the search engine to recognize the purpose of the data, it's necessary to perform further configurations in the Search microservice. The indexing of custom fields is based on the field type, as follows:

• Search EQ: string type
• Search Response: string, numeric, boolean