How third-party and automated requests can affect visit analytics.
A QR code scan does not always result in a single request generated directly by the person scanning the code. Third-party QR scanners, security services, corporate networks, email and messaging applications, and other intermediary systems may automatically request or inspect the encoded URL before or in addition to the user’s actual browser visit.
These automated requests can sometimes closely resemble legitimate browser traffic and may therefore be recorded as visits when they cannot be reliably identified as automated activity. As a result, what appears in analytics as two separate visits — or as a visit with unexpected location, network, device, or language characteristics — may actually represent automated processing and the subsequent human visit associated with the same QR code scan.
Unlike a scan performed directly through a device's native camera app, a scan using a third-party application may generate additional requests beyond the user's actual browser visit.
Some third-party QR scanners, security applications, corporate networks, email security systems, and messaging or email applications may independently request a URL before or in addition to the user's actual visit. These automated requests can be used for several purposes, including:
- Security and reputation checking. Determining whether the URL or destination is known or suspected to be associated with fraud, spam, or other unsafe activity.
- Malware and phishing detection. Automatically requesting or analyzing the URL and destination content to identify potential malware, phishing attempts, malicious downloads, or other security threats.
- Redirect resolution. Following redirects to determine the actual final destination of a shortened, dynamic, or redirected URL.
- URL rewriting and inspection. Rewriting or routing URLs through a security service so the destination can be inspected before or when the user follows the link. This is commonly used by corporate email and network-security systems.
- Link preview generation. Retrieving information about the destination, such as the page title, description, or other metadata, before presenting the link to the user.
- Content inspection. Examining the destination page, response, headers, or downloaded content for suspicious or prohibited behavior.
- Indexing or caching. Recording or caching information about URLs and destinations for the application's or security provider's own services, databases, or future lookups.
- Analytics or telemetry. Recording information about scanned, accessed, or processed URLs for usage analytics, diagnostics, performance monitoring, security intelligence, or other operational purposes.
These requests may originate from the scanner provider's servers rather than from the user's device. As a result, they may use a different User-Agent, IP address, geographic location, network, language, or locale than the person who actually scanned the QR code. The language reported by an automated request may therefore reflect the scanner application's configuration, server environment, or request headers rather than the user's actual device or preferred language.
In some cases, an automated request may use a browser-like User-Agent and otherwise closely resemble a normal human visit. When the request does not contain characteristics that allow it to be reliably identified as a bot, crawler, security scanner, prefetch, or other automated traffic, the analytics platform will record it as a visit because, from the information available at the time of the request, it is indistinguishable from legitimate human traffic.
For example:
QR Scan → Third-Party Scanner Automated Request → Recorded Visit → Destination Validated → User Opens Destination → Actual User Visit
This can potentially produce two requests associated with what the user perceives as a single scan: one generated automatically by the third-party service and another generated when the person actually opens the destination.
The two requests may also look substantially different. For example, the automated request may originate from a cloud data center in the United States and report a different IP address, geographic location, network, User-Agent, or language, while the subsequent human visit originates from the user's mobile device in China and reflects the user's actual device and network characteristics.
Therefore, in these cases, a request generated shortly before the apparent human visit should not automatically be interpreted as a second person scanning the QR code, nor should it necessarily be considered an error or anomaly. It may instead represent an automated request associated with the same QR code scan.It may instead represent an automated request generated by a third-party QR scanner, security service, link-preview system, messaging application, browser, or other intermediary service as part of processing, validating, or inspecting the same QR code scan. Please also note that we filter known bots at both the reverse-proxy and server levels, using established bot-detection mechanisms as well as custom identification and filtering rules developed by Delivr. These controls are intended to prevent known automated traffic from being recorded as legitimate human visits.
The large majority of QR codes today are scanned using native smartphone functionality, such as the iPhone Camera or Android Camera/Google Lens. A smaller percentage are scanned through third-party QR scanner applications. There is no authoritative industry-wide measurement of the exact percentage, and usage can vary considerably by device, region, and user population. Third-party and in-app QR scanning may also be more prevalent in some Asian markets, where QR codes are deeply integrated into mobile applications, messaging, payments, and other everyday digital services.
