Design a data product exposing merchant sales analytics to hundreds of thousands of independent merchants on a commerce platform. What makes it a product rather than a table?

The properties that make it a product

• A named owner accountable for it, not a pipeline that exists because someone built it once.
• A published contract — schema, semantics, quality guarantees, freshness, change policy.
• Freshness as a measured SLI, not an aspiration. Merchants make stocking decisions on this data and need to know how current it is.
• Discoverability, with documentation describing what each metric means in business terms. "Sessions" and "visitors" are different numbers and every merchant will assume they are the same one.
• A versioning and deprecation policy, because the consumer base is too large to coordinate with.
• Usage measured, so the owner knows who depends on what and can deprecate with a conversation rather than a broadcast.

The multi-tenant complications

Tenant isolation is a correctness property, not just a security one. A join that leaks one merchant's data into another's aggregate is a breach, so isolation must be enforced structurally — row-level policy at the storage layer, not a WHERE clause every query author must remember.

Cardinality is the cost driver. Per-merchant aggregates across hundreds of thousands of merchants times many dimensions produce enormous result sets, most of which nobody looks at. Compute on access with caching, or precompute only for active merchants.

Small merchants are the majority and the long tail. A design tuned for the largest merchants will be wasteful for the median one, and a design tuned for the median will fail the largest.

The question that shapes everything

Is a merchant looking at their own data, or is the platform looking across merchants? These are different products with different isolation, cardinality and aggregation properties, and conflating them produces a system that serves neither well.