Review analysis needs aspects, context and an unknown label
Build a review-analysis dataset that distinguishes product quality, service, delivery and uncertainty instead of reducing every review to one score.
In this article
THE KEY IDEA
A review can praise the product and criticise delivery at the same time. Analyse the relevant aspect and disclose what the sample does not represent.
01Define the unit of analysis
Decide whether you are analysing a review, a sentence or an aspect within a review. A single positive or negative label can erase the useful distinction between a good product and poor fulfilment. Start with the business questions you need to answer, such as packaging complaints or changes in support experience.
Keep the original rating separate from model-generated sentiment. A five-star review can contain criticism, and a low rating can describe a problem unrelated to the product itself. Neither field should silently replace the other.
02Preserve the sampling context
Record the platform, entity being reviewed, language, date, collection time and the selection method. Sorting by most helpful produces a different sample from sorting by newest. A limited set of visible reviews should not be presented as every customer's opinion.
Avoid collecting reviewer details that the analysis does not require. Review text itself may contain personal information, so include an appropriate privacy review and retention policy. Do not assume that removing a username makes every passage anonymous.
| Keep separate | Why |
|---|---|
| Published rating and inferred sentiment | They measure different things |
| Product and delivery aspects | Different teams own the remedies |
| Original text and translation | Meaning can shift during translation |
| Not mentioned and neutral | Absence is not an opinion |
03Use a constrained aspect schema
Define a small taxonomy and include unknown or not-mentioned outcomes. Require supporting text for each assigned aspect. A model should not invent a complaint because the rating is low or because other reviews mention the same issue. Validate labels and field types before aggregating results.
For multilingual reviews, evaluate examples in the original language where possible. Sarcasm, negation and product-specific wording can be lost in translation. Keep translated text as a derived field with the transformation version so a reviewer can trace a questionable label back to the source.
04Test agreement before publishing a trend
Create a manually reviewed sample that includes mixed sentiment, very short reviews, duplicates and ambiguous language. Compare aspect labels and sentiment separately. A system can identify the right topic but assign the wrong polarity, and a single overall accuracy figure hides that difference.
Check how duplicates and copied reviews affect the result. Do not simply remove every similar sentence: legitimate customers can describe common problems in similar words. Use a documented deduplication policy and report its effect on the sample size.
05Report changes with denominators
An increase from five complaints to ten means different things in a sample of twenty reviews and a sample of two thousand. Show counts, sample size, collection window and coverage gaps alongside percentages. Compare like-for-like cohorts before describing a change as a product trend. The output should guide investigation, not imply that a scraped sample represents the whole customer population.
References & further reading
Put it into practice.
Try a public-page workflow, or scope a maintained dataset with our team.