QRStuff.com - QR Code Generator

QR Code Error Correction

Posted: December 14th, 2011 | Author: | Filed under: General, QR Code Error Correction, QRStuff Features | 5 Comments »

Part of the robustness of QR codes in the physical environment is their ability to sustain “damage” and continue to function even when a part of the QR code image is obscured, defaced or removed.

This is acheived by using the Reed-Solomon Error Correction algorithm – some serious algebra that happens in background when the QR code is created. The original data in the QR code is converted into a polynomial, the number of unique points required to uniquely define that polynomial is determined, and this point set is added back into the QR code so that it then also contains the original data expressed as a polynomial.

If that description threatened to make your head explode, just call it “mathematically adding backup data to the QR code”.

There are 4 error correction levels used for QR codes, with each one adding different amounts of “backup” data depending on how much damage the QR code is expected to suffer in its intended environment, and hence how much error correction may be required:

  • Level L – up to 7% damage
  • Level M – up to 15% damage
  • Level Q – up to 25% damage
  • Level H – up to 30% damage

A fundamental part of the way QR codes work is that the more data you put into them, the more rows and columns of modules will be introduced into the QR code to compensate for the increased data load. As the error correction level increases, this means there will also be an increase in the number of rows and columns of modules required to store the original data plus the increasing amount of backup code words. This is shown in the diagram below – the QR code becomes more dense as the error correction increases from Level L to Level H even though the QR codes contain exactly the same website URL.

Quite conveniently, there’s also 2 modules down in the bottom left-hand corner of every QR code that display what the error correction level used in that QR code is.

So here are the take-outs:

  • The lower the error correction level, the less dense the QR code image is, which improves minimum printing size.
  • The higher the error correction level, the more damage it can sustain before it becomes unreadabale.
  • Level L or Level M represent the best compromise between density and ruggedness for general marketing use.
  • Level Q and Level H are generally recommended for industrial environments where keeping the QR code clean or un-damaged will be a challenge.

As an aside, this is also one of the reasons why a QR code containing the same data will look different depending on which QR code generator you use – it depends on the error correction level being used by that particular website. Even though there is a single ISO standard for QR codes, there are variables within the ISO standard (error correction level being one of them) that will result in a different looking QR code image based on how that particular QR code creation website sets these variables.

This doesn’t mean that any particular QR code generator is any more or any less standards-compliant than any other, it just means that the people behind the different generators have made different choices when setting the underlying technical specifications and parameters for the QR codes that their website creates.


Subscribers Get More QR Stuff!

Become a QR Stuff paid subscriber and get unlimited QR codes, unlimited scans, analytics reporting, editable dynamic QR codes, high resolution and vector QR code images, batch processing, password-protected QR codes, QR code styling, QR code pausing and scheduling and more, for one low subscription fee.

Full subscriptions start from just $11.95 for a 1 month subscription (lower monthly rates for longer periods) or you can set up a 24 hour trial subscription for $3.95 to check out what we can do for you. Subscribe now.

Subscribe Now

 


Password Protected QR Codes

Posted: October 31st, 2011 | Author: | Filed under: Password Protected QR Codes, QRStuff Features | 1 Comment »

There’s always been a need to password protect web content for security or privacy, but with QR codes being, by their very nature, very public, password protecting the QR code itself to limit access to the content it links to can add a “softer” security layer to that content.

“Locking down” the content with a password barrier actually on the website limits access for anyone who arrives at that page, regardless of how they arrived there, but being able to limit public access to it only for visitors that come in through one channel – the QR code – can sometimes be handy if there’s no password functionality on the website itself.

So, why would you have a password on the QR code, but not on the section of the website it links to? Sometimes a QR code can make publicly available content just too public.

In its simplest form a password protected QR code can be used for “privacy”, like closing a door but leaving it unlocked to stop people aimlessly wandering in, through to “security” to put a limit on open public access to content that isn’t password protected in its own right, or isn’t accessible via any other means apart from the QR code itself.

Examples would be:

  • Prying Eyes: Content intended only for members, customers, family, classmates, etc that you’d like to keep semi-private.
  • Pre-Release: Linked content that isn’t finished or ready for public release yet, but the QR code linking to it has to be published publicly on promotional material beforehand.
  • Competitions: Content related to a promotion where participants are issued with a pin number or password, and only the “winners” with the correct password get through to a prize page.
  • Private Viewing: Linking to content on someone else’s website that isn’t password protected, but you would still prefer to limit access to that remote content via your QR code.
  • Field Testing: QR code campaign or deployment testing that needs to be done publicly while still maintaining the privacy of the linked content.
  • Customers Only: Limiting access to people in-house, in-store or in-venue who have passed some sort of threshold in the physical space eg; they’ve paid, ordered, signed in, registered, etc while on the premises and who are then issued with a printed receipt or docket showing the password to access the content behind the QR code, whether it be at a gym, a parking station, a restaurant, a clinic, etc.
  • Private events in public places: Whether it’s the driving directions to a party posted on a power pole down at the highway turn-off, or the QR codes scattered across town as part of a treasure hunt, a simple password on the QR code will limit access to the information just to those who are supposed to have it.
  • Private equipment in public places: Service tags, useage statistics or specifications data for plant and equipment linked with QR codes can be access-limited to only employees or service staff even if the equipment, and the QR codes on them, are in public view.

Make A Password Protected QR Code At QRStuff.com

Being able to password-protect a QR code is part of the feature set for QR Stuff subscribers.

  1. Log into your subscriber account and go to your account history page.
  2. Click the “Manage” tab for the QR code you want to password-protect to open up the Management panel.
  3. QR codes that are able to be password protected (ie; you have used our URL shortner with them) will have a “Password Protect” link.
  4. A pop-up will allow you to turn password protection on (or off) and specify the password for that QR code. Click “Save” and it’s done.

…and here’s what it looks like from the scanning end (the password is 123456):

Yes, I know a QR code should link to mobile content but there isn’t a mobile version of the QRStuff website (yet) 🙂

 


Using Google Analytics With QR Codes

Posted: May 1st, 2011 | Author: | Filed under: General, QRStuff Features, Using Google Analytics With QR Codes, Using Google Analytics With QR Codes | 7 Comments »

As QR code use and implementation becomes more sophisticated, the reasons for having your own URL in the QR code, rather than a URL provided by an external shortening service, become more compelling:

  • You want your customer to have the confidence of seeing your branded website address when their scanning app asks them if they want to click through, rather than a URL from a shortening service they may not be familiar with.
  • You want to collect direct scan event data within your own analytics program, rather than just “seeing” the referral details of the shortening service associated with the URL redirection.
  • Having your QR code analytics data quarantined on someone elses website (whether it’s the QR code service or the URL shortening service) makes integrated analytics reporting awkward.

But having your own URL in the QR code, and hence not being able to rely on someone else to collect your analytics data for you, brings with it the challenge of exactly how to collect the analytics data relating to visitors arriving at your website from the QR codes you have out there.

Obviously using a URL shortener to keep the density of the QR code under the control when long URL’s are involved is a big plus for going in the other direction, and there will also be users who prefer to outsource the task of collecting analytics data to a third party, but knowing what your options are helps with choosing the one that’s right for you and your circumstances.

With Google Analytics installed on your website, there are 3 reasonably simple ways to keep track of who is coming in via your QR codes, and how effectively your various QR code programs are working.

Use Unique Landing Pages

Having every QR code simply linked to the front page of your website won’t give you any opportunity to split out the traffic from each one. All you will see is an increase in traffic from smartphone devices with very little other specific information to go on.

If you give each one its own unique landing page so that the only way a visitor can get to a particular page is by scanning the QR code, then you can assume that all traffic metrics associated with that page are as the result of that particular QR code being scanned.

For example:

Link your first QR code to https://www.qrstuff.com/qrcode1.html
Link your second QR code to https://www.qrstuff.com/qrcode2.html
Link your third QR code to https://www.qrstuff.com/qrcode3.html

This also gives you the unique opportunity of being able to tailor the content of that page to the context of the QR code that links to it. The QR code published in a magazine can point to a page of special offers, while the QR code on the packaging can point to a different page that contains an instructional video for the product itself.

Append URL Parameters

If the landing page for each of the various QR codes doesn’t need to be content specific, but there’s still the need to for individually reporting the analytics data associated with multiple QR codes, adding a parameter string onto the end of the URL will send everyone to the same place on your website but will report as different pages in Google Analytics.

For example, when linked from 4 different QR codes, all of the following will send the user to the front page of the website (https://www.qrstuff.com/index.html) without any modifications to the website at all, but will report as traffic to different pages in Google Analytics because of the ?id=xxxx bit at the end:

https://www.qrstuff.com/index.html?id=magazine
https://www.qrstuff.com/index.html?id=billboard
https://www.qrstuff.com/index.html?id=packaging
https://www.qrstuff.com/index.html?id=flyer

Manually Adding Google Analytics Campaign Tracking

A more sophisticated method is to use Google Analytics Campaign Tracking which involves combining URL parameters into a query string, adding the query string to the end of the URL, and then putting the whole extended URL into the QR code.

Google Analytics is set up to recognize this query string, extract the data the query strings contains, and report it uniquely. In this way you can transfer specific information from the QR code into the reporting framework of Google Analytics every time the QR code sends a visitor to your website.

The campaign tracking parameters that you can use are:

utm_source – Where the QR code was placed eg; “Flyer”, “Magazine”, “Billboard”, etc
utm_medium – How the campaign is being “pushed”. Just “QR Code” in most cases
utm_content – Convenient for sub-dividing the source or campaign parameter eg; “April 2011”
utm_campaign – The broad campaign name eg; “Spring Sale”

When these parameters, and your chosen descriptive variables, are all put together into a query string, and that query string is then added to the website address, the whole thing looks something like this:

https://www.qrstuff.com/?utm_source=flyer&utm_medium=qrcode&utm_content=apr2011&
utm_campaign=spring

You then manually paste this full URL into your QR code to enable campaign tracking every time the QR code is scanned.

If this looks a bit tricky, Google Analytics has a handy tool to help you build URL’s containing campaign tracking query strings. And here’s a great guide put together by Prateek Agarwal.

For Paid Users

If you are a QR Stuff paid subscriber, adding Google Analytics campaign tracking parameters is built in as a feature of the QR code creation process for both dynamic and static QR codes.

In your account dashboard you can also add campaign tracking parameters to an existing QR code, or edit the existing parameters already associated with one of your QR codes. Please note that both of these features for existing QR codes only applies to dynamic QR codes since static QR codes aren’t editable.

Become a paid subscriber from $7.50 per month to get this great feature as well as unlimited QR codes, unlimited scans, dynamic QR code editing, scan analytics, vector files, QR code styling, password protected QR codes and much more.

 


Not All QR Code Scanning Apps Are Created Equal

Posted: May 1st, 2011 | Author: | Filed under: General, Not All QR Code Scanning Apps Are Created Equal, Not All QR Code Scanning Apps Are Created Equal, QRStuff Features | 3 Comments »

The reason this post came about was that a few days ago Roger Smolski over at 2D Code posted about Color Card Administrator (CCA) setting up a QR Code Test Suite to determine the accuracy and sophistication of QR code scanning apps.

The test suite presents an array of QR codes containing a variety of data types and is intended to set a benchmark standard of readability and interpretation that all scanning apps should aspire to. Testing begins on 01 May 2011 and is open to all QR code scanning app developers. Apps that pass the test will be given an official CCA seal of quality to indicate that it’s able to properly deal with the various established standards that are currently being used in QR codes.

CCA QR Code Test Suite

After reading the article, I thought to myself “about time!” and recalled the regular emails I get from users of the QRStuff website that begin “I made a QR code on your website and my scanning app won’t read it”, with the immediate assumption being that the QR code is broken, and no consideration given to the possibility that scanning app was at fault by not being standards compliant.

Further investigation usually leads to the same outcome each time – the scanning app used was one of several “suspect” apps that lurk amongst the majority of reputable apps in the iTunes App Store or Google Play, the developers of said app not even appearing to be able to spell “standards compliance” let alone put the concept of it into practice, and which stumbled badly when confronted with a QR code that had anything more complex than a website address in it.

Now when I say regular, I mean out of the 100,000 people that used the QR Stuff website last month I probably received about a dozen emails, but I’m sure there were others who didn’t bother emailing. It concerns me when the blame for someone else playing loose-and-fast with the technology behind QR codes (either by design or through ignorance) is dumped on an innocent third party, so….

MEMO TO (SOME) APP DEVELOPERS:

Just thought I’d drop you a few suggestions on how to give your users a better experience when using your scanning app:

  • There’s an ISO standard for QR codes – please familiarize yourself with it.
  • There are RFC’s for the main data types used in QR codes – please read them. They aren’t suggestions, they’re actually the rules.
  • QR codes will often contain more than just a simple URL, contact details or a phone number – please make your app smart enough to cover the possibilities.
  • People have been using colour in QR codes for ever – please make sure your app scans (and also interprets) in colour rather than in shades of grey. In a black and white world many colours look the same.
  • If there are apps on the smartphone you’re coding for that handle different types of content better than the default browser, please use them – there’s a native YouTube player available for a reason, and Twitter sucks in Safari on an iPhone.
  • If you choose to use an in-app browser please make sure it’s up to the task of correctly displaying the wide variety of content that a QR code could link to.

Oh, and learning what “UTF-8” means, and the significance of reserved characters in URL’s, would be appreciated as well.

One final matter – I suppose error messages that indicate that your app didn’t understand the QR code, rather than blaming the QR Code for the failed scan, are out of the question, but then again if you were to follow the suggestions shown above, the actual content of the error messages would become a moot point because there would be significantly less of them to display.

There are indisputably many fine apps out there that are a credit to the expertise and diligence of their developers, and definitely worth every cent you pay for them (even the free ones!). While I’m not going to name the apps that are usually mentioned in conjunction with scan failures (although a quick flick through the review scores in the iTunes App Store and Google Play is quite telling), I am going to take the opportunity to highlight a few that I very rarely hear anyone mention anything negative about – they’re also the ones I use myself for my own in-house testing.

This post was never intended to be a rant – it just ended up veering in that direction because there’s not enough hours in each day as it is, and having any of them sidetracked unnecessarily because someone else didn’t do their job really annoys me.

It would be great if app developers took advantage of the CCA QR Code Test Suite now that a compliance standard has been made available.