Per-Record Pricing: Examples & Companies

What is it

Per-Record Pricing is a billing unit where each data record processed, labeled, or extracted is metered — common in data platforms and web scraping services.

The word “record” does a lot of heavy lifting. In the web data world, a record is one row returned by a structured dataset scrape — a product listing, a company profile, a job posting. In the ML data world, a record is one labeled training example — an annotated image, a preference rating, a conversational turn used for post-training. Both get metered as “records,” but the economics are separated by orders of magnitude: Bright Data charges $2.50 per 1,000 pre-built dataset records — a quarter of a cent each — while a labeled row on Labelbox Annotate burns a full Labelbox Unit at $0.10, roughly 40x more per record before any human-labor component is added.

That gap is the defining tension of per-record pricing. The unit name implies equivalence — one record is one record — but the cost to produce, verify, and deliver those records depends on what they contain and who created them. A table-extracted e-commerce row is an automated pipeline output; a domain-specific annotation for a frontier lab involves a skilled human’s time. The shared billing vocabulary is a useful abstraction for platform generality, but a trap for any buyer who assumes the rates are comparable.

On the spectrum of data-atom billing units, records sit beside per-document pricing and per-page pricing but are smaller and more numerous — thousands to millions per batch, not the tens or hundreds of pages in a typical job. That scale is why per-record billing quotes per 1,000, and why committed tiers with volume discounts are standard at the self-serve end while the highest-complexity labeling end abandons the published rate for sales-quoted contracts.

How it works

The base formula is simple: bill = records × rate_per_record. What varies across the five companies in this cluster is what counts as one record, how the rate changes with volume, and whether records are metered live or negotiated up front as a committed contract.

Unit math: Web scraping — monthly bill = (records / 1,000) × rate_per_1k. Annotation — monthly bill = labeled_rows × $0.10 on Labelbox Starter, where each labeled row burns one Labelbox Unit (LBU) at the $0.10/LBU Annotate rate.

Worked example — web data at scale. A data team runs a monthly pull of 500,000 e-commerce product records from Bright Data’s pre-built datasets at the base rate of $2.50 per 1,000 records. That is $1,250 per month. Bright Data’s refresh-cadence discount then lowers the effective rate by how often the dataset is refreshed: One-time is 0% off, Biannual 25%, Quarterly 50%, and Monthly refresh is 80% off — dropping the rate to $0.50 per 1,000 and the same 500k pull to $250 per month. The discount is the opposite of typical volume pricing: it rewards subscription cadence, not raw batch size.

Worked example — annotation platform. The same 500,000 rows through Labelbox’s Annotate product at $0.10 per LBU (1 LBU per labeled row) costs $50,000 in platform fees before any human-labor component — and the platform fee is often the smaller line item. The sales-quoted Alignerr human-data services that sit on top of the per-LBU meter, plus data-licensing contracts, are where the real spend lives for large ML teams.

Companies using this

Five companies in the corpus list records as a billing unit — two web data platforms (Bright Data, Oxylabs) plus three AI training-data vendors (Scale AI, Labelbox, Snorkel AI). The split illustrates how the same unit name covers two very different product economics — a self-serve per-1k rate card at the web-data end, and sales-quoted enterprise contracts at the frontier-labeling end.

Patterns observed

• Volume discounts come from commitment, not raw scale. Bright Data’s most aggressive per-record discount is unlocked by committing to monthly refresh cadence rather than ordering a larger one-time batch — a cadence-as-discount model that inverts standard usage tiering. Labelbox has the inverse problem: no published commit or volume discount on its self-serve rate, which pushes high-volume teams into sales-quoted enterprise negotiations.

• Success-based metering distinguishes the scraping tier. Oxylabs charges its Web Scraper API on successful results only — 5xx and 6xx system errors are not billed — aligning the per-record meter with delivered value rather than attempted scrapes. Bright Data’s scraper and dataset records are similarly success-shaped: you pay for a delivered row, not a failed fetch.

• Annotation platforms abstract records into a normalized unit. Rather than a flat per-row rate, Labelbox invented the Labelbox Unit (LBU), which converts rows to LBUs at different ratios by product: 60 rows per LBU for Catalog (curation), 1 per LBU for Annotate (labeling), 5 per LBU for Model (evaluation). One meter prices three workloads without exposing three rate cards — but it opens a 60x gap between the cheapest and most expensive use case that surprises teams budgeting off the headline LBU rate.

• Enterprise labeling pricing is entirely sales-quoted. Scale AI publishes no rate card — every intent routes to “book a demo,” and only third-party estimates (roughly $0.02 per image, $0.06 per annotation for self-serve) exist. Annual platform contracts with data volume as a scoping dimension, not a live meter, are the norm at the frontier-labeling end; the opacity is deliberate, so competitors can’t reverse-engineer the margin.

Counterexamples & variants

The most instructive counterexample is Snorkel AI itself, whose pricing thesis is that per-record metering is the wrong unit for its product. Snorkel Flow generates labeled data at scale using programmatic labeling functions — weak supervision that annotates thousands of records automatically from a few rules — so billing per labeled record would perversely penalize the product’s core value: the more efficiently the platform labels, the more records it produces, and a per-record meter would convert that efficiency into a larger bill. Instead Snorkel sells annual platform subscriptions (third-party estimates put entry around $50,000/yr and an AWS Marketplace 12-month contract at $60,000) scoped on users and data volume, decoupling the fee from the per-record output rate — a structure that helped drive ARR from $36.8M to roughly $148M into 2025.

The variant worth examining is the forecasting trap inside Labelbox’s normalized LBU. Because the meter hides three different row-to-LBU ratios behind one headline rate, a team moving from Catalog-heavy curation to production Annotate work sees its bill jump sharply at the same nominal record count — a bill-shock scenario the choosing the right usage metric guide covers for any vendor designing multi-product meters.

The natural competitor to a per-record scraping model is per-GB bandwidth billing, which both Bright Data and Oxylabs also offer on their proxy products (residential from $8→$2.50/GB and $6→$2.50/GB respectively). A team pulling many small, lightweight records may find per-record cheaper; a team retrieving large, media-rich records may find per-GB more predictable. Neither is universally correct — the right meter depends on whether the cost driver is the count of records or the volume of data transferred.

What this means for buyers vs vendors

For buyers

The first question to ask any per-record vendor is what, exactly, one record is. A pre-built dataset row (extraction already done), a successful scraper result, and an approved human-reviewed label are three different products behind one word — so mixing their rates when budgeting produces nonsensical comparisons.

The second question is what discounts require and what the published rate excludes. Bright Data’s steepest discount is a monthly refresh commitment — a spend floor, not a rebate — while Labelbox’s per-LBU rate covers software only, not the sales-quoted Alignerr labor that usually dominates a real annotation bill. Before signing a tier, model the break-even against pay-as-you-go using your actual volume; the usage invoicing and billing cycles guide covers how commitment floors compound with overage in these multi-tier data contracts, and the pricing calculator can sanity-check a per-1k tier against your monthly record count.

For vendors

Per-record pricing works when the cost to serve one record is reasonably uniform, which is why it fits pre-built dataset delivery better than bespoke annotation. Bright Data and Oxylabs can publish a per-record rate because the marginal cost of delivering one more row is predictable; Scale AI and Snorkel AI cannot, because the cost to label one “record” varies enormously by domain, quality level, and labeler skill — so both route to sales-quoted contracts with only third-party estimates in public.

The lesson from Labelbox’s LBU is that a normalized unit can extend a per-record frame across a multi-product platform, but the conversion ratios need to be transparent, not buried in documentation. A 60x cost asymmetry between your cheapest and most expensive use case is a retention risk, not just a technical detail — buyers surprised at invoice time churn. If your per-record rate varies by workload type, surface those variants explicitly on the pricing page. See the introduction to usage-based pricing for how the best-designed per-unit meters handle this kind of complexity.

Explore this theme in the knowledge graph →