Our first scan looked at 105 big UK and Australian Shopify brands and found no made-up urgency at all. We said the list was the problem: big brands have real traffic and little reason to fake it. So we ran a second scan aimed at the stores the question is really about.
The short version: of 200 small Shopify stores, 12 (6%) showed fake urgency we could prove from outside the store. 7 had a countdown timer that starts over for every new visitor, and 5 had a "people viewing" or "sold recently" number that the browser made up. Of the 17 stores showing a ticking countdown, 7 restarted. That is 41%.
What we scanned
This time we did not pick the stores. Every store in the sample left a review on one of 16 urgency, sales pop, countdown or visitor counter apps in the Shopify App Store. We matched each reviewer to the store's own domain and kept it only if the store's Shopify data confirmed the same shop name. That gave 200 stores in 34 countries, most of them in the US (63), the UK (25), Australia (15) and Canada (15).
That selection is the most important fact in this post. These are stores whose owners once installed an urgency app, so they are far more likely to run one than a random Shopify store. 6% is a rate for this group, not for Shopify. A review also only shows that the owner used the app at some point, sometimes years ago, not that it is installed today.
Every page was tested this time
The first scan had a gap we admitted at the time: pages that timed out were not tested, and the scanner did not record how many there were. We fixed that before this run.
- Slow pages get a second try with twice the time.
- Every store records its coverage: pages tested and pages failed. A store where nothing loaded is reported as unchecked, never as clean.
- One sale or campaign page per store is tested alongside the homepage and product pages, because urgency often lives there. 85 of the 200 stores had one.
- A store's rate-limit page is not a store. Shopify answers too many requests with a "Verifying your connection" page. That page now counts as untested.
The result: all 200 stores and all 673 pages were tested, and none failed.
How the scanner decides
Each page was loaded in a fresh headless Chromium browser with no cookies or history, the way a new shopper sees it.
Countdown timers. The scanner reads the first ticking timer, waits two minutes, then opens the page again in a brand new browser and reads it again. A timer counting down to a real deadline will have dropped by about two minutes. A timer that starts over for each visitor reads the same as before, or higher. Timers that read like a delivery cut-off or "today only", or are close to zero, are marked inconclusive.
Viewer and sales counters. When a page shows text like "23 people are viewing this" or "15 sold in last 16 hours", the scanner reads it five times over eight seconds, reloads the page three more times as a new visitor, and checks every value against the network responses of the load it came from.
- If the number changes and at least one value never arrived from any server, the browser made it up. Flagged.
- If every value arrived in a live data request (a fetch, XHR or websocket response), a server is counting. Real data.
- If the number only appears in the page HTML, we cannot tell. The theme writes it on the server, and from outside a real count and an invented one look the same.
That last rule is new, and we tightened it during this scan. On the first pass of the data, the scanner still counted a number as real if it appeared anywhere in a server response, including the page HTML. Reading the results, that was too generous. Small numbers like 1 or 7 match unrelated text by chance, and one store showing 112, 14 and 283 "customers viewing" passed because the number 10 was in its HTML. We changed the rule, tested it against fixture pages, and re-scanned all 12 stores that had shown a counter. One of them did not show its counter on the second visit, so the counter numbers below are from 11 stores.
What we found
| Result | Stores |
|---|---|
| Stores scanned (all pages tested) | 200 |
| Script from an urgency or social proof app on the page | 110 (55%) |
| Ticking countdown timer found | 17 |
| Countdown restarted for a new visitor | 7 |
| Viewer, in-cart or recent-sales counter found | 11 |
| Counter made up in the browser | 5 |
| Stores with fake urgency we could prove | 12 (6%) |
No store had both a fake countdown and a fake counter.
Countdown timers
| Countdown result | Stores |
|---|---|
| Restarted for a new visitor | 7 |
| Counted down to a fixed deadline | 8 |
| Could not tell (near zero, or a "today only" daily timer) | 2 |
The restarting timers gave themselves away by where they started over. A fresh visitor two minutes later saw the timer back at exactly 5:00, 10:00 or 25:00, or at 1:46:00, 3:00:00, 8:20:00 or 24:00:00. A real deadline does not land on a round number every time somebody new arrives. These are per-visitor timers: the countdown starts when you open the page and is stored in your browser, so it ends at a different moment for every shopper.
Eight stores did the opposite. Their timers counted down to the same moment for everyone, from about 2 hours to 32 days away. Countdown apps can be set up honestly, and in this sample about half were.
Viewer and sales counters
| Counter result | Stores |
|---|---|
| Made up in the browser | 5 |
| Came from a live data request | 2 |
| Only in the page HTML, could not tell | 4 |
The 5 flagged counters were not subtle. On one store, three product pages showed "customers are viewing" numbers that changed on every load, "30 → 18 → 27 → 22" on one and "43 → 43 → 24 → 13" on another, and kept changing while nobody touched the page. On another, a "sold in last 12 hours" figure read 15, 10, 12 and 17 across four visits less than half a minute apart. Sales from the last 12 hours do not change every time you press reload. In all 5, a script on the page also carried a minimum and maximum setting next to viewer wording, which is how a random range is usually configured.
Only 2 counters were fed by a live data request, so a server was counting. Their numbers were small (3, 4 and 5 viewers) and steady across visits, which is what real traffic on a small store looks like.
Compared with the first scan
| First scan (big brands) | Second scan (small stores) | |
|---|---|---|
| Stores | 105 | 200 |
| Pages that failed to load | not recorded | 0 |
| Urgency or social proof app script | 15 (14%) | 110 (55%) |
| Ticking countdown tested | 1 | 17 |
| Fake urgency proven | 0 | 12 (6%) |
The two samples were picked in different ways, so the gap between 0 and 12 is not a measured difference between big and small stores. What it does show is where fake urgency lives. It is rare among established brands. Among small stores whose owners installed an urgency app, it is common enough that 4 in 10 ticking countdowns we tested were fake.
A correction to the first post
Our first post said 17 of the 105 big brands (16%) had an urgency or social proof app, and listed Secomapp on two of them. Our scanner matched any Secomapp script, and on both stores it was Secomapp's BOGOS free gift and bundle app, not an urgency tool. Neither store had another app we track, so the right number is 15 (14%). We have corrected the first post, and the scanner no longer counts Secomapp scripts. The app count in this post leaves them out too.
What we could not see
- This is not a random sample of Shopify. Every store was chosen because its owner reviewed an urgency app. The 6% applies to that group only.
- Up to four pages per store. We tested the homepage, up to three product pages and one campaign page. A fake timer on a page we did not open was missed.
- One moment in time. Each store was scanned once, on 29 October 2026. A timer switched on for Black Friday would not show up.
- Server-written numbers are out of reach. 4 counters were written into the page HTML. Some may be real and some may be invented on the server; no test from outside can tell them apart.
- Real data is not proof of honest data. A counter fed by a live request comes from a server, but we cannot see what that server is counting.
We are not naming the stores. Most of these are very small businesses that installed an app and turned on a setting, and the point of the scan is to measure how common this is, not to single anyone out.
Check your own store
The scanner behind this post runs as a free tool at provedly.app/check, with the stricter counter rule described above. Paste a product page URL and it runs the same countdown and counter tests in about a minute, with screenshots of what it saw on each load.
If your countdown restarts for each visitor, the fix is a setting: point the timer at a real date, or say plainly that the offer is per visitor. Provedly's countdown bars count to one real date. Our live counter only shows visitors our server has actually seen on that page in the last 90 seconds, and hides itself below a minimum you set instead of inflating. How verification works explains the rest.
Frequently asked questions
How can a countdown timer restart for every visitor?
The app starts the timer when you first open the page and saves the start time in your browser. A new visitor, or you in a private window, gets a fresh timer. That is why the scanner opens the page again in a brand new browser: a real deadline reads two minutes less, and a per-visitor timer reads the same as before.
Does a countdown app mean a store is faking urgency?
No. In this scan, 8 of the 17 stores with a ticking timer counted down to a fixed deadline that was the same for everyone. What matters is how the timer is set up, and a reload in a private window answers that.
Why is 6% lower than people expect?
Most stores in the sample showed no counter or ticking timer on the pages we loaded, even with an app installed. An app can be installed and switched off, or show its timer only during a sale. Among stores that did show urgency, the share that was fake was much higher: 7 of 17 countdowns and 5 of 11 counters.
Can I test my own store the same way?
Yes. Run a product page through the free checker. It shows each reading it took, the network responses it searched and screenshots from each load.