provider_error
Updated 2026-09-15
provider_error is the status for a sampled request that failed — a timeout, a rate limit, or an API error — so no answer was produced. It records a measurement failure, not a visibility outcome.
How it is handled
Failed requests are excluded from every rate and reported as a count, because counting them as non-mentions means an outage at a vendor silently reduces your visibility number. A high error share is its own signal: it tells you a cycle is under-sampled and that the rates from it carry more noise than usual, which is worth stating in the report rather than absorbing quietly.
Illustrative cycle (example numbers)
Ninety planned samples return 84 answers and 6 provider errors. Rates are computed over the 84, and the report notes the 6. Had they been counted as misses, the mention rate would fall by roughly seven percent for reasons entirely unrelated to the brand.
Common mistakes
- Silently retrying failures until something returns, which biases sampling toward whatever succeeds.
- Counting errors as zeros, which makes vendor uptime look like a visibility change.
- Hiding the error count from reports, leaving readers unable to judge how solid the cycle was.
Frequently asked questions
- What error share is acceptable?
- Low enough that excluding failures does not reshape the sample — a few percent is routine, a double-digit share means the cycle should be flagged or re-run rather than reported as usual.
- Should failed samples be retried?
- Within the same cycle and with a cap, yes; retrying indefinitely until the result looks normal is sampling bias with extra steps.
