QR code retargeting: turning print scans into ad audiences on Meta, Google, and TikTok

Most guides on QR code retargeting stop at "add a Facebook pixel to your landing page" and call it done. Several go further and describe the whole thing as cookieless marketing, which is not true on any of the four major ad platforms. None of them mention that the biggest reason a scan quietly fails to reach the audience it should is not the QR code at all, but how fast the visitor abandons the page it redirects to. This is the version that covers all of it: what actually happens between a scan and an ad audience, why the "cookieless" claim is wrong, what consent law really requires, what Apple's privacy rules do and do not restrict, and how to build the pixel-plus-server-side setup that survives contact with a real mobile browser.

What QR code retargeting actually is

A QR code cannot retarget anyone by itself. It is a link. Retargeting happens on the page the code redirects to, through the same ad-tech mechanism that powers retargeting from a Google search or an Instagram story: a small script on that page, usually called a pixel or a tag, tells an ad platform "this browser was just here."

The chain runs in five steps. The phone's camera reads the code and follows the redirect. The redirect resolves, normally as a fast server-side 301 or 302, to the destination URL. The destination page's HTML loads and the tag's JavaScript downloads and executes, for example Meta's fbevents.js or TikTok's pixel script. The tag fires a network beacon carrying an identifier: a cookie value, a click ID, or hashed contact data. The ad platform matches that beacon to an existing profile and, on its own schedule rather than instantly, adds the browser or the person to an audience you can target with a future campaign.

Nothing in that chain is unique to QR. What is unique to QR is that the visitor arrives with no browsing history on your site and no prior interaction with your ad account, so the first pageview after the scan is also very often the only chance the tag gets to fire before the fastest visitors close the tab. That single fact is why the failure modes below matter more here than they do for a normal web visit.

No, it is not cookieless

Several QR vendor pages describe pixel-based retargeting as "cookieless marketing." It is worth being precise about this, because it shapes both what you can promise a client and what consent you need to collect. Check each platform's own documentation and the pattern is consistent: every one of them names a cookie as part of how matching works.

Meta's developer documentation states that the Pixel "relies on Facebook cookies, which enable us to match your website visitors to their respective Facebook User accounts," and names two specific ones: _fbp, a randomly generated first-party ID cookie created automatically on first page load, and _fbc, which stores the ad-click identifier from a fbclid URL parameter and expires after 90 days. Google's support documentation describes the Google Ads tag as storing "cookies that contain information about the interaction, and a unique identifier for a user or the ad click that brought the user to your site," keyed to the click ID your ad generated. TikTok's help centre confirms the TikTok Pixel uses first-party cookies by default, plus third-party cookies unless you turn them off, "to help match events with people who engage with your content on TikTok." LinkedIn's Insight Tag sets cookies and, outside the EU, EEA, UK and Quebec, an additional pseudonymous identifier called the LinkedIn Ads ID, which LinkedIn describes explicitly as "an additional signal on top of cookies," not a replacement for them.

Read literally, that is four separate platforms confirming, in their own documentation, that cookies are core to how a QR-driven retargeting audience gets built. A QR scan reaches the same cookie-based stack as any other web visit; the code just changes how the visitor arrives at the page that sets it. Calling it cookieless is not a simplification, it is a factual error, and one with consequences for the next section.

The consent problem a QR scan creates

Because the cookies are real, the consent rules that apply to any other tracking pixel apply here too, and a QR scan makes the timing tighter than most agencies expect.

Under the ePrivacy Directive, storing or reading information on a user's device requires prior consent unless it is strictly necessary to deliver a service the user explicitly asked for. A retargeting pixel is not that. The European Data Protection Board's Guidelines 2/2023, finalised in October 2024, address tracking pixels directly and conclude that placing one on a page counts as "storage" through the device's caching mechanism, and the pixel then "phoning home" to the ad platform is a separate act of "gaining access," so a marketing pixel needs the same prior consent as a cookie regardless of whether it happens to use one. That closes the loophole some vendors have relied on, arguing a 1x1 tracking pixel is somehow different from a cookie. Under current EDPB guidance it is not.

GDPR's own definition of consent, in Article 4(11) and Article 7, requires it to be freely given, specific, informed, and given through a clear affirmative act; Recital 32 rules out silence, pre-ticked boxes, or simply continuing to browse as valid consent. France's CNIL has applied this concretely to marketing tags since April 2021: no read or write to a visitor's device before they have said yes.

Here is the QR-specific wrinkle. A visitor who clicks a search result or an ad has usually already passed through your cookie banner once, on an earlier visit, or arrives via a link where a consent management platform has time to load before anything fires. A QR scan often lands cold, straight from a physical object, on a single dedicated page that has one job: redirect and track. If your retargeting tag is the first thing that page does, you are firing it before consent exists, on every single scan, which is a clean Article 5(3) violation rather than an edge case. The fix is mechanical, not legal: gate the retargeting tag behind your consent banner using a tool like Google's Consent Mode or your CMP's own blocking rules, so the QR landing page behaves exactly like any other first-party-visited page, not like a shortcut around the banner.

Outside the EU/UK/EEA, the calculus flips. California's CCPA and CPRA use an opt-out model: a business may share data for cross-context behavioural advertising by default, until the visitor exercises a "Do Not Sell or Share My Personal Information" right, either through a posted link or an automated opt-out preference signal such as Global Privacy Control, which businesses have had to honour automatically since 1 January 2026. Practically, that means the same QR landing page needs two different defaults depending on where the visitor is standing when they scan: gated in Europe, open with an honoured opt-out signal in California. Most consent management platforms handle this with geolocation rules; check yours does before the print run goes out under both jurisdictions.

For the wider picture on what a tracked scan collects and how to stay compliant end to end, see are QR codes GDPR-compliant?

What Apple's privacy rules actually restrict

Agencies commonly assume Apple's App Tracking Transparency framework is the thing standing between a QR scan and a clean retargeting audience. It mostly is not, and getting this wrong leads to fixing the wrong problem.

ATT, which has required apps to request permission before tracking users or reading the IDFA advertising identifier since iOS 14.5 in April 2021, governs native app behaviour. Apple's own developer FAQ is specific about the boundary: ATT applies to an in-app web view only when it is used "for app functionality," and explicitly does not apply when the web view is "enabling the user to navigate the open web." A QR scan opens the phone's camera, then hands off to the default browser or a web view acting as plain web navigation, which is squarely on the far side of that line. ATT is very unlikely to be the mechanism blocking your QR retargeting pixel, because it was never built to govern this path in the first place.

The rule that actually matters is Safari's Intelligent Tracking Prevention, and it is more restrictive than most agencies realise. ITP has blocked all third-party cookies by default since 2020, with no exceptions. More specifically for QR: when ITP detects "link decoration," meaning tracking parameters appended to a URL, which describes almost every QR redirect, it caps the lifetime of any cookie set by that page's own JavaScript to 24 hours, rather than the longer window the same tag would get on a normal referral. Meta's _fbc cookie is documented as lasting 90 days; on a QR landing page opened in Safari, ITP's link-decoration rule can cut that down to one day. This is the real, citable, technical reason a QR retargeting audience skews towards the day of the scan and thins out fast after that on iPhone traffic specifically, and it is worth explaining to a client in those terms rather than a vaguer "Apple privacy stuff."

Add to that where a QR scan is actually likely to open: inside Instagram's or TikTok's own in-app browser, if the visitor tapped through from a story or a shared link rather than the native Camera app. These in-app browsers commonly run their own separate cookie jar rather than sharing Safari's, so a visitor who scans from a printed poster into the native camera, then later clicks a related link from inside Instagram, can look like two different, unmatched people to the same pixel. This is well documented as a technical possibility (security researcher Felix Krause demonstrated in 2022 that Instagram's in-app browser injects tracking-capable script into third-party pages it renders) but there is no public data on exactly what each platform does with it today, so treat it as a reason your numbers will be noisier on social-referred scans, not as a specific privacy breach to allege.

The real reason scans go missing from the audience

The most common technical explanation for QR retargeting under-counting is wrong: it is not that a fast redirect somehow "outruns" the pixel. A server-side 301 or 302 resolves before any HTML or JavaScript runs at all, so redirect speed has nothing to fire early or late against. The pixel lives on the destination page, and the actual risk window opens the moment that page starts loading and closes the moment the visitor leaves it. A visitor who scans, glances at a slow-loading page, and backs out in under a second can leave before the tag's script has even finished downloading.

Browser vendors have built specific tooling around exactly this problem, because it predates QR and affects any page a visitor might abandon quickly. The sendBeacon() API exists so a page can queue a small analytics payload that survives navigation away, and current browser guidance (from Chrome's own engineering documentation) recommends firing it from the visibilitychange event, checking that the page has gone hidden, rather than from unload or beforeunload, which Chrome is actively deprecating because they "do not fire in many typical unload situations, including closing a tab from the tab switcher on mobile." An independent empirical study of beacon delivery reliability found roughly 72% of unload-time beacons and closer to 93% of beacons fired earlier, at page-load time, actually reached their destination, with iOS Safari singled out as the least reliable case for anything deferred to the moment of leaving. None of that is an official platform statistic, but it lines up with what agencies see in practice: mobile visitors on slow connections are the ones retargeting quietly fails to catch.

The practical upshot for a QR landing page: keep it light enough to render and fire its tags well within the first second or two, do not add anything that delays the tag behind other scripts, and if you use Google Tag Manager, check that any trigger involving a click-through or a form on that page uses GTM's "wait for tags" option rather than assuming the tag has already fired. None of this fixes a slow connection, but it removes every avoidable delay you control.

Adding a pixel to a QR landing page, step by step

The reliable way to do this is through Google Tag Manager rather than hand-editing the page, because it gives you one place to manage every platform's tag and to scope consent gating.

Create a GTM account and a Web container at tagmanager.google.com, then install the two snippets GTM gives you: the main script as high in the page's <head> as possible, and the <noscript> fallback immediately after the opening <body> tag. For each platform, add its tag using the official template from GTM's Template Gallery rather than pasting raw vendor script: Meta publishes its own Pixel template (built and maintained on GitHub under the facebook organisation) that supports an Event ID field specifically for deduplicating against server-side events, which matters once you add a Conversions API alongside it, covered next.

Scope the trigger narrowly. Because a QR landing page is usually one dedicated URL rather than a whole site, fire the retargeting tag on that specific page path, not on GTM's default "All Pages" trigger. This keeps the tag, and your consent gating, contained to exactly the page it belongs on rather than leaking onto the rest of the site. Publish through "Submit" then "Publish and Create Version," not just "Create Version" alone, which only saves a draft; every real publish creates a version you can roll back to if something breaks.

Audience size and timing: what to tell a client

Agencies get asked two questions before every campaign: how big does the audience need to be, and how soon can we use it. The honest answer is that this varies by platform and some of the official numbers are less settled than they look.

Google Ads' Customer Match needs a minimum of 100 uploaded records. Its Display, Search and YouTube remarketing segments need a minimum of 100 active visitors within the last 30 days for lists created or refreshed since 1 February 2024, though Google has a separate, seemingly unreconciled support page still stating a 1,000-cookie minimum for Search remarketing lists specifically. Given Google has changed this number before, check the current Google Ads UI rather than quoting either figure to a client as fixed. TikTok's Custom Audiences need 1,000 total matched users before an ad group can use them. LinkedIn's Matched Audiences need 300 matched member accounts before the platform marks the audience "Verified" and usable. Meta publishes no fixed minimum for a website Custom Audience; its own guidance is qualitative, to wait for "several hundred people" before activating one. The "100" figure agencies often quote for Meta actually comes from the separate minimum source size for a Lookalike Audience, not from Custom Audience delivery, and the two are easy to conflate in a client deck.

Timing is similarly uneven. Google Ads starts matching visitors within seconds of a tag firing, but a newly created list can take 48 to 72 hours to fully populate. LinkedIn states plainly that a Matched Audience can take up to 48 hours to process. Meta and TikTok publish no official processing-time figure at all; both only say population depends on your traffic and when the tag went live, with no backfill for scans before that date. Promise a client a number for Meta or TikTok and you are promising something neither platform commits to in writing.

Server-side tracking closes the gap a pixel cannot

Every platform's own documentation converges on the same admission: a browser-only pixel loses events to connectivity issues, page-load failures, ad blockers, and exactly the ITP and in-app-browser behaviour covered above, and a server-side connection recovers a meaningful share of them. Meta calls this the Conversions API, which sends the same events from your server directly to Meta, deduplicated against the browser Pixel using a shared event ID, and states it exists to "share website events that the Pixel may lose due to network connectivity issues or page loading errors." TikTok's Events API uses almost identical language: "connectivity issues and browser inconsistency can impact conversions reported via Pixel," recommending both run together. Google Ads offers Enhanced Conversions, which hashes first-party data such as an email address before sending it, matched against Google's own signed-in-user data, to recover conversions the cookie-based tag alone would miss. LinkedIn's Conversions API sends server-side events that reduce reliance on cookie matching entirely.

For QR specifically, where the traffic is overwhelmingly mobile and disproportionately hits Safari's ITP restrictions and in-app browsers, server-side tracking is not an optional upgrade, it is the piece that makes the numbers a client sees roughly match what actually happened. If you only build one thing beyond the basic pixel from this guide, make it the platform's Conversions API or equivalent, run alongside the pixel with matching event IDs so the platform deduplicates rather than double counts.

For the attribution question this whole setup is trying to answer, see how it compares with a UTM-based approach in QR code UTM parameters, and for where this typically gets deployed at volume, see QR codes for direct mail and QR codes for events and trade shows.

Frequently asked questions

Is QR code retargeting cookieless?

No. Meta, Google Ads, TikTok and LinkedIn all document cookies as part of how their pixel or tag matches a visitor to an audience: Meta names _fbp and _fbc specifically, Google Ads keys a cookie to the click ID, TikTok uses first- and third-party cookies by default, and LinkedIn's pseudonymous ID is described as an addition to cookies, not a replacement. A QR scan reaches the same cookie-based stack as any other web visit.

Do I need consent before retargeting someone who scans a QR code?

Yes, in the EU, UK and EEA. The European Data Protection Board's 2024 guidance treats a tracking pixel the same as a cookie under the ePrivacy Directive's consent requirement, so it must be gated behind affirmative consent, not fired on page load. Outside those regions, rules like the CCPA/CPRA instead give visitors an opt-out right, including via an automated Global Privacy Control signal that businesses must honour.

How long does it take for a QR scan to show up in a retargeting audience?

It depends on the platform. LinkedIn states up to 48 hours. Google Ads starts matching within seconds but a new list can take 48 to 72 hours to fully populate. Meta and TikTok publish no official processing time, only that it depends on traffic volume and when the tag was first live.

What's the minimum audience size for retargeting?

Google Ads Customer Match needs 100 records; its Display/Search/YouTube segments need 100 active users in the last 30 days for newer lists (check current Google Ads guidance, as this figure has changed before). TikTok requires 1,000 matched users. LinkedIn requires 300 for a "Verified" audience. Meta sets no fixed minimum, only qualitative guidance to wait for several hundred people.

Does Apple's App Tracking Transparency block QR code retargeting?

Not directly. ATT governs native app tracking and the IDFA identifier, and Apple's own documentation excludes in-app web views used for open-web navigation, which is what a QR scan typically triggers. The restriction that actually matters is Safari's Intelligent Tracking Prevention, which blocks third-party cookies outright and caps first-party, JavaScript-set cookies to 24 hours on any URL it flags as carrying tracking parameters, exactly the shape of most QR redirect links.

Why isn't my retargeting pixel picking up all my QR scans?

The most likely cause is not the QR code or the redirect, both of which resolve before any tracking script runs. It is how quickly the visitor abandons the destination page relative to how long the tag's script takes to download, execute and fire, combined with ITP's 24-hour cookie cap on decorated URLs in Safari and the separate cookie jar many in-app browsers use. Keep the landing page light, fire tags early, and add server-side tracking to recover what the browser pixel misses.

Should I use a pixel, a server-side Conversions API, or both?

Both, deduplicated. Every major platform documents the same reasoning: a browser pixel alone loses events to connectivity problems, ad blockers and browser privacy restrictions, and a server-side connection (Meta's Conversions API, TikTok's Events API, Google's Enhanced Conversions, LinkedIn's Conversions API) recovers a meaningful share of them when run alongside the pixel with a matching event identifier.

Can I retarget QR code scanners on TikTok or LinkedIn, not just Meta and Google?

Yes, using the same underlying mechanism: a tag on the landing page, added and scoped the same way through Google Tag Manager, with each platform's own minimum audience size and processing time.

What's the difference between QR code retargeting and QR code analytics?

Analytics counts and describes what happened: how many scans, from where, on which device. Retargeting turns those same visitors into an audience you can advertise to again on another platform. They can run from the same scan, but the second only works if a retargeting tag, correctly consented, is present on the destination page. For the analytics side, see QR code analytics: which scan metrics matter.

The short version

QR code retargeting is not a special or cookieless technique; it uses the same pixels, the same cookies, and the same consent rules as any other web retargeting, reached via a scan instead of a click. Gate the tag behind real consent in the EU/UK, respect opt-out signals in California, and stop worrying about Apple's App Tracking Transparency, which almost never applies here, in favour of Safari's Intelligent Tracking Prevention, which does, and which quietly caps your tracking cookie to 24 hours on most QR links. When the numbers still look thin, look at how fast your landing page fires its tag relative to how fast mobile visitors leave, not at the QR code itself, and close the gap with a server-side Conversions API or Events API connection rather than a heavier pixel. Check each platform's current audience minimum and processing time before you put a number in front of a client, because several of them move. Build this once, as a scoped Google Tag Manager setup on your QR landing pages, and every future campaign inherits it for free.