Scan counts that mean people, not previews

A QR code’s link gets fetched by a lot of things that are not customers. Messaging apps fetch it to build a preview card — often several times, from several servers, the moment somebody pastes it. Search crawlers follow it. Uptime monitors poll it on a schedule. Security scanners open every link in an email. Browsers prefetch links they think you are about to click.

Every one of those looks like a visit at the redirect. Counted as scans, they turn a poster that got eleven real scans into one that reports forty, and the inflation is worst on exactly the campaigns that got shared the most — which is where you are most likely to be making a decision from the number.

Automated traffic is still recorded, with a note of why it was classified that way. It simply does not raise the scan count, fire a webhook, or trigger a scan notification email, and it is hidden from analytics by default — so the dashboard, the CSV export, the API and the mobile app all show human scans without anyone having to remember a filter.

The count of what was filtered is shown too. Knowing that a code got 30 human scans and 120 previews is genuinely useful: it tells you the link travelled, even where the camera did not.

The classifier errs towards counting. A request with an unfamiliar or missing user agent is treated as a person, because dropping a real scan is a worse mistake than counting a script — an under-reported campaign gets cancelled, an over-reported one just gets watched.

When a new signature is added, historical scans are re-classified and each code’s count is rebuilt from the human ones, so the past matches the present rather than showing a step change on the day of a deploy.