How recent does a sold comp need to be?

A comp query could be bounded two ways. A time box takes every sale in the last twelve months. A count window takes the most recent n sales, whenever they happened. We use the count window: the paid report prices against the most recent 200 priced sales of the asset type by sale date, and the free calculator reads a wider 500. Both then apply the same five-comp floor to whatever survives filtering.

Nothing in that pipeline asks how old a deal is. A sale from two years ago is used, in full, if it is among the most recent sales we hold of its type — and a sale from last week is dropped if 200 more recent ones exist.

The reason is that a time box fails silently in exactly the categories that need help. Put a twelve-month cut-off on a thin category and the query returns three rows, the floor rejects them, and the honest answer — "here is a small, older sample, read it carefully" — is replaced by no answer at all. A count window degrades in a way you can see: the sample stays as recent as the category allows, and its age is disclosed rather than promised.

The window only matters where a category holds more sales than it. Below that line the report is reading everything we have of that type, and "recency" is not a filter at all — it is just the whole shelf.

Loading live coverage from /api/stats…

"Read by the report" is the smaller of the two preceding columns. Where the window binds, the sample is a recent slice and older sales in that category sit outside it; where it does not, the sample reaches back as far as our collection does. Either way the count is before filtering — rows that state no earnings carry no multiple and drop out later, which is why a large category can still fail to produce an estimate.

Before asking how old a comp is, ask what its date records. Sources do not agree on this, so every row we hold carries a basis derived from its source, and the Pro CSV exports it in a sold_date_basis column beside sold_date:

• Close — the date the sale closed, per the marketplace that ran it. The only basis that means what "sold date" sounds like.
• Announcement — the date the sale was announced, used where the page states no closing date. The close came first, by an unstated margin.
• Reveal — the date the price was first published. One of our domain-sale sources runs on this basis, because it states outright that its figures have always been dated from when a price was first revealed rather than from the transaction.
• Self-reported — the date a party to the deal gave us, unverified.

This matters for recency in a specific way: a reveal-basis date is never earlier than the sale, and can be much later. A comp set that looks six months old on reveal dates may be describing a market rather older than that. The bias runs one way, so it is at least predictable — assume the underlying sales are older than their dates, never newer. Where sold-price data comes from covers which sources we take and what they publish.

Every estimate we publish carries the first and last sale date in the sample it used, together with a breakdown of how many of those comps sit on each date basis. That pair of dates is the single most useful line in the sample disclosure, and it answers a question the median cannot:

• A span of weeks means you are reading the market as it is now, through a narrow slot. Current, but thin on variety — one active seller or one auction house can dominate it.
• A span of years means the median is an average across conditions that may no longer exist. It is still evidence; it is not a quote.
• A span that ends months ago means collection in that category has slowed or the source stopped publishing. Treat the number as provisional and check the venue mix.