Review request email metadata and retention

This article explains how Bazaarvoice manages the data (metadata) associated with review request emails (RRE). It details what information Bazaarvoice stores, why it is stored, and how long it remains in Bazaarvoice systems.

What is RRE metadata?

When Bazaarvoice sends an email to a consumer to ask for a product review, Bazaarvoice stores specific "metadata"—structured information about the email and the transaction—rather than the full content of the email itself.

1. Recipient identifiers

These details are provided by clients, and Bazaarvoice uses them to identify the email recipient information.

• Details stored:
  • Encrypted and hashed recipient email addresses.
  • customer IDs (user IDs)
  • Nicknames (display names)
  • Clients and their specific deployment zones
  • Destination reviewer details (applicable only to previous reviewers)
• Why it is stored:
  • To route and deliver emails to the correct person and link their eventual review to the right account.
  • To correlate delivery and engagement events to the correct customer account, client, and deployment zone.
  • To support privacy rights requests, such as locating relevant records for Right to be Forgotten (RTBF) or data access requests.
• Retention period:
  • Client configurable, typically 6, 12, or 24 months. You can define the retention period in Ratings & Reviews settings in the Bazaarvoice Portal. If not configured, a default of 2 years plus a one-month buffer is applied (25 months).

2. Send and delivery metadata

This is operational telemetry data that enables tracing the journey of a specific email.

• Details stored:
  • “Sent” status of the email
  • Email message IDs
  • Timestamps of when the email was sent
  • Delivery status (such as PENDING, SENT, FAILED or CANCELLED)
  • The reason for any delivery failures is also recorded.
• Why it is stored:
  • To troubleshoot delivery issues and monitor the overall health of the email service.
  • To provide visibility into whether an email reached the recipient or was blocked/bounced.
• Retention period:
  • Follows the same 6, 12 or, 24 month rule as recipient identifiers.

3. Email links and content data

This includes information embedded in the links the consumer clicks.

• Details stored:
  • Review links:
    • Product ID
    • Action type (indicates submission intent (e.g., rr_submit_review))
    • User Token (Email, Username, ID, Authenticated status, Incentivized review flag, Product purchaser status)
  • Product data:
    • Name
    • Price (stored in the database, but not included in emails)
    • Image URL
  • Campaign and tracking data:
    • Campaign ID
    • Email message ID
    • Email message type (RRE or RRR)
    • Recipient domain.
  • Unsubscription link (non-customized):
    • Hashed email address of the recipient
    • Email message type (RRE or RRR)
    • Client and Deployment zone
    • Locale
• Why it is stored:
  • To enable review submissions and attribute engagement back to the correct product or campaign.
  • To ensure the "Write a Review" link directs the consumer to the correct product page with the necessary purchase verification.
  • To ensure the recipient’s consent and subscription preferences were honored for each email sent.
• Retention period:
  • 90 days. This aligns with the typical lifecycle of a review request link.

4. Email engagement metrics

• Details stored:
  • Email Opens & Link Clicks
  • Subscribe/Unsubscribe events
  • Bounces & Spam Complaints
  • Device Info (Email client, Device type, OS)
• Why it is stored:
  • Provide client reporting (open/click rates).
  • To monitor email delivery system health and to improve system performance.
  • Prove consent/preferences were honored
• Retention:
  • Permanent. This data does not contain any Personally Identifiable Information (PII) or any user-specific information and is only used for engagement analytics.

5. Data that is never stored

• Full rendered HTML body of the email.
• Inline content (Images/Media referenced via URL).
• Bazaarvoice excludes non-essential fields from long-term storage because they are not required for reporting or analytics. For example, the system uses server thread and process IDs only during active processing and deletes them shortly after

Client customization options

Clients can customize how some of this data is handled through ConfigHub:

• Data retention windows: Clients can choose to retain PII for 6, 12, or 24 months. This is calculated from the transaction date, not the date the data was provided to Bazaarvoice. To learn more about how to configure the retention period, refer to How to customize the PII retention period.
• Campaign timing: Clients define the number of follow-up emails and the delay between them, which dictates the scheduling metadata. For detailed instructions, refer to Enable and configure review requests
• URLs: Clients can configure the specific submission URLs and return URLs, which changes the paths recorded in the email link metadata.

Privacy deletion request

Bazaarvoice fully complies with the General Data Protection Regulation (GDPR), including the 'Right to be Forgotten (RTBF)' and all formal deletion requests.

What gets deleted?

When a valid deletion request is processed, Bazaarvoice removes the following from RRE records:

• All encrypted/hashed email addresses and user IDs (recipient identifiers).
• Transaction history and locale information.
• Product information (product IDs, names, and prices) and custom attributes.
• Detailed delivery tracking information for that specific email request ID (sent time, status, and failure information).
• Custom attributes (Email template names and configuration information).
• Destination reviewer references (applicable only to previous reviewers).
• All parameters related to the corresponding email address.

What is not deleted?

To remain compliant with the law and user preferences, and to track system performance, Bazaarvoice does not delete:

• Subscription preferences: Bazaarvoice must keep a record of "unsubscribed" users to ensure Bazaarvoice never accidentally emails them again.
  
  

  Note: Subscription preferences are stored at the client instance level and are specific to the email type (e.g., RRE, RRR). This allows a user to opt out of a specific email type without unsubscribing from all communications across the entire client portfolio. To learn more about email subscriptions, refer to Manage email subscriptions.
• Aggregated analytics: Aggregated email engagement analytics that cannot be tied back to any individual.

Post-processing privacy request

1. Once a privacy RTBF request is processed, new metadata is created for the same user only if a new transaction occurs.
2. System checks retained subscription preferences before sending. If an "Unsubscribe" record exists, no email is sent, regardless of the new transaction.

RRE metadata retention period