How do I know if a dropshipping product is saturated?

By measuring the same figure twice and comparing. A sold count, a review total or a rating on its own tells you where a product has got to, not whether it is still moving. Saturation is a statement about the rate of change, so it cannot be read from a single visit no matter how precise that visit's numbers are.

Why do product research tools show a level instead of a trend?

Because a trend requires history, and history requires having visited before. A hosted tool must poll every product for every user to build that, which is expensive, so the category sells a point estimate instead — a number for right now, which is the cheaper thing to produce and the easier thing to display confidently.

How many readings do you need before a trend means anything?

At least three. A line through any two points has a direction, and reporting that direction as a trend is inventing information — two readings cannot distinguish a real movement from noise or from a one-off event. Below three readings the honest output is the readings themselves and a statement of how many more are needed.

Can you measure product velocity without a server?

Yes, if you accept that your own visits are the sampling schedule. Recording what a page publishes each time you happen to look builds a time series for free, on your machine, with no polling and no account. The trade is that the series only covers products you actually looked at — which are the ones you care about anyway.

Every tool gives you a number. None gives you the derivative.

“This product sells about 400 a month.” That sentence is useless on its own, and it is what the entire product-research category sells. Four hundred is a gift if last month was 200 and a warning if last month was 900 — and nothing in the figure tells you which.

2 September 2026 · the thesis behind MurmPulse

The level is trivia. The rate is the decision. Whether to enter a market depends on where it is going, not where it has got to — and direction cannot be read from a single visit, however precise that visit’s numbers are.

Why the category sells levels anyway

Not laziness — economics. A trend requires history, and history requires having looked before. A hosted tool has to poll every product for every user, continuously, to be able to answer “how has this changed” for whichever product you happen to open. That is a large recurring cost for a question most users ask about a handful of products.

A point estimate is far cheaper: crawl once, model, display. It is also easier to display confidently, which matters more to conversion than it should. So the category converged on the number that is cheap to produce rather than the one that answers the question.

The trap of the precise wrong number

These estimates are, by the industry’s own account, 70–85% accurate. Now consider what happens when you use an 80%-accurate level to infer a change: you are subtracting two uncertain numbers, and the error in a difference is larger than the error in either input. Two estimates that are each “good enough” produce a change figure that is mostly noise.

Which is the strongest argument for measuring the change directly rather than deriving it from two modelled levels.

What can be measured honestly

Whatever the page publishes about itself, recorded each time you look:

Sold count, where a marketplace shows one.
Review total and its rate of accumulation.
Rating, and whether it is drifting.
Price, and every change to it.

None of these is revenue. All of them are counted rather than modelled, and the change between two of your own readings is a fact about the page rather than an inference about the business.

Three readings, and why not two

A line through any two points has a direction. Reporting that direction as a trend is inventing information: two readings cannot separate a real movement from noise, from a promotional spike, or from a marketplace resetting a counter.

So the honest floor is three, and below it the correct output is the readings themselves plus a statement of how many more are needed. That is a worse product demo and a better answer.

The other refusals this forces

No forecast. A record of what changed is not a projection of what will. There should be no dashed continuation of the line, because there is no evidence for it.
No percentage from zero. There is no percentage change from a baseline of zero, and Infinity rendered in a tile is a lie in a confident typeface.
No smoothing across a gap. If you did not look for three weeks, the record should show three weeks of nothing, because that is what was measured.
No trend from a floor. A page saying “500+ sold” is declining to give a count. Three readings of the same floor is not evidence that nothing moved.

The trade-off, stated plainly

A local time series only covers products you actually visited, and it starts empty. A hosted archive can tell you about a product you have never opened, today.

That is a real advantage and worth paying for if you screen hundreds of products. If you are tracking the ten you are seriously considering, your own visits are already the sampling schedule — and the series you build is measured rather than modelled.

MurmPulse records what a page publishes each time you click, and from the third reading reports which way it moved and at what rate, with the sample count and window printed beside the figure.

How MurmPulse works →→

Questions

How do I know if a product is saturated?

Measure the same figure twice and compare. Saturation is a statement about rate.

Why do tools show a level instead of a trend?

History requires polling every product for every user, which is expensive.

Why three readings?

Two points always have a direction. Three is the floor for that direction meaning anything.

Can you do this without a server?

Yes — your own repeat visits are the sampling schedule.