Business Data Scraper: What the Fields Actually Are

Most of the frustration people have with business data tools comes from one mismatch: they expected a field the source never carried.

The tool did what it said. The field was not there. But nobody says which fields are there, so you find out after you have paid.

Here is the honest inventory — what a business data scraper returns, where each field comes from, and what it costs in time or accuracy to get.

Tier one: on the listing

These come directly from the public map listing. They are fast, cheap, and close to always present.

The two that do the most work are the ones people overlook. Review count is the closest thing you get to a size signal without buying firmographic data — a business with 400 reviews is a different prospect from one with 12. Rating tells you what conversation you are walking into. Both come back as numbers, so filtering on them is a comparison rather than another purchase.

Tier two: resolved, not read

These are not on the listing. Something has to go and find them, which is why they cost more and arrive less reliably.

Email address. Map listings do not carry one. To get an email, a run has to visit the business's own website and resolve a contact address from it. This means:

• Businesses with no website usually have no email
• The address you get is often a shared inbox (info@, contact@) rather than a person
• It takes real time per row, which is why enrichment is priced separately

Social profiles. Same mechanism — resolved from the business site's own links, when it has them.

Deliverability. Whether the email you resolved actually accepts mail is a third step again. Worth doing when the list is going to a client; a bounced-out list is worse than a shorter one.

On the SenseCollect API these map to enrich=true (resolve contacts, 17 credits a row) and verify=true (check they are deliverable, 45 credits — and rows that fail the check are dropped and never charged).

Tier three: does not exist publicly

This is the tier that causes the arguments.

Owner or decision-maker names. Listings carry the business, not the person. Any vendor selling you "owner data" derived from map listings is joining against a separate source — a corporate registry, a data broker, a social profile — and inheriting that source's error rate. For small independents the business contact usually is the owner, which is often good enough. For anything larger it is a receptionist.

Employee count and revenue. Not on any public local listing. These come from firmographic vendors with their own coverage gaps, and for local businesses under fifty people the figures are mostly modelled rather than observed.

Business Profile analytics. Impressions, search queries, direction requests, call clicks. Owner-only, behind a login. No public API returns them.

Email open rates, tech stack, funding. Different sources entirely. Some are real products; none of them come from a business listing.

If a tool claims to deliver tier three from map data alone, that is the claim to interrogate.

The unified record

The other thing worth asking about a business data scraper is what shape the answer comes in. Most return whatever the source happened to give, which means every source you add is another parser.

The SenseCollect record is the same across every source:

{  "id": "ChIJ0xT4…",  "type": "place",  "source": "google_maps",  "title": "Mitte Dental Studio",  "url": "https://maps.google.com/…",  "content": "Dentist",  "published_at": null,  "author": { "name": "", "handle": "", "url": "" },  "contact": { "phone": "", "email": "", "website": "" },  "location": { "address": "" },  "metrics": { "rating": 4.6, "reviews": 42 },  "raw": {}}

Fields a source cannot fill come back empty rather than missing. That single decision is what lets one parser handle every source — your code never branches on which one answered, and adding a source does not mean adding a code path.

raw carries every original field untouched, so nothing is lost by the normalisation. If you need something the flat shape does not model, it is in there.

What this costs

Per row returned, rather than per call:

A call that returns nothing costs nothing, and a run that fails refunds itself. The range reflects which credit pack you are on.

Picking the right depth

Most people default to the deepest option and overpay for a list they end up filtering down anyway.

Use listing-only when you are sizing a market, mapping competitors, or deciding whether a niche is worth working at all. You need names and counts, not contacts, and it costs half as much.

Use enrichment when the list is going into outreach and you need a way to reach each row.

Use verification when the list is going to a client, or when your sending domain's reputation is the thing at risk. Paying 45 credits for a row that is definitely reachable beats paying 17 for one that bounces.

Where to start

Run a small, narrow query first — one business type, one city, forty rows. That costs a fraction of a cent and tells you whether the fields match what you assumed before you commit to a market's worth.

• Local business leads — the lead-list version of this, with qualification advice
• Export Google Maps business data — the call, end to end
• Lead lists by niche and city — the same call with the parameters already filled in