Catalog product data
Catalog product data
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).
|
|||
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 |