Pricing models for data products

# 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.

The four models and what they actually optimize for

Every data productdata productA data asset managed like a product, with an owner, defined users, guaranteed quality, and measurable business value.View full definition → 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 critical insight: these are not mutually exclusive

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.

The selection framework: four diagnostic axes

When a product manager brings you a pricing proposal on Monday, run it through four axes before you approve anything.

1. Value attributionattributionA framework for assigning credit to the touchpoints that contributed to a conversion, so you can measure which channels and interactions actually drive results.View full definition →: can the customer trace outcomes to your data?

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.

2. Consumption pattern: continuous or spiky?

Chart the actual usage telemetry from your beta customers. (You instrumented the product; use the data.)

• Flat, continuous consumption → subscription is efficient. Metering adds friction and billing overhead for no gain.
• Spiky, unpredictable consumption → usage-based, so light users aren't subsidizing heavy ones and heavy users pay their share.
• Growing-then-plateauing → the classic case for the freemium → usage → commitment stack.

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.

3. Marginal cost: what does the next unit cost you to serve?

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.

4. Competitive reference price: what's the buyer's mental anchor?

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.

Engineering the price: metrics, fences, and the adoption trap

Choosing a model is 40% of the work. The other 60% is designing the mechanics so the model doesn't quietly destroy adoption.

Pick a value metric, not a cost metric

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.

Build fences, not walls

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:

• Volume tiers (the bank consumes more, pays more)
• Feature differentiation (real-time vs. daily batch; the latency premium)
• Support and SLA (99.9% uptime guarantee as a paid tier)
• Use-case licensing (internal analytics vs. redistribution rights, the redistribution right is where the D&B-style premium lives)

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 adoption trap and how to defuse it

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 annual

Note 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.

Governing price over time: the CDO as steward

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.

Instrument willingness-to-pay continuously

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.

Run price as an experiment, not an edict

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.

Own the metric's integrity

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.

Key Takeaways

• Design transitions, don't pick a model. The winning pattern stacks freemium (acquire) → usage-based (scale) → value-based commitment (capture and smooth). Your real job is engineering the threshold at which each customer moves between them.

• Choose a value metric over a cost metric. Charge for outcomes the customer values (verified identities, qualified leads), never for costs you incur (APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition → calls, GB processed). When the bill grows only as customer success grows, price objections disappear.

• Capture the value spread through use-case fences, not more data. The premium a large customer will pay lives in redistribution rights, SLAs, and latency, contractual fences, far more than in volume. Treat contract terms as a primary pricing lever.

• Cap the customer's downside to protect adoption. Spend caps and free exploration/sandbox usage remove the bill-shock fear that silently suppresses the consumption you're trying to grow.

• Govern the pricing metric like a regulated definition. When your price is tied to a data-derived quantity, its definition is a financial instrument, version it, change-control it, and audit it under your existing governance mandate.