Review requests FAQs

Contact Bazaaroice Support or your Technical Account Manager to investigate the email delivery status (sent, pending, failed).

Common causes include:

• User is OPT_OUT or unsubscribed.
• Unverified sender profile (missing DKIM/SPF).
• Email address is not whitelisted (common in staging).
• Suppressed PIE trigger or DO_NOTHING docket status (e.g., product already reviewed within 180 days).
• Email landed in spam/social folders due to recipient inbox settings or poor custom template content.
• XML or Text schema validation failure. (this can be a silent failure).

• DKIM keys are generated by Bazaarvoice. Open a support ticket to add the sender email address. Bazaarvoice provides the CNAME records to clients, which they must add to their DNS. 
• SPF: Similarly, Bazaarvoice provides the SPF records (including amazonses.com) that they must add to their DNS. This verification can take up to 72 hours from the time of receipt.
• Changing a sender display name does not require re-verification. 
• The default bazaarvoice-cgc.com domain is not supported by self-service DKIM tools.
  
  

  Note: For detailed instructions, refer to Domain authentication for sender email address. 

Yes. Bazaarvoice uses dedicated IPs via Amazon SES.

• Disabling RRE: Deploying this change immediately cancels all pending sends. Any emails currently in the queue will not be delivered. 
• Changing delay wait time: Emails already in the queue are rescheduled based on the new delay. However, if a delay is increased (e.g., 9 to 30 days) and then reverted, orders that fell into the "gap" window may not send.

• If you send order data to Bazaarvoice, either manually or via BV Pixel, to invalidate specific transactions, the feed file with the transaction details must be sent to the following directory: SFTP server/ppe/invalidate.
• For clients sending product catalog data through the Transactions API, invalidating specific transactions requires calling the Invalidate Transaction API.
  
  

  Note: To learn more about how to send an invalid request for specific order data, refer to Invalidate review requests. 

Clients must upload a new order data file (XML) to the SFTP server/ppe/inbox with updated TransactionDate values to trigger immediate processing within the current window.

Some of the common root causes are the following:

• Hard bounce suppression
• RRE delay wait time misconfiguration
• missing EmailAddress field in order data file (silent failure), 
• If hadPII is set to false in the transaction records
• unverified SPF/DKIM, email in unsubscribed list, DO_NOTHING docket status
• pixel feeds not landing in SFTP / ppe / backup
• wrong Deployment Zone configured
• The transaction is too old to request a review; specifically, it is older than the configured “Number of days before a transaction is considered too old to send a review request” setting in the Ratings & Reviews configuration.
• An RRE has already been sent to the user for a previous purchase of the same product within the configured “Delay between multiple review requests for the same product (in days)” setting in Ratings & Reviews configuration.

Pixel feed generation is controlled per Deployment Zone. The "Trigger messages" setting must be set to "Automatically" in the correct deployment zone—not just in the main site zone. 

Yes, if  hadPII is set to false in the order data records, it can be a root cause for RREs not being delivered.

• {{PRODUCT_NAME}}is used in standard templates, while {{product.name}} is for custom templates.
• By default, both tokens pull data from the order data file. If it is not provided in the order data file, the name given in the Product catalog feed is considered. If the order data provides a different name than the product catalog, the order data value will be considered for RREs.

• This token extracts the link from the product display page (PDP) URL in the Product Catalog. If a client changes their product page URLs, they must update the catalog.
• RRE submission links expire after 90 days — clicking after that returns a 404 error. 

Yes. You can remove the email open tracker from custom email templates. For step-by-step instructions, refer to Manage email open tracker. 

No. The helper (ghost) text in the rating stars is hard-coded and cannot be edited. 

• Subject
• Body
• Additional Products Heading
• Additional Information

• Subject
• Title
• Body
• Additional Products Heading
• Additional Information

• Logos: Your logo has a hard size limit. It cannot be wider than 300px. 
• Buttons: Buttons have a default rounded look. You cannot change the corners to make them sharp or square; only font color is customizable in the Style Editor.

Custom templates allow you to replace the default Bazaarvoice opt-out URL with a branded link (this feature is not available for standard or In-mail templates). If you switch to a custom unsubscription link, you can manage user preferences by sending a Subscription feed file (via Portal or via SFTP server)   to Bazaarvoice for bulk updates or use the Notifications API for real-time tracking.

1. Bazaarvoice takes user names from the <UserName> field in the order data file.
2. If you do not include this field in the order data file, Bazaarvoice searches its system for an earlier user name associated with the provided email address and uses that one. 
3. If the reviewer has since changed their user name and you have not sent the new one, Bazaarvoice continues to use the name already on record.

Yes, it is case-sensitive and must match the exact casing used in the product catalog feed file. Any mismatch will result in a feed validation error.

• TransactionDate must be a full ISO 8601 datetime (for example, 2025-12-20T10:30:00.0000). Date-only values (for example, 2025-12-20) will fail.
• The correct XML header uses schema 14.8.

This error occurs when the same UserID appears in multiple <Interaction> blocks in one file. Bazaarvoice still processes the transactions, but it is recommended to group all products for one user into a single <Interaction> block. 

No. The Transactions API currently requires plain text email addresses.

No. Non-ASCII characters (for example, ö, ü) in email addresses are not supported and will fail validation. Only ASCII-compatible email addresses should be used in order data files. Punycode encoding can be used for the domain part (for example, info@xn--brütabela.com.tr) but not the local part. 

No. Only <EmailAddress> and <PhoneNumber> fields are PII. 

No. You must encrypt only the <EmailAddress> and <PhoneNumber> fields. All other fields in your order data file must be sent as plain text, without encryption.