The Pricing Team’s First Data Vendor: A One-Page Due Diligence

Pricing teams are expert buyers of software and naive buyers of data — and the difference shows in the first vendor conversation, where questions about UI go unanswered in place of questions that matter (license, freshness, delivery, schema). If your team is hiring its first external data vendor for competitor price monitoring, this is the one-page due diligence to walk in with: eight questions, what good answers sound like, and the red flags that end evaluations early.

Before the Questions: Name Your Workload

“Track competitor prices” is three workloads wearing one phrase, and vendors price them differently:

The evaluation fails most often when a team shopping for workload #1 accepts pricing for workload #2. Write down which one you need before the first call — and note that most pricing teams need #1 with occasional #3.

The Eight Questions

1. “What fields ship per record, and is the schema documented?”
Good answer: price, currency, availability/seller, timestamp, product identifier, URL — documented, with a schema-stability policy. Red flag: “we can send you whatever you need,” which means no schema.

2. “How fresh, exactly?”
Good answer: cadence per dataset (daily/hourly where it matters), record-level timestamps, scheduled delivery. Red flag: “regularly updated.” A pricing model keyed to yesterday’s competitor moves is a lagging indicator wearing a dashboard.

3. “How does data get to us?”
Good answer: delivery to your S3 bucket or API pull, in JSON/CSV/Parquet, on a schedule you control. Red flag: “our platform” — a portal your analysts log into manually is 2015’s delivery model priced at 2026 rates.

4. “What’s the license, per record?”
Good answer: commercial use named, scope attached to the data structure or contract, provenance documented. Red flag: anything requiring three meetings to answer. This question is also where “we scraped it ourselves” answers disqualify themselves.

5. “Can we see a sample first?”
Good answer: sample fields downloadable before any commitment. Every serious vendor — Thordata’s sample-first flow is the category norm worth demanding — lets you inspect before you buy. Red flag: sample “after the pilot agreement.”

6. “What’s covered, and what happens when a target isn’t?”
Good answer: a catalog of pre-built targets (Thordata’s covers 120+ including the major marketplaces), plus a collection path for gaps — Scraper API at roughly $0.50–$1.00 per 1,000 delivered results, residential collection from $0.65–$2.00/GB at volume. Red flag: “we cover everything,” unpriced.

7. “How do failures bill?”
Good answer: per delivered result — a blocked attempt costs you nothing, retries are the vendor’s problem. This single pricing property determines whether your monitoring cost is predictable (data delivered) or variable (attempts made).

8. “What does our exact volume cost?”
Good answer: a number, from published rates — e.g., catalog datasets from about $0.25 per 1,000 records, a two-million-record-per-month monitoring feed priced per record at volume, no discovery call required to learn the ballpark. Red flag: “depends on your needs” before any needs were stated.

Scoring the Answers

Three of the eight are pass/fail: license (#4), sample-first (#5), and failure billing (#7). Fail any one and the evaluation is over regardless of the other five — these are the properties that separate data products from data promises. The remaining five rank vendors: schema and freshness quality, delivery mechanics, coverage-plus-gaps pricing, and price transparency.

Run the same eight against every candidate — including the “we’ll build it ourselves” option your team will quietly propose, which scores zero on #3 (you become the delivery mechanism), #5 (your sample is a prototype), and #4 (you’re the counterparty on your own license risk).

The Question That Comes After You Buy

Pricing teams that buy competitor data well almost immediately ask a second question: *what does the market see?* A price is half the picture; where products surface — in search, in shopping placements, in the comparisons buyers actually read — is the other half. That’s a retrieval workload, not a scraping one: structured SERP records per market per keyword, on a schedule. The SERP monitoring solution delivers it at roughly $0.70 per 1,000 structured responses, and running continuous SERP data crawling alongside your price feed turns “competitor cut prices” into “competitor cut prices *and* moved up two positions” — which is the difference between a data alert and a decision.

FAQ

What’s a realistic first-year budget for a mid-size pricing team?
For named-competitor monitoring across a few hundred SKUs plus quarterly market snapshots: hundreds per month at published per-record rates, not the enterprise quotes first-time buyers brace for. The expensive version of pricing intelligence is the wrong-workload version — buying snapshots when you needed feeds, or feeds when you needed one snapshot.

Should the pricing team run the vendor or should data engineering?
The pricing team should own questions 1, 2, and 8 (the workloads and the money); data engineering owns 3, 6, and 7 (the plumbing); legal owns 4. The one-page format exists so all three owners can score one document instead of attending one death-by-meeting.

How do we evaluate data quality before trusting it?
The audit that works: pull your own top-20 SKUs manually, once, and compare against the vendor’s records for the same window. One afternoon, and it catches the classic failure — plausible-looking prices that lag reality — better than any reference call.

Where does this leave “build vs buy” for pricing data?
Rebuilt spreadsheet, same conclusion: per-delivered-result pricing plus per-record catalogs versus your engineering queue — and for the search half of the picture, per-response pricing through SERP monitoring versus building the most-defended-page scraper in the world. Bring the eight questions to every conversation, including the internal one.