Every vendor in web data claims "business-ready," and we're no exception: it's on our homepage. But a phrase everyone uses and nobody defines is a phrase you can't hold anyone to. So here's our definition, made concrete enough to test against any provider. Including us.
The short version: business-ready data is data your team can act on the day it arrives, with no engineer standing between the delivery and the decision. Getting there means clearing three bars that most "data" quietly fails.
It's not raw HTML
Scraping platforms will happily hand you the page. Status 200, bytes delivered, job done from their side. Then someone on your team opens it.
The price appears in three places (a JSON-LD block, a meta tag, the visible span), and during a sale they disagree: is €89.90 the list price or the markdown? The German storefront writes €1.299,00 while the French one writes 1 299,00 €, so the parse rule that works on one corrupts the other. The product has fourteen colorways, but the page renders only the default; the other thirteen never appear in the HTML you were handed. And the category listing claims 47 pages but silently stops serving results after page 40, so a slice of the catalog never appears anywhere.
None of this is exotic. Across the 252 brand-site assessments we ran this year, the blocker was almost never getting a response. It was getting data you could defend in a pricing meeting. And no two sites fail the same way; real sites differ wildly in how their catalogs can be collected, and the differences aren't visible from the outside.
Here's the distance between raw and ready, on patterns we see weekly:
| Raw fragment | Business-ready row |
|---|---|
| <span class="price">€1.299,00</span> | price: 1299.00, currency: "EUR" |
| Button text: IN DEN WARENKORB | available: true |
| JSON-LD says 89.90, the visible page says 71.92 | list_price: 89.90, sale_price: 71.92, resolution rule documented |
| The same sneaker five times, once per colorway | One deduplicated product row, variants nested under it |
Closing that gap per site, per layout change, indefinitely is exactly the workload teams underestimate. We did the honest math on it in build vs buy.
It's not an alert
Page monitors send you an email: "Something changed on competitor.com/product/4471." That's a to-do item. Someone still clicks through, finds only the current price, digs out last month's spreadsheet to reconstruct what it used to be, and then decides whether any of it matters.
Compare that with a delivered row: sku: 4471, price_was: 249.00, price_now: 199.00, currency: EUR, collected_at on both observations, below_map: true. Nothing to reconstruct. You can filter for every MAP breach this week, join the feed to your own catalog, chart discount depth by brand. The alert tells you to go find out; the row already knows.
Monitors also only watch the pages you pointed them at. A feed built from the whole catalog notices the product that launched yesterday.
It's not a dataset you can't trust
The quietest failure mode in this category is unknown completeness. Say you reprice against a competitor feed that covers 60% of their catalog, and nobody knows that number. Every figure downstream (average discount depth, price position by category, which SKUs undercut yours) is computed over an unknown sample. The missing 40% might be random, or it might be precisely the premium lines whose pages fight collection hardest. From inside the dataset, you can't tell the difference.
It gets worse. Some sites respond to suspected bots with plausible-looking wrong prices instead of a block; we covered that in why web data got expensive. A dump with no validation can't distinguish a real price from a poisoned one. Which is why validation can't be a setup-time step. It has to run on every single delivery.
So what is it?
Four criteria. Each comes with a test you can run yourself.
Structured. The same typed schema on every delivery: prices as decimals, currencies as ISO codes, availability as a boolean, stable product IDs. The test is the second delivery: does the join you wrote against the first one still work, or did a renamed column take down your dashboard?
Validated. Claims are cheap here, so ask what actually runs. On our side, the QA pipeline checks each delivery's row count against the expected catalog size (derived from the site's own sitemaps and category counts), runs field-level checks (null rates, prices out of plausible range, currency consistency), and cross-checks a sample of rows against the live pages. The test for any vendor: ask for the completeness figure on the last delivery and how it was computed. "We scrape everything" isn't a number.
Fresh, on a cadence you can see. Every row carries collected_at, and the collection schedule is agreed per project: daily, weekly, or monthly. The test: sort a delivery by collected_at. You should be able to read the cadence off the data itself rather than take it on faith.
Yours. Exportable to BigQuery, CSV, JSON, or over an API, history included. The test: could you leave tomorrow and keep everything? If walking away means losing your data, you were renting a dashboard, not buying data.
The questions to ask any provider (including us)
- Show me a sample from my actual target sites before I pay anything.
- What's your completeness check against the full catalog, and what number did my last delivery score?
- What happens when a site changes its layout: who notices first, you or me?
- When sale price and list price conflict on the page, what's your resolution rule?
- Can I export everything, history included, into my own warehouse?
- Is freshness stamped on every row, or just claimed in the pitch?
We'd genuinely rather you ask these everywhere, because we've built ours to hold up. There's a sample delivery table on the product page you can inspect right now, schema and all.
And if you'd rather run the test on your own targets than on our examples, that's what the free assessment is for: tell us which sites matter to you, and you'll get back a real, inspectable sample built from those sites before any money changes hands. Judge the definition on your own catalog.