Catalog product data

This is for:

Developer

Products are searchable items. In a catalog without variants, a product is also a purchasable item.

Here’s an example of a JSON representation of a product named Coveo Soccer Shoes - Red, which includes generic information such as its description, image, and price.

{
  "documentId": "product://001-red", 
  "FileExtension": ".html",
  "ec_name": "Coveo Soccer Shoes - Red",
  "model": "Authentic",
  "ec_brand": ["Coveo"],
  "ec_description": "<p>The astonishing, the original, and always relevant Coveo style.</p>",
  "color": ["Red"],
  "ec_item_group_id": "001",
  "productid": "001-red", 
  "ec_images": ["https://myimagegallery?productid"],
  "gender": "Men",
  "price_dict": { 
      "": "28.00",
      "store1": "28.00",
      "store2": "30.00"
  },
  "ec_category": "Soccer Shoes",
  "objecttype": "Product" 
}

The documentId metadata is the unique identifier of your item in the index and will be used to fill the item’s uri field. This value is essential to update the item’s information.

The productid is the unique identifier of your product. Depending on your catalog configuration, this metadata may have a different label.

The price_dict is a dictionary field that can be used in an environment where products need to have different prices (for example, when the price is based on location or seasonal pricing) for a single item, instead of sending a single price value (see Dictionary fields).

Note

If your product’s price is static, you can store the product’s price in a single price field (for example, ec_price).

The objecttype metadata is crucial, as it will be used to identify the item as a product in the index.

When defining your product data, we highly recommend using the standard fields for storing related data (for example, using ec-prefixed fields, such as ec_price). This will simplify the mapping process later on.

Leading practice

In your catalog content, avoid using the same field name that you intend to use as facets, on different types of items. For example, if you’re defining the color at a product level, then you shouldn’t define the color at the variant level. If you need to include a field at both levels, prefix it with product and variant (e.g, productcolor, variantcolor) so that they’re different in the index.