QR codes as first-party data: attribution that survives cookies, ad blockers, and iOS privacy

Every agency reporting a QR campaign's results eventually has to answer an uncomfortable question: how much of this attribution can you actually stand behind? For years the honest answer has been "less than the dashboard implies," because most digital attribution still leans on third-party cookies and ad-network pixels, and both are quietly losing their grip. A QR scan doesn't have that problem, not because ScanKit is clever about privacy, but because of what a scan structurally is: a first-party event, logged on your own server, with nothing to match across sites in the first place.

This isn't a workaround for a temporary inconvenience. It's a structural advantage that's becoming more valuable every year the rest of the tracking stack gets noisier. Here's what's actually happening to cookie- and pixel-based attribution, why a QR scan sits outside that decay, and how to wire scan data into a report a client can trust without asking you to caveat half of it.

The tracking stack agencies built their reporting on is quietly breaking

Safari has fully blocked third-party and cross-site cookies by default since Safari 13.1 and iOS/iPadOS 13.4, back in March 2020. That's not a recent change; agencies running campaigns to an iPhone-heavy audience have been living with it for six years. Firefox followed with Total Cookie Protection, which isolates every third-party cookie into a per-site jar so it can never be matched across domains, on by default for all users since Firefox 103 in June 2022.

Chrome is the one everyone gets wrong. The "Chrome is killing third-party cookies" headline has been circulating since 2019, but Google delayed the plan in April 2024, then abandoned the deprecation timeline entirely in July 2024, then in April 2025 dropped even the standalone "choose your tracking preference" prompt it had proposed as a replacement. Chrome still allows third-party cookies by default today; the practical effect of two years of announcements has been existing browser privacy settings, not a new blocking mechanism. If a report or a vendor pitch tells you Chrome killed cookies in 2024, that's simply not what happened, and it's worth correcting, because it understates how much of the real blocking (Safari, Firefox) has been quietly in place for years.

Layer ad blockers on top. Survey data from GWI put global ad blocker use at 29.5% of internet users in Q2 2025, with the US figure closer to a third, at 32.5%. And the platforms that used to backstop weak first-party measurement have said outright that mobile privacy changes hurt them: Meta's own CFO described the impact of Apple's App Tracking Transparency as a headwind "on the order of $10 billion" to 2022 revenue, on the company's Q4 2021 earnings call, an estimate Meta made about its own measurement, not a third-party guess.

None of this means digital attribution is broken everywhere. It means the specific mechanism a lot of campaign reporting depends on, cross-site or cross-app identity matching, has been getting weaker for six years and shows no sign of reversing. A QR scan was never built on that mechanism to begin with.

What makes a QR scan structurally different

Marketing data is usually sorted into three buckets. First-party data is what you collect directly from your own interactions with someone, no intermediary. Third-party data is aggregated by a company that never had a direct relationship with the person it describes, which is exactly the category cross-site cookies and device-graph matching fall into. Zero-party data, a term Forrester analyst Fatemeh Khatibloo coined in 2018, is what someone deliberately and proactively tells you, a stated preference or an explicit opt-in.

A scan against a ScanKit dynamic code is first-party by construction. There's no ad network in the loop deciding whether to fire a pixel, no cookie that needs to survive a cross-site redirect chain, and no probabilistic model stitching a mobile ID to a desktop session because a third of the signal got blocked somewhere upstream. The phone's camera reads the code, opens the URL, and your own redirect server logs the request. That's the entire chain.

What does that server-side log actually capture? A standard HTTP request carries a timestamp, the user agent string (which identifies device type, OS and browser), a referrer header if one is present, and the client's IP address. That's genuinely useful for campaign-level reporting, but it's worth being precise about what IP tells you: geolocation databases resolve IP addresses to country with roughly 99.8% accuracy, but IP-based location is not, and cannot be, precise enough to identify a specific address or individual. Vendor accuracy figures for finer resolution (state or region, roughly 80% in the US; city within about 50 kilometres, roughly two-thirds of the time) make the point clearly: you get a directionally useful location signal, not a household match. If you want a firmer identity signal than "someone in this city scanned this code," you need to link the scan to a form fill, an account login, or another explicit, zero-party action downstream, not stretch the log itself further than it goes.

The other structural point worth naming plainly, because vendors rarely will: nobody in the identity resolution business (AppsFlyer, Adjust, mParticle, and the rest) publishes a specific deterministic-versus-probabilistic match-rate percentage you can cite. What they will say, and what's true by definition, is that deterministic matching (an identifier tied unambiguously to one action, which is what a scan against a unique dynamic code is) doesn't carry the same estimation error as probabilistic matching (inferring that two different devices or sessions "probably" belong to the same person). A QR scan against a code you generated and control is deterministic from the start; there's no modelled estimate to distrust.

Does iOS privacy protection actually break QR code tracking?

Agencies who've had ATT quoted at them as a reason "mobile tracking doesn't work anymore" should know exactly what it covers. App Tracking Transparency governs one specific thing: an app's access to the device's advertising identifier (IDFA) and its ability to link that app's data with data from other companies' apps and websites for ad targeting or measurement. It's an App Store and SDK policy that applies inside native apps. A QR scan that opens a normal web page in Safari or Chrome isn't an app requesting IDFA access, so ATT has no jurisdiction over it at all.

Mail Privacy Protection is a separate, narrower feature: it hides a Mail user's IP address and preloads remote content (including tracking pixels) so a sender can't tell whether or when an email was opened. It's scoped entirely to Apple Mail. A QR code printed on a flyer, poster or product isn't an email open event, so MPP doesn't touch it either.

The one Apple feature that can genuinely interact with a QR redirect is Link Tracking Protection, introduced with iOS 17 and macOS Sonoma in 2023. It strips known tracking parameters out of a URL's query string before the request is ever sent over the network, but only in three specific surfaces: Messages, Mail, and Safari Private Browsing. It targets recognised tracking identifiers, the kind ad networks append to a link for cross-site click matching, not a URL's path or a standard campaign-attribution parameter. In practice this means two things for how you build a dynamic code's destination URL. First, the vast majority of QR scans, opened via a phone's camera straight into a normal, non-private browser tab, are never in a surface LTP touches at all. Second, if you also share the same tracked link by text message or email, keep any campaign identifier in the URL path or slug rather than in a query parameter that resembles a known tracker, and it will pass through untouched regardless of surface.

Do QR redirect logs need a cookie consent banner?

This is where a lot of agencies over-caution themselves out of useful data, or under-caution themselves into a compliance problem, so it's worth being exact. Under the ePrivacy rules (and the UK's equivalent, PECR), consent is triggered by storing information on, or reading information from, a user's device, the mechanism a cookie or a tracking script uses. The European Data Protection Board's Guidelines 2/2023 and France's CNIL have both been explicit that this scope isn't limited to literal cookies; IP collection that originates from reading the user's terminal equipment (which a tracking pixel does) can fall inside it too. The regulators haven't drawn a blanket line exempting all server-side IP logging as a category, so don't build your compliance position on "it's just a server log, so ePrivacy doesn't apply."

What does hold up: a QR redirect that logs a request for the purposes of running the service reliably and preventing abuse (the "strictly necessary" exemption both the ICO and CNIL recognise, the same basis that covers fraud prevention, load balancing and basic authentication) doesn't need the same opt-in consent banner as a marketing cookie dropped on the landing page afterwards. The distinction that matters is what the logging is for: operating the redirect and measuring campaign-level scan volume sits differently to setting a persistent identifier so you can retarget that visitor on other sites later, which is squarely a consent-gated activity. And regardless of the ePrivacy answer, the IP address in your log is still personal data under GDPR, so you still need a lawful basis (legitimate interest is the common choice for this), a stated retention period, and to keep the logged fields to what you actually use. Our GDPR guide goes deeper on consent design for the landing page itself; the point here is narrower: the scan log and the landing-page cookie are two different compliance questions, and conflating them is how agencies end up either over-blocking useful reporting or under-covering a real obligation.

Turning scans into attribution your client can actually trust

The practical payoff of all this is a reporting workflow that doesn't need the caveats a cookie-based report does. Start with a unique dynamic code per touchpoint, not one code reused across a poster, a flyer and a direct mail piece, so a scan is attributable to a specific placement the moment it happens; that's the same discipline behind tracking a print campaign with QR codes. Each scan is then a first-party event you can push, in real time, to wherever the client already keeps their source of truth. The general pattern is a webhook: your redirect server posts the event payload to a URL the moment it happens, rather than the CRM having to poll for it. HubSpot's custom-events API is a concrete example of the receiving end: a POST containing the event name, an ISO 8601 timestamp, a properties object, and a contact identifier is enough to attach a scan directly to a person's record, no cross-site matching required to get there.

That doesn't mean you throw out UTM parameters or GA4. It means you stop treating them as your only source of truth. Feed scans into GA4 the way we cover in our Google Analytics 4 guide so a scan shows up as its own channel instead of collapsing into "direct," but treat the server-side scan log, the one with no cookie dependency and no ad blocker to dodge, as the reconciling source when the two disagree. When you build the client report, our scan metrics guide and the campaign ROI walkthrough both assume exactly this kind of clean, deterministic event as the input; the fewer probabilistic links in the chain before the number reaches the client, the easier that conversation is.

Frequently asked questions

Do QR codes use cookies?

No. Scanning a QR code opens a URL; the redirect server can log the request (timestamp, device type, IP) without setting or reading any cookie at all. A cookie only enters the picture if the landing page itself sets one, which is a separate decision from the scan.

What data does a QR code scan actually collect?

At minimum, whatever a standard HTTP request carries: a timestamp, the user agent string (device, OS, browser), a referrer header if one exists, and the client IP address. IP resolves reliably to country level and roughly to a city or region, not to a specific person or address.

How accurate is QR code tracking compared with cookie-based tracking?

No named analytics vendor publishes a specific percentage for this comparison, so treat any number you see quoted with suspicion. What's true qualitatively is that a scan against a unique code you control is a deterministic event (this exact code was scanned at this exact time), while cookie- and cross-device attribution increasingly relies on probabilistic matching to bridge the gaps cookie blocking and ad blockers create.

Why is pixel-based ad attribution getting less reliable?

Because the identity signals it depends on are being switched off by default. Safari has blocked third-party cookies since 2020, Firefox since 2022, and Apple's App Tracking Transparency restricts cross-app identifier sharing inside iOS apps. Meta's own CFO put the 2022 revenue impact of ATT at roughly $10 billion, by Meta's own estimate.

Does iOS Link Tracking Protection break QR code tracking?

Almost never. It only strips known tracking parameters, and only inside Messages, Mail, and Safari Private Browsing. A normal scan opened via the phone's camera into a regular browser tab isn't in any of those three surfaces.

Do QR code redirects need a cookie consent banner?

Logging a request purely to run the redirect and measure scan volume can usually rely on the "strictly necessary" exemption regulators recognise. Setting a tracking or retargeting cookie on the landing page afterwards is a separate, consent-gated action. The IP in either case is still personal data requiring a GDPR lawful basis and a stated retention period.

What's the difference between first-party, zero-party and third-party data?

First-party data comes from your own direct interactions with someone. Zero-party data is what they deliberately tell you (a stated preference, an opt-in). Third-party data is aggregated by a company with no direct relationship to the person it describes. A QR scan against your own code is first-party by definition.

Can QR scan data feed into a CRM or CDP?

Yes, typically via a webhook: the redirect server posts the scan event to the CRM or CDP the moment it happens. Platforms with a custom-events API, HubSpot among them, accept an event name, a timestamp, a properties object and a contact identifier, which is enough to attach a scan directly to a person's record.

Do I still need UTM parameters if I'm using dynamic QR codes?

Yes, for channel-level reporting inside GA4 and similar tools. The point isn't to replace UTM tagging; it's to treat the server-side scan log as the reconciling source of truth when cookie-dependent tools under-report scans that ad blockers or browser privacy settings hid from them.

The short version

Third-party cookies are already blocked by default in Safari and Firefox, Chrome never followed through on doing the same, ad blockers reach close to a third of users, and platforms like Meta have said plainly that mobile privacy changes cost them measurable ad revenue. A QR scan sits outside that decay because it was never built on cross-site identity matching in the first place: it's a first-party, deterministic event your own server logs directly. iOS privacy features aimed at apps and email don't touch a normal scan, and the compliance question for the scan log is separate from, and simpler than, the consent question for a landing-page cookie. Wire each unique dynamic code to a webhook that pushes the scan straight into your client's CRM, keep GA4 for channel-level views, and use the deterministic scan log as the number you defend when the two disagree.