60 products, two windows, measured 17 October 2026. Including the hypothesis that failed.
Published 17 October 2026 by CompsAPI
We set out to measure something specific: how much of an item's sales record is hidden by eBay's roughly 90 day sold window. The answer turned out to be "less than we expected", and on the way we measured something more useful.
Method: 60 specific products across ten categories, from graded cards to Festool track saws. For each one, the same query run twice, once over 90 days and once over 1,095, reading the cleaned statistics rather than raw listings. 120 requests in total, paced. Numbers below are from that run.
We expected most products to have a thin 90 day window and a rich three year one. They did not. 58 of 59 comparable queries had eight or more clean sales inside 90 days, and for the typical product the 90 day window already held essentially the whole visible record.
Only one query in sixty was genuinely starved: a complete copy of Earthbound on SNES returned 6 sales in 90 days and 228 over three years.
The reason is not that eBay shows more than we thought. It is that a keyword search is broad. Ask for "seiko skx007 dive watch" and the 90 day window fills up easily, because it is filling up with straps, bezels, crystals and cases as well as watches. Breadth hides depth. We are publishing the failed hypothesis because a study that only reports what it hoped to find is an advert.
Changing only the window changed the answer, often a lot.
| Change in median, 90 days vs 3 years | Share of products |
|---|---|
| 10% or more | 16% |
| 25% or more | 9% |
The individual movers are the interesting part.
| Query | 90 day median | 3 year median | Move |
|---|---|---|---|
| rolex datejust 16220 | $435.56 | $4,400.00 | 10x |
| mike trout bowman chrome 2009 | $4,750.00 | $897.50 | 5.3x |
| seiko skx007 dive watch | $14.13 | $200.00 | 14x |
| marantz 2270 receiver | $99.00 | $710.00 | 7.2x |
| festool track saw ts 55 | $199.31 | $325.00 | 1.6x |
A 10x move on a Rolex reference is the kind of number that is usually a bug, so we pulled both windows again and looked at the listings rather than the statistics.
Both windows return the same kinds of thing. At the bottom: a sapphire crystal at $23, a bracelet link at $39, an engine turned bezel at $84. At the top: real watches at $4,500, $5,100 and $5,700. The three year set is the 90 day set plus 62 older sales, and those added sales sit high in the distribution, which 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 between windows, and anyone who compared those two medians and concluded that it did would have been confidently wrong.
Price history is usually sold on depth: more years, more data, better answers. Depth is real and it does help, mostly by giving you sample size on scarce items. But depth does nothing at all if the query is matching the wrong population, and widening the window can quietly change which population you are measuring.
This is the same failure measured from a different direction, where the same card search returned a $14.73 median raw and $545.00 cleaned. Retrieval is the problem. The window is just another way to perturb it.
Never compare medians across windows unless the filters are identical and tight. If the only thing you changed is days and the number moved by more than a few percent, suspect the match before you believe the market.
Filter on 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. Every one of these responses carries count and used_for_stats. When a median moves and the count jumped too, 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 an item that sells twice a quarter. For a trend over time, bucket the sales by date and look at the buckets, rather than taking one median over a long period and comparing it to a short one.
60 queries, 10 categories, both windows, with the capped queries marked and excluded from the volume claims. Two of 59 hit the page size and are excluded. The run, the aggregator and the verification output are kept alongside the numbers, and the failed hypothesis is in there too.
Reproducing it needs a key, which is free for 100 requests a month, and the count, median, p25 and p75 fields are returned on every comps response.
100 free requests a month · every filter on · no card
Get a free key