Two customers ordering the same dish from the same restaurant pay different totals depending on where they stand. For anybody analysing delivery economics, that variation is not noise to be averaged away — it is the subject.
The source is named because it is public; the client is not. Every figure on this page is a measured production number the client agreed to publish. Have a source of your own? Send it over, whatever its size — you get an answer within 24 hours.
menu-item records since 2024
a year
measured coverage
merchants tracked
Not more rows. Every one of these projects started with somebody who already had data and could not use it for the decision in front of them.
The problem
The client analyses the economics of delivery for investors and operators, which means the questions are about margin: what does the platform take, how does it vary by distance and basket, and how has it moved. None of that is answerable from menu prices, and menu prices were what everybody in the category was selling.
Fixed on day one
Every one of these is measured continuously and reported on the same dashboard the client watches. A commitment nobody measures is a sentence in a proposal.
None of these is solved by better headers or a bigger proxy pool. Each needs a different piece of engineering, and working out which one you are actually facing is most of the job.
Delivery fee, service fee and minimums all vary with distance, basket and time, so a single observation per merchant describes one customer out of thousands.
What we doThe fee stack is sampled at several basket sizes from several grid points per merchant, so the client sees the surface rather than a point on it.
A denser grid finds more merchants and resolves fee variation better, and costs proportionally more. Both under- and over-building are invisible from inside the data.
What we doDensity is derived per market by measuring what a finer grid would have added, and tightened only where the marginal point still finds something.
Chains change quarterly, independents weekly, and availability hourly. One refresh cadence is either wasteful or wrong.
What we doPer-merchant refresh cadence derived from observed change rate, with promotion when a merchant starts moving.
Coverage measured by sampling the grid you built is circular, and it is how most geographic datasets overstate themselves.
What we doThe recount samples addresses deliberately outside the grid and asks whether what they see is already known. That discrepancy is the published coverage number.
The architecture is not interesting; every extraction system has a queue, a fetcher and a parser. These are the decisions that made this one work where the last one did not.
Several basket sizes from several points per merchant, so the client can model how the take varies rather than reading a single total.
For each market we test whether a finer grid finds anything new, and stop when it does not. This is the difference between a defensible national figure and an expensive guess.
Cadence per merchant follows how fast that merchant actually moves, with automatic promotion when it starts changing.
Coverage is measured from addresses that are not part of the collection grid. Measuring your own grid against itself is the most common self-deception in geographic data.
The same restaurant seen from twelve grid points is one merchant with twelve fee observations, not twelve rows to deduplicate later.
Production figures, not a benchmark run. Coverage is recounted daily against an independent sample of the live source rather than asserted, which is why the numbers are not round.
Daily profile
Thirty-four million item records a day is 1.0 billion a month, 12 billion a year and 23 billion since 2024, from 1.5 million requests — seventeen a second — because a menu page returns the whole menu at once. The off-grid discrepancy is the only number here that can embarrass us, which is exactly why it is the one we publish: everything else can be made to look good by choosing the measurement.
Headline
These four sit in the support agreement. When one of them drifts outside its band, we are alerted within fifteen minutes and fixing it is routine work under the monthly arrangement, not a change request.
The columns are the client's own numbers from before the rebuild and the measured ones from production today. The left column is the part most vendors would rather not put on a page.
| Metric | Before | Today |
|---|---|---|
Economics visible |
Menu prices only | Full fee stack, sampled |
Geographic basis |
A merchant list | A measured address grid |
Fee variation |
Invisible | Modelled across distance and basket |
Coverage claim |
Asserted | Measured from outside the grid |
The client's first published analysis of platform take rate was picked up widely. The methodology section, which explained the grid and the off-grid recount, is why it survived scrutiny.
One case file per source, each opening the same way: what the client needed, what the source put in the way, how the pipeline is built and what the numbers are today.
420k vehicles, availability by the hour
Read the case →
Half a million events on sale, priced continuously
Read the case →
135M properties, and the whole live market daily
Read the case →
1.6M properties, 120M rate quotes a day
Read the case →
A 180M-SKU competitive catalogue, swept weekly
Read the case →
Start here
Send the source, the fields you need and roughly how often. You get a straight answer within 24 hours: whether it can be done, what makes it hard, what coverage is achievable and roughly what it costs to build and to run. Whatever the size.
Direct
NDA before technical detail, as always. If it isn't our kind of work, we say so in the first reply.