In the modern e-commerce stack, User-Generated Content (UGC) and Loyalty Programs are often treated as separate silos. One captures the voice of the customer (Ratings, Reviews, Q&A); the other manages the economy of retention.
For brands and retailers, the challenge isn’t just “collecting reviews”—it’s building a high-performance bridge between user action and value generation. How do we reward UGC generation in a way that reinforces positive user behavior?
I. The Challenge: Bridging UGC and Loyalty
Bazaarvoice acts as the primary engine for collecting and displaying UGC. While the marketing value of a 5-star review is obvious, the technical friction often lies in the “latency of gratitude.”
If a customer writes a thoughtful review but sees no acknowledgement or reward for weeks, the behavioral loop breaks.
To maximize participation, the system must be automated, scalable, and—most importantly—synchronous enough to feel impactful.
II. Understanding the Integration Mechanism
From an architectural standpoint, the integration follows a Source-Connector-Destination pattern.
A. The Core Components
The Source (Bazaarvoice): The event generator. This is where the user interacts with the submission form or the on-site review module.
The Connector (APIs): The technical bridge. This is the transport layer that transmits the payload (user ID, content type, transaction ID) to the loyalty engine.
The Destination (Loyalty Platform): The actioner. Platforms like LoyaltyLion, Rivo, or Rediem consume the data and update the user’s profile.
B. The Standard Workflow: From Payload to Points
To ensure data integrity and a smooth user experience, the workflow typically follows these steps:
Step 1: Event Trigger: A customer submits a review. Bazaarvoice captures the submission.
Step 2: API Request: The loyalty partner requests recent submissions. This payload includes critical metadata with the customer email address serving as the primary key between platforms.
Step 3: Validation & Credit: The Loyalty Platform validates the event against its internal rules (e.g., 50 points for a text-only review vs 100 points when a photo is included). Once validated, points are awarded instantly.
III. Benefits of a Robust Integration
When these two systems talk to each other fluently, the impact on the business KPIs is measurable and significant.
A. Increased Content Volume
Incentives are the ultimate fuel for UGC. By automating the reward process, top-performing loyalty programs can increase revenue for brands by 15-25% annually. From a data perspective, this creates a richer dataset for sentiment analysis and product improvement and helps with future onsite conversion.
B. Deeper Community Engagement
Loyalty isn’t just about spending money; it’s about contribution. By rewarding Q&A participation—not just reviews—you foster a self-sustaining community. When an “Expert User” is incentivized to answer a “Novice User’s” question, the platform’s utility increases without manual intervention from the brand’s support team.
IV. Conclusion: Building the Loop
Combining UGC and Loyalty transforms a static storefront into an active ecosystem. It moves the needle from “transactional” to “relational” by rewarding customers for the value they provide back to the community.
Ready to connect the dots?
For Brands: If you’re looking to turn your UGC into a loyalty powerhouse, reach out to your Bazaarvoice account team to discuss our integration partners.
For Loyalty Platforms: Interested in building a certified integration with the Bazaarvoice ecosystem? Contact our Partner Engineering team to get started with our API documentation and sandbox environments.
Your product catalog is more than just a list of items; it’s the backbone of your online presence and the engine that powers dynamic experiences for your customers. For Bazaarvoice clients, a well-structured and meticulously maintained product catalog is especially vital. It ensures that your valuable user-generated content (UGC)—like ratings, reviews —submitted and displayed flawlessly for its respective products.
At Bazaarvoice, our systems rely on your product catalog as the definitive source of truth for all product-related information. Whether you’re updating your catalog via a feed or by uploading an Excel file directly to the Bazaarvoice portal, adhering to a few best practices will unlock the full potential of your UGC program.
Let’s explore the key elements to focus on for an optimal product catalog:
1. The Power of a Precise Product Name
The product name is arguably the most critical piece of information in your catalog. It’s how your customers identify items on your site, and it’s equally important for our hosted display solutions and APIs.
Best Practice: Always ensure every product in your catalog has a clear, accurate, and consistent product name. This enables our APIs to retrieve and display product information correctly, ensuring that your reviews and ratings are always associated with the right item and appear prominently on your product pages. A complete product name allows for a rich, informative display that enhances the customer journey.
2. The Clarity of Consistent Category Information
Categories help organize your products and, by extension, your UGC. They allow customers to filter, browse, and discover content relevant to specific product types.
Best Practice: Assign every product to a valid and appropriate category ID within your catalog. Furthermore, ensure that the category names associated with these IDs are consistently provided and accurate. Proper category data facilitates seamless content submission by guiding user contributions to the correct product groupings. It also empowers your customers with intuitive navigation and filtering options on your hosted display solutions, making it easier for them to find the reviews that matter most to them.
3. Naming Conventions for Optimal Integration
Beyond simply having a name and category, the format of these identifiers can significantly impact how smoothly our systems process and display your data.
Best Practice: For product and category IDs, it’s highly recommended to use only hyphens (-) and underscores (_) as separators for multi-word identifiers. Avoid spaces, plus signs (+), and other HTML characters (like &, <, >, etc.). For a comprehensive list of HTML characters and their entities, you can refer to resources like the W3C HTML Entities list. This practice ensures compatibility across various systems and prevents potential encoding issues when data is transferred via APIs, leading to more robust and predictable data flow.
Your Catalog: The Core
Your product catalog information, securely housed within the Bazaarvoice database, is the ultimate source of truth for all your product data. By ensuring its accuracy and completeness, you establish a strong foundation that empowers every Bazaarvoice service you utilize.
When you consistently provide precise product ID, product names, category ID and valid category names in your catalog—whether through feeds or direct Excel uploads—you actively contribute to:
Seamless Display: Ensuring all your products and their rich UGC are accurately visible and attributed across Bazaarvoice display solutions and your website (if using our APIs).
Smooth Submissions: Guaranteeing that new reviews are submitted flawlessly and effortlessly linked to the correct products and categories.
Enhanced Data Integrity: Building a clean, reliable dataset that drives superior analytics and insights.
By embracing these best practices in your product catalog management, you empower your Bazaarvoice solutions to deliver the most impactful and engaging experiences for your customers, ultimately driving trust and conversions.
Bazaarvoice has thousands of clients including brands and retailers. Bazaarvoice has billions of records of product catalog and User Generated Content(UGC)from Bazaarvoice clients. When a shopper visits a brand or retailer site/app powered by Bazaarvoice, our APIs are triggered.
In 2023,Bazaarvoice UGC APIs recorded peak traffic of over 3+ billion calls per day with zero incidents. This blog post will discuss the high level design strategies that are implemented to handle this huge traffic even when serving hundreds of millions of pieces of User Generated Content to shoppers/clients around the globe.
The following actions can take place when shoppers interact with our User-Generated Content (UGC) APIs.
Writing Content
When a shopper writes any content such as reviews or comments etc. on any of the product on retailer or brand site, it invokes a call to Bazaarvoice’s write UGC APIs, followed by Authenticity/content moderation.
Reading Content
When a shopper visits the brand or retailer site/app for a product, Bazaarvoice’s read UGC APIs are invoked.
Traffic: 3+ Billion calls per day(peek)
Data: ~5 Billions of records,Terabyte scale
High-level API Flow:
Whenever a request is made to Bazaarvoice UGC API endpoints, the Bazaarvoice gateway service receives the request, authenticates the request, and then transmits the request information to the application load balancer.
Upon receiving the request from the load balancer, the application server engages with authentication service to authenticate the request. If the request is deemed legitimate, the application proceeds to make a call to its database servers to retrieve the necessary information and the application formulates response accordingly.
Let’s get into a bit deeper into the design
Actions taken at the gateway upon receiving a request
API’s authentication:
We have an authentication service integrated to the gateway to validate the request. If it’s a valid request then we proceed further. Validation includes ensuring that the request is from a legitimate source to serve one of Bazaarvoice’s clients
API’s security:
If our API’s are experiencing any security attacks like Malicious or DDOS requests, WAF intercepts and subsequently blocks the security attacks as per the configured settings.
Response Caching:
We implemented response caching to improve response times and client page load performance, with a duration determined by the Time-to-Live (TTL) configuration for requests. This allows our gateway to resend the cached response, if the same request is received again, rather than forwarding the request to the server.
Understanding User-Generated Content (UGC) Data Types and API Services
Before delving into specifics of how the UGC is originally collected, it’s important to understand the type of data being served.
e.g.
Ratings & Reviews
Questions & Answers
Statistics (Product-based Review Statistics and Questions & Answers Statistics)
Products & Categories
For more details, you can refer to ConversationsAPI documentation via Bazaarvoice’s recently upgraded Developer Center.
Now, let’s explore the internals of these APIs in detail, and examine their interconnectedness.
Write UGC API service
Read UGC API service
Write UGC API service:
Our submission form customized for each client, the form will render based on the client configuration which can include numerous custom data attributes to serve their needs. When a shopper submits content such as a review or a question through the form, our system writes this content to a submission queue. A downstream internal system then retrieves this content from the queue and writes it into the master database.
Why do we have to use a queue rather than directly writing into a database?
Load Leveling
Asynchronous Processing
Scalability
Resilience to Database Failures
Read UGC API service:
The UGC read API’s database operates independently from the primary, internal database. While the primary database contains normalized data, the read API database is designed to serve denormalized and enriched data specifically tailored for API usage in order to meet the response time expectations of Bazaarvoice’s clients and their shoppers.
Why do we need denormalized data?
To handle large-scale traffic efficiently and avoid complex join operations in real-time, we denormalize our data according to specific use cases.
We transform the normalized data into denormalized enriched data through the following steps:
Primary-Replica setup: This will help us to separate write and read calls.
Data denormalization: In Replica DB, we have triggers to do data processing (joining multiple tables) and write that data into staging tables. We have an application that reads data from staging tables and writes the denormalized data into Nosql DB. Here data is segregated according to the content type. Subsequently, this data is forwarded to message queues for enrichment.
Enriching the denormalized data: Our internal applications consume this data from message queues, with the help of internal state stores, we enrich the documents before forwarding them to a destination message queue.
e.g. : Average rating of a product, Total number of ugc information to a product.
Data Transfer to UGC application Database: We have a connector application to consume data from the destination message queue and write it into the UGC application database.
Now that you’ve heard about how Bazaarvoice’s API’s handles the large client and request scale, let’s add another layer of complexity to the mix!
Connecting Brands and Retailers
Up to this point, we’ve discussed the journey of content within a given client’s dataset. Now, let’s delve into the broader problem that Bazaarvoice addresses.
Bazaarvoice helps its brands and retailers share reviews within the bazaarvoice network. For more details refer to syndicated-content.
Let’s talk about the scale and size of the problem before getting into details,
From 12,000+ Bazaarvoice clients, We have billions of catalog and UGC content. Bazaarvoice provides a platform to share the content within its network. Here data is logically separated for all the clients.
Client’s can access their data directly, They can access other Bazaarvoice clients data, based on the Bazaarvoice Network’s configured connections.
E.g. :
From the above diagram, Retailer (R3) wanted to increase their sales of a product by showing a good amount of UGC content.
Retailer (R1)
1 billion catalog & ugc records
Retailer (R2)
2 billion catalog & ugc records
Retailer (R3)
0.5 billion catalog & ugc records
Retailer (R4)
1.2 billion catalog & ugc records
Brand (B1)
0.2 billion catalog & ugc records
Brand (B2)
1 billion catalog & ugc records
Now think,
If Retailer (R3) is accessing only its data, then it’s operating on 0.5 billion records, but here Retailer (R3) is configured to get the ugc data from Brand (B1) , Brand (B2) , Retailer (R1) also.
If you look at the scale now it’s 0.5 + 0.2 + 1 + 1 = 2.7 billions.
To get the data for one request, it has to query on 2.7 billion records. On top of it we have filters and sorting, which make it even more complex.
In Summary
Here I’ve over simplified, to make you understand the solution that Bazaarvoice is providing, in reality it’s much more complex to serve the UGC Write and Read APIs at a global scale with fast response times and remain globally resilient to maintain high uptime.
Now you might correlate why we have this kind of architecture designed to solve this problem. Hopefully after reading this post you have a better understanding of what it takes behind the scenes to serve User Generated Content across Brands and Retailers at billion-record-scale to shoppers across the globe.
This blog post only applies to the Conversations API and does not apply to any other Bazaarvoice product. You are able to identify the Bazaarvoice Conversations API by the following:
Path includes ‘data’: http://api.bazaarvoice.com/data/reviews.json?
Code related to the Bazaarvoice Hosted Display does not need modification. It can be identified by the following:
Today we are announcing two important changes to our Conversations API services:
Deprecation of Conversations API versions older than 5.2 (4.9, 5.0, 5.1)
Ending Conversations API service using custom domains
Both of these changes will go into effect on April 30, 2016.
Our newer APIs and universal domain system offer you important advantages in both features and performance. In order to best serve our customers, Bazaarvoice is focusing its API efforts on the latest, highest performing API services. By deprecating older versions, we can refocus our energies on the current and future API services, which we feel offer the most benefits to our customers. Please visit our Upgrade Guide to learn more about the Conversations API, our API versioning, and the steps necessary to support the upgrade.
We understand that this news may be surprising. This is your first notification of this change. In the months and weeks ahead, we will continue to remind you that this change is coming.
We also understand that this change will require effort on your part. Bazaarvoice is committed to making this transition easy for you. We are prepared to assist you in a number of ways:
Pre-notification: You have 12 months to plan for and implement the change.
Documentation: We have specific documentation to help you.
Support: Our support team is ready to address any questions you may have.
Services: Our services teams are available to provide additional assistance.
In summary, on April 30, 2016, Conversations API versions released before 5.2 will no longer be available. Applications and websites using versions before 5.2 will no longer function properly after April 30, 2016. In addition, all Conversations API calls, regardless of version, made to a custom domain will no longer respond. Applications and websites using custom domains (such as “ReviewStarsInc.ugc.bazaarvoice.com”) will no longer function properly after April 30, 2016. If your application or website is making API calls to Conversations API versions 4.9, 5.0 and 5.1 you will need to upgrade to the current Conversations API (5.4) and use the universal domain (“api.bazaarvoice.com.”). Applications using Conversations API versions 5.2 and later (5.2, 5.3, 5.4) with the universal domain will continue to receive uninterrupted API service.
If you have any questions about this notice, please submit a case in Spark. We will periodically update this blog and our developer Twitter feed (@BazaarvoiceDev) as we move closer to the change of service date.
Thank you for your partnership,
Chris Kauffman
Sr. Product Manager
Imagine you’re a developer working for Widgets n’More. The marketing team just came up with a new cross platform social media promotion. It’s going to involve collecting user generated content in the form of ratings and reviews. As luck would have it you remember your friend on the Ecom Team had mentioned working with a company called Bazaarvoice last year. Widgets n’More partnered with Bazaarvoice specifically for the purpose of collecting and displaying reviews.
In short order you find yourself at developer.bazaarvoice.com where you start reading the Conversations API documentation. There are a lot of fields and parameters and content types. What’s more, some of them appear to be customizable. They offer custom rating fields, tags, context data questions, and additional free text fields. One company might have “rating_value” while another might be using “rating_quality”. It’s also not immediately clear how any those should be displayed in a webform. The fields can even have customizable properties like min and max length.
So, you call your friend hoping she’ll be able to shed some light on the situation. She explains that Bazaarvoice can even configure fields based on content type, like reviews, questions or answers, and make different custom fields available depending on the parent category of a product. Unfortunately it’s been so long since the initial Bazaarvoice implementation that she doesn’t remember what was set up. If only there was an easy way for you to see exactly what fields are available taking all those factors into account…
Conversations API Inspector to the rescue
The Conversations API Inspector was created with the above scenario in mind. It is a web based app that shows what fields can be submitted to the Bazaarvoice platform using the Conversations API for any API key + content type + ID combination. With the Conversations API Inspector our imaginary developer would be able to see what fields are available, how they must be submitted in an HTTP request, meta-data about each field and much more
The Conversations API Inspector is ready to use and publicly available at http://api-inspector.bazaarvoice.com/. It is well documented at our Developer Portal, so instead of repeating that here I’ll leave you with some screenshots.
Epilogue
Even without the Conversations API Inspector all would not have been lost for our imaginary developer. He could have used the API itself to determine what fields are available. In fact this is exactly how the Conversations API Inspector does it. Of course, the Inspector provides a much more user friendly and interactive GUI than the raw JSON or XML returned by the Conversations API. You can read more about how the inspector works at the documentation under the heading “How it works”.
Welcome to the Mashery-powered Bazaarvoice Developer portal. We strive to give you the tools you need to develop cutting-edge applications on the Bazaarvoice platform.
Some changes you’ll notice:
You no longer have to login to see documentation. Just click the Expand icon () to drill down to the information you need.
If you want to request an API key or need to contact us with a support question, you will need to create and use a Mashery ID (or use your existing one if you access other Mashery-powered APIs). Your current Bazaarvoice developer portal ID will no longer work.
Note that none of your existing API keys are affected by this transition. They will continue to work without interruption.
Thanks for your support of the Bazaarvoice platform.
Submission forms pre-filled for non-anonymous users
When submitting content, the values of all known submission fields are now returned in the submission response fields. This only affects submissions where the user is not anonymous and the user/userid parameter is provided with the GET request.
Full text search on all UGC and on includes
The following content types were added to the existing search capabilities:
reviews
answers
comments (story and review)
stories
All content is now searchable. For a list of all the fields that are searched for any given content type, see the API Basics page.
Product family queries
When filtering by product id, all content from that product’s product family is also returned by default. There is a new excludeFamily parameter that you can set to not return product family content. For examples and full documentation, see the Product Display method page.
Photo upload accepts URLs
The uploadphoto endpoint now accepts HTTP URLs of images in addition to locally stored photos from the client side. For examples and full documentation, see the Photo Submission method page.
Brightcove Smart Player Javascript integration
Brightcove videos can be loaded in a variety of ways. The information necessary to load these videos in the browser is now returned in the Videos block of the response elements. See the API Basics page for details on the new response items that were added to support Brightcove videos.
Story rating field exposed in the response
The story display response has a new block called “StoryRating” that contains two fields:
Average score – average of the rating feedback score displayed for each story ID
Range – range of the average score
Special product attributes exposed in the response
The product display response has new fields for each of the following five product attributes:
EANs
UPCs
ISBNs
ModelNumbers
ManufacturerPartNumbers
New filtering capabilities
The following new filters are available:
Affiliation filter on reviews
Brand answer filters on questions and answers
Brand external ID filter for reviews, stories, questions, and products
Hosted email authentication can be used during submission to confirm the identity of a content submitter. When submitting content for the first time, a user receives an email containing a link. When the link is clicked, the user is directed to a landing page that calls back to the API to confirm their identity. This call results in the generation of an encrypted user token that can be used in subsequent submission calls. Depending on your configuration, the submitter’s content might not be accepted until the confirmation call is submitted. In order to use this feature, you must have hosted authentication enabled for your submission process. If you need more information, read the “Bazaarvoice hosted authentication reference guide” and the submission method documentation for details on the required parameters.
Feedback submission for comments
Feedback submission for review comments and story comments is now supported in addition to the existing support for feedback submission on reviews, questions, answers, and stories. For complete documentation, see the Feedback Submission method page.
RatingDistribution and SecondaryRatingsAverages added to review statistics
New RatingDistribution and SecondaryRatingsAverages blocks have been added to the ReviewStatistics block. You can now see the distribution of ratings for each product, which allows you to construct a rating histogram. You can also see the average rating of your secondary rating dimensions for reviews in relation to products and authors.
Time zone changed to UTC
The API now returns all time data using UTC (+00:00) to avoid the confusion of multiple time zones. The date format has not changed.
Error codes added to form errors
The API response has been updated to return error codes in addition to the existing error message for all form errors. A complete listing of the error codes can be found in each submission method.
Syndication attribution on reviews
All reviews have an “isSyndicated” field set to true or false. If the review is syndicated, a SyndicationSource block is displayed with details of where the review is being syndicated from. Syndicated content can only be returned if the API key is configured to show syndicated content.
Submission of helpfulness votes and inappropriate feedback can now be done through the API. The response for the user-generated content has also been updated to display the actual inappropriate feedback and total vote and feedback counts. In order for inappropriate feedback to be populated, the API key must be updated.
Implicit default ContentLocale filter removed
There is no longer any implicit ContentLocale filter if none is specified as an argument. If no filter is provided, all content will be returned, regardless of what locale the content is in. There is a default locale defined for every API key. Prior to version 5.2, if the locale parameter was used, it caused an implied ContentLocale filter to be used.
Note that version 5.2 does not change the behavior of explicitly supplied ContentLocale filters. In addition, you can now ask for labels in any locale and specify a different content locale. Therefore, if you request a locale of en_US and a ContentLocale of fr_FR, you get English labels and French content.
Product and category attributes
Products and categories now have a new attributes field populated. This field contains a map of attributes provided to Bazaarvoice from a product feed import.
Hosted video submission and display
Video elements of all content now contain URLs that can be used to embed the video into an HTML page. Bazaarvoice provides boilerplate HTML tags for use with embedding these videos. For more information, see the API Basics page.
Inline ratings data
A new method has been created to provide a quick way to access inline ratings data for products. For complete documentation, see the Statistics Display method page.
We recently released our new Bazaarvoice Platform API. This is a new RESTful API that allows access to much more data and provides responses in XML and JSON. We are really excited to see the types of applications our clients will be building on the API.
For a quick introduction to the API, we created the API Tutorial (you must be logged in to view) that walks through creating a Javascript-based widget for displaying Bazaarvoice content on any webpage. The tutorial explores the JSONP response format of the API and how it can be used with Javascript templates to inject content onto the page.
) to drill down to the information you need.