← All articles

Link and QR Code Analytics When Trackers Are Blocked

Learn how short links record link clicks and QR code scans when client-side analytics trackers are blocked, while preserving UTM campaign parameters.

Link and QR code analytics when trackers are blocked

So you pushed out a campaign, stuck a QR code on a poster, dropped a link into a chat - and the numbers in your dashboard come back looking a bit sad. Don't jump straight to "nobody cared." More often, something between the click and your analytics script quietly killed the signal.

Where visits go to disappear

Most analytics tools (yes, GA4 included) work the same way: a script loads on the page, the script sets a cookie or writes something to storage, the cookie ties the visit to a session. If anything along that chain breaks, the visit just doesn't exist as far as the dashboard is concerned.

Plenty of things can break it:

  • browsers that block trackers by default
  • ad blockers and privacy extensions
  • corporate firewalls and DNS filters
  • antivirus doing a bit too much
  • JavaScript turned off
  • people saying "no" to the consent banner
  • in-app browsers that quietly do whatever they want

That's not your campaign failing. It's just the measurement layer missing everything that happened before the page could even load.

How common is tracker blocking: built-in browser protections share 23.85% (Safari 15.31%, Edge 5.21%, Firefox 3.33%) versus Brave with 120.9M active users and ad blockers with ~912M users

A short link sits in the middle of the click. The request hits the short-link server first, the server logs it, and only after that the visitor gets bounced to the real page. Recording happens before any of the page-level tracking can run - no JavaScript, no cookies, nothing to block.

Worth being clear about what this actually counts: clicks and scans, not confirmed humans. One person clicking three times shows up as three. So does a bot checking the link. It's a useful complement to your site analytics, not a swap-in replacement.

Making QR codes measurable

A QR code on its own is just a picture of a URL. Scanning it tells you nothing.

Put a short link behind it, though, and you suddenly have a flow you can actually measure:

QR code -> short link -> request logged -> redirect -> landing page

This is where it really earns its keep - anywhere the code lives outside a browser tab. Packaging. Flyers. Posters. Menus. Event signage. Tickets. Slide decks. Product inserts. Once that stuff is printed, you can't change it, but the URL behind the code can still be tracked, and even swapped out later if the campaign needs to go somewhere different.

Two layers, two numbers

In real life you usually end up with two counts going on at once. The short-link service logs the request. The site analytics (when it's allowed to run) logs what happens on the page after that.

Those numbers won't line up. They rarely do, and that's fine. They're measuring different things at different points in the journey. The gap between the two isn't a bug. It's information about where your measurement is and isn't reaching.

Left on their own, redirect logs would be full of noise - security scanners, monitoring services, and especially link previews from social networks and messengers. The moment you paste a link into Slack, Telegram, WhatsApp, or post it on X, those services fetch the URL to generate a preview card. That fetch is a real request, but nobody is actually looking at your page yet.

MeoVC filters these out. Known bot user agents, headless browsers, prefetchers, and social-preview crawlers don't end up in the redirect statistics. So the numbers you see in the dashboard lean toward actual clicks and scans rather than automated traffic.

There's a catch, though. Any bot that bothers to send a normal-looking User-Agent and behaves like a regular browser is hard to tell apart from a human. The same is true for residential proxy networks and headless browsers that mimic a real device. Filtering is heuristic, not perfect - it's good at cutting the obvious noise, less reliable against something deliberately trying to blend in. Worth keeping in mind when you see a number that looks a little too clean or a little too high.

UTM still works

You don't have to give up campaign tagging to use a short link. The destination URL behind it can carry a full set of UTM parameters. The link you print or share stays short, the QR code stays scannable, and any analytics tool that reads UTM still credits the campaign. The redirect gets counted by the short-link service even if the destination script never gets a chance to run.

For example:

https://example.com/product?utm_source=poster&utm_medium=qr&utm_campaign=summer_sale

UTM isn't a Google-only thing either - it's a shared convention. Most platforms know what to do with it.

MeoVC Relay

If you need more than just the standard UTM tags, MeoVC has a feature called Relay. It forwards query parameters from the short link to the destination, and you get to pick how much goes through.

UTM parameters only - just utm_source, utm_medium, utm_campaign, utm_content, utm_term, and ref. Keeps things predictable when all you need is campaign attribution.

Pass all parameters - every parameter on the short link gets copied over, same keys, same values. Handy for affiliate IDs, promo codes, internal campaign IDs, pre-filled form values, anything a downstream integration needs.

Quick reminder while we're here: don't put anything sensitive in a URL. Passwords, tokens, personal data - all of that can end up in browser history, server logs, referrer headers. URLs are public. Treat them that way.

What it can't do

Recording a redirect doesn't need a cookie on the destination page, which keeps things lighter from a privacy angle. It doesn't get you out of privacy obligations, though. What you collect, how long you keep it, what you link it to - that still matters legally.

It also won't show you everything. Without a real consent flow or an identity layer, you're not going to reliably recognize the same person across visits or devices, you won't see the full path from first click to final purchase, and you won't always be able to tell a human from a bot. It's a useful signal. Just don't mistake it for the full picture.

How this plays out

Say a company prints a QR code on a product brochure. Behind the code sits a MeoVC short link. Someone scans it, MeoVC logs the request and bounces them to a campaign page with UTM parameters attached. If the page's own analytics runs fine, great - you get time on page, clicks, conversions on top. If a browser or extension blocks the script, that part is lost. But the original scan is still sitting in MeoVC's redirect statistics, completely independent of what the destination page did or didn't do.

That's the real value of this setup. You won't catch every visit. But you have a measurement layer that doesn't depend on the destination page cooperating - and for link tracking without cookies and QR code tracking without cookies, that's often the difference between having some numbers and having none at all.

Try a measurable link / QR code

Frequently asked questions