Use case · lead lists
Build a list of businesses in a place, and keep the proof of where each row came from.
You supply the search terms and the places to run them in. What comes back is one row per business — name, address, phone, website, category, rating — and beside every value, the record of where it came from.
The shape of the job
before anything else
- You give it
- Keywords × locations
- You get back
- One row per business
- Not collected
- Email addresses
A list a person can then check, rather than one they have to take on trust.
- 01Agencies running lead research for a client.
- 02Sales operations building a territory list.
- 03Market and location research.
One row per business, not one row per page.
A listing becomes a record, and sixteen columns come out of it. Fourteen hold something the source stated. Two are marked, because they arrive empty from this source — one that never carries a value, one that never yet has.
- 01Name
- 02Domain
- 03Website
- 04Phone
- 05Languagenever filled from this source
- 06Descriptionempty in every row measured
- 07Category
- 08Address
- 09Latitude
- 10Longitude
- 11Rating
- 12Review count
- 13Opening hours
- 14Listing URL
- 15Place ID
- 16CID
Google Maps is the source for this job. Web pages and whole sites are collected by other connectors, through the same boundary and into the same record shape.
Two identifiers, kept apart
Both are kept, in their own columns
Place ID
The token beginning ChIJ that the Places API takes.
CID
The number in a maps.google.com link to the same listing.
Storing one under the other's name gives you a column of values the API refuses. They are separate fields here for that reason.
Google Maps does not give email addresses.
The engine's result columns are a closed list, and no email is among them. So the export has no Email column — and no empty one either.
Two fields, and only one of them exists
nothing is inferred
A column that is blank in every row is a promise the file cannot keep.
What this produces is business records: a company, its address, its published number. It is not a file of personal contact details about named individuals, and it is not built to become one.
The work is in the parts nobody advertises.
A list is usable when it has no repeats, opens cleanly, and can answer a question about any single row.
One business, one row, however often you collect
Identity comes from the source's own identifier for the listing, with the connector's name attached. Run the same area again next month and the existing record is updated rather than duplicated.
The connector's name is part of the key because two directories can use the same number for two unrelated businesses, and merging those would be a false merge with nothing to signal it happened.
It opens in Excel without rewriting your numbers
Every cell in a workbook is written as text. A number that starts with a plus is a phone number, and the file states that rather than leaving a spreadsheet to guess at arithmetic it cannot do.
Cells that a spreadsheet would read as a formula are neutralised first, so text collected from the public web cannot execute when the file is opened.
CSV
The records your filters selected, and no more than those.
Excel
The same rows as a workbook, every cell written as text.
Evidence CSV
One row per stored piece of evidence, rather than one per business.
Excel + evidence
Two sheets, Records and Evidence, joined on Record ID.
An export covers exactly what your filters selected — not the page you are looking at, and not the whole workspace.
“Where did this come from?”
The question comes from a client, a colleague, or whoever reviews the file later. The answer travels with it, in these nine columns.
- 01Record ID
- 02Company
- 03Field
- 04Stored value
- 05As observed
- 06Connector
- 07Connector version
- 08Source
- 09Observed at
Evidence is per field, never per record. A phone read from one observation and a category read from another are two separate rows, each naming its own connector, version, source and time.
“As observed” is what the source printed before it was normalised. It is legitimately blank where nothing distinct was stored, and is never reconstructed from the stored value — an invented original is worse than an absent one.
How the two halves are kept apart is in where every value came from.
A list of that size takes days, not minutes.
The engine collects one search at a time. Everything about planning a large list follows from that one number.
- One search
- ≈ 35 seconds
- 100 keywords × 100 locations
- 10,000 searches
- That plan, end to end
- ≈ 4 days
A campaign is a named plan — keywords by locations — that expands into many jobs and works through them on its own. One job takes at most ten searches, so a plan of that size cannot be a single job.
The work list is a table rather than a variable in a running process, because four days spans a restart. Pause it, deploy, come back: it resumes where it stopped.
A row does not record which search found it. The address on the record is the listing's own, which is the location you can rely on.
This installation holds a few hundred businesses. That is real data, collected through the path described above, and it is a small amount — what has been checked, and what none of it proves.
Request access.
Accounts here are created by hand, one at a time. There is no self-service registration, so asking is the only action this page offers.