Turning Yellow Pages into Gold: Making Money from Mobile Search.

CHANGE IS COMING TO BUSINESS SEARCH:

That we are about to witness a sea of change in the traditionally tranquil waters of business directories was made patently clear at a recent meeting of key Yellow Page businesses at the EADP Conference in Mallorca. In mature European markets like the UK, printed directory revenues are declining by approximately 12% year on year.

Meantime, digital revenues (PC web and mobile) have been growing year after year, and on a global basis, account for more than 20% of total business directory revenues. But the web growth story is one that dates from the ‘noughties’, the decade spanning 2000-2009. Today in the ‘teenies’, the decade started this year; mobile is the key engine of growth.

In fact, already 30-40% of Europeans access web services more regularly from a mobile device than from a PC. This means that the ability for business directories to deliver a personalised experience on mobile is more important than ever before.

HOW DO YOU MAKE MONEY FROM MOBILE SEARCH?

The big question is: how do you make money by letting business directory users access the service on mobile?

Firstly, a quick explanatory note on the mobile channel, as this can mean two things: the Mobile Web and Mobile Apps.

This can seem obvious, but the distinction is important. With a mobile website, a business directory can deliver an improved experience for those users browsing through the directory’s website on a mobile device. It is a good starting point. But to make the most out of the mobile device’s capabilities (especially those of smartphone devices) mobile apps are the key.

Here, the app can make full use of the positioning, touch screen and other Smartphone gizmos (like the accelerometer that detects handset motion). By doing so, a much more unique, interactive and engaging experience can be delivered to mobile users.

Business directories with a good set of mobile apps and a mobile website can not only deliver extra value to existing directory users. They can also open up the service accessible to new groups of users (for example, teenagers with iPhones, who may have never opened a printed Yellow Page book in their lives). Business directories have the possibility of charging their customers (advertisers who list in their directories, not the end user) for this new mobile channel.

Business listings on mobile are also the perfect route towards order fulfilment –as the mobile is also the most common way of getting in touch with the business that is listed. Take the example, if you will, of a stranded person in an unfamiliar part of town that needs a taxi to get home. A search for ‘taxis’ within the Yellow Page app is the quickest way to get the number of a taxi company. And by having a ‘click-to-call’ button next to the company name, the user can dial straight through and order a taxi. This can be through a premium number that can generate shared revenues for both the Yellow Page Company and the advertiser.

RFQ-REQUEST FOR QUOTES

 Another exciting development is the up-and-coming RFQ, or Request-for-Quote model on mobile. Here, the realisation is that business directories can add most value by linking specific advertisers with specific user requests.

For example, a plumber participating in the scheme would receive real-time requests for his services obtained by users searching within the plumbing category of the business directory. Monetising the service is carried out by charging a commission for each fulfilled order. Quotify, based in San Francisco, have already rolled out this service using web platforms, but are seeing increasing demand for delivering the solution on mobile.

Licensing Server News

It’s been reported that someone has figured out, and published, a way to hack some Android apps to bypass our new Android Market licensing server. We’ll be saying more on this, but there are a few points that deserve to be made right now:

• The licensing service, while very young, is a significant step forward in terms of protection over the plain copy-protection facility that used to be the norm. In the how-to-pirate piece, its author wrote: “For now, Google’s Licensing Service is still, in my opinion, the best option for copy protection.”

• The licensing service provides infrastructure that developers can use to write custom authentication checks for each of their applications. The first release shipped with the simplest, most transparent imaginable sample implementation, which was written to be easy to understand and modify, rather than security-focused.

• Some developers are using this sample as-is, which makes their applications easier to attack. The attacks we’ve seen so far are also all on applications that have neglected to obfuscate their code, a practice that we strongly recommend. We’ll be publishing detailed instructions for developers on how to do this.

• The number of apps that have migrated to the licensing server at this point in time is very small. It will grow, because the server is a step forward.

• 100% piracy protection is never possible in any system that runs third-party code, but the licensing server, when correctly implemented and customized for your app, is designed to dramatically increase the cost and difficulty of pirating.

• The best attack on pirates is to make their work more difficult and expensive, while simultaneously making the legal path to products straightforward, easy, and fast. Piracy is a bad business to be in when the user has a choice between easily purchasing the app and visiting an untrustworthy, black-market site.

Android Market is already a responsive, low-friction, safe way for developer to get their products to users. The licensing server makes it safer, and we will continue to improve it. The economics are already working for the developers and against the pirates, and are only going to tilt further in that direction.

Mobile OS Platforms-Which horse should you bet on?

Here is an extract from Golden Gekko's view of the mobile platform landscape today with an insight into likely losers and gainers going forwards:

The mobile ecosystem keeps on evolving faster than ever and it's often difficult to see the macro trends with all the day to day announcements and comments about winners and losers. One of the most exciting things is that nothing is certain.

Here's a short summary of the trends that we are seeing and longer term impact:

Handset Operating Systems and Development Platforms

• iPhone - Continues to evolve with OS4 being a great leap forward and with the best UI and SDK for developers but overall market share is stablising at about 13.5% of smartphones globally and with only one new device release per year growth is likely to be tempered going forward
• Android - Outsold iPhone in Q2 and increased their market share by 886% since last year with more handset manufacturers continuing to launch devices and competing against each other with vastly improved hardware including QWERTY keyboards, better cameras as well as very competitive prices and is expected by most to be the nr 1 smartphone OS in 2011
• RIM continues to hold on to a big share of the smartphone market with 18% based on a wide range of communication and utility focused devices for business users as well as the youth market with an amazing usage adaption among teenagers in the UK thanks to Blackberry Messenger but market share is expected to decline unless Blackberry 6 delivers improved app support and user interface 
• Nokia has gone from the undisputed leader to an underdog despite still being the global leader in overall market share (36% in Q2) and smartphones (43% in Q2) due to lack of great new devices and unclear strategy of Symbian and MeeGo but we would definitely not rule them out as they still have deep pockets and a very loyal base in emerging markets and a partnership with Intel with even deeper pockets and long term bets riding on the success of MeeGo
• Palm WebOS went from being a dead horse to a joker when HP acquired Palm earlier this year thanks to having developed the 2nd best OS to iPhone in terms of user experience and based on open standards and as the largest PC manufacturer worldwide HP won't give up in the first place
• Microsoft Mobile has constantly failed to deliver a really appealing user experience since they first launched the SPV in 2002 and although they undoubtedly provide the best PC - Mobile integration it hasn't been enough but with Windows Mobile 7, the biggest development community in the world and a track record of not giving up they might still have a chance to find a market and slowly grow over the next couple of years from 5% of the smartphone market in Q2
• Samsung Bada Wave is another unexpected player in the smartphone OS space as they also deliver devices with Android and Windows Mobile but Bada has outperformed most people’s expectations in terms of user experience although it essentially is a Android copycat based on Linux and Java and won’t have much chance in the high-end smartphone segment
• Webruntime Widgets are not really a OS or a platform but with the popularity of webkit based mobile browsers and the push for standardisation among carriers the widget standard (also referred to as JIL by Vodafone, webruntime by Nokia and WebOS by Palm) it's becoming an important platform and might actually have a good chance of establishing a standard for apps that don't require the latest and greatest from each of the individual platforms.
• Java ME continues to be the leading platform in terms of installed base and handset sales supported by Symbian, Samsung Bada, Windows Mobile, Blackberry and most proprietary OS from Nokia (e.g. S40), Sony-Ericsson, LG and Samsung with well over 2 billion devices worldwide and over 0.4 billion downloads per month with majority of Java downloads now in emerging markets such as India, Indonesia, Brazil and China

In conclusion
The media and financial community seems to believe that there can only be two or maybe three winners in the smartphone space like in the PC world with Microsoft Windows, Mac OSX and various Linux versions. What if it’s possible with more? Maybe the market is so big, the technology development so fast and customer preferences so different that there is room for more than three? Google Android definitely looks like the favorite of the day but we don’t think the battle is close to being over. Like we said in a previous update. “In mobile fragmentation is forever. Deal with it.”

A Little Too Popular

A couple of weeks ago, we arranged that registered developers could buy an unlocked Nexus One via their publisher page in Android Market. We think it’s a good development platform and a nice phone. Apparently, you agree. Somewhat too many of you, in fact; we blew through the (substantial) initial inventory in almost no time, and they’re back-ordered from HTC, who are doing a pretty good job of managing runaway success amid a worldwide AMOLED shortage. Everyone appreciates that it’s important to the platform to get phones in the hands of developers, so we’re working hard on re-stocking the shelves; stand by.

Two Simple Questions

And the answers to them, posted here and there by senior Android engineers.

How much memory is my app using?

Over at Stack Overflow, our own Dianne Hackborn takes this up in detail. There's no simple answer, but Dianne does offer lots of useful information.

How do I make a ScrollView behave?

This one does have a simple answer, and our Romain Guy offers it in ScrollView’s handy trick. It's easy enough to do once you know how, which is harder to find out than you might think, because there's one useful XML attribute that's there in the examples but missing in the docs. Oops!

Powering Chrome to Phone with Android Cloud to Device Messaging

[This post is by Dave Burke, who's an Engineering Manager 80% of the time. — Tim Bray]

Android Cloud to Device Messaging (C2DM) was launched recently as part of Android 2.2. C2DM enables third-party developers to push lightweight data messages to the phone. C2DM created a nice opportunity for us to pull together different Google developer tools to create a simple but useful application to enable users to push links and other information from their desktop / laptop to their phone. The result was Chrome to Phone - a 20-percent time project at Google.

Chrome to Phone comprises a Chrome Extension, an Android Application, and a Google AppEngine server. All of the code is open sourced and serves as a nice example of how to use C2DM.

The message flow in Chrome to Phone is fairly typical of a push service:

1. The Android Application registers with the C2DM service and gets a device registration ID for the user. It sends this registration ID along with the user's account name to the AppEngine server.

2. The AppEngine server authenticates the user account and stores the mapping from account name to device registration ID.

3. The Chrome Extension accesses the URL and page title for the current tab, and POSTs it to the AppEngine server.

4. The AppEngine server authenticates the user and looks up the corresponding device registration ID for the user account name. It then HTTP POSTs the URL and title to Google's C2DM servers, which subsequently route the message to the device, resulting in an Intent broadcast.

5. The Android application is woken by its Intent receiver. The Android application then routes the URL to the appropriate application via a new Intent (e.g. browser, dialer, or Google Maps).

An interesting design choice in this application was to send the payload (URL and title) as part of the push message. A hash of the URL is used as a collapse_key to prevent multiple button presses resulting in duplicate intents. In principle the whole URL could have been used, but the hash is shorter and avoids unnecessarily exposing payload data. An alternative approach (and indeed the preferred one for larger payloads) is to use the push message service as a tickle to wake up the application, which would subsequently fetch the payload out-of-band, e.g. over HTTP.

The code for Chrome to Phone is online. Both the AppEngine and Android Application include a reusable package called com.google.android.c2dm that handles the lower-level C2DM interactions (e.g. configuration, task queues for resilience, etc).

Chrome to Phone is useful, but maybe it’s most interesting as an example of how to use Android C2DM.

Element Youth Mobile Marketing Campaign including Crowdharnessing

Element - Claim it! from Morten Halvorsen on Vimeo.

A friend and former colleague in the US shared this mobile marketing campaign with me several months ago and it provided such a perfect (and rare) example of how to bridge the gap between the real and virtual world, that I have been using it continuously since then.

The campaign for sporting goods/Sporting brand Elements manages to pull off creating a well-targeted app (just for urban skaters), with a strong viral element (competition for the best skating stunt allowing skaters to ‘claim their spot’), an integrated digital experience (a customised website linking to the mobile site) and rich mobile features (location plus video) as well as social media/crowd harnessing (the best skater videos were uploaded to the official Elements website).

The promotional side involved giveaways of branded gear at ‘on-the-spot’ competitions, the cherry on the cake for what was undoubtedly one of the most complete, well thought out mobile campaigns I’ve witnessed in the last couple of years.

You can see the explanatory video above which illustrates clearly how all the various elements of the campaign fit together. Special thanks to Ed o’Meara and Josh Dhaliwal.

Nexus One Developer Phone

We've always offered unlocked phones for direct sale to registered Android Developers. As of today, the Developer Phone is the Nexus One, at a price of $529. To see the details or order a phone, you need to sign in to your Android developer account and click on the "Development Phones" link.

The Nexus One combines an up-to-the-minute platform (Android 2.2), modern hardware, and the pure Android software suite. It's a good choice both for people who want to build Android applications using either the SDK or the NDK, and those who want to experiment with modified versions of the Android platform. Note that the Nexus One still ships with Android 2.1 but will download 2.2 soon after you turn it on; make sure you’re near a fast network.

As well as being an outstanding developer platform, it's a really nice everyday phone; we're really happy to have connected the right dots to make this happen.

[Update]: A bunch of people have spoken up wondering about Nexus One accessories. They are available right now in HTC's European online store. When we get more news, we'll pass it along.

[Update, Aug 6th]: The HTC US store now has accessories too.

Best Practices for Handling Android User Data

[This post is by Nick Kralevich, an engineer on the Android Security Team. — Tim Bray]

As the use of mobile applications grows, people are paying more attention to how these applications use their data. While the Android platform contains extensive permissions designed to protect users, application developers are ultimately responsible for how they handle users’ information. It’s important for developers to understand the code they include, and consider the permissions they request, as mishandling these issues can result in users perceiving a violation of trust.

Maintaining a healthy and trustworthy ecosystem is in every Android developer’s best interest.

Here are a few tips for writing trustworthy Android applications:

1. Maintain a privacy policy

2. Minimize permissions

3. Give your users a choice regarding data collection

4. Don’t collect unnecessary information

5. Don’t send data off the device

6. ... but if you have to, use encryption and data minimization

7. Don’t use code you don’t understand

8. Don’t log device or user specific information.

Maintain a privacy policy

Trustworthy applications are up-front about the data they collect and the reasons for collecting it. Users are generally happy to share information via such apps if they believe they will personally benefit. A clear and concise privacy policy, with details about the type of information collected and how it’s used, goes a long way towards generating trust and good will.

Minimize permissions

Android is unique among mobile operating systems for its simple, straightforward, operating-system-enforced permission model. All Android applications must declare the permissions they require, and users must approve these permissions before the application is installed. Users tend to distrust applications that require excessive permissions.

For example, a user installing this tic-tac-toe game might reasonably wonder why it needs to take pictures.

Give your users a choice regarding data collection

It’s called the paradox of privacy [PDF, 890K]. Users are often happy to share their information, but they want control over that sharing. Trustworthy applications give users control over their information. For example, the Android Browser has privacy settings which enable users to control how their information is shared.

Don’t collect unnecessary information

Trustworthy applications limit the kinds of data they collect. Collecting unnecessary information, especially if you never use it, just invites suspicion. When in doubt, don’t collect it.

Don’t send data off the device

If you have to handle user data, ensure that the data remains on the device whenever possible. Users are comforted knowing that their private information strictly resides in the phone. Sending data outside the phone, even if done for the user’s benefit, tends to draw suspicion.

... but if you have to, use encryption and data minimization

Sometimes, the collection of data is necessary. In that case, applications need to ensure that it is handled safely. A privacy policy will avoid leading to surprised and irritated users; in some cases, it may be advisable to prompt the user before transmitting data off-device.

First, minimize the amount of data you collect. Do you really need the user’s full phone number, or would the area code be sufficient? Can you use a one-way cryptographic hash function on the data before sending it to the server to help protect the user’s confidential information?

A case study: User Favorites

Suppose you want your app to maintain a list of “favorites” for each of your users, without going through a full registration process. In theory, you could do this by sending your server some combination of their phone number, device ID, or SIM ID. But why take the chance of worrying people about privacy issues; why not send a one-way hashed signature of whatever the identifying information is? Or even better, create a random unique id and store it on the phone, and use this unique id as the registration key for your application.

In the end, you’ll will still be able to retrieve their favorites, but you won’t need to send or store anything sensitive.

Second, encryption is critical to the safe handling of user data. Phones often operate on untrusted networks where attackers can sniff confidential traffic. Encrypting data in transit is a critical part of protecting user information.

Finally, when communicating with a server over HTTP, it’s a good idea to avoid encoding user information in a URL that is used with HTTP GET; rather, POST it in a message body. While using POST doesn’t guarantee that your information won’t be sniffed, putting it in the URL increases the likelihood that it will be automatically logged; out of the box, most web server software logs all the URLs that are received.

Don’t use code you don’t understand

In the open-source Android environment, it’s common (and good) practice to rely heavily on other people’s code, in the form of libraries and frameworks. But if that code is handling your users’ information inappropriately, it’s your problem. So make a point of checking code before you rely on it.

Don’t log user or device specific information

Application developers should be careful about on-device logs. Android makes it easy to write to the phone’s log, and anyone who has looked at “logcat” output knows that it is full of important but seemingly random debugging information from many applications. In Android, logs are a shared resource, and are available to an application with the READ_LOGS permission (only with user consent, of course!). Even though the phone log data is temporary and erased on reboot, inappropriate logging of user information could inadvertently leak user data to other applications.