QR Codes — How They Work (at least…What Matters for Analytics)

I’ve had a couple of situations in the past few weeks where I’ve found myself explaining how QR codes work and what can/cannot be tracked under what situations. To whit, this post focuses on tracking considerations — not the what and why of QR codes themselves. This is an “…on data” blog, after all!

Nevertheless, the Most Basic of the Basics

A QR code contains data in a black-and-white pixelated pattern. That’s all there is to it. It can store lots of different types of data (only a finite amount, of course), but the most common data for that pattern to store is a URL. For instance, the QR code below stores the URL for this blog post:

Please, DON’T Do What I Just Did!

Here’s the key point to this whole post: the example above is a perfect example of how NOT to generate a QR code.

Two reasons:

It will not be possible to track the number of scans of the QR code

The QR code is needlessly complex, which requires a larger, more involved QR code

With the QR code above, the QR code reader on a person’s phone reads the underlying URL and routes the user to the target address:

The problem here is that, if you’re using QR codes in multiple places — printed circulars, product packaging, in-store displays, etc. — and they’re sending the user to the same destination URL, you won’t be able to distinguish which of the different physical placements is generating which traffic to that destination URL.

That’s a problem, because, inevitably, you’ll want to know whether your target users are even scanning the codes and, if so, which codes they’re scanning. It would be one thing if QR codes were inherently attractive and added to the aesthetics of analog collateral. But, like their barcode ancestors, they tend to lack visual appeal. If they’re not adding value and not being used, it’s best that they be removed!

Why, Yes, There IS a Better Way. I’m Glad You Asked.

The QR code below sends the user to the exact same destination (this post):

Notice anything different? For starters, the code itself is much, much smaller than the first example above. That’s nice — it takes up less room wherever it’s printed! Designers will hug you (well, they won’t exactly hug you — they’ll still blanch at your requirement to drop this pixelated box into an otherwise attractively designed piece of printed material…but they’ll gnash their teeth moderately less than if they were required to use the much larger QR code from above).

The trick? Well, this new QR code doesn’t include the full URL for this page. Rather it has a much simpler, much shorter, URL encoded in its pixels:

It makes sense, doesn’t it, that a shorter URL like this one will require fewer black and white pixels to be represented in a QR code format? This URL, you see, was generated using http://goo.gl — a URL shortener. You can also generate QR codes using http://bit.ly. Both are free services and both have a reputation of high availability.

Using some flavor of URL shortener is one of those things consultants and tradesfolk refer to as a “best practice” for QR code generation. What’s going on is that the process relies on an intermediate server-side redirect (of which goo.gl and bit.ly are both examples) to route the user to the final destination URL. This alters the actual user flow slightly so that it looks something like the diagram below:

That adds a little bit of complexity to the process, and, depending on the user’s QR code reader and settings therein, he/she may actually see the intermediate URL before getting routed to the final destination. That’s really not the end of the world, as it’s a fairly innocuous step with a dramatic upside. (Technically, this approach introduces an additional potential failure point into the overall process, but that plays out as more of a theoretical concern than a practical one.)

Why Is This Marginally Convoluted Approach Better?

By introducing the shortened URL, you get two direct benefits:

A smaller, cleaner QR code (we covered that already)

The ability to count the number of scans of each unique QR code

This second one is the biggie. To be clear, this isn’t going to distinguish between each individual printout of the same underlying QR code, but it will enable you to, for instance, identify scans of a code that is printed on a particular batch of direct mail from scans that are printed in a newspaper circular.

How is it doing that, you ask? Well, exactly the same way that URL shorteners like goo.gl and bit.ly provide data on how many times URLs created using them were scanned: when the “URL Shortener Server” gets a request for the shortened URL, it not only redirects the user to the full destination URL, but it increments a count of how many times the URL was “clicked” (and, in the case of a QR code, “click” = “scanned”) in an internal database. You can then access that data using the URL shortener / QR code generator’s reporting system.

But Wait! There’s MORE!

Take another look at the full URL that the shortened URL (embedded in the QR code) is redirecting to:

Notice how it has Google Analytics campaign tracking parameters tacked onto the end of it? That’s a second recommended best practice for QR codes that send the user to web sites that have campaign tracking capabilities. This is just like setting up a banner ad or some other form of off-site promotion or advertising: you control the URL, so you should include campaign tracking parameters on it! This will enable you to look at post-scan activity — did users who scanned the QR code from the product packaging convert at a higher rate on-site than users who scanned the in-store display QR code? You get the idea.

A Final Note on This — Where bit.ly and goo.gl Come Up Short

The upsides to goo.gl and bit.ly QR code generation is that they’re free and have decent click/scan analytics. The downside is that, once a short URL is generated, the target URL can’t be edited (they have their reasons).

Paid services such as the service offered by 3GVision i-nigma both offer solid analytics and allow QR codes to be edited after the short URLs (which the QR codes then represent) are created. This makes a lot of sense, because a printed QR code may stay in-market for a sustained period of time, while the digital content that supports the placement of that code may need to be updated. Or, say that someone creates a QR code and uses a target URL that is devoid of campaign tracking parameters — with a service like 3GVision’s, you can add the tracking parameters after the QR code has been generated and even after it has gone to print (any resemblance to actual situations where this has occurred is purely coincidental! …or so the blogger innocently claimed…). You can’t go backwards in time and add campaign tracking for scans that have already occurred, but you can at least “fix” the tracking going forward.

As is my modus operandi, this has been a pretty straightforward concept with a couple of tips and best practices…and I’ve turned it into a rather verbose and hyper-descriptive post. <sigh> I hope you found it informative.

9 Comments

Keep in mind that using URL shortening services will make the QR code “less complex” but you should still keep the QR codes at least 100×100 pixels at 72 dpi in size so QR code readers are able to scan them.

Great post Tim! I can hardly wait to start seeing QR codes identified “medium” in my GA reports along with the specific “campaign”. Thanks!

Rob — good point. I was just calling out that the number pixels dimensionally in the QR code would vary. Assuming the size of a “pixel” stays fixed, the shorter URL allows you to drop down to a smaller overall size for the code by dropping, say, from a 33×33 QR code to a 29×29 one.

How about encoding http://www.gilliganondata.com/qr and redirecting with a 301 in .htaccess to /qr-codes-how-they-work-at-least-for-analytics/ This has the advantage that you can change the redirect and keep the same code and easily modify the analytics.

Or what I do for some clients, register a 6 character domain like qr301s.com and 301 redirect from there.

@Roger Good points…and beyond the scope of my capabilities for this blog (every time I’m troubleshooting a WordPress issue and come across solutions that reference modifying .htaccess, I know I’m doomed!). As I understand it, you’re effectively building your own URL shortener solution for those clients, right? Having managed 301s manually in a past life (I was requesting them — our infrastructure team was implementing/maintaining), my experience was that it was a solution that didn’t scale well. Fine for this one post and one QR code, but not great if expecting to ramp up to 100s or 1000s of QR codes (product packaging with a QR code for each unique SKU, for instance). bit.ly and goo.gl aren’t good solutions there, either. But, it’s what 3GVision does — so the infrastructure and management platform is outsourced to them, and they can get economies of scale so, presumably, can provide a more robust service at a lower cost. No?

I have kicked around the idea of building a redirect system with a key added feature of facilitating A/B testing of QR codes — rather than having the system redirect to a single destination, have it alternate destinations as each scan occurs. In certain situations, you’d then be able to optimize the destination for the code (not necessarily needed if you’re just sending to two different versions of the same landing page on your site — that could be handled with site-side A/B testing). I’d love to know your thoughts on that — is anyone already doing it?

@Tim, RE AB Testing QRs – Not to spam your comments, but, yeah you can set that up in a couple of minutes with our platform. You can also add targeting to it, or make it adaptive as well. Simple. The only possible issue I would think about is traffic – but super easy to do.