Amazon Review Defect Finder

Find out which product complaints are REAL patterns and which are one-off grumbles.

Paste an Amazon product URL and it does the rest. It fetches the critical reviews, groups the complaints more than one person made, and hands you a ledger: each named fault with how many separate reviewers reported it, the date range, the worst star rating, and their own words as evidence.

Who it is for. Sellers and brand owners watching their own listings, and equally buyers, sourcing teams and researchers looking at a product they do NOT own. You need no seller account and no ownership — a competitor's product works exactly as well as your own.

Most review tools give you raw data. This one tells you which complaint is a pattern and which is one person having a bad week.

Run it in ten seconds

Paste a product URL into Amazon product URL(s) and press Start:

{
  "productUrls": ["https://www.amazon.com/dp/B0BSHF7WHW"],
  "maxReviews": 100,
  "minCorroboration": 3
}

It fetches only the 1-3★ reviews — the ones that can carry a defect — so you are not billed for five-star reviews it would only discard. Out comes one row per corroborated fault.

Leave the URL blank and press Start anyway. The Actor ships with a worked example in the reviews field, so you get a real ledger for free before spending anything:

{
  "reviews": [
    { "userId": "R1", "date": "2026-03-02", "ratingScore": 2,
      "reviewDescription": "The left earbud stopped charging after about four months. Case shows it at 100% but it is dead." },
    { "userId": "R2", "date": "2026-03-19", "ratingScore": 1,
      "reviewDescription": "Left bud stopped charging completely around month five. Right one is fine." },
    { "userId": "R3", "date": "2026-04-07", "ratingScore": 2,
      "reviewDescription": "Battery died on the left earbud after four months of light use." }
  ],
  "minCorroboration": 3,
  "productName": "Wireless Earbuds (example)"
}

and the ledger row it produces:

{
  "result": "DEFECT_CLUSTER",
  "asin": "_all",
  "product": "Wireless Earbuds (example)",
  "defectPhrase": "left earbud",
  "distinctReviewers": 3,
  "totalMentions": 3,
  "firstSeen": "2026-03-02",
  "lastSeen": "2026-04-07",
  "severityMinRating": 1,
  "exampleQuotes": [
    {
      "text": "The left earbud stopped charging after about four months",
      "userId": "R1",
      "date": "2026-03-02"
    },
    {
      "text": "Left bud stopped charging completely around month five",
      "userId": "R2",
      "date": "2026-03-19"
    },
    {
      "text": "Battery died on the left earbud after four months of light use",
      "userId": "R3",
      "date": "2026-04-07"
    }
  ]
}

That is the actual output of the input above, captured from a real run — not a mock-up. The review text is illustrative; the row is what the Actor produced.

distinctReviewers: 3 is the number that matters. Three separate people, three separate dates, describing the same physical failure — that is a defect. One person saying it twice is not, and this counts users rather than mentions so the two never look alike.

When nothing clears the threshold you get a row saying so, rather than an empty dataset that could mean anything:

{ "result": "NO_CORROBORATED_DEFECTS", "why": "no failure was named by 3 or more distinct reviewers" }

Output fields

Field	Meaning
result	DEFECT_CLUSTER, or a status row when there is nothing to report
asin	the product group this cluster belongs to, or _all when reviews carry no ASIN
product	the productName you passed
defectPhrase	the dominant phrase across the cluster, in reviewers' own words
distinctReviewers	how many DIFFERENT people named it — the corroboration count
totalMentions	how many times it was named, which can exceed the reviewer count
firstSeen / lastSeen	the date range, so you can see whether it is old or current
criticalReviewsAnalysed	how many 1-3★ reviews were read. On EVERY row — the denominator
failureSentencesFound	how many sentences carried failure language
clustersFound	how many distinct faults were grouped, before the corroboration cut
clustersBelowThreshold	how many of those had too few distinct reviewers to report
why	on a status row, the sentence explaining why there is nothing to report
minCorroboration	the threshold this run used
analysedAt	when the ledger was built — a saved ledger cannot say it is still true
severityMinRating	the lowest star rating among the reviews in this cluster
exampleQuotes	verbatim evidence, with the user and date behind each one
productUrl	the link back to the product: linkUrl if you set it, otherwise the first URL you fetched with. null if you gave neither

firstSeen and lastSeen are worth reading together. A cluster spanning eight months is a manufacturing problem; one spanning eight days is often a single bad batch.

What you get

Each dataset item is a defect cluster — one named product failure corroborated by multiple independent reviewers, with dates, severity and verbatim evidence. When no defect meets the corroboration threshold, you get an explicit record saying so — never silence, never an empty dataset that could mean anything.

How to use it

Paste a product URL. That is the whole thing. It fetches the critical reviews and builds the ledger in one run.

Amazon gives sellers no export of review text — Voice of the Customer exports returns and customer-experience data, and "download feedback reports" is seller feedback. So the reviews have to be scraped, and this does it for you rather than sending you off to do it.

If you already have review data, two other ways in:

• A dataset you already produced. Put its ID in reviewsDatasetId. Set it to {{resource.defaultDatasetId}} on a scraper's Integrations tab and that scraper feeds this Actor automatically, on whatever schedule you give it.
• Paste the objects into reviews. Fine for a handful or a hand-assembled set.

A product URL takes priority over both. Clear it to use the review data instead.

What makes this different

Every bulk review tool gives quantity. None tell you whether a complaint is a real recurring defect or noise. This one counts DISTINCT reviewers per named failure — so you know "battery dies after 6 months" reported by 12 independent people is different from "hated the colour" mentioned once.

Input

Field	Default	Description
productUrls	(empty)	Start here. One or more Amazon product URLs. It fetches the 1-3★ reviews itself and builds the ledger. Takes priority over the two fields below.
maxReviews	100	Caps how many critical reviews are fetched — five-star reviews are never requested, so this is the number you are billed for. Only applies when you give a product URL.
reviewsScraperActor	junglee/amazon-reviews-scraper	Which Store Actor does the fetching. Change it if you prefer another; it must return objects carrying review text, a rating, a reviewer id and a date.
reviews	(prefilled)	Review objects (JSON), if you already have them. Arrives filled with a worked example, so Start works before you change anything.
reviewsDatasetId	(optional)	The dataset ID of a run that produced reviews. Set it to {{resource.defaultDatasetId}} in an Integration and a scraper feeds this Actor automatically.
minCorroboration	3	Minimum distinct reviewers per defect to appear in the ledger
productName	(optional)	Human-readable label for the ledger entries
linkUrl	(optional)	A link copied onto every row so you can click back to the product. Only needed when you supply reviews yourself; if you gave a product URL, that one is used. Never fetched.

Give it a product URL, or reviews, or reviewsDatasetId. A URL wins over the other two, because a URL is something you typed and the prefilled reviews are a sample you did not choose. The log says so when it ignores something.

Two failures are reported as their own rows rather than as an empty result, because a run that could not look and a product with no defects are different answers:

• REVIEW_FETCH_FAILED — a URL was given and the fetch returned nothing usable.
• REVIEWS_DATASET_UNREADABLE — a dataset ID was given and could not be opened.

Honest limits

On a free Apify plan the fetch returns at most 10 reviews, from one product URL. That is the review scraper's own limit, not ours, and you will meet it before you meet anything else: ten critical reviews rarely contain three people naming the same fault, so a free-plan run will often return NO_CORROBORATED_DEFECTS on a product that genuinely has a defect. Measured on a real product 2026-08-27: 10 reviews fetched, 5 failure mentions, 5 candidate faults, none reaching even two distinct reviewers. Raise maxReviews on a paid plan, or supply reviews you already have.

It under-reports, and you should know how. Two reviewers are joined into one defect only when they use the same two-word phrase. Measured: "Case hinge snapped in my pocket" and "the hinge on the charging case broke" share no two-word phrase, so they do not cluster — even though both name the hinge. Short sentences are also dropped: "Hinge cracked." is below the length floor and never reaches the clustering step at all.

So a NO_CORROBORATED_DEFECTS result means no defect was named the same way by enough people, which is not the same as no defect existing. Read the reviews yourself before concluding a product is clean. This is deliberate: a defect it missed costs you a second look at the reviews, while one it invented would cost you a decision you cannot take back.

• It does not judge quality, only corroboration. Three people reporting the same fault is a pattern; whether that fault matters is your call, not a number this returns.
• The fetch is done by a separate review-scraper Actor, so its coverage and its limits become this Actor's. If it returns nothing for a product, you get REVIEW_FETCH_FAILED rather than a clean bill of health.
• Clustering uses bigram overlap on failure-language sentences. It finds recurring themes; it does not perform NLP-level semantic understanding of each complaint.

Questions

What review shape does it accept? Objects with the text under text or reviewDescription, the score under rating or ratingScore, plus userId and date. Output from the common Store scrapers works without reshaping.

Should I filter to 1-3 star reviews first? You do not have to, because this Actor does it for you — and you should know that it does. Every review rated 4 or 5 is dropped before any text is read, so a fault mentioned inside a five-star review does not contribute to a cluster and is not counted in criticalReviewsAnalysed. Send everything and the filter runs here; filter first and you only save scraping cost.

Why did it find fewer defects than I expected? See the limits section above; it under- reports on purpose and the reason is mechanical rather than mysterious.

Does it work for multiple products at once? Yes. Reviews are grouped by ASIN before clustering, so a mixed dataset gives you one ledger per product rather than one blend.

Pricing

Pay per event. There are exactly two, and these are the prices the platform charges:

Event	Price	When
defect-cluster-found	$0.015	once per corroborated defect cluster in the ledger
apify-actor-start	$0.00005	once per gigabyte of memory, when the run starts

So a run that finds 5 corroborated defects costs about $0.075 — 5 x $0.015, plus a single start event at $0.00005.

This Actor runs in 256 MB, which is under a gigabyte, so the start event is charged exactly once per run whatever the review count.

When you give a product URL, you pay two publishers. The fetch runs a separate review scraper on your account and its publisher bills you for that run — the default charges about $0.006 per review returned, so 100 critical reviews is roughly $0.60, on top of what this Actor charges. maxReviews caps it. Supplying your own reviews or a dataset ID costs nothing extra, because nothing is fetched.

Filtering happens before you are charged for anything. Dropping the 4-5 star reviews, reading the critical ones and grouping them are all free; the only per-unit charge is a corroborated cluster in your results. So what a run costs follows the number of defects found, not the number of reviews you send: ten thousand reviews producing three clusters cost the same as fifty reviews producing three.

A run that finds nothing charges no defect-cluster-found events at all. Complaints that no one else corroborated are NOT reported at all — they are counted in clustersBelowThreshold and nothing else, because you are paying for the finding rather than for the reading.

That covers every outcome where there is nothing to report, including a run that stops because a dataset ID could not be read. The start event is charged by Apify on every run whatever happens, so a run that finds nothing costs $0.00005 and never more.

apify-actor-start is Apify's own platform event, charged on every pay-per-event Actor rather than added by this one. No per-row event is billed alongside the cluster event, so one unit of work is billed once.

Where the reviews come from

Give it a product URL and it fetches them, using junglee/amazon-reviews-scraper by default — the most used Amazon review scraper on the Store. You can point reviewsScraperActor at a different one if you prefer.

Only the 1-3★ reviews are fetched. A five-star review cannot carry a defect, and fetching one would cost you money for data this discards.

You can also bring your own, from any scraper, a Seller Central export, a helpdesk, or a CSV a colleague sent you: if it has a reviewer id, a date, a rating and the text, this reads it.

The companion to this one is Apify Store Intelligence, which applies the same corroboration-before-conclusion idea to a marketplace rather than a product.

Integrations

An ordinary Apify Actor, so the whole platform works with it: schedule it, call it from the Apify API or the JavaScript and Python clients, wire it into Zapier, Make, n8n, Slack or a webhook, or reach it from an AI agent over MCP. Output is a dataset you can export as JSON, CSV or Excel.

The obvious chain is a review scraper on a schedule feeding this one, so a defect that is newly corroborated reaches you the week it crosses the threshold rather than the quarter. Set it up on the scraper's Integrations tab with reviewsDatasetId = {{resource.defaultDatasetId}}.

Why it never invents a link

Every row can carry a link back to the product, because a defect cluster you cannot trace to a listing is an interesting fact you can do nothing with.

It would be easy to build that link from the ASIN — amazon.com/dp/<asin> — and it would be wrong for every review set that is not from the US store. This Actor never fetches the product page, so it does not know whether your reviews came from .com, .co.uk, .de or .co.jp, and a link that is right most of the time is worse than no link at all: nobody checks the ones that look plausible.

So you supply it, or you leave it blank and the field is null. Guessed and absent are different answers, and this returns the honest one.

Found a problem?

Report it on the Issues tab. Paste the reviews that produced the wrong answer if you can share them; a description of the fault the ledger missed is enough if you cannot.

The most useful report is a real defect this failed to cluster. That is the direction it errs in, and a concrete example is what gets the threshold changed.

Unofficial

Not affiliated with or endorsed by Amazon or Apify. It reads review data you supply and contacts no third-party service.