Aggregate competitor review analysis: what the official interfaces return, why no review text or name is stored, and turning a theme into a testable gap.
Key takeaways
- The output of the analysis is a theme and a count, not a quote. Reviews are text written by people, and they frequently name an employee.
- Google's Places API returns at most five reviews per place, and even those may not be stored: the policy forbids pre-fetching or caching content, with `place_id` as the exception.
- So a "competitor review warehouse" is not an available design. What is available is a derived count that you produce and that keeps no text.
- Your own business's reviews are reachable through the Business Profile API via `accounts.locations.reviews.list`, and that is the only place you hold a full, authorised corpus.
- A service gap is not a finding until a test has been defined against your own business - a measurement, a mystery shopper, or a survey question.
Analysing competitor reviews produces one useful thing: a list of recurring themes with counts. The output is not a quotation and not a dossier on another business, but a hypothesis about your own service that you can test - for example "phone response time is what people complain about in this category".
What the output is, and what it is not
The output is a theme table: theme, mention count, share of the items read, and sentiment direction. A row looks like this: "waiting for a reply - 19 mentions out of 140 items read, 86 percent of them negative".
What is not part of the output, and not for reasons of taste but as a design decision:
- A verbatim quotation of a review, short or long.
- The reviewer's name, their photo, or a link to their profile.
- The name of an employee mentioned in a review, even where it appears openly at the source.
- Any detail that identifies a person: a single-incident description, an exact visit date, an order number.
- A "competitor report" assembled by copying their content into a different layout.
The easy test to apply: if a row in the output does not survive replacing every name with a letter, it is not an aggregate row. Aggregate review analysis as a working tool is also covered in analysing customer reviews with AI.
What do the official interfaces actually return?
Know the numbers before designing, because they decide what is possible at all:
| Source | What comes back | The constraint that matters |
|---|---|---|
Places API - reviews[] field | A list of reviews about the place, sorted by relevance | A maximum of 5 reviews per place |
Places API - rating | A rating between 1.0 and 5.0 | An average only, not a per-star distribution |
Places API - userRatingCount | The total review count, with or without text | A number, with no breakdown over time |
Places API - reviewSummary | An AI-generated summary of the place from user reviews | Ships with disclosure text, and is not the raw data |
| Places policy | place_id is exempt from caching restrictions | All other content must not be pre-fetched or cached |
| Business Profile API | accounts.locations.reviews.list on a location you manage | Requires OAuth and covers only your own businesses |
Two conclusions. First, userRatingCount tells you how many reviews exist while reviews[] hands over up to five - so the distance between what exists and what is reachable is structural, not a fault. Second, place_id is the only identifier you may retain over time, which makes it the right anchor for the list of places you follow.
How to analyse without storing the text
The structure that works is a pipeline that processes and discards, not one that accumulates:
- Keep a list of
place_idvalues for the places you compare against. That is what persists. - On each run, read what the interface returns, in memory only.
- Classify each item into a theme from a fixed list you defined in advance - response, waiting time, price, quality, cleanliness, schedule reliability.
- Count by theme and sentiment direction, and produce the aggregate rows.
- Discard the text and everything that identifies a person. What remains is counters.
- Persist only the counts, alongside the
place_id, the run date and the number of items read.
The step people skip is the fourth, and without it you accumulate a corpus sitting on your disk for no reason. A run that ends holding only counters is also far easier to explain to anyone who asks what exactly you are keeping.
From a recurring theme to a testable hypothesis
| Recurring theme at competitors | What it suggests | Hypothesis about your business | How you test it |
|---|---|---|---|
| "nobody got back to me" | Slow first response across the category | Your response time may also run long | Measure time to first reply on this week's enquiries |
| "the quoted price was not the final price" | Weak pricing transparency | Your quote may leave ambiguity | Read your last five quotes and flag every unclear line |
| "they did not arrive on time" | Schedule reliability | You may be promising a date you do not control | Compare promised against actual date on ten jobs |
| "they could not answer my question" | Uneven front-line knowledge | There may be no written answer for common questions | Count how many enquiries were escalated this month |
| "after the sale they disappeared" | Weak post-sale service | No defined process after closing | Check whether a scheduled touchpoint exists after delivery |
That fourth column is the entire difference between an intelligence document and an improvement. A theme with no test stays an opinion, while a test produces a number you can return to next quarter. The next step, wording a response and running a process against your own reviews, is discussed in responding to reviews with AI.
What can this analysis not tell you?
- It does not represent customers generally. People who write reviews are mostly the very satisfied and the very disappointed. The middle is barely represented.
- An average rating is not service quality. A business with 4.6 across 2,000 reviews and one with 4.6 across twenty are not the same thing, and the average alone hides it.
- It does not detect manipulated reviews. There is no reliable way from the outside to separate an authentic review from a solicited one.
- Five reviews are not a sample. Ordering by relevance is not random sampling, so your counts are biased toward whatever the interface chose to surface.
- It does not explain cause. A recurring theme points at where to look, not at what happened.
That is why the number of items read is part of the output itself and not a footnote. A row annotated "out of 140 items read" can be challenged; the same row without that number reads like a fact about the market.
Comparing against your own reviews
The other half of the analysis is the only place you hold a complete and authorised corpus: your own reviews. The Business Profile API lets you read the reviews of a location you manage through accounts.locations.reviews.list after OAuth authorisation, and lets you reply to them.
That produces the comparison that carries value: the same themes, classified with the same list, once on your reviews and once on what was read at competitors. A theme that is strong for them and weak for you is an advantage worth saying out loud in marketing; a theme strong on both sides is a category problem. Pulling your own reviews from several platforms into one place is described in aggregating Google and Facebook reviews.
Sources
Frequently asked questions
Can you build a store of all competitor reviews?
Not through the official route. The `reviews[]` field in the Places API returns at most five reviews per place, and the policy forbids pre-fetching or caching interface content, with `place_id` exempt from that restriction. A design that assumes a full archive of competitor reviews does not fit that route.
Can a competitor's review be quoted in an internal deck?
That is no longer aggregate analysis but use of text a person wrote about another business, often naming an employee as well. The method described here contains no quotation, internal or otherwise, because the useful output is the count and not the sentence.
What do you do when the number of items read is too small?
Report it. A row resting on twelve items is not a finding, and the right way to present it is with the counter beside it. If you need a broader base, widen the number of places examined in the category rather than drawing a strong conclusion from a small sample.
How do you compare a business with thousands of reviews to one with dozens?
Not on the average. Compare rates - what share of the items read mentioned a given theme - and always display the number of items read on each side. Comparing average ratings between two businesses of very different scale is the most common mistake in this kind of analysis.
Keep reading
Related service
Integrations
Make the systems you already pay for talk to each other.
About the author
Yehonatan Saadia
Freelance automation, web & MVP developer
I'm Yehonatan Saadia, a senior developer who builds business automation, custom websites, and MVPs for small and mid-sized companies across the US, Europe, and Israel. These guides come from real client work, not theory.
Work with meHave a project like this?
Tell me what you're trying to automate or build. I reply within 24 business hours with a few targeted questions, then we walk through it on a free 30-minute call, with no commitment. You come away with a scope, a timeline and a fixed price - or a straight answer that it isn't worth building.