Skip to main content
The product feed is a crucial part of the Voyado Elevate integration. It directly impacts available features and overall performance. This page provides best practices and guidelines for the product feed, along with their rationale.
  • Some guidelines involve data normalization and asset handling, which must be addressed by retailers for successful implementation.
  • Many content-related best practices can be implemented iteratively, allowing for a faster go-live with room for future improvements.
  • Use these best practices as a checklist during catalog import integration.

​
Checklist

​
Natural key mapping

Product groups, products, and variants require natural key mapping to identifiers comprehensible on the retailer side. Use article numbers or codes used both internally and externally. The keys provided in the feed must match those in order notifications. Variant keys should use SKU IDs.
  • Exact key matches in search direct visitors to the corresponding product page.
  • Variant keys matching SKU IDs in Engage enable Evolve features.

​
Release dates

A product’s release date indicates how new it is considered. This should reflect the date the product becomes available for purchase. Providing release dates in the feed is highly recommended.
  • Newness factors into product ranking.
  • Enables the NEW product badge.
  • Allows sorting by newness.
  • Supports dynamic product selections based on newness.

​
Cost

Providing product cost allows Elevate to optimize for profit and display profit metrics in the Elevate Apps. Costs can be included as variant attributes in the catalog import or supplied at purchase time through order notifications. Retailers should choose the easiest method for supplying cost information.
Cost must be a non-zero value smaller than the selling price. Transactions not meeting this condition will be ignored in profit calculations.
  • Profit optimization as a business objective.
  • Profit as an included aspect in various statistics.

​
Images

The recommendations below concern image management and image creation. These should preferably be considered when taking new product pictures.

​
Missing images

If an image is missing, do not provide a placeholder image indicating a missing image. Let the provided image URL point to a 404. Missing images are handled by image analysis. Custom images indicating missing images should be handled through a client-side action.
Products with broken imagery are automatically buried.

​
Multiple product images

Supply all available images for each product and differentiate images by supplying image tags. Image tags help merchandisers differentiate between image types such as primary, full, front, back, side, and detail images.
  • Providing multiple images enables product card features in the settings , such as selecting the order in image galleries.
  • Providing multiple images enables automatic image fallback for broken or missing images.

​
Multiple image resolutions

It is highly recommended to supply at least one image resolution with a width of around 500 px, even when an image service is available. This resolution supports fast app rendering and efficient image analysis. Provide the image resolutions required for site rendering, including variants suitable for thumbnails, mobile listings, and desktop listings as needed.
  • Fast product app rendering.
  • Performant image analysis.

​
Image type separation

For retailers with highly structured image assets, advanced image imports including image type information, especially for cutouts, are recommended. A cutout image is an isolated image of only the product, typically with a single-color background.
Performance gains with faster color analysis of new collections, as cutout images can be analyzed significantly faster than other image types.

​
Cutout guidelines

Cutout images are images where only the product is represented, without a model or other additional products. If there are multiple cutout images for each product to choose from, select the ones that best follow these recommendations:
  • Portray the entire product as accurately as possible.
  • Avoid sharp edges in the background.
  • Avoid shadows on the products.
  • Use homogeneous background colors for all products. Images are not required to all have the same background color.
  • Product colors are automatically extracted, allowing Elevate to retrieve a complex view of colors, including detailed nuances and color distribution.
  • This enables powerful color search, color filtering, and precise color swatches.
  • Cutout imagery provides the fastest and often the most accurate color distributions.

​
Consistent image ratio

All images provided should ideally have the exact same ratio. The height of rendered product cards will be the same to avoid alignment issues, meaning inconsistent image ratios will lead to clipping.

​
Clean imagery

Keep images clean and separate from functionality and information that belongs elsewhere. Avoid overlays, badges, padding, and similar content built into the images.

​
Colors

​
Providing metallic colors

Provide metallic properties in colorInitial for products that are Gold or Silver. Metallic properties cannot be found through color analysis and must be tagged manually.
Correct presentation of products with metallic properties.

​
Providing initial colors

For retailers with very high product turnover, manually setting colors ensures products have colors before analysis is completed, or if automatic analysis is unsatisfactory. Colors must be provided as exactly Gold, Silver, Multi, or a valid RGB hex code. When used, always strive to provide as detailed nuances as possible. Multiple colors can be provided and will be considered an evenly distributed color representation.
Enables color search, filtering, and swatches before automatic color analysis is completed.

​
Where to provide color information

Color information must be provided at product level, not variant level. Each color should be modeled as a separate product with its own variant. Although color-related custom labels are technically accepted at variant level by the API, they will not be used by the image analyzer. The color analysis relies on image analysis and operates at product level. colorInitial and colorOverride are not supported at variant level.
Do not supply color information at variant level. It will be silently accepted by the API but ignored by color analysis, and will not contribute to color search or swatches.

​
Product titles

Do not include the brand, or other redundant information, in the product title. Brands can be presented and styled separately in product cards. Product titles should ideally be kept short, as long titles may be clipped for mobile visitors. Displaying the color of a product in the product title is often not necessary, as it is displayed in the image. One exception is when the retailer has a set of specialized custom colors that are well known among visitors. In this case, place the color name at the end of the title. Placing the color elsewhere may cause the title to flicker when the visitor hovers over different colors. Examples:
  • Clara T-shirt - spirit green
  • Clara T-shirt - dreamy pink
  • Clara T-shirt - real teal

​
Sizes and labels

Use sizes when multiple variants of a product are differentiated by size. Otherwise, use a label to distinguish each variant. Think of the label as the variant’s title on the product page. Do not use sizes or labels if all products have a single variant. Rather than supplying an arbitrary size that has to be the same for all variants, skip the field entirely. Even when using sizes on variants, labels may also be used if they provide better results. For example, on a shoe with size 40 in EU and size 7 in US, the label could be 40 (US 7).

​
Size fractions

State fractions with a single character. For shoe size forty-two and a half, use 42 ½ or 42½. This avoids the ambiguity of 1/2 being read as “one half” or “one or two”.

​
Categories and ontology

Use the ontology attribute to define a product’s place in a product-based categorization hierarchy. The category attribute can include multiple categorizations of the product and does not have to be strictly product-based. Each level in the hierarchy is defined using the greater-than sign >. To ensure stable product selections, it is highly recommended to include category IDs in the product data with translations. Product data
Translations
  • Both ontology and category attributes help Elevate accurately classify products, enhancing search, recommendations, and overall relevance.
  • The category attribute can be used to make product selections, for example to define pages in Elevate Apps, using hierarchical information.
  • The category attribute is required for all retail media-related features.

​
Custom attributes

Custom attributes enhance search, enable facets and filters for search and navigation, and complement predefined attributes as the foundation for creating product selections. There are several types of custom attributes, including customLabels, customLengths, customNumbers, and customJson.
  • Choose the custom attribute type that best matches the available data.
  • Provide any non-predefined data that is useful for search, facets, filters, or product selections as custom attributes.
    • Useful customLabels could include season, style, and material.
    • Useful customLengths could include packaging size information.
    • Useful customNumbers could include the number of items in packs.
  • Use customJson when purely presentational data is unsuitable for search and filters.
  • Send structured data when possible.
  • Provide the highest granularity possible for available values.
  • Normalize values. Avoid using Long dress, long dress, and Long dresses for the same property.
  • Custom attribute names should be in English and consistently named across markets.
  • The name of the custom attribute is not considered for search or classification. Avoid attributes such as windproof with the value true. Instead, use an attribute called features with the value windproof.
  • Use translations to ensure stable product selections.

​
Translations

Translations should be used whenever possible to ensure stable product selections. A translation connects an ID to a label for a given locale, allowing label changes without disrupting product selections.
A product selection is a defined set of products. Product selections are used in boost , bury , and pages nodes and are often rule-based.
For example, if a product belongs to the category Cell phones and the category name changes to Smartphones, any product selection relying on the label Cell phones will no longer include those products. By using IDs in the product feed with localized labels supplied as translations, you ensure stability.
  • Stable product selections during label changes.
  • Cross-market and cross-locale product selections are enabled.

​
Departments

Ensure department values in products are stable and not changed often. Common department values for fashion are Women, Men, and Kids. For a single-department retailer, all products should have the same department value, or the retailer should consider switching to well-defined categories. Using departments is optional. If departments are not available, use categories instead.

​
Content

Provide content items for vital pages of high client interest. Typical pages recommended to include are:
  • Returns
  • Shipping
  • Delivery
  • Contact
  • Stores
Use the Search phrase report in the Experience app to keep track of popular search phrases.

​
Using product list templates

While only tangentially related to catalog imports, it is highly recommended to use a template to control which imported attributes Elevate should return in requests to the Storefront API. This is useful to reduce response sizes or include attributes that would not be included by default, such as custom attributes.
Last modified on September 11, 2026