Why did this complaint count go up?

If the result cannot point back to the source review, a product or support team has to search the raw text again. This tutorial uses a deliberately small synthetic apparel example to show a more auditable output contract: every aggregate keeps review IDs and exact evidence quotes.

Fastest key-free check

If you already have two authorized English reviews, open the public Apify Actor input form, keep mode set to rules, and paste this input:

{
  "mode": "rules",
  "reviews": [
    {"id": "check-1", "product": "Demo shirt", "text": "Too small across the shoulders."},
    {"id": "check-2", "product": "Demo shirt", "text": "Not too small. Fits perfectly."}
  ]
}

This key-free check should preserve the first sentence as evidence and avoid counting the negated second sentence as a sizing complaint. Download the dataset, complete OUTPUT JSON, or REPORT.csv from the run results. Rules mode is only a narrow diagnostic, not full semantic analysis. A successfully completed report still costs $0.03; no TokenHub key or model fee is needed for this rules check. Apify currently labels the launch button Try for free; that label opens the console and is not a price promise. Review the current Store pricing before running.

1. Start with a narrow input contract

Use supplied, authorized review text rather than mixing collection and analysis into one opaque step. A minimal input can look like this:

{
  "mode": "rules",
  "reviews": [
    {
      "id": "demo-1",
      "product": "Demo shirt",
      "text": "Too small across the shoulders.",
      "rating": 2
    },
    {
      "id": "demo-2",
      "product": "Demo shirt",
      "text": "Not too small. Fits perfectly.",
      "rating": 5
    }
  ]
}

Both reviews are synthetic. The second one is important because a keyword-only counter may classify small as a complaint even though the sentence negates it.

2. Make the aggregate traceable

For this input, the expected small-sizing aggregate is one mention across two reviews, or a share of 0.5. The output should retain the evidence that produced the count:

{
  "product": "Demo shirt",
  "topic": "size_small",
  "mentions": 1,
  "shareOfReviews": 0.5,
  "trend": "insufficient_data",
  "evidence": [
    {
      "reviewId": "demo-1",
      "quote": "Too small across the shoulders.",
      "rating": 2
    }
  ]
}

This structure lets a reviewer inspect the claim without trusting the aggregate blindly. It also makes false positives easier to debug: if demo-2 appears in the evidence array, the negation rule or semantic classifier needs attention.

What a buyer actually gets

The useful output is not six counters. It is a short decision-support trail: the main recurring problems, the exact customer quotes behind them, and clearly labeled questions for a human to verify next. For example, a shoulder-fit complaint can prompt a size-chart measurement check; a seam failure can prompt a retained-sample wash test. Those are investigation hypotheses, not proven causes or promised improvements.

3. Separate evidence from confidence

An exact quote proves that the report copied text from a specific review. It does not prove that the topic classification is correct. That distinction should remain visible in both the schema and the documentation.

A practical report can keep these fields separate:

• topic: the assigned issue category
• mentions: the number of unique reviews assigned to it
• shareOfReviews: mentions divided by the product's reviewed-item count
• evidence: source review IDs and quotes
• trend: a cautious comparison only when both time windows have enough dated reviews

For tiny samples, insufficient_data is more honest than a dramatic trend label.

4. Export defensively

CSV exports are often opened in spreadsheet software. Prefix cells that begin with =, +, -, or @ so untrusted review text is not interpreted as a formula. Also deduplicate review IDs and cap input size before analysis; otherwise one repeated review can inflate both counts and model cost.

5. State the operating boundary

The implementation I built accepts up to 100 unique reviews and 30,000 unique text characters. It does not scrape reviews or fetch arbitrary URLs. Its rules mode is a limited diagnostic, not a substitute for broad semantic understanding. Semantic mode requires the customer's Tencent TokenHub key, which is a real setup trade-off rather than something to hide.

The public Apify Actor is here: https://apify.com/davidlee2026/my-actor

It charges $0.03 per successfully completed report, including Apify platform costs. Rules mode does not need a model key, but the successful report is still charged. Semantic mode separately uses the customer's TokenHub account and may incur that provider's model fees.

Public availability and technical tests do not prove customer demand, classification accuracy, or profitability. The useful design lesson is narrower: keep every aggregate close enough to its source evidence that a human can challenge it.

If you maintain review-analysis pipelines, I would be interested in the failure case you find hardest to audit: negation, mixed opinions in one sentence, product variants, or time-window comparisons?