# Pricing Models for Data Products
In 2015, Dun & Bradstreet sold the same corporate credit data to a small lender for $12,000 a year and to a global bank for $4 million. Same underlying database. Same refresh cadence. A 300x spread. That gap is not a pricing accident — it is the entire discipline. The CDO who understands why that spread exists, and how to engineer it deliberately, captures value that the CDO who publishes a flat rate card leaves on the table.
You already know how to build a data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → and stand up a monetization function. This lesson is about the decision that determines whether that function generates $2M or $20M from the identical asset: how you price.
Every data product pricing model is a bet about where value is created and how the customer experiences cost. There are four archetypes, and each one optimizes for a different thing.
Subscription (fixed periodic fee). You optimize for revenue predictability and low friction. The customer pays a flat fee — monthly or annually — for access. Bloomberg Terminal is the canonical example: ~$32,000 per seat per year, no metering, unlimited queries. Subscription works when consumption is continuous and hard to meter cleanly, and when the buyer values budget certainty over paying-for-what-they-use. The danger: you either underprice your power users (who'd pay 5x) or overprice your light users (who churn).
Usage-based (pay per unit consumed). You optimize for adoption and alignment. The customer pays per APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → call, per record, per query, per GB. Snowflake built a $70B business on this: you pay for compute-seconds consumed. Usage pricing removes the adoption barrier — a new team can start at $200/month and scale — and it aligns your revenue with the customer's realized value. The danger is the flip side of that virtue: revenue is volatile, and customers experience "bill shock" and start rationing usage, which throttles the very adoption you wanted.
Value-based (price tied to customer outcome). You optimize for value capture. You price against what the data is *worth* to the customer, not what it costs you to produce. The D&B example above is pure value-based pricing — the bank pays more because the same data protects a larger loan book. This is where the money is, but it demands that you can (a) segment customers by the value they extract and (b) defend the segmentationsegmentationDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition → without it feeling arbitrary or extractive.
Freemium (free tier plus paid conversion). You optimize for top-of-funnelfunnelThe customer journey from awareness to purchase, typically Awareness, Interest, Consideration, Decision, Action, with prospects narrowing at each stage.View full definition → and land-and-expand. A free tier drives adoption and creates a data-network or habit effect; a paid tier monetizes the users who hit a limit. This is a distribution strategy disguised as a pricing model. It only works if the free tier is genuinely useful AND there is a natural, non-punitive wall that heavy users hit.
The rookie mistake is treating this as a multiple-choice question. Sophisticated data products stack models along the customer lifecyclecustomer lifecycleThe full sequence of touchpoints a customer has with your brand before, during and after purchase, spanning awareness, consideration, decision, retention and advocacy.View full definition →. Freemium acquires. Usage-based scales the account through early growth. Then, at a certain spend threshold, you convert the customer to a value-based committed contract that both smooths your revenue and captures the premium. Snowflake does exactly this: consumption pricing for entry, then "capacity commitments" — pre-purchased, discounted credits that convert volatile usage into predictable, contracted revenue.
Your job as CDO is not to pick a model. It's to design the transition points between models.
When a product manager brings you a pricing proposal on Monday, run it through four axes before you approve anything.
Ask: how directly does the customer connect *your data* to *their money*?
If the linkage is tight and quantifiable — a fraud-scoring feed that a lender can literally attribute to reduced charge-offs — you have earned the right to value-based pricing. If the linkage is diffuse — a market-intelligence dataset that informs strategy in ways no one can isolate — the customer will resist value-based framing, and you're pushed toward subscription or usage.
The practical test: can you build an ROI model the customer will accept? If your sales engineer can sit with the buyer and jointly build a spreadsheet showing "$X saved per Y consumed," value-based is on the table. If that spreadsheet requires heroic assumptions, don't fight it — meter the usage instead.
Chart the actual usage telemetry from your beta customers. (You instrumented the product; use the data.)
A CDO at a logistics data firm I advised discovered their "flat subscription" customers had a 40x usage spread between the 10th and 90th percentile. They were massively underpricing the top decile. The telemetry made the case for a hybrid model in about ten minutes.
Data products famously have near-zero marginal cost — but "near-zero" is doing a lot of work in that sentence. If your product runs expensive real-time inference or streams high-volume data through cloud egress, your marginal cost is real and usage-based pricing must at minimum cover it. Model your cost-to-serve per unit explicitly. Freemium in particular dies when a "free" user with unlimited APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → access generates $8,000/month in your compute bill.
Buyers don't evaluate your price in a vacuum; they anchor to whatever they're already paying for something adjacent. If every competitor sells per-seat subscriptions, a usage-based model forces the buyer to do unfamiliar math — sometimes a differentiator, often a friction. Know the reference price and decide deliberately whether to match the mental model or deliberately break it.
Choosing a model is 40% of the work. The other 60% is designing the mechanics so the model doesn't quietly destroy adoption.
The single most consequential decision is your pricing metric — the unit you charge against. The rule: the metric should scale with the *value the customer receives*, not with the *cost you incur*.
Charging per APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → call is a cost metric — it tracks your infrastructure, not the customer's benefit. Charging per "verified identity" or per "qualified lead delivered" is a value metric — it tracks outcomes. When the metric tracks value, the customer's bill grows only as their success grows, and price objections evaporate because paying more means getting more.
A classic failure: an enrichment APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → priced per record processed. Customers responded by aggressively pre-filtering records to minimize matches — degrading their own outcomes to lower their bill. The metric had put the vendor and customer in opposition. Repricing to "per successful enrichment" flipped the incentive and lifted both usage and revenue.
In value-based and freemium models you need fences — legitimate, defensible reasons different segmentssegmentsDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition → pay different prices. Good fences feel fair; bad fences feel like punishment.
Defensible fences:
Notice that use-case licensing is how you legally capture the 300x spread: the bank isn't paying more for more data, it's paying more for the *right to embed the data in a product that generates more value*. Structure your contract terms as a pricing lever, not an afterthought handed to legal.
The most expensive pricing mistake is optimizing for value capture so aggressively that you kill the adoption that would have generated far more value over time. Three specific defenses:
Cap the downside for the customer, not for yourself. Usage-based pricing terrifies buyers because the bill is unbounded. Offer a spend cap or predictable ceiling — "pay per use, but never more than $X/month." You remove the fear that suppresses adoption while keeping the upside alignment.
Never punish the behavior you want. If you want data explored, don't meter exploration. Meter production consumption. Make sandbox and development usage free or heavily discounted so teams build against your product before anyone worries about the bill.
Grandfather aggressively when you raise prices. Your early adopters are your reference customers and your case studies. Repricing them punitively torches the trust you need for the value-based conversations that actually move the needle.
Here's a clean tiered structure that encodes several of these principles — a hybrid freemium/usage/commitment model:
pricing_tiers:
free:
monthly_calls: 5000
latency: batch_daily
redistribution: false
price_usd: 0
growth:
monthly_calls: metered # $0.02 per successful enrichment
latency: realtime
redistribution: false
spend_cap_usd: 2000 # defuses bill-shock
price_usd: usage
enterprise:
monthly_calls: unlimited
latency: realtime
redistribution: true # the value fence that unlocks premium
sla: "99.9%"
price_usd: negotiated # value-based, committed annualNote what the config encodes: a value metric (*successful enrichment*, not raw calls), a spend cap that removes the adoption fear, and the redistribution flag that fences the enterprise premium. The tiers are the *transition points* between models made concrete.
Knowledge check
1. The lesson opens with the same corporate credit data sold for radically different prices to a small lender versus a global bank. What core principle does this illustrate?
2. A data product has continuous, always-on consumption that is difficult to meter cleanly, and its buyers strongly value budget certainty. Which pricing model best fits, and what is its principal risk?
3. Why does usage-based pricing tend to 'align your revenue with the customer's realized value' better than a flat subscription?
4. Select ALL correct answers about the trade-offs of usage-based pricing.
Select all the correct answers.
5. Select ALL correct answers about how a CDO should reason when choosing a pricing model for a data product.
Select all the correct answers.
Pricing is not a launch decision; it's an ongoing discipline, and this is where the CDO's ownership matters most. Three governance practices separate mature data-product organizations from the ones perpetually leaving money on the table.
You have a structural advantage that consumer-goods pricers would kill for: your product *is* an instrumentation surface. You can observe exactly how much each customer consumes, which features they hit walls on, and where usage decelerates after a bill. This is a live willingness-to-pay signal. Build a dashboard that flags accounts consuming 3x their tier's median (underpriced — upsell candidates) and accounts whose usage flatlined right after a price event (churn risk from over-extraction). Review it monthly with the commercial team.
Because your customer base segmentssegmentsDividing a market into distinct groups of customers who share similar needs, characteristics or behaviours, so each group can be served with a tailored approach.View full definition → cleanly and your product is digital, you can A/B testA/B testA/B testing is a controlled experiment that compares two versions of something (A and B) by splitting traffic randomly to learn which performs better on a chosen metric.View full definition → price points and packaging on new-customer cohorts — something impossible for most physical products. Test a metric change or a tier boundary on 10% of new signups before rolling it out. The data settles arguments that would otherwise be won by whoever is most senior in the room.
The most subtle CDO responsibility: when your pricing metric is a data-derived quantity ("verified identities," "qualified matches," "records enriched"), *you own the definition of that metric*, and that definition is now a financial instrument. If an engineer quietly changes the matching threshold, they've changed every customer's bill and your revenue recognition. Pricing metrics must be governed with the same rigor as any regulated data definition — versioned, change-controlled, and auditable. This is where your governance mandate and your monetization mandate fuse into a single responsibility.