Mobile Code Scanning: Selecting the Technology

Selecting the code scanning technology for your campaigns is a critical step. There are key factors in making that decision, and those, to mention two, are the code format and the features that the complete solution can offer.

To accompany the technology+vendor selection process, a good thing to do is to have the vendor list handy, and fortunately Scoot Shaffer in his Blog had composed a long list of code scanning vendors. Many vendors support standard code formats (QR+DM) while others have their own proprietary code format, plus optional support for the standard codes.

The code format has implications on the user experience, the value driven through simple or complex use cases, through to the control an operator has on their ecosystem and the ways in which revenue can be generated.
The following are the key factors when looking at code formats:

• Standard vs. Proprietary: That's probably the key decision to be made. Today there are two leading open-standard code formats: QR and DM. Both are old timers: QR has been largely successful in Japan and DM has had its own successes. What you want to keep in mind as you make this decision, is that in every emerging ecosystem, there would be two types of solutions: The first would be the existing solutions that were "loaned" from other industries, those would typically have significant traction by that time (otherwise nobody would "reuse" them) and in some cases they might be open standard. New solutions will have, by definition, less traction, they would typically be too new to be open standard. But, new solutions would almost always be optimized to the objective. So it's up to you whether you want to optimize the technology to what you're trying to achieve, risking it's immaturity, or you go down the safe route with open standard codes. If you chose the standard codes you can stop reading now, choose QR and/or DM and move to the next decision. If you want to learn the differences that new and innovative solutions create, keep reading.
  A note has to be said here about the 'Mobile Code Consortium', trying to make sense out of all of this. On one hand, recognizing that advertisers are the gold pot and they would not be in the game if the market were fragmented by different codes is a strategic required decision to be made. On the other hand, this is not the first time that a consortium is gathered in a very early market. For more reading on this, Scott Shaffer had made a good post on this and so had I, and the bottom line is, when you look into this consortium, make sure you are comfortable with the forum, timing, agenda (which is public) and their motivations.
  

• Scanning Performance: Once of the objectives you want to get from code scanning is how easy it is to scan codes. This should be an obvious operation for a non-trained subscriber. It should be immediate to an enterprise user. You want to find codes that were optimized for "real human hands" environment, where everything goes: blur, rotation, angles, slight motion or shiver, different lighting and shading conditions etc. You also want to find the decoding application that provides a timely response rather than choking the phone's CPU for several good seconds.
  
• Code size has reach implications: Certain codes compress information better than others, so that the resulting image (usually measured in modules) is smaller. typically, codes would grow in size in proportion to the amount of data you try to put into them. In code scanning, there's a couple of parameters that count: How many pixels can you get from the phone's camera API and how many modules does the code have. what the decoder needs to be able to do is to contain the complete code in the image, and be able to determine each module. For that, there is a sweet-spot of how many pixels-per-module would optimize the probability to successfully decode the code. If you have a code format that does not compress well, the code would be large, and low-resolution phones would just not be able to scan that code.
• Information Reliability: OK, so you've successfully scanned the code, hooray! But-are you sure you got the right data? Error detection and correction algorithms are a must-have in code scanning systems, make sure they're there.
• Better Data Compression drives Flexible Use Cases: The better compression the code uses, the more information it contains per given size, the more data the code reader application can have immediately after decoding the code. The result is comprehensive UI that is more user friendly, and more complex, valuable use cases: anything from launching a local file on the phone to triggering a mobile payment transaction, including the merchant, the user, the amount and security fraud-prevention data, all of which can finally be transmitted over SMS to the mobile payment backend system.
• Aesthetics: Finally, one of the key features of the codes being a visual entity, is how can they be visually pleasing to the subscriber. The typically scenario would be that these codes would be embedded into an ad, and it is expected that the subscriber would be triggered to scan the code by the context of the ad, not by the code itself. Advertisers would be highly aware of the space the code takes and how does it embed well in the graphics of the ad. They would be surprised to see how their logo embeds in an interesting way into the code, or the code into the logo. Therefore, aesthetic features like code shapes, code coloring, module shapes and coloring and others are likely to be of high value to advertisers.

There are probably more code format features, but let's turn the attention now to the solution features that are important to look at:

• Direct vs. Indirect resolution: The resolution point is where does the code content translate into an actual action, like launching the browser to a URL, adding a contact to the address book, sending an SMS etc. Some code formats only allow limited data to be carried in the code, such that essentially the code itself would typically only contain some index, the code reader application on the phone would connect to a web server ("Central Resolution Server") to say what action is associated with this index. This is called "Indirect Resolution". In contrast, code formats that allow more data to be carried in the code, in some cases allow the code reader to translate and take a local action, immediately on the phone without necessarily having to connect to that resolution server. I call that "Direct Resolution". For example, if we're looking at an SMS code, if the code can contain something that tells it's an SMS, and then the target phone number and the content of the message, then there's no need to connect to a remote server to send the SMS. There are a couple of differences in comparing direct and indirect resolution:
  • Direct resolution provides immediate value to the subscriber: when the subscriber scans the code and they immediately see what the code does (for example, see the SMS message composer screen pop up) that immediacy is very pleasing to the subscriber. using the indirect system, having to connect to a remote resolution server to resolve the index BEFORE the user even knows what the code does, is somewhat degraded user experience.
  • Reliability: The indirect resolution system relies on the user's patience while the phone attempts to connect to the remote resolution server, that the user indeed has data plan and is in data network coverage area and so forth. the direct resolution system is autonomous for those codes that contain the data.
  • Use cases include local actions: the ability of the code reader application on the phone to scan a code and have all the information it needs, means that the code reader, being an application running on the phone, can take any action using the phone's resources: launching a local multimedia file, adding a contact to the address book, adding a meeting to the calendar, sending an SMS and much more. More important, complex use cases can be thought of where the combination of the data in the code, samples of the user's context (location, time etc.) and collecting user input can be performed before taking the action. Typically, remote resolution systems launch the phone's web browser and from there the actions that can be taken are somewhat limited.
  • Monitoring: to the benefit of remote resolution systems is that they inherently provide monitoring and reporting mechanisms that, if installed on the code reader application, might be unpopular by users who would find out about them.
  • Registration and maintenance: Usually the location of the resolution server is a powerful negotiation point. Who controls that server, how is it being maintained, can users create codes or brands only. All these are valid questions to be asked and they have a lot of bearing on the business models that are created finally.
    

• Support for subscriber code creation as well as enterprises: the architecture of the solution is very important factor to look at. Whether initially subscriber code creation tools are important or not, for example, to encourage adoption you will want subscribers to get familiar with code solution and promote it to their friends.
• Reach: You will want to maximize the effect on your subscribers. You want to choose between support for all your new phones that are sold in stores, or support for a high chunk of your install base. there are different mobile operating systems and you want to think how to maximize the potential of this solution. Reach is very important to subscribers' friends...
• Control on your ecosystem: This is probably one of the most important issues you want to look at. Essentially, if you're working with open-standard codes, everyone can create those codes, everyone can scan those codes. Well, what if you need some control? For example, you have an SMS-based mobile payment system. the parameters of each transaction are made of the vendor, the price, the product and the user identity. You will not want someone to decipher your codes, change the price and attach it to products, would you? Some proprietary code-based solutions allow you to have better control on who creates codes, who can scan which codes and what happens when an authorized user scans that code, or an unauthorized user scan that code. with those systems you can fully customize the user experience so that it is predictable, user friendly, you can control the user input collection, you can add hidden security information for fraud prevention, for example, and you can control the resulting transaction.
• Support for open-standard codes: If you have gone down the road of choosing a proprietary code format-based solution, you may be anxious whether that code format will make it successfully. In that case, you may want to ask the vendor whether they support open-standard code formats "just in case". If they do, you can launch your solution with confidence that you have an optimized solution and a fall back if all hell breaks.

I hope that provides a pretty good coverage of the issues you want to put on your check list when selecting the technology. You want to keep in mind the business goals and the revenue streams I discussed in an earlier post so you don't get lost in the technology maze. A successful solution is not necessarily the technological robust one, its the one that makes sense to your audience and your organization.

In benchmarking different technologies you want to research the web, you will find that independent academic researches have been made on different codes, you will find that creating codes yourself and downloading the matching code reader to your phone will give you a lot of insight into how this thing really works and from there you can evangelize on innovative services in your ecosystem.

On the next quick post I will talk a briefly about vendor selection, and specifically discuss how sometimes technology "features/limitations" (you pick) mandate the vendor's business model with the operator.

I hope you found this useful, thanks for reading!