To many companies and
independent developers --
not just software publishers
-- mobile apps represent
something even more
powerful and important
than a brand-new platform
to deploy apps on. It's a
new and dynamic source of
revenue, one with a lot of
room to grow. And given
how tough it can be to
make money selling
software at all, especially in
this world of open-source
and free Web apps, any
proven way to make
money in that field can
become a magnet.
Just like there's more than
one way to deliver software
in general, there's more
than one way to monetize
mobile applications. The
various strategies aren't
conflicting, but
complementary. Each app
can use the business model
-- or models -- best suited
to it.
The line at the register
With mobile apps, the
purchasing process varies
wildly, depending on which
operating system you're
dealing with. On the
iPhone, everything's done
through one interface: the
App Store in iTunes.
Windows Phone 7 supports
direct payment via credit
cards and third-party
billing of the customer's
service provider. Purchasing
through a service provider
is convenient, but I imagine
people might still opt for
credit cards to avoid the
possibility of spurious
charges on their phone
bills.
But with Android, the
dreaded "F" word --
fragmentation -- comes
into the picture. The main
way to pay for apps
through the Android
Market is via Google
Checkout, widely criticized
for its bad end-user
experiences. You can also
pay the app merchant
directly and there are a
number of other merchant
mechanisms ... all different.
(PayPal has also recently
been added to the mix.)
What's most lacking in
Android right now is a
single, consistent interface
for payments. The most
seamless solution would be
an API that allows app
purchases to be added to
the carrier's bill (with user
consent, of course), which
would make the process of
purchasing an application
all but frictionless. This
hasn't happened yet, but
Patrick Mork, vice president
of marketing for GetJar, a
cross-platform mobile app
store, claims that it is "right
around the corner" and
that Google has made no
secret of its negotiations
with the various carriers to
make this possible.
Integration with PayPal is
also a step in the right
direction, even if not
everyone uses it.
Less clear is whether such a
sea change will require a
new version of Android --
meaning those stuck on
older handsets that aren't
being updated to newer
editions of the OS would
be left behind. Because
Apple and Microsoft both
have ecosystems where the
purchasing system is
already pretty seamless,
Android runs the risk of
falling behind unless the
vast majority of its existing
installed base can be
brought up to speed when
new merchant mechanisms
arrive. And because of the
way Android is delivered to
the end user -- by the
handset maker rather than
by Google alone, and with
any number of gratuitous
changes -- a good chunk of
the existing generation of
Android phones might
remain stuck on the old-
school merchant systems.
The need to make app
purchasing as convenient as
possible will only become
more important over time,
to both the people buying
and selling them.
Smartphones have become
increasingly prevalent
among consumers as well
as business people; many
new users have no
experience with buying an
app and don't want the
experience to be more
complex than a click or
two. "Many apps are
currently purchased on an
impulse," says Ric Ferraro,
founder of mobile start-up
GeoMe. "People crave apps
in the same way [as candy
bars], and the longer it
takes to buy the app, the
less likely it is that the
purchase will be
completed."
Mork puts it another way:
"The best purchasing
experience is probably the
one where you never have
to leave the app."
Standing out from the
crowd
Along with ease of
purchase, discoverability --
how easily you can find a
given app and pick it out
from its competition -- will
also become increasingly
important. I've read more
than a few comments to
the effect that one
drawback of the Android
app stores is a proliferation
of me-too apps that
duplicate functionality to
the point of redundancy.
From this comes the
argument that an app
store with a more carefully
curated selection of
products is more genuinely
useful -- like the iTunes
app store, for instance. But
it's also possible to make
an argument that the size
of the store is not as
important as the interface
used to query it. Few
people complain about the
size of Amazon.com's
catalog, in part because it's
relatively easy to drill down
and narrow the scope of a
search.
Another possible solution
would be a universal app
catalog -- "a single store or
a single set of standards
which can be accessed
independent of the type of
mobile device or OS it is
running," as Ferraro
describes it. "Some
initiatives are being set up
to attempt this -- for
example, the Wholesale
Applications Community
initiative sponsored by the
GSM Association could go a
long way in setting unified
standards and creating a
single platform."
That wouldn't make things
much easier for developers,
who would still have to
produce and test variations
of a given app for different
platforms -- but the app
market is driven by
consumers and not
developers alone, and
where the consumers go,
the developers inevitably
must follow.
The cost of selling
One other major factor
that comes into play when
selling an app is the cost of
making the app available in
the first place. Apple's
iTunes store splits revenue
70-30, with Apple getting
the 30 per cent. Windows
Phone 7's app store has a
similar 70-30 split, but a
portion of Microsoft's 30
per cent is distributed back
to the network operators.
Both also have application
requirements and yearly
membership fees -- $99 for
Microsoft, and from $99 to
$299 for Apple, depending
on whether you get the
Standard or Enterprise
iPhone software
development kit.
The Android Market also
features a 70-30 revenue
split, but the 30 per cent is
distributed between the
payment processor and the
carrier. The registration fee
for developers is also only
$25, but an unlocked
developer phone, either
the Android Dev Phone or
the Google Nexus One, can
cost upwards of $500.
These phones are not
required, but they provide
some major power-
developer features: They
can work with any GSM
network, and the Android
Dev phone also lets you
install any custom Android
system image.
Alternative places to obtain
apps are also starting to
become available. For
example, Verizon is
planning to open its
Android V Cast apps store
sometime in November, for
which it will be offering a
70-30 revenue split. GetJar,
an independent site, takes
a varying fee for each app
download, using a bidding
system that starts at one
cent per download.
Making a living at apps
All that being said, there
are a number of different
strategies that developers
are using to earn money
with their apps -- most
outside the traditional pay-
for-product model.
The freemium model
The first and most basic
approach to monetizing a
mobile app is to just sell
the application itself. But
even a method this
elementary is fraught with
complexities. After all, how
much will people be willing
to pay for a given mobile
app? Set the price too low
and you can't cover
development costs; set it
too high and nobody will
touch it.
One quick way to resolve
that problem is to adopt
an approach that's been
used in the PC world for
decades: Give away a
minimally functional
version of the application
-- sometimes ad-supported,
sometimes just outfitted
with nag boxes -- and
encourage the user to buy
the full version. The missing
feature or features don't
have to be significant but
should be worth paying
for. Another way to put
this would be: Give away
the app, sell the
functionality.
The word freemium has
been coined to describe
this approach, and it has
quickly become an
essential means of bringing
a mobile app to market.
Ferraro described the
freemium model in his
blog as "a classic marketing
tool available to mobile
app developers to maintain
the perception of a free
service, while attempting to
lock-in customers into
some type of charging
mechanism."
The key word here is
perception: As long as
people feel as if they're
getting something for free,
they don't mind as much if
they have to pay down the
line -- even if they have to
pay again and again. What
matters is the sense that
they're getting something
for their investment.
Online games have
developed this to the level
of an art form. As
subscription-based games
lose favor and "freemium"
gaming comes to the fore,
the game makers have
come up with any number
of ways to scare up
revenue that don't depend
on selling the game itself.
Ferraro concurred on this
point in an e-mail
interview: "App publishers
can monetize free by
capitalizing on the
audience they obtained,
and promoting upgrades.
This is particularly visible in
mobile games, where more
advanced gaming levels are
only available at a
premium."
That said, reluctance on
the part of app makers has
been one obstacle to use
of the freemium model.
"Publishers of well-known
brands didn't want to be
perceived as giving things
away or devaluing the
brand," says GetJar's Mork.
"But this has changed in
the past couple of years."
Electronic Arts, for
instance, has been moving
toward a freemium model
for its online games --
something enhanced all
the more by its purchase of
game publisher Chillingo,
creator of the hit game
Angry Birds. Chillingo's
game-development SDK
includes technology to
easily create freemium
applications, something
useful to any company that
wants to push out such
applications across multiple
mobile platforms.
Microsoft sensed, quite
correctly, the need for
developers to create
freemium apps. The
Windows Phone 7 SDK has
direct provisions for this.
The free and full versions
of an app created with the
SDK can be the same
binary; all that's needed is
an unlock code. No new
download is required. This
takes the work out of
building a separate trial
version -- and gives app
developers that many
fewer excuses not to offer
both options.
The service-and-
subscription model
A major business model for
mobile apps is to sell access
to a service and give away
an application that's just a
convenient front-end for
that service. The biggest
question is: What service is
worth paying for?
It's not just a question of
the service being useful. It's
about the integrity of the
data provided by that
service as well. Consider
Zagat, the venerable dining
and entertainment guide,
which has a subscription
version of its review service
accessible through its
mobile apps for $24.95 a
year. Zagat's main
competition is from crowd-
sourced services like Yelp,
but Zagat's business model
is based on the idea that its
information has such a
known pedigree, it's worth
paying for. Yelp's database
may be contributed to by a
broader range of people,
but it's arguably much
messier and more
inconsistent.
Another method for selling
data involves creating
applications that offer a
repository of locally stored
data. For example, let's say
you worked for a company
that is known for
publishing foreign-
language dictionaries, and
you wanted to sell mobile
versions of its books. You
could give away the app
itself, with a minimal
version of the dictionary
data thrown in on top of
that (say, 2,000 words),
then sell the full-blown
version of the dictionary,
either all at once or in a
regularly updated,
periodic-subscription
version. This wouldn't stop
amateur competitors from
creating their own apps
and data sets, but a free
dictionary that's not very
accurate would have less
appeal to a serious
language student than a
modestly priced one that
has a brand-name pedigree
behind it.
The ad-funded model
A third way to generate
revenue from mobile apps
is a method ported directly
over from the Web at
large: advertising. But be
aware: Ad-supported apps
come with all the
controversies associated
with using advertising as a
revenue model, plus a few
new ones.
Ad-supported apps can
serve as a way to hook
people into buying a full
version of a program
without the ads. For
example, the MixZing Music
Player for Android has a
free, ad-supported version;
pay $6.99 for the full
version, and you not only
remove the ads (which are
at least unobtrusive), but
unlock a slew of extra
features, like an MP3 tag
editor.
The problem with ads in a
mobile application is -- for
lack of a better word --
acreage. On an ad-
supported Web page, ads
can run in banner or
skyscraper elements
confined to the edges of
the page and don't have to
be as intrusive. With a
mobile app, the small
screen means any ad is
going to eat into the UI,
and a badly integrated ad
will turn people off. Ads
placed too near controls,
for instance, may
mistakenly intercept
button-press actions.
Another small drawback to
advertising in mobile apps:
The ad system is all but
useless if the user doesn't
have an active data
connection. This will
become less of an obstacle
as more mobile devices are
sold with some form of
data plan included and as
municipal Wi-Fi becomes
more pervasive. (Also, an
ad can still be effective,
even if it clicking on it
doesn't work due to a lack
of networking. As long as it
raises some awareness in
the mind of the viewer, it's
still doing its job.)
Another method of
monetizing through
advertising is using revenue
generated through a search
engine. This has been
Mozilla's model with
Firefox and could just as
easily be applied to mobile
apps as well. Whenever a
user executes a Web search
via Firefox's native search
box, a certain percentage
of ad revenue generated
from the search goes back
to Mozilla through an
affiliate program.
The downside to this
approach is that it lends
itself only to applications
that have some search
component -- such as a
mobile browser -- which
make up a very small
segment of the existing app
mix. That said, it's entirely
possible that creative
methods of integrating
search with mobile apps
will make search-engine
revenue that much more
viable a choice.
Conclusions
Because the current
incarnation of the mobile
apps market is still so new
and only just now
experiencing a flowering of
cross-platform competition
and innovation, the ways
apps can be monetized and
sold are likely to enjoy as
much of a period of
experimentation as the
apps themselves.
What's clearest is that the
processes of selling and
monetizing apps have to be
as convenient as possible,
for customers and
developers alike. "To reach
as wide an audience as
possible, you have to be
able to go cross-platform,"
says Mork. "You need some
sort of business model
where you can reach
different audiences
depending on whether or
not they have data plans or
smartphones." This goes
double for apps that
spread virally, by word-of-
mouth or by direct
exposure: If your friend has
it on his iPhone, you're
going to want it on your
Android as well.
To that end, those who can
make the monetization
process as seamless as
possible are set to reap
rewards of their own --
along with those who write
apps that are worth
monetizing, of course.
Serdar Yegulalp has been
writing about computers
and information
technology for over 15
years for a variety of
publications, including
InformationWeek and
Windows Magazine.
Join the CIO Australia
group on LinkedIn
. The group is open to
CIOs, IT Directors, COOs,
CTOs and senior IT
managers.
No comments:
Post a Comment