Skip to main content
This feature is in beta. This means it might at any time be changed, withdrawn from your account, or become part of a paid add-on module. You might also experience interruptions of this service, degradation of user experience or faulty behavior even in critical processes such as automations and sendouts. Voyado welcomes feedback on beta features, and encourages you to try them, but you should not build business critical logic on beta features. Only when a feature reaches its full release can you trust it to function reliably with no further breaking changes.

Product Data Model

An online retailer usually sells articles in multiple colors, styles, sizes, or configurations. Voyado Ratings & Reviews describes this using a three-level hierarchy: Think of a women’s tops range.
  • The different types of tops are product groups
  • Different colours of the top are products
  • The individual sizes are variants
Example of the product data model

Example 1

Example of the product data model

Example 2

Field Reference

Script Installation

The Ripple script is the client-side JavaScript snippet installed to render the reviews interface and capture user-submitted content. It is configured with product hierarchy identifiers so reviews can be attached and aggregated to the correct items. The Ripple script is what renders the onsite rating widgets, review submission forms, and aggregate displays. When installing the Ripple script on the storefront, three values must be set manually:
  • product-group-id
  • product-id
  • product-variant-id
The remaining two fields are derived automatically:
  • reviewGroupId — Set by Customer Engagement based on the above data
  • productFeedId — Set via configuration based on which level you want to use as the key in the product feed

The productFeedId

The value of productFeedId is the ID used to look up product data (images, metadata, and so on) in the Customer Engagement product feed. The productFeedId value used must match the ID used as the key in the product feed for enrichment to work. There are two separate places where productFeedId is used, serving different purposes:

For enriching a completed review

When a review is submitted and sent to Engage, the productFeedId value will be set to either:
  • “productGroupId”
  • “productId”
  • “productVariantId”
This value then tells the site which of the three ID levels to use when passing the review data to Customer Engagement. Customer Engagement then uses this to fetch product data for enrichment, for example, with AI-generated summaries or product context in emails.

For mapping a receipt

When a receipt is imported into Customer Engagement to trigger a “request review” email, the productFeedId value is used to tell Customer Engagement how to map receipt line items to the product feed, so it knows which product data to use when enriching the review request email. In this case, productFeedId can have one of these values:
  • “productGroupId”
  • “productVariantId”
Ripple and review data are not involved at this stage, since this is the first send-out of a review request after a purchase has been made.

Uses of productFeedId value

Verified Buyer

For Customer Engagement to confirm that a review has a purchase connected to it, the productVariantId value for the review must match the sku value on the receipt. This is the assumed mapping for verified-buyer checks.
Note for integrators: The current fallback logic in the codebase tries productVariantId first, then productId, then productGroupId if the previous fields are empty.