3 min read

Explore your data model

With your commerce store data model, not only do you translate your product catalogue 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 catalogue.

Some fields are in fact directly consumed by the Search engine to feed data to its features and tools (such as Query Search, Equalize, Product Ranking, etc.). Therefore, you need to understand how the fields serve Empathy Platform within the search and discovery experience first, and then plan the 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 that they serve. Using the data model as a guideline to build your feed file is a key step to guarantee an enjoyable search and discovery experience 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 Empathy Platform features enlisted in the Description column.

interact

The Sample fields column shows the entire hierarchy of each field. For the detail 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 in 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 (e.g. 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 score dynamically. The score is calculated based 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