Whats the difference between reviews and user feedback

A skincare brand sits on a 4.6-star average across two app stores and feels good about it. Their support inbox, meanwhile, is filling up with variations of the same question: users cannot find where to reorder. The rating and the inbox are measuring different things entirely, and treating them as the same signal is how products stagnate while their scores stay high.

The rating and the inbox are measuring entirely different things, and treating them as the same signal is how products stagnate.

Reviews and user feedback get lumped together as though they are two names for one thing. They are not. One is a public declaration made in retrospect, coloured by emotion and social context. The other is a direct account of what someone experienced and why. Both carry information, but they carry different information, collected under different conditions, from people in different states of mind. Conflating them produces a flattering but incomplete picture of how a product is actually working.

This distinction matters because the decisions you make from each type of signal are different. A star rating tells you something about aggregate sentiment. Qualitative feedback tells you something about specific friction, specific delight, specific confusion. Using one to substitute for the other produces a different answer to a different question, presented as though it were the answer you needed.

What Star Ratings Actually Measure

A star rating captures a user's overall emotional state at the moment they were asked to rate, compressed into a single number. According to BrightLocal's Local Consumer Review Survey, 98% of customers read reviews before they shop, which makes those numbers commercially significant. But commercially significant is not the same as diagnostically useful.

The number aggregates experiences across time, across user types, and across very different versions of the product. A 4.2 average might include a wave of five-star reviews from the first cohort of enthusiastic early adopters, a dip of two-star reviews after a problematic update, and a cluster of one-star reviews from users who had a billing problem. The arithmetic sits in the middle and tells you none of that.

The sentiment behind the number

Ratings also capture sentiment at the extreme ends of the emotional range. Users who had a fine experience rarely feel moved to rate anything. The people who do rate tend to be those who felt strongly one way or the other, which means the sample is structurally biased before anyone reads a word of it. A 3.8 average does not mean "most users found it mediocre". It frequently means "a large group loved it, a visible group hated it, and everyone in between said nothing".

What the number cannot carry

The number cannot carry context, reasoning, or nuance. A user who gives three stars because the onboarding was confusing and a user who gives three stars because the product worked but crashed once have told you the same thing numerically and completely different things practically. The rating conflates them. Only the words beneath it, if any were left, begin to separate them.

What Qualitative Feedback Actually Measures

Qualitative feedback, at its best, captures the reasoning behind the feeling. Where a rating tells you that someone was dissatisfied, qualitative feedback can tell you at what point, during which interaction, and under what conditions. That specificity is what makes it actionable in a way a number rarely is.

Support requests are one underused source of this. When the same question arrives in a support inbox repeatedly, it is pointing at something structural in the product. The question is really about whether the product communicated clearly enough that no question should have been necessary. Patterns in support traffic can be traced back to specific points of confusion, and those points are usually fixable.

The honest account versus the curated one

Qualitative feedback gathered through in-product prompts or user interviews also captures something ratings cannot: the experience as it was happening, before the user had time to flatten it into a number. A user mid-session who says "I couldn't find the filter" is giving you a precise piece of information. A user who leaves a two-star review three days later and writes "navigation is confusing" is giving you a conclusion without the evidence.

Context and who gave it

Not all qualitative feedback carries equal weight either. A new user and a power user who have each had a poor experience are describing structurally different problems. Holding those two accounts separately, rather than averaging them into a general observation, is where qualitative feedback starts to earn its value. The context of who said it shapes what the feedback actually means.

Why the Two Are Not Interchangeable

The practical difference becomes clear when you try to act on each signal. A rating tells you there is a problem but not what to do. Qualitative feedback tells you what to do but not how widespread the problem is. Neither is sufficient on its own, and neither substitutes for the other, because they are answering different questions from the start.

A supplement brand with a 3.9-star average on their app knows something is wrong. They do not know if users are dropping off at checkout, struggling with subscription management, or confused by the dosage guidance. The rating is a symptom. Qualitative feedback is the diagnostic. Treating the symptom as the diagnosis leads to the wrong fix, or more often, no fix at all because the problem cannot be located with enough precision to address it.

A rating is a symptom. Qualitative feedback is the diagnostic.

There is also a social dimension to reviews that qualitative feedback does not carry. Public app store reviews are written for an audience of future users, not for the product team. That shapes what people say and how they say it. A user writing for a public audience will frame their experience differently than a user responding to a direct question from the product. Both accounts contain truth, but they are different truths, shaped by different purposes.

Before drawing conclusions from any feedback data, note the channel it came from. App store reviews, in-product surveys, support requests, and user interviews each produce a different type of signal. Mixing them without labelling the source produces a muddled picture.

The Weak Link Between Satisfaction Scores and Real Behaviour

The correlation between self-reported satisfaction scores, such as CSAT or NPS, and actual user behaviour like retention and conversion is widely regarded as modest, meaning satisfaction alone is a poor predictor of what users will do next. That is a weak to moderate relationship at best. It means that a brand with genuinely high satisfaction scores can still have poor retention, and a product that users say they love can still see them quietly stop using it.

Part of the reason is timing. Satisfaction surveys are answered after the fact, when the user is calm, reflective, and away from the friction they experienced in the moment. The score reflects a retrospective summary, not the lived experience. A user who found the checkout flow frustrating but got through it may still rate the product highly overall. Their satisfaction score captures the outcome; it misses the friction that nearly lost them.

Stated trust versus actual behaviour

Research by McKnight on online trust found that stated trust scores often diverge from users' actual willingness to transact or share data, particularly when friction or perceived risk increases at the moment of commitment. Users say they trust a product in the abstract. At the specific moment they are asked to enter a payment method or share personal data, behaviour tells a different story. The stated score and the real action are separated by context, and context is the variable the score cannot capture.

What this means for product decisions

Relying on NPS or CSAT as the primary signal for product health is not wrong, but relying on them alone produces a version of product perception that is only partially true. The conscious, stated view they capture is real. The subconscious, behavioural view they miss is also real, and often more predictive of what users will actually do next.

How Teams End Up Optimising for the Flattering Metric

Positive scores reflect well when reported upward through an organisation, right to board level. That is a real organisational dynamic and it shapes which metrics get prioritised. A four-star average is easier to present in a quarterly review than a session recording of a user trying and failing to complete a task. One is a number; the other requires interpretation and implies work.

The result is that teams, often without realising it, end up optimising for the metric that photographs well rather than the metric that is most diagnostic. Effort goes into prompting users to leave ratings, responding to negative reviews, and moving the aggregate score. The underlying friction that generated the low scores often stays in place.

If your team regularly reviews star rating averages in meetings but rarely reviews the qualitative comments beneath them, that is a process gap worth correcting. The number summarises; the words explain.

When the score and the product diverge

Featured App Store games averaged a 4.43 cumulative rating while their current reviewers gave an average of 2.95, according to AppFollow, 2026, a gap of 1.48 stars. A legacy rating inflated by early enthusiasm can mask a product that has since deteriorated, or one that attracted a different kind of user as it scaled. The score reflects history; it does not necessarily describe what new users are experiencing today.

The insider bias problem

Internal teams also carry what could be called insider bias. People who know a product deeply will naturally find it intuitive because they already understand its logic. A new user approaching the same product without that prior knowledge experiences a completely different flow. When teams evaluate feedback, they often filter it through their own familiarity with the product, which makes genuinely confusing things seem like user error rather than design problems.

How You Ask Changes What You Get

The framing of a feedback request changes the type of response it generates. On a travel app project we worked on, the standard prompt was "rate this experience". The psychological assumption users made was that the rating was for the company's benefit, not their own or other travellers'. That assumption suppressed response rates, particularly from users who had neutral or positive experiences and felt no urgency to act.

We reframed the copy to "what would you tell other travellers about this?" The shift was small in words but large in effect. Users who felt they were helping other people, not submitting data to a company, were more willing to engage and more willing to leave considered responses. The same information was being requested; the psychological context of the request was entirely different.

Timing is as important as framing

When a feedback prompt appears is as significant as how it is worded. Users asked for a rating the moment they open an app have not yet experienced the product's value, so the rating they give reflects almost nothing useful. A prompt placed immediately after a user completes something meaningful, finishes a workout, redeems a reward, or successfully tracks a goal, reaches them at an emotional high. They are far more likely to respond and far more likely to respond positively.

Avoiding the false positive

The risk of prompt timing is manufactured positivity. If a rating prompt only ever appears after positive moments, the collected ratings will skew high regardless of whether the broader product experience justifies it. That is why timing strategy needs to sit alongside honest qualitative collection, to ensure the high scores reflect real satisfaction rather than a well-placed ask.

Test your feedback prompt timing by mapping it against the user journey. If the prompt appears before the user has experienced anything of value, move it. If it appears at a natural moment of completion or achievement, you are more likely to collect a rating that reflects actual experience.

Weighting Feedback by Who Actually Gave It

Not every person who leaves feedback is equally relevant to every decision. A feature designed for a specific type of user, say someone who is new to tracking their fitness, should be evaluated primarily against feedback from people who match that profile. Feedback from a power user who has used the product daily for six months will reflect a completely different experience of the same feature, and conflating the two produces a distorted picture.

Before drawing conclusions from any batch of feedback, it is worth reviewing the user profiles of those who participated. Their background, their stage in the product lifecycle, and their fit with the target demographic for a given feature all shape how much weight their account should carry. A response from someone who has never completed onboarding and a response from someone who uses the product weekly are both valid, but they are valid for different questions.

Per-feature relevance

Relevance varies on a per-feature basis. Feedback about the onboarding experience is most useful from users who went through it recently and fit the new-user profile. Feedback about advanced filtering or subscription management is more useful from frequent, longer-term users. Treating all feedback as equally applicable to all decisions flattens the distinctions that make it actionable.

The practical step teams routinely skip

Teams routinely look at what feedback says without first checking who said it. Adding a step to every feedback review, explicitly asking which user profiles are represented in this data and whether those profiles are the right ones for the decision at hand, changes the quality of what you take from it. It is a slower process and produces better conclusions.

Using Both Signals Together Without Conflating Them

The answer to the weakness in either signal is not to abandon one for the other. Self-reported satisfaction data does not need to be replaced by behavioural or in-context data. It needs to be supplemented by it. The two types of signal produce a more complete picture together than either does alone, because they are capturing different dimensions of the same experience.

A practical way to hold them separately while using them together is to treat ratings as directional and qualitative feedback as explanatory. When the rating average drops, that is the signal to go looking. When qualitative feedback reveals a pattern of confusion around a specific interaction, that is the diagnosis. When both are pointing in the same direction, the case for action is strong. When they diverge, that divergence itself is informative.

After every product launch we have worked on, feedback has redirected the product in ways the internal team did not anticipate. The founding team's assumptions about what users would find valuable are rarely wrong in their entirety, but they are almost always incomplete. Real user accounts, gathered under the right conditions from the right people, fill in the parts that no amount of internal review can surface.

Conclusion

Reviews and qualitative feedback are not two words for the same thing. One is a public score reflecting emotional state at a specific moment. The other is a direct account of what happened and why. They are different instruments measuring different things, and treating either as a substitute for the other produces conclusions the data cannot support.

The practical discipline is to hold them separately while using them together. Ratings tell you something has changed or something is wrong. Qualitative feedback tells you where and why. Behavioural data tells you what users actually do, as distinct from what they say. Each layer adds something the others cannot, and the picture only becomes reliable when all three are present.

The structural biases in each signal are also worth keeping in mind. Ratings skew toward extreme experiences. In-product prompts skew toward the emotional context in which they appear. Qualitative feedback skews toward whoever participated and how relevant they were to the feature in question. Knowing the bias in a signal does not make it useless; it makes you better at interpreting it without overstating what it shows.

Getting this right is a sustained design decision about how your team collects, weights, and acts on feedback at every stage of the product lifecycle. If you want to think through how that works for your product, let's talk about your feedback strategy.

Frequently Asked Questions