Data sharing, marketplaces, and ecosystems

# Data sharing, marketplaces, and ecosystems

In 2021, a mid-sized European insurer discovered that its most valuable asset wasn't its actuarial models, it was fifteen years of granular claims data on residential water damage. A reinsurance analytics firm offered seven figures for access. The CDO said yes to the revenue, then spent eighteen months untangling the consequences: a competitor reconstructed the insurer's underwriting logic from aggregate patterns, and a regulator asked pointed questions about consent scope. The deal wasn't wrong. The *decision architecture* behind it was missing.

That is the gap this lesson closes. You already understand monetization as a concept. What you need now is the operational judgment to decide where you sit in a data ecosystem, buyer, seller, or operator, and how to build the machinery that makes each role safe and profitable.

The three postures and why you must choose deliberately

Every data ecosystem transaction puts you in one of three postures, and most CDOs drift into them by accident rather than choosing them by strategy.

As a buyer, you acquire external data to enrich internal decisions, demographic overlays, weather feeds, transaction panels, firmographics. The trap here is not cost; it's *dependency and 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 →*. When a bought signal becomes load-bearing in a production model, you've created a supplier who now prices against your switching cost. Snowflake's Data Marketplace and AWS Data Exchange have made acquisition frictionless, which is precisely the danger: frictionless procurement produces ungoverned sprawl. A retailer I worked with had 34 external data subscriptions across five teams, three of which were duplicative and one of which was legally indefensible.

As a seller, you package and license your own dataown dataData collected directly from your own customers and prospects through your own channels: your most reliable and privacy-compliant source.View full definition →. The insurer above was a seller. The core discipline is understanding what you're actually selling, raw records, derived features, or *insights*. These are three different businesses with three different risk profiles. Selling raw records maximizes buyer flexibility and your exposure. Selling insights (e.g., "propensity scores" rather than the underlying behavior) protects your competitive moatmoatA lasting edge over competitors: a resource, capability or position they cannot easily replicate, letting a firm earn above-average returns over time.View full definition → but requires you to build and maintain a product.

As an operator, you build the marketplace or clean room where others transact, the posture Bloomberg took decades ago and that companies like Snowflake, Databricks, and specialized players like Habu/LiveRamp occupy now. This is a platform business with platform economics: enormous upside, brutal cold-start dynamics, and a governance burden that dwarfs the other two roles.

The decision test is not "which is most profitable" but which posture matches your data's structural position:

• If your data is *commodity-adjacent* (you have it, so do others), you are a buyer of differentiated data and at best a low-margin seller.
• If your data is *unique and hard to replicate* (proprietary sensor networks, exclusive transaction flows), you have seller and possibly operator optionality.
• If you sit at a *natural aggregation point* where many parties need to combine data they won't share directly, you have operator potential, and only then.

Most CDOs are buyers who occasionally sell. Very few should be operators, and the ones who try without the aggregation-point advantage burn capital spectacularly.

How the machinery actually works: clean rooms and contracts

The defining technical shift of the last five years is that you no longer have to move data to combine it. This changes everything about the seller and operator postures.

The old model was "ship a file, hope for the best." The current model is the data clean room: a governed environment where two or more parties can run approved computations across their combined data without either party seeing the other's raw records. This is how advertisers match audiences with publishers post-cookie, and how the insurer *should* have structured its reinsurance deal.

The mechanics you need to understand as a CDO are three layers:

1. The privacy layer, techniques that make outputs safe: aggregation thresholds (no result released for fewer than N individuals), differential privacy (calibrated noise injection), and query auditing. This is what prevents a buyer from reconstructing individual records or, as in our opening case, reverse-engineering your model.

2. The governance layer, who can run which queries against which columns, with what allowlist of operations. This is where most implementations fail, because teams treat it as an afterthought.

3. The commercial layer, metering, entitlements, and billing tied to consumption.

Here's the shape of a clean-room policy that separates a defensible deal from the insurer's mistake, restricting operations to aggregates above a threshold rather than exposing joinable rows:

clean_room_policy:
  dataset: residential_claims
  allowed_operations: [count, sum, avg, join_on_hashed_key]
  blocked_operations: [select_raw, export_rows]
  aggregation_threshold: 50   # suppress any result covering <50 records
  join_keys:
    - property_id_hashed
  output_review: automated_plus_manual_sample
  differential_privacy:
    epsilon: 1.0

The insurer sold raw joinable records. Had they sold *only aggregated query results above a threshold of 50 with the join key hashed*, the reinsurer would have gotten legitimate risk signal and been unable to reconstruct proprietary underwriting logic. Same revenue, radically different risk. The contract terms and the technical controls must encode the same intent, if your legal agreement says "aggregate only" but your platform allows row export, the platform wins.

On the buyer side, the parallel discipline is a data acquisition gate: no external dataset enters production without answering four questions, What decision does this improve, and by how much? What is our switching cost if the supplier changes terms? Is the provenance and consent chain contractually warranted? What happens to our model if this feed goes stale or dies? The retailer's 34 subscriptions collapsed to 11 once these questions were enforced.

The economics: pricing, value capture, and the operator's cold start

The question that stalls most data-sharing initiatives is pricing, and the reason is that CDOs price data like a product when they should price it like *access to a decision*.

Three pricing models dominate, and each signals a different relationship:

• Subscription (flat access) rewards heavy users and is easy to budget, but it decouples your revenue from the buyer's value, dangerous when your data is highly differentiated.
• Consumption (per query / per record) aligns revenue with usage and is now the marketplace default, but it penalizes exploration and can suppress the experimentation that reveals your data's value to the buyer.
• Outcome-based ties price to the buyer's realized lift. It's the holy grail and almost impossible to instrument honestly, because 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 → is contested.

The practical answer for a seller is usually a hybrid: a subscription floor for access plus consumption for volume, with the floor set to cover your governance and support cost. Never price below your *cost to serve safely*, which includes the ongoing cost of monitoring for misuse, not just the infrastructure.

For value capture, the sharpest CDO framing is the value-migration question: when you sell data, does value flow *to* your buyer's product in a way that eventually competes with you? The insurer sold to a reinsurer, adjacent, not directly competing. Selling the same claims data to an insurtech startup would have been feeding a future competitor. The data is identical; the strategic consequence is opposite. This is judgment no contract template captures for you.

The operator posture deserves a hard warning on economics. Marketplaces are two-sided networks, and two-sided networks have a cold-start problem: buyers won't come without sellers, sellers won't come without buyers. The operators who won, Bloomberg, Snowflake, either seeded one side with an existing captive audience or subsidized one side heavily for years. If you're considering operating an ecosystem, the diagnostic question is brutal: *do you already own one side of the market?* A logistics firm that already connects 10,000 shippers and carriers can credibly operate a data exchange between them. A firm without that existing gravity is proposing to fund a network-effects flywheel from zero, and that is a venture bet, not a data strategy.

Making the decision on monday morning

Let's convert all of this into a sequence you can actually run.

Step 1: Inventory your data's structural position, not its volume. For each significant dataset, mark it on two axes: *replicability* (how easily can others obtain equivalent data?) and *aggregation value* (how much more valuable is it combined with others' data?). High-uniqueness, high-combination-value assets are your seller and operator candidates. Everything else, you're a buyer or you leave it alone.

Step 2: Run the value-migration and dependency screens. For each seller candidate, mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.View full definition → who the buyers are and whether any sits in your competitive future. For each buyer need, run the acquisition gate. This is where you say no to revenue that costs you strategic ground and no to subscriptions that create hidden model dependencies.

Step 3: Choose the minimum-viable technical posture. You do not need to build a clean room to start selling. The maturity ladder is: (a) governed file delivery with strong contracts, (b) APIAPIApplication Programming Interface: a standardised interface that lets applications communicate and exchange data without knowing each other's internal workings.View full definition →-based access with metering, (c) query access in a marketplace, (d) full multi-party clean room. Start one rung above where your risk demands, not at the top. The insurer needed rung (c); they operated at rung (a).

Step 4: Instrument misuse detection before the first transaction, not after. The single most common failure is discovering a violation through a news story or a regulator's letter. Query logging, anomaly detection on access patterns, and periodic output audits are not optional overhead, they are the thing that lets you sell at all. Budget for the *ongoing* cost of safe serving in your pricing.

Step 5: Decide operator posture only with the network-gravity test. If you don't own one side of the market, participate in someone else's ecosystem as a buyer or seller and revisit the operator question in eighteen months. Operating is the highest-ceiling, highest-failure posture, and it's rarely the right first move.

A useful reframe throughout: you are not deciding whether to share data; you are deciding how much of your data's optionality to convert into revenue, and at what strategic cost. The insurer converted too much optionality (raw records) for the revenue they captured. A disciplined CDO converts the *least* data necessary to capture the value, selling insights before features, features before records, and aggregates before raw.

Key Takeaways

• Choose your posture deliberately using structural position, not volume. High-uniqueness and high-combination-value data earns you seller/operator optionality; commodity data makes you a buyer. Most CDOs should be disciplined buyers who occasionally sell insights, not operators.

• Encode the same intent in contract and platform. If your agreement says "aggregate only" but your technical controls allow row export, the controls win and you're exposed. Sell the least data necessary: insights before features, features before records, aggregates before raw.

• Run every buy through an acquisition gate and every sale through a value-migration screen. Kill hidden model dependencies on external feeds, and refuse revenue that feeds a future competitor even when the data is identical to a safe deal.

• Price access to a decision, not a product, and price above your cost to serve safely. That cost includes ongoing misuse monitoring, which you instrument *before* the first transaction, never after.

• Attempt the operator posture only if you already own one side of the market. Without existing network gravity, building a marketplace is a venture bet disguised as a data strategy, and the cold-start problem will consume your capital.