GDPR for QR Code Analytics: A Practical Compliance Checklist

GDPR for QR Code Analytics: A Practical Compliance Checklist

A QR code can send a phone through several services before a page appears. A scan might reach a short-link platform, pass through an analytics provider, and then load a campaign page with its own cookies. Each step can affect what information is collected and who handles it.

GDPR for QR code analytics starts with the full scan journey, not just the dashboard where scan totals appear. Use this checklist before launch, then revisit it when a destination, vendor, or tracking setting changes. Legal obligations depend on the setup and the people affected, so confirm uncertain points with a qualified adviser.

1. Before launch: Map the scan journey

Start with the printed code. Write down every destination and service the phone contacts after a scan, including any redirect, short-link service, landing page, tag manager, analytics tool, and advertising pixel. A campaign poster that points to a short URL may involve more processing than the visible destination suggests.

Keep a copy of the actual link and test it on a phone. Record each redirect in order, the organization operating it, and the data fields collected at that stage. For example, a redirect service may record a timestamp and IP address, while a landing page may also trigger a cookie-based analytics event.

Build a simple inventory for each step. Include the purpose, data collected, recipient, storage location if known, and how long the record remains available. Mark unknowns for follow-up rather than assuming that a vendor collects nothing because its dashboard displays only totals.

• QR code: Identify whether the code is static or points to an editable redirect.
• Redirect: Check whether the service logs IP addresses, device details, or scan times.
• Landing page: List cookies, pixels, forms, and analytics scripts that load.
• Downstream tools: Record any CRM, email platform, or advertising account receiving events.

A spreadsheet is often enough for a small campaign. Give each QR code a campaign name, such as “Spring menu — café window,” so a scan record can be tied to the right printed item without relying on a vague label like “QR 4.”

2. Assign responsibility and choose a lawful basis

Identify who decides why the scan data is collected and how the campaign uses it. That organization may be a controller, while a provider acting only on its instructions may be a processor; roles depend on the actual processing and arrangements. A contract label alone does not settle the question.

For each purpose, document the proposed lawful basis and the reason it fits. Measuring aggregate visits, attributing purchases, and building an advertising profile are different purposes; do not treat them as one general “analytics” activity. If a retailer and an agency jointly decide what data to collect and how to use it, assess their respective roles and responsibilities.

Check whether applicable privacy and electronic-communications rules require consent for cookies, pixels, or similar tracking technologies. A QR scan is not automatically consent to tracking. If consent is needed, make sure the relevant choice appears before the non-essential tracking begins, and test that declining does not silently trigger the same scripts.

Consent is not a label. Keep evidence of the choice, such as the consent record and the version of the notice shown, where needed. For a campaign that uses only a basic redirect and aggregate counts, document why that limited measurement is necessary and check whether any personal data is still processed.

Review third-party terms before launch. If a QR campaign sends visitors to a Google service, check the applicable privacy policy – privacy & terms and determine which settings or notices apply to your use; do not assume the provider’s notice replaces yours.

3. Prepare clear, accessible notices

Tell people what happens when they scan. A notice should identify the organization responsible, the purposes of collection, the kinds of data involved, the recipients or recipient categories, and the retention approach, along with other information required for the situation. Avoid saying only “we use analytics” when the page also sends events to an advertising platform.

Make the notice available before or when collection begins so people can understand the processing as it starts. A short line beside the code can direct people to a full privacy notice, but a notice hidden several taps into the destination may not explain a redirect that has already recorded scan information.

Keep the first explanation readable on a phone. For a restaurant table tent, for example, place a short privacy link beside the QR code and make the full notice accessible on the menu page. Use plain descriptions such as “we record the time of a visit to count menu scans” rather than relying on terms like “event processing.”

Check the notice against the journey map. If the code first opens a short-link platform, make sure your explanation covers that collection where appropriate, not only the analytics script on the final page. Include contact details and a clear route for privacy questions, such as a monitored email address or web form.

Where Google tools are part of the campaign, review the relevant google terms of service – privacy alongside the service configuration and your own obligations. A vendor’s terms can help identify features and data routes, but they do not automatically provide a complete notice for your campaign.

4. Minimize data and set retention limits

Collect only fields needed for a defined purpose. If the campaign team needs to compare scans by poster location, a campaign-specific code or broad location label may be sufficient; collecting precise GPS coordinates or a full device fingerprint may add risk without answering a useful question.

Review IP address handling, device identifiers, timestamps, and location data separately. Ask whether each field is necessary, whether it can be shortened or aggregated, and whether the analytics can work without it. Whether a field is personal data depends on the context and how it is used.

Set a retention period for raw scan events and linked records. A useful schedule might distinguish identifiable event logs from aggregated campaign totals, then state when each is deleted or converted so individuals are no longer identifiable. Choose periods based on operational need and applicable requirements rather than leaving data indefinitely because a provider’s default setting allows it.

Keep a deletion record. For instance, if raw logs are scheduled for removal after an approved period, note the owner, the system, and how the deletion is checked; include backups and exports in the deletion plan. If the campaign does not need to connect a scan to a named customer, avoid joining scan data to a CRM record simply because both tools are available.

5. Review analytics providers and data routes

List every provider that receives scan-related information, including the QR platform, hosting company, analytics service, tag manager, and any agency with account access. For each one, check the processing terms, instructions, security commitments, subprocessor information, and support for deletion or access requests. Ask for answers in writing when the public documentation leaves a material gap.

Check where data is stored and where it can be accessed. A provider may host information in one country while support staff or subprocessors access it from another, so review the full route rather than the marketing page’s headline location. Review whether data is transferred or accessed outside the relevant jurisdiction, and identify applicable safeguards before launch.

Confirm that the contract covers the processing you actually plan to do. If a vendor receives scan identifiers for campaign measurement but its settings also enable advertising features, disable features you do not need and confirm the change in the account. A signed agreement does not make an unsuitable configuration safe by itself.

For an API-based redirect or analytics integration, document the endpoint, credentials, and data fields sent in each request. Keep credentials out of public QR destinations and staff documents. Limit account permissions to the people who manage the campaign, and review access when an agency contract ends.

6. Test user requests and campaign changes

Write down how the team will route a request to access, erase, or object to processing, and how it will record a consent withdrawal where consent applies. Identify the rights, response periods, and exceptions that apply to the relevant circumstances and jurisdictions. Assign an owner and backup contact.

Test the process with a sample record before printing or distributing codes. Check whether the team can locate a scan record across the redirect platform, analytics account, and CRM if those systems are linked. If records cannot be found without an identifier, document the limitation and decide whether the campaign should collect that identifier at all.

Retest after a material change. Recheck the journey when a vendor is replaced, a landing page adds a pixel, the destination changes, or a new audience is targeted. A redirect update can alter data collection even when the printed QR code stays exactly the same.

Keep a dated campaign file with the journey map, notice version, lawful-basis assessment, provider review, retention schedule, and test results. Before approving the next print run, compare the live scan path with that file and resolve any new data collection before the code reaches customers.