Customer review and social mining

Insight leads and product marketers start this job with a folder of unstructured text: retail reviews, app store ratings, support forum threads, community posts, and whatever the listening tool exported overnight. The useful output is a short list of named themes, each one carrying the verbatims it was built from and a pointer back to the original post. A theme that cannot show its quotes is a label somebody liked, not a finding.

Ranking sets research priority. It is not a vote. A cluster of four hundred posts about a docking station tells the team where to look next. It does not say how many customers hold that view, because the people who post chose to post. Read the rank as an order of work, not as a share of the market.

Brandwatch and platforms in that class usually own collection, language detection, and the export. They do not decide what your product's pain points are. A person decides that, after reading the cluster.

Keep this apart from interviews an LLM moderates on demand. Mining reports what people already said, unprompted, to someone else. An interview lets you ask the second question. Mixed into one deck, the two hide which claims were volunteered and which were requested.

Write the boundary down first. Which sources, which product or model, which markets, which languages, and which dates. Embeddings cluster whatever you hand them. A corpus that quietly holds a discontinued model, a reseller's own listing, or a competitor's app reviews will produce themes about things you do not sell.

Four settings decide most of the quality. Source list: name each site, subreddit, forum, or handle, and record why it is in scope. Time window: pick dates that match a release, a season, or a campaign, so a spike has something to sit against. Product scope: map SKUs and app versions, because "the app is broken" means nothing across three release trains. Language: keep the original text and translate for reading only, never for clustering.

Deduplicate before you embed, not after. Retail reviews syndicate across storefronts. The same paragraph can appear on four sites under three names. If those copies survive into the vector store, the cluster looks large and the theme looks urgent.

If the source list is empty, or nobody can say which product the posts are about, return nothing. An unscoped run produces a tidy chart of themes that no one can act on, and it takes a week to disprove. Empty is faster.

Run the pipeline in that order. Embed each post, cluster the vectors, then ask a model to propose a name for each cluster using only text inside it. Seeding the taxonomy first is the common shortcut and it wastes the method. If you hand the system your existing pain point list, it sorts posts into your categories and returns your assumptions with a volume number stapled on.

A cluster name should be quotable. "Brush tangles on long pet hair" can be checked against the posts. "Reliability concerns" cannot. When the proposed name is broader than the quotes, split the cluster or leave it unnamed until a human reads it.

Rank on more than volume. Count distinct posts after dedupe. Look at whether the cluster is growing across the window or sitting flat. Look at severity language: refund, returned it, cancelled, warranty. Look at source spread, because a theme that lives on one platform behaves differently from one that appears on three. Show those signals as separate columns. A single blended urgency score hides which one fired.

Mark thin clusters as thin. Nine posts is a lead, not a theme. Keep it on the list, label it low evidence, and do not let it inherit the confidence of the rows above it.

This walkthrough is illustrative, with invented numbers. A consumer robotics brand wants to know what owners of its mid-tier vacuum complained about between January and March, after a firmware release in February.

The corpus is scoped to that model: reviews on three retail storefronts, the brand's own support forum, one enthusiast subreddit, and public posts naming the model. After dedupe, roughly 2,900 posts remain, down from 3,600, because two storefronts syndicate the same review feed.

Clustering returns eleven groups. Four are worth reading. The largest, around 640 posts, is about brush roll tangles on long pet hair, steady across all three months, spread over every source. The second, around 310 posts, is about the app losing the robot after the February firmware, almost flat in January and sharply up in March, and it carries refund language. The third, around 180 posts, is about odor from the self-emptying base. The fourth, 24 posts, is about the unit missing a specific dark rug, and it lives entirely in one forum thread.

The app cluster ranks above the tangle cluster despite lower volume, because the growth slope starts at the firmware date and the severity words are there. The tangle cluster is bigger but stable, and it appears in reviews of the previous model too, which the boundary file makes visible. The dark rug cluster is marked low evidence and single source. It is one thread with engaged repliers, not a market signal.

What the system does not do: it does not say the firmware caused the disconnections, and it does not estimate how many owners are affected. The research lead takes the app cluster to support tickets and to engineering, with fifteen cited posts and their dates.

Four things break this pipeline in practice, and they all produce output that reads well.

Duplicate text inflates volume. Syndication, quoted replies, and bot reposts stack the same sentence into a cluster that then ranks first. Dedupe on near-identical text, not on post ID.

One loud thread becomes a theme. A creator video, a review campaign, or a single angry forum post with sixty replies produces a dense cluster in a day. Check author count and distinct source count, not just post count, before anything goes in a deck.

Sentiment averaging destroys the point. A theme scored at neutral overall can hold both delighted owners and people demanding refunds. Keep the polarity distribution and the strongest quotes at each end. One number per theme is where the nuance dies.

A seeded taxonomy hides the new problem. If the run maps posts to last year's categories, the issue that has no category yet lands in "other" and nobody reads "other." That is the failure this method exists to prevent.

The related trap is treating this as an audience study. Posters are not the customer base. Segment work belongs with clustering on CRM and CDP records, where you know who the people are.

The final name on every theme belongs to a person who read the verbatims. The model proposes, the researcher confirms, edits, or splits. That step is short and it is where most bad labels die.

The researcher also decides what leaves the room. A ranked list is an internal artifact. Themes that are single source, thin, or built on one thread stay marked that way when they travel, or they get dropped. Nothing goes into a campaign brief assembled from research and goals as a customer need until someone has stood behind it by name.

Do not convert cluster counts into claims about the market. "Six hundred posts mention tangles" is defensible. "A fifth of owners struggle with pet hair" is not. Keep the count next to the corpus definition so the two travel together.

Do not let this replace verification. Themes are hypotheses about what matters. Confirm the important ones against support tickets, returns data, or a fresh round of interviews before they change a message. A cited desk research brief can add public context, and competitor mentions pulled from sales calls can show whether buyers raise the same thing in a live conversation.

When a theme does change a message or a roadmap item, record who decided and what they read. Six months later, the useful question is not what the model clustered. It is which person believed it, and on what evidence.