Every organisation is sitting on a large corpus of customer text it did not design: reviews, support tickets, chat logs, app-store ratings, open-ended survey boxes, cancellation reasons. It is cheap, unprompted, and continuously refreshed — and it is the most systematically over-read data in commercial research, because the analysis almost never accounts for who wrote it and why. Mining it well is mostly a matter of being precise about what a self-selected corpus can and cannot support.
Found data, and what that costs
The strength of this material is that nobody asked for it. Reviews and tickets are written for the writer's own purposes — warning others, obtaining a refund, venting — which means they surface issues no research instrument thought to ask about, in the customer's own vocabulary.
The cost is selection. People write reviews at the extremes; they open tickets when something breaks; they fill in the free-text box when they have a grievance. The corpus is not a sample of customers and cannot be treated as one, which rules out the most tempting claim: "37% of our customers are unhappy with onboarding" is not supportable from a review corpus, whatever the arithmetic says.
What the corpus does support is a claim about the issue space: what kinds of problems exist, how customers describe them, what vocabulary they use, and how the composition of complaints changes over time. Those are real findings and they are enough to be useful.
The methodological literature
The most rigorous treatment of using text corpora in consumer research is Humphreys and Wang's Automated Text Analysis for Consumer Research in the Journal of Consumer Research, which sets out when automated approaches are defensible and what validation they require. It is the paper to read before building any pipeline.
Netzer and colleagues' Mine Your Own Business: Market-Structure Surveillance Through Text Mining demonstrates that competitive market structure can be inferred from forum text — the strongest published demonstration of what found text can support beyond complaint counting.
An earlier applied treatment of forum analysis is available as Using text mining to analyze user forums, and for the cultural dimension of online discussion Kozinets's The Field Behind the Screen remains the reference — analysing an online community as a community, not just as a text source.
A defensible process
Define the corpus and document its bias
State the sources, the date range, the platform and the inclusion rules — and then write down, explicitly, who is missing. Customers who left silently, users who never contact support, people who churned without a cancellation reason.
This paragraph is what stops the analysis being misread later, and it is the paragraph that never gets written.
Clean, and check for manipulation
Deduplicate, strip templated text, and separate genuine content from bot and incentivised material. Review corpora contain fake entries, and clusters of near-identical five-star reviews posted within a short window are the obvious signal.
Where the corpus is multilingual, decide whether to translate or analyse separately. Translating before coding loses idiom that often carries the complaint.
Code inductively on a sample first
Read a few hundred documents properly and build categories from them before automating anything. Categories imported from an existing taxonomy will find what the taxonomy already knows about.
The vocabulary customers actually use is one of this data's most valuable outputs and it is destroyed by mapping to internal terminology at the coding stage.
Scale, then validate against human coding
Apply the scheme across the corpus, then take a random sample of the automated output and check it by hand. Report that agreement.
This validation step is what Humphreys and Wang insist on and what most commercial pipelines omit. Without it, an automated classification is an assertion.
Analyse composition and change, not prevalence
Report what proportion of the complaints concern each issue, and how that composition moves over time and across releases — not what proportion of customers hold a view.
Time series are where this data is strongest: a category that goes from 4% to 19% of tickets in the fortnight after a release is a signal that no survey would have caught in time.
Read the extremes closely
Return to the actual text for the categories that matter. Aggregate counts tell you where to look; the specific accounts tell you what is wrong, and they contain the reproduction steps and the workarounds.
What sentiment scoring does and does not do
Sentiment classification is the default first move and the weakest part of most pipelines. It is worth being clear about its failure modes rather than abandoning it.
- Sarcasm and irony invert it. "Brilliant, another update that logs me out" scores positive on most classifiers.
- Negation and scope are handled unevenly. "Not what I would call fast" is routinely misread.
- Domain terms carry the wrong polarity. "Sick", "insane", "ridiculous" are positive in some product categories and negative in others.
- Mixed documents get averaged. A review praising the product and condemning delivery is not neutral; it contains two findings, and the average destroys both.
- A score is not a reason. Knowing sentiment fell tells you nothing actionable. The category composition does.
Sentiment is useful as a triage signal — sort the negative material to the top of the reading queue — and it is not a finding. Reporting a sentiment score as the headline of a feedback analysis is the equivalent of reporting a satisfaction average from a usability test.
Worked example: reading a support corpus after a release
A software company analysed 14,000 support tickets and 3,200 app-store reviews spanning six months either side of a major release.
The corpus definition stated plainly that it excluded the roughly 60% of users who had never contacted support, and that app-store reviewers skewed to one and five stars.
Inductive coding on 400 documents produced eleven categories, one of which — "cannot find where X moved to" — used customers' own framing rather than the internal category "navigation". That distinction mattered: the internal taxonomy would have merged it with genuine navigation defects, and the fix is different.
Automated classification across the full corpus was validated against 300 hand-coded documents, with agreement reported at 0.81 and the disagreements characterised: the classifier over-assigned the billing category to any document containing a currency symbol.
The composition analysis was the finding. The "cannot find where X moved to" category ran at 3% of tickets before the release and 22% for five weeks after, then decayed to 6% — where it stayed, well above baseline. The residual 6% was concentrated in accounts created more than two years earlier.
Close reading of that residual gave the actionable detail: those users were navigating from muscle memory to a location that no longer existed and had no redirect. The aggregate said where to look; the individual tickets said what to do. Neither would have been enough alone, and no claim was made about how many customers were affected — only about what share of the people who complained were complaining about this.
Common mistakes
- Treating the corpus as a sample of customers. The single most consequential error, and it produces confident numbers about a population that was never surveyed.
- Sentiment score as the finding. It is triage, not a result.
- No validation of automated coding. An unchecked classifier is an assumption at scale.
- Importing the internal taxonomy. Loses the customer vocabulary that is the data's distinctive value.
- Ignoring fake and incentivised content. Especially in public review corpora.
- Aggregate without close reading. Counts locate the problem; the text explains it.
- Comparing across platforms without adjustment. App-store reviews, support tickets and survey free text have different populations and different norms, and pooling them merges three biases.
How quality is judged
The reporting requirements are specific: the corpus definition with dates, sources and exclusions; an explicit statement of who is absent; whether coding was inductive or applied, and how any automated step was validated; results framed as composition of the corpus rather than prevalence in the population; and time-series comparisons made against a defined baseline.
A feedback analysis that reports percentages without saying "of complaints" is the one to send back.
Limitations
Selection bias is structural and cannot be corrected, only stated. No weighting scheme recovers the silent majority from a corpus of self-selected writers.
The data is also thin per document. A review gives you an outcome and a complaint, rarely the context, the alternative considered or the sequence of events — which is why review mining identifies where to investigate rather than concluding an investigation.
Platform changes break comparability: a review prompt redesign, a support-form change, or a moderation policy shift will move the composition without anything changing in the product. And public review corpora carry terms-of-service constraints on collection and storage that need checking before a pipeline is built.
Where software helps
This is the methodology with the largest corpus and the strongest case for tooling: 17,000 documents cannot be read, and inductive coding on a sample followed by consistent application at scale is exactly the shape of work a qualitative platform handles.
The two things worth insisting on are that the coding scheme comes from the data rather than from a stored taxonomy, and that a hand-coded validation sample is checked against the automated output and reported. Evidano supports review and feedback mining as a named methodology and handles spreadsheet and free-text corpora at this scale. Defining the corpus honestly — and saying who is missing from it — is the researcher's responsibility, and it is what determines whether the analysis is evidence or a confident-looking artefact of who happened to complain.
Topics
- review mining
- feedback analysis
- automated text analysis
- sentiment analysis
- voice of customer
- open-ended responses
- social listening
Other methods in customer experience and voice-of-customer research
Written guides are linked directly; the rest have a reference entry in the methodology directory.
Keep reading
- Research MethodsOutcome Harvesting: a practical guideHow to run an outcome harvest: the six steps, what counts as an outcome, how substantiation works, and when harvesting beats a conventional results framework.
- Research MethodsContribution Analysis: a step-by-step guideHow to run a contribution analysis: build the contribution story, test it against evidence, and address rival explanations when no counterfactual exists.
- Research MethodsRealist Evaluation: context, mechanism, outcomeWhat realist evaluation actually asks, how to build and test a CMO configuration, where the mechanism concept gets misused, and how realist quality is judged.
