A marketplace comparison should explain what its price includes

A listing comparison panel sorts ten items by total price. The cheapest result has no shipping information.

If missing shipping was converted to zero, the ranking may be rewarding incomplete data rather than a lower cost.

This is a hypothetical marketplace design problem. It connects data modeling with the promise a comparison interface makes.

Preserve different meanings

I would distinguish these cases in the data:

shipping: known cost
shipping: confirmed free
shipping: unknown
shipping: not applicable to this transaction

They should not collapse into the same numeric value before the UI sees them.

The same issue appears with condition, availability, accessories, and model variants. A default value can make a record easier to process while making the resulting comparison less accurate.

Define the number before naming it

“Price” could mean the asking price, an observed completed-sale amount, a subtotal, an estimated total, or a model-generated estimate.

Each can be useful. A label such as “total cost” needs a clear inclusion rule. If shipping and fees are unknown, a subtotal may be the more defensible description.

For example:

Asking price: €900
Shipping: unknown
Known subtotal: €900

That is less compact than one large number. It tells the user what the number measures.

Make missingness part of the sort policy

There are several possible policies:

• Sort by asking price and name that sort explicitly.
• Rank known totals separately from incomplete totals.
• Show a range when the product has a defensible basis for one.
• Require the user to inspect missing costs before drawing a conclusion.

I would not choose a policy solely because null is awkward for a comparator. The ranking changes how users interpret the data.

It can also be useful to let users filter to records with the information they require. Show how many records that excludes so the comparison's coverage remains visible.

Comparability matters as much as arithmetic

Two items with the same title may differ in condition, included accessories, storage capacity, warranty, or location.

Before presenting a median or a “below market” badge, I would define which differences make a listing unsuitable for the comparison. A larger sample is not automatically a better one if it mixes different products.

Duplicate and relisted records need a policy as well. Counting the same item several times can give one seller's asking price more influence than intended.

Give freshness a meaning

“Updated today” can describe the browser's request time without establishing when a listing was observed or whether it is still available.

If freshness matters to the decision, keep the relevant observation time and explain what it represents. A fresh response can still contain old source data.

A useful comparison test

Create a small dataset with one known free-shipping item, one paid-shipping item, one unknown-shipping item, and one item with a different configuration.

Then inspect the totals, sorting, summary statistics, and explanatory labels together. Does any missing field become a confident advantage? Does the summary quietly combine items the user would not consider equivalent?

The goal is a comparison users can inspect and question. A precise-looking result is useful when the interface also explains which observations and assumptions produced it.

What would you want beside a price comparison before using it to make a decision?