Online prices change by store and by day. A price study is a dated snapshot, and a different price found later is usually drift to log, not an error to chase. Only a row that could not have been right when it was read gets corrected.
Without that rule, a price sheet never finishes. Every re-check finds new differences, and every difference turns into a fix. With it, a re-check becomes a short list of real errors and a longer list of dated notes.
The moment: every re-check found something
I was working on a shelf-price sheet of a little over a hundred rows: one product, one store, one price per row. Using the invented trail mix example from this site, picture rows like "Brand C Fruit Mix, Store 2, 6.29."
Each time the sheet was re-checked, the reviewer opened the links and compared. Each time, some prices were different. And each time, the differences were treated as mistakes and fixed. The sheet was updated to the newest price, then re-checked, then updated again.
It looked like care. It was actually a loop. The sheet never settled, and after a few rounds it mixed prices read on different days at different stores, with no way to tell which was which.
What went wrong first
There was no rule that separated two very different things:
- This price was wrong when it was read. The reader typed a sale into the regular column, or picked up the wrong size, or copied a price from another product on the page.
- This price changed since it was read. The store moved its price, or the site showed a different store's price to the next visitor.
The first is an error. The second is drift. They look identical in a side-by-side comparison, which is why a re-check without a rule treats them the same way.
The second one is also very common. Many store sites decide which store you are shopping at by themselves, from your location or a cookie. Two people opening the same link on the same day can see two prices, both correct for the store they were shown.
Store and date on every row
The fix starts at collection, not at review. Every row carries the store and the date it was read, along with the location the page showed and a clickable link to the source.
| Product | Store | Location shown | Read on | Regular | Sale |
|---|---|---|---|---|---|
| Brand C Fruit Mix | Store 2 | Location on file | Day 1 | 6.29 | |
| Brand D Protein Mix | Store 1 | Location on file | Day 1 | 5.29 | 4.79 |
Now a re-read can be compared fairly. Same store, same location, a different price a week later: the price moved. A different store shown: the comparison does not even apply. Either way the original read stands, because it was true where and when it was taken.
The rule: could it have been right?
When a re-check finds a difference, ask one question about the original read. Could this price have been right at that store on that day?
If yes, it is drift. Log it in a dated note on the row: what the re-read showed, where and when. Do not change the price.
If no, it is an error, and the row gets corrected. In practice there are three kinds of row that could not have been right:
- Wrong size. The price was read for a different size option than the one on the row.
- Sale entered as regular. The page shows "Sale 4.79, was 5.29" and 4.79 went in the regular column. The regular price is 5.29, and 4.79 belongs in the sale column.
- Related-item price. The number came from a "you may also like" box, not the product's own buy box.
Each of these was wrong on day one, whatever the price is today. So each one gets fixed, and the fix is noted on the row with the evidence.
Drift is logged. Errors are fixed. The test is whether the first read could have been right, not whether today's price matches.
The exception: big drift gets a re-read
Most drift is small: a few cents, a few percent. Some is not. When a re-read differs from the original by more than about 25%, I treat that as a signal worth a closer look, not just a note.
Those rows get re-read at a named store, on purpose, with the location set by hand. A gap that large can mean a real price change, but it can also hide an error that the three checks above missed, like a multi-pack price on a single-pack row. The re-read decides which.
There is one more narrow exception. A source that charges one price everywhere, like a brand's own online store, has no store drift. For those rows, updating to the latest read taken on the same day as the rest is fine.
Why freeze instead of chase
There were three ways to handle this, and I weighed all three.
- Keep updating every row to the latest read. It looks current. It mixes stores and dates and never finishes.
- Freeze a dated snapshot and log drift in notes. It is honest and finishable. The cost is that a reader who clicks a link may see a different number.
- Re-read everything at one fixed store on one day. It is the cleanest. It is often impossible, because sites assign the store themselves.
I chose the second. A price study usually answers one question: where does this product sit in the range? A dated snapshot answers that well. Chasing every few cents of drift adds cost without changing the answer.
The cost of option two is real, so I disclose it. A short line at the top of the sheet says the prices are a snapshot, gives the dates, and explains that a link opened later may show a different price.
Decide the rule before you re-check
The order matters. If you start a re-check with no drift rule, every difference feels like a finding, and findings feel like they need fixing. Write the rule first: what counts as drift, what counts as an error, the threshold for a re-read. Then run the check against it.
It also helps to treat a reviewer's difference as a question, not a correction. The reviewer reports what the re-read showed. The person who owns the sheet decides whether it is drift or error. I wrote more about that habit in A Flag Should Be a Question, Not a Decision.
What goes wrong
- No date on the row. Drift and errors become impossible to tell apart. Date every read.
- Location changes silently. Record the store the page actually showed, every time.
- Drift fixed as an error. The sheet becomes a mix of days. Log it instead.
- Links that die. A dead link is not an error in the price. Mark it, and keep the dated read.
- Endless re-checks. Freeze the file after one full acceptance check, and reopen only on new instructions.
The free shelf price normalizer applies the regular and sale rules for you, so a sale typed as regular is caught at entry instead of at the third re-check. The full method, with the row template, the drift rule and the checklist, is in The Price Check Playbook (PDF).
The takeaway
Put a store and a date on every number you collect from the web. Decide your drift rule before you re-check.
Correct only the rows that could not have been right: wrong size, sale entered as regular, a related-item price. Log everything else as dated drift, and re-read at a named store when drift tops about 25%. Then freeze the file.
A snapshot is not a mistake. Date it, log drift, fix only real errors, and let the file finish.