Skip to main content
The journal
AI workflows3 min read

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
  1. Define the unit of analysis
  2. Preserve the sampling context
  3. Use a constrained aspect schema
  4. Test agreement before publishing a trend
  5. Report changes with denominators

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 separateWhy
Published rating and inferred sentimentThey measure different things
Product and delivery aspectsDifferent teams own the remedies
Original text and translationMeaning can shift during translation
Not mentioned and neutralAbsence 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.