How to price a dataset and structure a data deal

Two buyers can receive the same file and purchase very different things. One may get thirty days to evaluate it internally. Another may get a perpetual training license with the right to sublicense it. The bytes do not explain the price difference. The rights do.

Before quoting, write down the product, permitted uses, users, term, delivery, update schedule, and support. If those are still moving, present a scoped proposal rather than an unexplained number.

Choose a model that matches the product

Model	A reasonable fit	A question to resolve
One-time license	A fixed historical snapshot	What happens to corrections and later versions?
Subscription	A feed with continuing updates	What freshness and support are included?
Usage-based access	A product delivered through measurable requests or consumption	Can both sides reconcile usage?
Custom collection	A defined new dataset or annotation project	Who pays for rejected work and specification changes?
Revenue share	A partner sells or licenses the product onward	What revenue is counted, and what can be audited?

Do not add usage billing simply because it sounds scalable. If a buyer cannot predict its bill, procurement may become harder. If you cannot audit usage, enforcement may depend on a reporting process you have not designed.

Marketplace programs have their own constraints. Check the current Snowflake listing documentation or AWS provider requirements for the route you actually choose.

Calculate the cost of keeping the promise

Separate one-time work from recurring work. One-time work may include rights review, cleaning, documentation, integration, and initial delivery. Recurring work may include refreshes, supplier payments, support, hosting, corrections, and channel fees.

Your time has a cost even when you do the work yourself. Record hours and use an explicit planning rate. Keep taxes, financing, general overhead, and other excluded costs visible rather than quietly treating contribution as take-home profit.

For a simple annual license model:

Annual contribution = annual gross revenue − channel fees − annual recurring delivery costs − one-time preparation costs.

The deal economics calculator implements that model. Its default inputs are illustrative assumptions, not market benchmarks.

A worked example with invented numbers

Suppose you model three customers paying $12,000 each for a year. Assume a 15% channel fee on all revenue, $6,000 in one-time preparation, and $300 per customer per month for delivery and support.

Gross annual revenue is $36,000. Channel fees are $5,400. Recurring costs are $10,800. After $6,000 of preparation, modeled first-year contribution is $13,800, before the excluded costs above.

Nothing in this example establishes that a buyer will pay $12,000. It shows how a seemingly attractive deal can narrow after the work and channel costs are counted. Change the assumptions to match your own product.

Test the value in the buyer’s workflow

Ask what alternative the buyer would use, what work your product saves, and what a failed or delayed implementation costs them. Treat answers as commercial discovery, not an excuse to invent a return-on-investment figure.

Then offer a pilot with a defined scope and decision date. A buyer who agrees to a serious evaluation gives you stronger information than someone who says a dataset “sounds interesting.” Record acceptance, rejection, and the reason for both.

If several well-qualified buyers reject the price, investigate fit before discounting. The issue may be weak rights, poor coverage, integration work, or an outcome they cannot measure.

Treat exclusivity as its own negotiation

An exclusive license can remove future opportunities. Define the field of use, territory, customer class, and duration. Ask whether the buyer actually needs worldwide exclusivity or only protection against a named use in a narrow market.

You can model alternative scenarios, but do not assume foregone sales that have no evidence behind them. A narrower grant may make the deal workable for both sides. Record exactly what remains available to license elsewhere.

Put the proposal on one page

List the asset version, rights, term, deliverables, update schedule, support, pilot acceptance, payment milestones, and price. State the assumptions that would change the quote. Attach the dataset card and a rights checklist rather than hiding exceptions in an enthusiastic pitch.

A clear proposal makes negotiation faster because both sides can see what a price change would actually change.