Buying Web Data: Coverage Audits, Refresh Cadence and Licensing Terms

In People Data Labs' v35.0 release, published 21 July 2026, the work_email field on its resume dataset dropped 6.42 percent against the previous version while github_url rose about 60 percent. Same vendor, same dataset, one version apart. Anyone who bought on the headline record count, which went up, had no way of seeing it.

That is what a coverage number does not tell you. It cannot tell you how much of your population is in there, which fields arrive populated, or how stale a record is by the time it reaches your pipeline. Vendor roundups rank providers without publishing any way to check, so buyers sign on the total and find out afterwards.

What follows is a method: audit coverage against a sample you drew yourself, test freshness against changes you witnessed, diff the schema across two deliveries, then read the four clauses that decide whether a technically good dataset is legally usable. It judges the dataset, not whether the vendor will still exist in three years.

Browse the data providers category for the vendors named here. If you have not yet decided between buying a dataset and collecting it, how to choose a web scraping tool covers the collection side.

Start with the population, not the vendor list

Most bad data purchases start with a vendor demo instead of a definition. Write the population down first, in a form specific enough that two people would build the same list:

• The universe. "US companies" is not a population. "US companies with 50 to 500 employees in NAICS 3345, active in the last 12 months" is.
• The cardinality you expect. If you think there are roughly 18,000 such companies and a provider offers 400,000 "matching" records, one of you is wrong, and it is worth finding out which before money changes hands.
• The fields that make a record useful versus merely present. A company record without a website URL may be useless to you even though it counts toward coverage.
• The decision the data feeds. This sets your freshness requirement more reliably than any vendor conversation. Quarterly board reporting and intraday pricing are not the same purchase.

That definition is what turns a vague coverage claim into a testable one. It also stops you from paying for breadth you will never query. A marketplace listing that spans 250 domains is impressive and irrelevant if your population is one vertical in three countries.

Draw a sample the provider did not choose

The single most common failure in dataset procurement is auditing the vendor's sample file. Sample files are selected, not drawn. They will match at close to 100 percent because they were built from records the provider already has.

Instead, build a ground-truth sample you control:

1. Take 300 to 500 records at random from a source you trust. A CRM export, a government registry, a conference attendee list, or a set of URLs you crawled yourself all work. Random matters more than large.
2. Strip it to match keys only. For company data, a domain is the strongest key. For person data, a profile URL or an email. For job postings, a source URL.
3. Verify a subset by hand. Pull 30 to 50 of those records manually so you have an independent answer for what the correct field values are. This is the part everyone skips and the part that makes the rest meaningful.
4. Send the keys to the provider as an enrichment or match request. Every serious vendor will run a match test during evaluation. If one will not, that is a finding.

Three hundred records is enough to distinguish an 80 percent match rate from a 50 percent match rate with confidence. It is not enough to distinguish 80 from 82, and you do not need to.

Two numbers: match rate and field completeness

Score the return with two separate metrics, because a provider can be strong on one and weak on the other.

Field completeness is where published numbers are genuinely useful, because a few vendors report it. People Data Labs publishes per-field coverage in its changelog. Its v35.0 release, published 21 July 2026 and read here on 27 July 2026, puts the Person API dataset at 2,465,129,875 records and the resume dataset at 814,778,903. The same release shows work_email on the resume dataset declining 6.42 percent to 84,215,498 records, while github_url and github_username each rose 59.46 percent to 1,994,722.

Field coverage is not monotonic, which matters more than any of the absolute numbers. A dataset can grow overall while the one field your product depends on shrinks, usually because the provider dropped a source or tightened a validation rule. If your evaluation is a single snapshot, you will never see this. Ask for the previous version's per-field stats alongside the current one, and treat a provider that cannot produce them as a provider that does not track them.

The shape that buys well here is a large probabilistic person graph you resolve against. It buys badly if you need a small hand-verified list where every row has to be correct, or if your legal position cannot carry the obligations person-level data brings, which the contract section below covers.

Freshness arrives as a distribution of record ages

Vendors quote an interval. What lands in your bucket is a spread of record ages, and the old tail is what hurts.

Test it directly. Pick 20 to 40 records where you know the date something changed, because you watched it happen: a company that announced a funding round three weeks ago, a job posting that closed last Tuesday, a product whose price moved on a date you logged. Then measure how long that change took to appear in the provider's data, and how many of your known changes are still missing.

Two things usually surface:

• Batch lag. The record is refreshed on the stated cadence, but collection starts before delivery. A vendor scheduling a monthly file has to begin crawling early enough to guarantee the delivery date, so a file that arrives on the first of the month can contain records already several weeks old. Ask directly where the collection window sits relative to the delivery date. It is a fair question and a vendor who cannot answer it has not thought about your problem.
• Stale-record floor. Some records simply have not been recrawled in a long time, and the average hides them. Ask whether every record carries a per-record collection timestamp, and make it a condition rather than a preference. A provider that ships without them has made the freshness distribution unmeasurable on your side, which means you cannot run this test at all after the first delivery.

Note also that refresh and delivery are two different clocks, and vendors state them separately. Coresignal's FAQ, read on 27 July 2026, says it fully refreshes most datasets daily, weekly or monthly depending on the scraping speed it can achieve, while most data is delivered monthly, with daily and quarterly deliveries available on specific datasets and real-time access through its APIs. A daily refresh behind a monthly delivery still gets you a monthly view. Oxylabs' dataset page the same day listed monthly, quarterly and one-time delivery on standard datasets, and daily, weekly, monthly, quarterly or custom on custom ones. Cadences on vendor pages change without notice, so confirm yours in a written quote rather than from any third-party page, this one included.

Match the cadence to the decision. Firmographics and headcount move slowly enough that monthly is defensible. Pricing, inventory and job-posting recency do not, and a monthly dataset used for those will be confidently wrong. If your requirement is genuinely sub-daily, you are usually buying an API rather than a dataset, which is a different product with different economics. How scraping API credit pricing works covers that side.

Schema stability across two snapshots

A dataset you buy once is a file. A dataset you subscribe to is a contract with your ETL, and the failure mode is a schema change nobody told you about.

Ask for two deliveries a full cadence apart during evaluation, then diff them:

• Field set. Added fields are harmless. Removed and renamed fields break pipelines silently if you parse permissively.
• Value formats within a field. This is the sneaky one. A pay-period field that starts emitting yearly alongside per year, or a currency field that switches between symbols and ISO codes, keeps its name and passes every null check you have while quietly corrupting anything downstream that groups on it. Diff the distinct values per field, not just the field list.
• Enumerations. Industry codes, seniority levels and country names are where vendors quietly reclassify.
• Record identity. If the primary key is regenerated between deliveries, incremental loading is impossible and you are doing full replaces forever.

Then ask the question almost nobody asks in procurement: does the provider publish release notes with a deprecation window, and how long is that window? People Data Labs publishes a public changelog with per-field record counts and percentage deltas per version, which is the standard to hold others to. Ask every shortlisted vendor for the last two releases in writing. A provider that ships schema changes silently is a provider whose changes you will discover from a broken dashboard.

Delivery mechanics, as documented

The mechanics decide how much integration work sits on your side. Here is what these vendors document publicly, checked 27 July 2026. Treat it as a starting point for your own quote, not as pricing you can rely on.

On the shape of pricing rather than the price: read on 27 July 2026, Bright Data's datasets page advertises up to $0.0025 per record against a $250 minimum order, and discounts subscriptions over one-time purchases rather than the other way around, with monthly delivery marked "Save 80%" against quarterly at 50 percent and biannual at 25 percent. Oxylabs' dataset page the same day listed standard datasets from $400 per month and custom datasets from $800 per month. Those are list prices on vendor marketing pages, they move, and enterprise deals are negotiated off them. The useful signal is structural: per-record pricing rewards a narrow population and punishes a broad one, and a monthly floor means a pilot costs the same as a month of production.

Datarade deserves a specific note because it is the odd one out. It does not produce data. It is a marketplace that brokers between buyers and a large number of third-party providers, so what you get from it is a shortlist, not a dataset. That is genuinely useful when you do not know who sells what in a category, and it is the wrong tool once you already know your population and your schema, because you still have to run this entire audit against whichever provider replies. It also means the SLA, the deletion obligation and the block risk all sit with a counterparty you found through an intermediary. Use it for discovery, then evaluate the provider exactly as if you had found them yourself.

Apify is the buy-versus-build hedge. Its storage documentation, read on 27 July 2026, is worth understanding before you rely on it: named storages are retained indefinitely, while unnamed ones follow your plan's retention period, and on the free plan only your 10 most recent runs are kept, for four months. That is an operational fact rather than a criticism, and it generalises. If you run collection yourself, retention becomes your problem instead of a vendor's, along with proxies, blocks and parser drift. Apify is wrong for a team that wants a finished file and has nobody to own a pipeline. It is right when the schema you need does not exist for sale, which is more often than the marketplaces suggest. See the no-code scrapers category for the broader set.

The contract layer

A dataset that scores well and cannot be used the way you intend is a failed purchase. Four clauses decide this, and none of them are usually in the first draft you are sent.

Redistribution and derived data

Ask, in this order: can you expose individual records to your own customers, can you expose aggregates, and what survives termination. The last one is where deals break. If you train a model or build an index on licensed data, and the contract says derived works must be destroyed on termination, you have bought a dependency rather than an asset. Get an explicit derived-data carve-out in writing. Vendors will often grant it and almost never volunteer it.

Deletion, takedown and subject access

Person-level data carries obligations that follow the data into your systems. European regulators have penalised contact-data vendors over how professional details were collected from social platforms, including a reported CNIL fine against the contact-data company Kaspr in late 2024 covering legal basis, retention and the handling of access requests. We were not able to confirm that decision against the CNIL's own published text while writing this, so treat the specifics as reported rather than settled and check the regulator directly before you rely on it in a legal review.

The buyer-side lesson does not depend on any single case. If a provider is ordered to delete records, your copy is downstream of that obligation, and the contract is the only thing that tells you what happens next. It needs to say what triggers a deletion instruction, what format it arrives in, how quickly you must act, whether deletions propagate into derived aggregates and model training sets, and who answers a data subject who contacts you rather than the vendor. Ask what the provider can prove about provenance for an individual record, because "publicly available" describes a source, not a legal basis.

None of that is legal advice, and your counsel should look at any person-data purchase. It is a list of the questions that make the legal review fast.

Refresh SLA

Cadence in a marketing page is not cadence in a contract. Push for three things: a delivery window with a named consequence for missing it, a minimum delivered record count relative to the previous snapshot, and a maximum record age. The third is the one vendors resist and the one that actually protects you, because it is the only clause that turns "we delivered on time" into "we delivered fresh data on time".

The block clause

Web data is collected from sources that can change their mind, and vendors will point at case law to argue they cannot. The most quoted example is Meta Platforms v. Bright Data in the Northern District of California, reported in early 2024 as going Bright Data's way on the contract claims over logged-off collection of public data. We did not read the docket for this guide, so treat the holding as reported rather than as a settled description of the law, and have counsel read it if it matters to your deal.

Either way, that argument answers a question you are not asking. A favourable ruling on contract claims does not make a source permanently collectable, and it says nothing about whether a particular site will succeed in blocking a particular provider next quarter. Blocking happens on an engineering timescale that no lawsuit comes close to matching. Your contract should assume a source can go dark regardless of who would win an argument about it.

What happens when the provider gets blocked

This is the failure everyone discovers in production. The delivery does not fail. The file arrives on schedule, the row count looks plausible, and the records for one source are three months old.

Three defences, in order of how much they help:

1. Contract. A maximum-record-age clause with a credit attached is the only thing that makes the provider's incentives match yours.
2. Monitoring on your side. Track delivered row count, distinct entity count, and the p50 and p95 of record age per snapshot, per source. Alarm on relative change, not absolute thresholds. This catches the silent version, and it is a day of work.
3. A second source. For data that matters, contract a fallback before you need one. The same reasoning applies here as in running failover across multiple proxy vendors: a single supplier for a critical input is a single point of failure whatever the SLA says.

It also helps to know why sources break in the first place. Why scrapers get blocked and the anti-bot system definition cover the mechanics your provider is fighting on your behalf.

Buy or crawl

The break-even sits with whoever absorbs the maintenance when a target changes, which is rarely the same place the spreadsheet puts it.

Buy when the schema you need already exists, the cadence on offer matches your decision cycle, and the licence permits your end use. All three, not two. A dataset that fails the licence test at a good price is not cheap.

Crawl when your schema is unusual, when you need freshness the market does not sell, or when the data is your product rather than an input to it. In that last case you cannot afford a supplier who can reprice or deprecate you. Running it yourself means owning proxies, blocks and parser drift, which is the subject of most of the rest of this site: the proxy networks and web scraping APIs categories, and the Bright Data vs Oxylabs comparison if you are choosing infrastructure. The 2026 web scraping stack sketches how the pieces fit.

The hybrid is common and sensible: buy the broad base that would take you a year to crawl, collect the narrow slice that is actually differentiating. If you go that route and use a model to extract fields from pages, validating AI-extracted data matters more than usual, because extraction errors and coverage gaps look identical in a dashboard.

A one-week evaluation plan

1. Day 1. Write the population definition and the required-field list. Estimate the expected cardinality independently.
2. Day 1. Draw 300 to 500 random match keys from a source you control. Hand-verify 30 to 50 of them.
3. Day 2. Send the keys to two or three providers as a match test. Ask each for per-record timestamps, the current per-field coverage stats, and the previous version's.
4. Day 3. Score match rate, field completeness, field accuracy against your hand-verified subset, and duplicate rate. Do not let a vendor score their own return.
5. Day 3. Assemble 20 to 40 records with known recent changes. Measure appearance lag and how many are still missing.
6. Day 4. Request two snapshots a cadence apart, or the last two release notes. Diff the field set, the value formats and the enumerations.
7. Day 5. Send legal the four clauses: redistribution, derived data, deletion and subject access, refresh SLA with a maximum record age.
8. Day 5. Decide. If two providers score within a few points on coverage, pick the one with published release notes and a per-record timestamp, because that is the one whose failures you will be able to see.

Bottom line

A coverage claim stays unfalsifiable until you spend the week making it falsifiable, and almost nobody spends the week. The part that gets skipped even by buyers who do run the audit is the negotiation afterwards: most of the effort goes into price per record, when the terms that decide whether the dataset is still useful in a year are the derived-data carve-out and a maximum record age. Argue for those two and let the per-record price go.