I went looking for one thing, failed to find it, and measured something more useful on the way. Both results are below, including the hypothesis that did not survive.
The setup
60 specific products across ten categories: graded cards, retro games, sneakers, watches, lenses, coins, tools, collectibles, consumer electronics. For each one, the same query twice, once over 90 days and once over 1,095 days, reading cleaned server side statistics rather than raw listings. 120 requests, paced.
The question: eBay's public sold filter shows about 90 days. How much of an item's sales record does that window hide?
The hypothesis failed
I expected thin 90 day windows and rich three year ones. Instead, 58 of 59 comparable queries already had eight or more clean sales inside 90 days. For the typical product, the 90 day window held essentially the whole visible record.
Only one query was genuinely starved: a complete copy of Earthbound on SNES, 6 sales in 90 days against 228 over three years.
The reason is not that eBay shows more than I thought. It is that a keyword search is broad. Ask for seiko skx007 dive watch and the window fills easily, because it fills with straps, bezels, crystals and cases as well as watches.
Breadth hides depth.
What showed up instead
Changing only the window changed the answer, often by a lot.
| Change in median, 90d vs 3y | Share of products |
|---|---|
| 10% or more | 16% |
| 25% or more | 9% |
The individual movers:
| Query | 90 day median | 3 year median | Move |
|---|---|---|---|
rolex datejust 16220 |
$435.56 | $4,400.00 | 10x |
seiko skx007 dive watch |
$14.13 | $200.00 | 14x |
marantz 2270 receiver |
$99.00 | $710.00 | 7.2x |
mike trout bowman chrome 2009 |
$4,750.00 | $897.50 | 5.3x |
festool track saw ts 55 |
$199.31 | $325.00 | 1.6x |
I checked the biggest one, because 10x usually means bug
Pulled both windows again and looked at listings instead of statistics.
Both windows return the same kinds of thing. Bottom of the distribution: a sapphire crystal at $23, a bracelet link at $39, an engine turned bezel at $84. Top: real watches at $4,500, $5,100, $5,700. Identical price deciles in both.
The three year set is the 90 day set plus 62 older sales, and those added sales sit high in the distribution. That drags the midpoint from the parts end of the list to the watch end.
So the market did not move. The composition of the match moved. Nobody's Datejust changed price by 10x, and anyone comparing those two medians would have concluded it did.
Why this is the more useful result
Price history gets sold on depth. More years, more data, better answers. Depth is real, and its actual value is sample size on scarce items.
But depth does nothing if the query is matching the wrong population, and widening the window can quietly change which population you are measuring. Retrieval is the problem. The time window is just another way to perturb it.
I measured the same failure from another angle recently: the same card search returned a $14.73 median raw and $545.00 once lots, proxies, accessories and "PSA 10 contender" listings were removed. That write up is here.
Four rules if you work with marketplace price data
Never compare medians across windows unless the filters are identical and tight. If the only thing you changed is the date range and the number moved more than a few percent, suspect the match before you believe the market.
Filter on parsed structure before you widen. Condition, grading fields, print run, category, and dropping lots and accessories. A tight match is stable across windows. A loose one is not.
Read the count alongside the median. If the median moved and the count jumped, you are looking at a different set of sales, not a trend.
Use depth for sample size, not for trend. Three years is the right tool for something that sells twice a quarter. For a trend, bucket sales by date and compare buckets. One long window median is a level, not a trend.
Reproducing it
Numbers are from a run on 17 October 2026. Capped queries, where the result hit the page size, are marked and excluded from the volume claims. Two of 59 were capped.
The free tier is 100 requests a month and no card, and count, used_for_stats, median, p25 and p75 come back on every response: compsapi.com/docs.
Top comments (0)