Raw Logs Stay Intact as Marketers Filter Bot Scans in QR Analytics
Bots commonly inflate QR code scan counts, sometimes by a wide margin, and a layered approach combining crawler verification, bot scoring and deduplication filters out most of that noise. The first practical step is to flag suspicious hits without deleting them, so you can audit the filter later. Keep raw logs intact, build a filtered view on top, and report the filtered number as your human-scan metric.
TL;DR:
- Treat scores from 1 to 29 as high confidence automation, and manually review borderline hits because missing headers or rapid repeats can reflect genuine scans.
- Verify claimed crawlers with reverse and forward DNS checks that tie the request IP to its hostname, since a User Agent string can be spoofed.
- Use a deduplication window that fits the campaign: scanning libraries often default to about 3,000 milliseconds, while event entry lines may require minutes.
- Keep raw logs intact and flag suspected bots instead of deleting them; report filtered unique scans, with exclusions and deduplication rules available for audit.
Table of Contents
- What bot scans are and what triggers them
- How platforms detect and score automated activity
- Step-by-step methods to identify bot hits in your logs
- Turning raw hits into a human-scan metric
- How filtering gets implemented in practice
- Verifying crawlers with Forward-Confirmed Reverse DNS
- Checklist for auditable filtering with QRlytics analytics
- Why layered, auditable filtering beats one-off rules
- Report scan numbers you can stand behind
- FAQ
- Sources
What bot scans are and what triggers them
A bot scan is any hit recorded against your QR code that didn’t come from a person pointing a camera at it. A human scan happens when someone opens their camera app and decodes the code themselves. A bot scan happens when software fetches the destination URL automatically, often before any person sees the code at all.
Several automated sources routinely trigger these hits:
- Search engine crawlers that index the linked page shortly after you publish it.
- Email security scanners that pre-fetch links inside messages to check for malware.
- Messaging apps generating link previews when someone shares your QR destination in a chat.
- Uptime monitors and QA tools pinging the URL on a schedule to confirm it’s live.
Some of these you’ll want to exclude outright from your human-engagement numbers. Others, like your own QA checks, are worth tagging separately rather than discarding, since they tell you the code is working, just not that anyone scanned it.
How platforms detect and score automated activity
Most analytics platforms assign a bot score to each hit rather than a simple yes or no label. Cloudflare’s bot score runs from 1 to 99, where scores in the 1 to 29 range indicate high-confidence automated activity and higher scores point towards likely human traffic.
Pro tip: Treat the middle of the bot-score range as a review queue rather than an automatic pass, since that’s where genuine ambiguity lives.
That score comes from combining several signals rather than relying on one:
- Request headers that are missing, malformed, or inconsistent with a real browser.
- Rapid repeated hits from the same source in a short window.
- JavaScript execution checks and other behavioural fingerprints that a simple fetch script can’t replicate.
- Timing patterns, such as a scan arriving within milliseconds of the code being published.
No single signal is reliable on its own. A missing header might just mean an older device, and a fast repeat hit might be a person scanning twice because the page loaded slowly. Combining several weak signals into one score catches far more genuine bot activity while keeping false positives lower than any single rule would.
Step-by-step methods to identify bot hits in your logs
Before you filter anything at scale, label a sample of your data by hand so you know what you’re actually dealing with.
- Pull the full record for each hit: timestamp, IP address, User-Agent string, referrer, device type and bot score if your platform provides one.
- Apply a bot-score threshold as a first pass, then pull out the hits sitting near your cut-off line for manual review.
- Verify any hit claiming to be a known crawler using Forward-Confirmed Reverse DNS rather than trusting the User-Agent string, since Google’s own guidance recommends this exact check for confirming its crawlers.
- Look for behavioural red flags: identical intervals between scans, the same destination hit from dozens of IPs in the same second, or sessions with zero time on page.
- Test your rules on a copy of the dataset before applying them to live reporting, and check how many hits each rule removes.
This process takes longer than flipping a single toggle, but it means every exclusion rule is something you can explain and defend later, rather than a black box that quietly shaved a chunk off your numbers.
Turning raw hits into a human-scan metric
Once you’ve identified likely bot hits, the next decision is how to count what’s left. Raw hits are every request your server logged. Unique scans collapse repeated requests from the same source within a set window. Filtered unique scans go one step further and remove the hits you’ve flagged as automated.
- Choose a deduplication window, sometimes called a duplicate forget time, to decide how close together two hits need to be before they count as one. Barcode-scanning libraries commonly default this to around 3,000 milliseconds, though some extend it to minutes for scenarios like event check-ins where longer queues are normal.
- Never overwrite your raw logs. Build filtered views as a separate layer so you can always re-run the analysis with different rules.
- Decide what you’re actually reporting: first scan per device, unique user across the campaign, or session-based counts. A product launch QR code might care most about first scans, while a loyalty programme cares more about repeat unique users.
That choice should match your campaign goal, not just whatever your dashboard happens to show by default.
How filtering gets implemented in practice
Most platforms mark suspected bot hits rather than deleting them outright, which keeps your raw data intact for later review.
- Flagging, not blocking, preserves the ability to re-examine a hit if your rules turn out to be too aggressive.
- Allowlisting known monitoring tools and partner services stops you from repeatedly flagging traffic you already trust.
- Per-customer behavioural baselines learn what normal traffic looks like for your specific campaign, which Cloudflare’s own research on bot defences notes reduces false positives compared with generic static rules applied across every account.
- Exception rules for known partners, such as an events platform or a ticketing integration, stop legitimate automated check-ins from being misclassified.
Verifying crawlers with Forward-Confirmed Reverse DNS
A User-Agent string claiming to be Googlebot proves nothing on its own, since any script can set that header to whatever it likes.
- Reverse-resolve the IP address that made the request to get its hostname.
- Confirm that hostname belongs to the domain the crawler claims to represent.
- Forward-resolve that hostname back to an IP address and check it matches the original request.
Google recommends this exact FCrDNS process for verifying its own crawlers, and it works the same way for Bingbot or any other legitimate automated visitor. Automate this check for your highest-volume suspected crawlers and reserve manual spot checks for anything unusual, since many malicious scrapers now spoof User-Agent headers specifically to look like trusted search bots.
Checklist for auditable filtering with QRlytics analytics
Building a filtered view you can trust comes down to a short sequence: preserve every raw log entry, flag suspected bot hits rather than deleting them, then layer a bot-score threshold and a deduplication window on top to calculate your human-scan figure.
Our QR code analytics dashboard keeps that raw data accessible alongside filtered totals, and CSV export lets you pull the full dataset for your own audit if a number looks off. Because our codes stay live once created during an active subscription, you can keep adjusting your filtering rules without ever needing to reprint a physical code. That separation between what was logged and what gets reported is the part worth protecting as you tune any filter.
Why layered, auditable filtering beats one-off rules
The temptation is always to write one aggressive rule, block anything under a score of 30, and move on. That approach trades measurement integrity for a quieter dashboard.
A better habit is to document your filtering policy somewhere your team can actually find it, and revisit the thresholds every few months. Bot behaviour shifts, and a rule that worked well last year can quietly start hiding real engagement.
— The
Report scan numbers you can stand behind
Accurate QR reporting starts with the same habit that makes any analytics trustworthy: keep the raw record, apply your filters on top, and be ready to show your working if someone asks.
Our platform is built around that separation. Every code created during an active subscription keeps working, even if billing lapses, so you’re never rebuilding a campaign from scratch while you’re still tuning filter thresholds. Analytics come with bot-flag fields and full CSV export, which means the filtered human-scan number you publish always traces back to a raw log you can re-check.
- Start on the Free plan with no credit card required, then move to Pro for additional features. Current prices are detailed on our pricing page.
- Generate a dynamic QR code now and watch filtered scan data arrive in real time as you test your campaign.
If you’re running QR codes at events where check-in volume and queue timing matter, this organiser playbook on cutting entry time is a useful companion read for setting deduplication windows that match real foot traffic.
FAQ
What is the FBI warning about QR codes?
The FBI has warned about criminals using residential proxy networks to disguise automated and malicious traffic as ordinary home internet connections, making bot activity harder to spot by IP address alone. This is one reason relying on a single signal, like IP reputation, is no longer enough on its own.
How to make QR unreadable?
Damaging, obscuring or distorting enough of a QR code’s pattern, particularly the corner squares, stops scanner apps from decoding it. This isn’t something we’d recommend for any legitimate marketing or operational code, since it defeats the purpose of publishing one in the first place.
Is QR bot safe?
Automated bot traffic hitting your QR code isn’t inherently dangerous to you as the code owner, but it does inflate your scan counts if left unfiltered. Combining bot scoring, crawler verification and deduplication, as outlined above, keeps your reported numbers accurate without needing to block anything outright.
What is the QR bot app?
There’s no single standard product called a “QR bot app”: the phrase generally refers to automated scripts or services that scan, generate or interact with QR codes programmatically, including the uptime monitors, email scanners and crawlers that inflate analytics data. The filtering techniques described in this guide apply regardless of which specific automated tool is generating the hits.
Sources
- Bot scores · Cloudflare bot solutions docs
- Verify Google requests
- MultiFrameResultCrossFilter Class - Dynamsoft Capture Vision Flutter
- Building unique, per-customer defenses against advanced bot threats in the AI era | Cloudflare Blog