Thursday, 21 April 2011

QR Code Tracking

We've had a few people talking to us recently about QR Code tracking so we thought we'd put some notes in the blog. These notes apply specifically to QR Codes which are intended to redirect the scanner to a web page, social network or similar - not a QR Code providing, say, vCard information. 

Essentially, there are three ways to track QR Codes. Before we go into that though, we need to define what we mean by 'track'. The most logical way to look at tracking is to look at the 'hits' on the destination page that the QR Code links to. In the case of Kimtag, that can either be your connection page or it could be a page that you are autoconnecting directly through to. But this only tells half the story. 

The Scanning Process
There are two stages to the scanning process. The first is the scan by the mobile on the QR Code which reveals the data 'embedded' within. The second is that the scanning software or App then interprets this data, decides what to do with it and, in the case of the data being a web address, opens a browser to display the appropriate page. 

Depending on your phone scanner App or pre-installed scanner software, this process might be obviously two stages or it may appear as one seamless process. The key point here is that with scanners that split the process into two stages, it's possible that the user can scan the QR Code and then choose not to do anything with the data (web address) that was provided to them. Essentially, the QR Code has been 'scanned' but your page will not have been visited. The implications for this will become clearer as you read on. 

First Tracking Option : The Redirect
This assumes that the user completes both stages outlined above. Essentially, instead of the QR Code linking directly to your page, it links to another address first so the 'hit' can be registered and then this address redirects through to the final destination. This is standard practice within the online advertising industry and it's certainly nothing new - you don't usually notice the hit to Google when you click on a Google ad for example. 

Where it gets tricky is that the web address displayed after the first stage of the scan is for the service doing the redirect. In our case this address would be something like . If you are using a Kimtag connection page then this is ideal and presents no problems. However, if you are using our autoconnect feature or another QR Code service to link directly to your site, this may present confusion to the user. However, if the user looks as the result of the link (ie, after the service redirect), then it will show the correct address. Moreover, this would only affect users who have software that obviously splits the scan process into two stages. The 'one stage' users wouldn't know any difference. 

(For the techies amongst you, Kimtag generally uses HTML5's state change functionality to change the visible URL from to without doing a redirect at all for users using our connection hub. Makes things quicker on mobiles.)

Second Tracking Option : QR Scanning App
The second option is that you use a QR service where the user is required or expected to use a matching QR Code scanning App from the same service. 

In the event where you are expecting the user to have a particular App (such as the case with Microsoft's Tag system), you are taking the risk that the user hasn't got the App and/or can't be bothered to download the App. 

The alternative here is that you just hope that the user is using an App from the service provider you are using. In reality this is unlikely. However, the scans that you do register may provide you with some additional information such as user location and so on. In addition, this method can also mean that scans can be registered even if the user chooses not to visit (or cancels the visit to) the site the scan displayed. In other words, you can log the 'stage 1', even if the 'stage 2' of the scanning process isn't followed. Of course you could use the process described in the first tracking option with this second option, whereby you use the additional data provided by the services App where it's being used. However, this would provide a partial (and possibly biased) data set which is likely to be worse than none at all. (On the 'knowing what you don't know' is usually better than 'not knowing what you don't know' data principle !) 

Third Tracking Option : Unique Web Address
This involves setting up a separate web address on your own site (or a web address that looks different but points to the same page) for your QR Code(s).  You can then use your web analytics software to monitor the number of hits on this page (or 'fake' page) and know they initially came from the QR Code. This is great if you run your own website but clearly might present issues if you are directing through to Facebook, Twitter, etc. 

In short, unless you are in control of your website and only want your QR Codes to point to that site, your best bet is usually the first option. 

However, there's a few more points worth noting. 

The first is how quickly the provider redirects. Kimtag's engineers used to work in the online ad industry and we know that at this stage, every millisecond counts. If your QR Code service provider is too slow or puts a pointless landing-style promo page in the middle, then you are going to lose people. 

The second is that using a redirect system, rather than a direct link system (as in the Third Tracking Option), means that you can change where your link directs to at any time. Which may be a very useful feature for you in the future. 

The third is that using a proper connection page like Kimtag rather than direct linking means your users can choose how they want to connect with you. We provide both connection page and redirect systems with every account and you can switch between the two instantly whenever you want but connection pages are great and your users will thank you !