Every scraper listing says which fields it returns. Almost none says how often those fields have anything in them — which is the only number that decides whether the pipeline you are planning will work.
A field list is not a measurement
“Returns business email” is true if one business in the sample had an email. It is also true if all of them did. Those are completely different products and the sentence cannot distinguish them.
The measured answer for Nextdoor is 62.6% over 741 businesses. If you were planning an email-first campaign, that single number changes your row count by a third — and you would rather learn it from documentation than from a half-built sequence.
The correction
The Nextdoor Actor's first fill-rate table was measured on 30 businesses. It looked good. When the sample grew to 741 across 5 cities and 12 categories, several fields came out lower — opening hours most sharply:
| Field | n = 30 | n = 741 |
|---|---|---|
hours_open_status | ~77% | 57.4% |
The published table is the second one. The first is not quietly gone either — the correction is recorded in the README and on the methodology page, because a number that changes without a trace is indistinguishable from a number that was made up.
Why small samples flatter
Two mechanisms, and the second is the one that catches people who know about the first.
Variance. Thirty rows put a wide confidence interval around any percentage. A true rate of 57% will show up as 77% often enough that you will believe it once.
Selection. More important and less obvious. A first sample is usually one city and one or two categories — and it is usually a category the developer chose because it looked healthy. Dentists in an affluent coastal town maintain their opening hours far better than landscapers in a small inland one. The variance shrinks with more rows; the selection bias does not shrink at all until you cross cities and categories.
Which is why the sample is described as “741 businesses across 5 cities and 12 categories” rather than just “741 businesses”. The breadth is the part that makes it credible.
“Not promised” as a first-class statement
Both Actors' documentation says the same thing after the fill-rate table: anything not listed here is not promised. That is stronger than silence, and it is deliberately stronger.
Silence lets a reader assume. An explicit refusal to promise tells them a field may appear, may be useful, and must not be depended on — which is exactly the state of most fields on most scraped sources, and almost never stated.
When to omit a field entirely
Sometimes the right answer is not a low percentage but no entry at all. On coches.net, two fields were measured and left out of the documented schema:
- Video links — 20.9%.
- The featured flag — 17.5%.
Below roughly a quarter, a field creates more work than it saves: a pipeline that handles it has to handle the missing case on four rows out of five, and a pipeline that ignores it has a column of mostly-nulls in a warehouse forever. Listing it as “available” would be technically true and practically misleading.
How to measure your own
You do not need the developer's numbers. Run the smallest job the Actor allows — cents, under per-event pricing — and count:
SELECT
COUNT(*) AS rows,
ROUND(100.0 * COUNT(phone_number) / COUNT(*), 1) AS phone_pct,
ROUND(100.0 * COUNT(email) / COUNT(*), 1) AS email_pct,
ROUND(100.0 * COUNT(website_url) / COUNT(*), 1) AS website_pct
FROM businesses;Do it across at least two cities and two categories, because that is where the selection bias lives. The documented figures are an average over a mixed sample; yours will differ, and yours is the one your pipeline has to survive.
