How to analyze competitor reviews with AI without drawing false conclusions

A marketer wants to understand what customers complain about and value in competitors. Hundreds of reviews are scattered across maps, marketplaces and social platforms. It may seem that AI can collect them all, group them by topic and produce a ready-made conclusion: “the competitor has a delivery problem.”

The short answer: you can automate the permitted collection of available data, deduplication and topic grouping. Conclusions still need to be checked against the original reviews, with the sample’s bias in mind. The share of complaints among collected reviews is not the share of dissatisfied customers at a competitor. Keep that distinction at every stage.

The key requirement is to obtain data through permitted methods, respecting platform terms and personal-data rules. After reading, you can define an analysis question, prepare a review corpus, check its topics, and phrase findings and hypotheses accurately. All numbers in the examples are illustrative.

Start with an analysis question

“Collect everything about competitors” is not an analysis question. It produces a pile of data and a cloud of topics with no clear next step.

A useful question is narrow and tied to a decision you can make:

• What delivery issues do competitor customers mention in our segment?
• What do customers praise about competitors’ support, and do we do something similar?
• Which expectations about warranties and returns are most often unmet?

The question determines what follows: which platforms, time period, competitors and topics to include. It also helps avoid collecting data you do not need, including personal data.

Obtain data through permitted methods

Before collecting anything, identify an allowed method for each platform: an official API, an authorized export, a manual sample or another verified approach consistent with the service terms. Do not bypass access restrictions or technical safeguards or collect data contrary to the terms of use; that can create legal and account-blocking risks.

Consider a specific but product-limited example: one map-service API returns up to five reviews for a place, sorted by relevance, rather than a full archive. That API’s data has attribution and original-link requirements, as well as restrictions on pre-fetching, caching and storage outside stated exceptions. So “export every competitor review to a spreadsheet and keep it for analysis” is not an appropriate use of that API. This is a product-specific rule, not a limit that applies to every platform. Terms and features can vary by service and region and can change. Check the current terms for the source you choose and the relevant agreement before a project.

Other platforms have their own conditions. The general rule is to record how data was obtained and what coverage it provides.

Personal data is another consideration. A public review may still include personal data, such as the author’s name, profile photo or details in the text. If data-protection rules apply to your processing, limit use to a defined purpose and collect only what is necessary. A review being public does not by itself remove your obligations. Which laws apply and what they require depends on your situation; check with legal counsel.

Prepare the corpus

A corpus is the set of reviews used in the analysis. Its quality affects how much confidence you can place in the findings.

Record and check:

• Period. Reviews from the past six months and the past five years may describe different versions of a company.
• Language. If reviews use several languages, decide how to process them so topics do not split only by language.
• Competitors. Which companies, locations or products are included.
• Duplicates. The same review on multiple platforms or reposted.
• Likely spam. Identical text from different authors, promotional inserts or reviews about another company.
• Reviews without text. A rating without a comment cannot help identify themes, though it can affect an overall score.
• Source link. Keep a way to check the original review later, if the platform terms allow it.

For topic analysis, review text, date, platform and a link are often enough—if the source terms allow you to retain them. Author names and photos are usually unnecessary; pseudonymization alone does not remove personal-data obligations.

Illustrative corpus schema

Before starting, record how many reviews you had before cleaning and how many remained afterward. The difference helps show how much filtering affected the corpus.

Build and validate topics

Automated topic grouping can save time. One method is BERTopic: it converts documents into numerical representations using a language model, clusters similar representations and identifies characteristic words for each cluster with a class-based TF-IDF variation. In simple terms, texts with similar representations may land in the same group, and the method identifies words that characterize the group. A review with multiple topics may need multi-label annotation.

A cluster is not a conclusion. The method finds groups of similar text; it does not establish whether reviews are true or what is happening inside a company. After automated grouping, use human review:

• Name the topics clearly. Read examples from each group and give it a useful name, such as “delivery later than promised,” instead of “delivery_delay_courier.”
• Handle ambiguous reviews. One review may cover several topics: “delivery was late, but support resolved everything.” It may need multiple labels.
• Check sarcasm and context. “Very fast, just two weeks” could be classified as positive automatically.
• Test a control sample. Manually label part of the reviews and compare those labels with the automated topics. This shows how well the grouping matches human interpretation.

Illustrative calculation: an analyst randomly selects 50 reviews and assigns one main topic to each by hand. They then compare those labels with the automated groups. If the main topic matches for 42 reviews, the simple agreement rate is 42 ÷ 50 = 0.84, or 84%. This is not a complete quality measure for reviews with multiple topics. The pattern of errors matters more: if 6 of 8 errors fall into “returns,” review that topic manually in full or revisit the grouping settings. These numbers are invented to explain the method.

State findings accurately

A finding should describe exactly what it measures. A common mistake is turning review data into a claim about the company itself.

Example: calculation and wording

Suppose you collected 200 available reviews about one competitor during one period, and 40 mention delayed delivery.

Calculation: 40 ÷ 200 = 0.2, or 20%.

The share of reviews is not the share of customers: only some customers choose to post. Platforms also have their own display and moderation rules. State the sample size, period and data source alongside a finding.

Comparative table template

The figures in the table are illustrative and should stay labeled that way. Keep the “Coverage” column: it reminds readers that the sample is incomplete. Put hypotheses, not facts, in “Possible explanation.”

Turn findings into hypotheses

Competitor-review analysis is useful not as “the truth about a competitor,” but as a prompt for what to test in your own business.

Move from a finding to an action:

• Product hypothesis. “Delivery times appear in available reviews. Let’s check whether our customers raise this issue and how we communicate expected arrival times.”
• Communication hypothesis. “Available reviews praise support for acknowledging problems quickly. Let’s review whether our response templates do the same.”
• Research hypothesis. “Warranty complaints recur in available reviews. We should explore this with our own customers.”

Do not:

• Publish accusations about a competitor based on unverified reviews. A review describes its author’s experience; it does not establish a fact about a company.
• Use competitor names or review quotations in advertising without legal review.
• Replace research with your own customers with analysis of someone else’s reviews. It is an additional source of hypotheses, not a substitute.

What to change in your process

1. Define one focused analysis question and the decision it will inform.
2. For each platform, identify a permitted way to obtain data and record its coverage.
3. Choose corpus fields: text, date, platform and link. Do not keep names or photos without a justified purpose; check retention conditions separately for each source.
4. Remove duplicates, likely spam and off-topic reviews.
5. After automated grouping, name the topics manually and check a control sample.
6. Phrase findings as shares of the available sample, with its size, period and source.
7. Turn each important finding into a hypothesis you can test with your own customers.

Frequently asked questions