Review a sudden spike in negative reviews

Compare a bounded low-rating window with a verified baseline, identify concentrated sellers or listings, and return evidence for a human incident decision.

Updated July 10, 2026 · published May 16, 2026

difficulty intermediate · time to value 10 minutes · execution human review required

Review low-rating review_submitted events from the last 15 minutes against the prior seven-day baseline. Show the sample size, multiplier, affected sellers or listings, and recent deploy context. Do not message anyone or change listing state.

Why this matters

A burst of one- and two-star reviews can indicate coordinated abuse, a seller quality problem, or a product regression. The multiplier alone is not enough: a change from one review to three looks dramatic but may be noise. A useful review includes the absolute count, historical baseline, concentration, sample window, and nearby deploys.

Run the review

First prove the telemetry exists:

GET /v1/projects/:project_id/event-names
GET /v1/projects/:project_id/event-property-keys?events=review_submitted
GET /v1/projects/:project_id/onboarding
# Require status: "verified"; use live event/property reads for the selected signals.

If review_submitted.rating is missing or partial, report that gap instead of calculating a rate. Otherwise, in the interactive owner session, fetch the filtered schema for POST /v1/projects/:project_id/analytics/query and run a bounded custom analysis that returns:

low-rating count for the current 15-minute window;
comparable 15-minute buckets across the prior seven days;
median and upper-percentile baseline, not only an average;
counts by seller_id and listing_id with minimum sample sizes;
recent deploys that overlap the start of the spike.

Do not include full review text by default. If text is needed to distinguish abuse from a fulfillment failure, sample the minimum necessary rows and keep them in the owner-controlled session.

Output format

Negative-review review — <UTC window>

Current low ratings: <count>
Historical median per 15m: <count>
Historical p95 per 15m: <count>
Multiplier vs median: <value>
Evidence quality: <answerable | partial | missing>

Concentration
- <seller/listing> — <count> — <share> — <minimum sample met?>

Possible explanations
- <hypothesis> — <supporting evidence> — <contradicting evidence>

Human decisions
- investigate abuse / fulfillment / deploy regression / keep observing

A human decides whether to contact support, pause a listing, roll back a release, or share the report. This workflow grants none of those actions.

Instrumentation

Send review creation from the trusted application server:

await fetch("https://api.agentry.sh/v1/analytics/", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.AGENTRY_SERVER_API_KEY}`,
    "Content-Type": "application/json",
    "User-Agent": "marketplace/1.0",
  },
  body: JSON.stringify({
    event: "review_submitted",
    distinct_id: reviewer.id,
    properties: {
      rating: review.rating,
      seller_id: review.seller_id,
      listing_id: review.listing_id,
    },
  }),
});

Unattended boundary

No current versioned automation template grants generic HogQL, raw review access, messaging, or listing mutation. Keep this analysis on demand until a narrow immutable server-owned source and matching policy exist.

Variations

“Compare low-rating concentration by seller tenure.”
“Cross-reference the spike with disputes and fulfillment failures.”
“Compare the first hour after the latest deploy with its prior-period baseline.”
“Draft an incident summary for a trust lead to review; do not send it.”

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access

5.5 Extra High

1. Open your repo in Codex, Claude Code, Cursor etc.
2. Paste the install prompt.
3. Your agent reads the install doc and shows you an implementation plan for approval.