Monetization of applications - where is the money, or why is it all advertising?

One of the most frequent requests from mobile application developers that we hear at our events is a request for monetization reports. Everyone is interested in success stories about how someone earned millions of dollars. Everyone wants it too.

Everyone wants to eat.
')
We see disputes and throwing between what is the best way to make money. What to choose: paid applications, free, but with advertising, or free, but with internal payments or payment for additional functionality. Trial, donations ...

“Paid or free with advertising?” Is a traditionally raised question. And not by chance! Many of us remember the good old days when there were desktop apps with built-in ads - and today they have almost disappeared (as a class). Advertising in the application seems to be nonsense and disrespect to the user. We are accustomed to advertising on websites, and are so accustomed that we are mostly accustomed to ignoring it - and we perceive it as a completely normal manifestation of the desire of the website owners to make money on it or, say, to pay for hosting.

But advertising in (mobile) application? “Ugh!” - you will surely say ( as a user ).

Advertisers who provide various API / SDKs for inserting ad units, of course, say that the market is growing and they have a queue of people willing to advertise in your applications.

And they ask the developers why they do not insert advertising. And the developers say they consider it unnatural and it is easier for them to earn paid applications. (Honestly, something like this happens.) And the advertisers responded: “Well, let's count ...”

And if it is impossible to pay for a fee, because immediately a hundred thousand developers nashtampuyut the same thing, but for free, and with advertising unnatural, then on what, in the end, the money to do?

Or is it all prejudice and is it time to master the insertion of advertising in mobile applications? Or do paid applications really also actively buy?

Or, let's say, this eternal dispute between the sale of products and services? Sell ​​the finished product or try to build a service with a subscription or micropayments, which will generate revenue from each user gradually. And there are a lot of discussions about it.

Or, also an interesting question, do two parallel versions: paid and free with advertising or limited functionality - or one trial version, but with the ability to buy additional features? Is this problem purely technical or does it have a practical business component?

There are many such questions. And, by the way, they will be more and more relevant not only in the light of mobile applications, but also further tablet and desktop applications and any other.

Do you know what I think of them? I think that all these disputes and alternatives, - they are, in fact, about the same thing - about advertising.

It's all advertising

First of all, I must say that whichever way you use the applications you choose, it will always be a question of advertising. As soon as you agree that this is a question of advertising, all alternatives begin to play in a completely different light.

Look!

Free and extended paid

Let's start with a classic story. There are two versions of the application: free with limited functionality and paid with advanced features. You can call the first lite-version or the second pro-version, or even call them different applications - this is all marketing husk.

Another thing is important: you earn from the fact that someone still buys the paid version from you. Perhaps, of course, some of these people immediately buy a paid version, because this is exactly what they need. But, most likely, you rely on the fact that some users of the free version will decide that this is not enough for them, they want more - and here you offer a paid one.

And, if you think about it, it turns out that all your investments in the free version are advertisements for the paid version. Advertising can be direct (in the application) or mediated through the name of the application in the store or, say, through the website.



If at this point you split into two “for yourself doing the free version” and “yourself doing the paid version”, then it should be clear that “the first you” earns money by advertising the “second you”, while the “second” earns on direct sales.

It may even be easier for you to think about your creations not in terms of the “A” application and the expanded “A +”, but in the terms of the “A” and “B” applications, in one of which you sell advertising for another.



The free version is a fundamental investment in which you need to invest a portion of (future) paid income, it also needs to be promoted and maintained up to date. The free application advertises to the user the idea of ​​how good he will be (even better) with the paid version.

This is similar to the launch of flights with economic and business classes. In any case, you will have to invest in a plane and you will simultaneously serve passengers of both classes, hoping that some of the business will ever go into business. But on a bad plane, if there are alternatives, they will not fly even in economy.

Example

gMaps and gMaps Pro are popular mapping applications based on Google Maps services. The first one is free with ads, the second is paid without ads and with advanced functionality.

Trial and additional functionality

The second scenario - similar, but different in details (in particular, in implementation details) - instead of two applications, do one with extensible functionality.

You give the user the opportunity to play around with your application or toy, get into the taste and maybe even solve his main tasks ... A little bit more and he gets into your deft pulling in networks - and he will pay you his money to get all that magic functionality which you so wanted to give him, but shy.

Application features may be limited, hidden or hidden over time. You can make a trial with the integration of payment through the market or provide the user with the opportunity to buy more opportunities through some other service. You can even make your subscription mechanism for the app. In essence, in the context of our thinking, there is no big difference in limiting time or limiting functions.

If you ask the question of what the key role of the trial version is, then it turns out that you need it in order to advertise the paid functionality - to promote an idea in your head to continue using your application indefinitely or to buy additional features.

In the example with airplanes, this is similar to one general class, but with the possibility of additional payments for additional services: food, alcohol, etc., which helpful and cute flight attendants advertise during the flight. Another interesting analogy: the construction of a free road with earnings on the related infrastructure (hotels, cafes, gas stations, parking lots).

Trial is a way to get on your road.



I repeat: all the basic functionality exists only because it advertises paid features or lifting restrictions. As is the case with the free and paid versions model, this is a fundamental investment, from which there is no way to go, in which you also need to invest resources.

In practice, there may be various psychological nuances and differences between how you place accents and what you advertise. If you give the user a trial for 30 days, this is one situation that immediately forms the user’s expectation that in the end you have to pay a certain amount.

If you give the basis for free and offer to pay for additional functionality, then the expectations are different: no matter how much effort you put into the basic functionality, it is free for the user - and he subconsciously estimates the cost of the additional functionality, not the full application. Therefore, especially if there are alternatives on the market, it is necessary to find a balance between the importance of additional functionality and its price.

What is the difference between pay for functionality and free + paid versions? Well, apart from purely technical implementation differences? In my opinion, there are two key points. On the one hand, this is exactly the nuance mentioned above: free + paid separates more clearly what the user pays for. If you evaluate your complete application, say, at $ 2, then in the case of a trial, it will be $ 2 for additional functionality, and in the case of a paid one, $ 2 for the entire application. On the other hand, the implementation as a single application with built-in ability to purchase additional functionality is much closer to the user than a separate application with full functionality, and this should give a big conversion.

In practice, you have to experiment.

Example

The game Doodle God provides a trial version with a limited number of levels and some functionality blocked in the trial (for example, achievements that, by the way, remind you of the opportunity to buy a paid version).


Read more about creating trial applications for Windows Phone on MSDN .

Selling content

The third popular scenario concerns the in-app sales of some additional content. In general, it does not matter what you sell: tangerines, articles, books, music or swords, shields and virtual gifts for friends.

You can argue here that it’s one thing to do a social game with the built-in sale of nishtyachkov and quite another when your application is, for example, a shell and a mazagin for books, cartoons or articles. And they don't need to equate them ...

Yes Yes Yes. But in each of these cases, the main role that your free application performs is advertising the opportunity to buy something.

You may be making an incredibly beautiful and awesome game, but the goal of this game is nothing more than advertising for paid content. Perhaps, even technically, you will spend 90% of the effort on developing the game itself, and the remaining 10% on the content services sold - this is not important, your game has become an advertising platform for shields, swords, armor, magic potion ... or whatever it is now fashionable ? Cabbage, carrots, pigs?



Your application all its essence advertises the opportunity to get additional happiness: getting content, nishtyachki or saving time on growing potatoes.

Service sale

Often a free application acts as a client to the service. The user pays for additional services of the service itself. For example, for extra gigabytes, computing power, reliability, support, or additional functionality of the service itself.

Here again you will say that this is just a client for the service - and you will be right, but ...

But your client is nothing like advertising your service. The more a user uses your application, the more he uses the service and the more he is dependent on the service and the desire to get more from him - and at this moment he brings you a denyuzhku.

Even the fact of having a client for your service in the app store is the very thing that the ad service is.



Receiving in one way or another the income from your clouds, you invest part of the funds into service advertising in the form of clients for various platforms, which also increase the use of your service and, for example, occupancy of free space.

Example

Evernote is a client for a popular eponymous note-taking service that earns users who buy premium services with advanced features.

Using the user base

Now that we have reviewed the main scenarios for monetizing applications through the self-promotion of something of your own, it's time to switch to classic advertising scenarios, when, in fact, you sell access to your users.

How can you not remember: "if they gave you something for free, it is likely that they are not selling to you, but you."

You, probably, are already wondering what I can say here, except for inserting traditional ad units that we discussed at the very beginning? Now…

Scenario 1. Classic

You insert advertising of other offers inside your application. In fact, you rent a space, an advertising space - and this is a classic advertisement, for example, inserted by some advertising block using the SDK from one or another advertising network.

But there may be more interesting twists and turns: for example, you can embed ads from other apps! This may seem strange, but in fact sometimes it is quite meaningful, especially if advertising promotes not competitors, but some kind of complimentary solutions, perhaps not even directly related to your area.

For example, you make a geo-targeted service, then your application may offer applications related to a particular place (application of a specific restaurant, museum, etc.).



Geo-targeting and, in general, contextual targeting is an extremely rich topic, and in the application market we all still have a long way to go in mastering this area. Mobile form factor is interesting because you can “sell” not just a user, but a user “here and now”.

(And ... if you close your eyes to some technical aspects, in fact, this is no different from advertising inside your free application of yours, but paid.)

Example

To insert advertising into the application, you can use your own, perhaps more contextual and customized solutions specifically for your audience, and ready-made platforms like Microsoft Advertising ( SDK , help ) or Russian Begun .

This is a classic of the genre. Think that's all? No matter how!

Scenario 2. Branding and integration

Remember the trial version and the sale of additional functionality? How about the sale of additional "alien" functionality? You can think of it as plugins or extensions.



Your popular application offers basic functionality and possibilities for the implementation (integration) of a functional promoting other services or other companies. For example, you can make additional level packs in your game, as Angry Birds does under different platforms. A sort of sponsorship packages, extensions or just branding.

But for a start, of course, you will need a popular application or, more likely, a popular toy.

Or, for example, you can make a platform for organizing events and sell customization to users or organizers for a specific event (site, schedule, etc. - all within your application with additional extensions).

Scenario 3. Content Store

How about selling someone else's content in your application with the appropriate deductions?

What? Are you already selling someone else's content, since we already discussed this a few minutes ago? No no. We talked about your own content. But what do you think about the site with your users to provide space for someone else's content?



For example, it may be just articles of popular publications or not very popular ones that want to expand their audience, but are not ready to write their own application, but you can offer them in an interesting format. Or you can make a mobile platform for undistorted, but talented musicians or photographers.

Wider range - more users. And vice versa.

(And, of course, this includes any stores for resale of other people's content.)

Given mobility, you can develop various interesting context scenarios: photos of sights that I see, guides to the museum in which I am, a recipe for what I now eat, music or words for what I am listening to.

The hackneyed topic of "taxi services" is also the resale of someone else's content: information about transportation services that advertise certain taxi drivers or taxi fleets.

And there may be simply branded carrots for the garden ...

Example

Amazon Kindle is a free client (unfortunately, in the Russian market is not yet available) for e-books sold through Amazon, which actually acts as a publisher and a sales store. Amazon offers authors to publish books in electronic form directly in the kindle-devices and applications for different platforms.

Scenario 4. Services exploitation and barter

(Looking back ...) We have already sold someone else's advertising, an additional "someone else's" functionality, and built a platform for someone else's content. I feel, you guessed it, what will the fourth scenario be about?

That's right, you can offer your audience, especially if it is large, to third-party services.

Of interest is that many Internet services provide an API for developers so that they can write their own solutions based on these services or their combinations. This opens the way for creating your own clients (possibly paid or with advertising) to these services, and for expanding the functionality of your applications at the expense of third-party services (for example, through the introduction of Facebook social mechanisms).

An important, however, question is who pays for whom and for the service, because if you pay for the service, that is another story ...

Most often, an external service makes money on users in two ways:

• users pay premium services - for example, an increase in network storage (classics of the genre - Dropbox),
• users of the service itself see the advertisement and / or the service needs an additional audience or constant interaction with the audience (for example, Twitter).

In both cases, the service exposes a free API to developers in exchange for attracting users and generating additional contacts with the service.


In fact, this is a barter: by giving away users, you will save on your costs and get the coveted functionality, but your application acts as an advertisement for an external service.

Perhaps there are some interesting examples when the service will pay you extra for using its API, but I don’t see such examples (except for the advertisement inserts :)). If you know, tell me!

I hope now you believe me that all monetization is built around advertising?

Bonus!

Bonus theme - advertising your services. Good applications, even free ones, often turn out to be quite good advertisements for the developer or company that provides the corresponding services.

In this case, the monetization of the application itself is no longer your headache. You get money for the flow of applications:

Nameplate

Summarizing all the above, here is a small sign:

	Its	Alien
A place	Free + Paid: a free application advertises paid.	The application advertises other people's applications or offers.
Functional	The trial version advertises paid functionality.	The application integrates additional "alien" functionality that advertises the sponsor or the user needs.
Content	The application promotes additional content: articles, a book, a carrot.	The application is a platform for selling someone else's content.
Service	The application advertises a paid level of your service.	The application uses someone else's service for free, receiving additional value, or receives income from the promotion of the service.
Applications	Developing applications to promote yourself as an application developer: a job or custom application development.	Application store with earnings on the share of the sale of applications or advertising.

In practice, a particular application can make money using only one method or a combination of several:



For example, in one application you can combine your own and someone else’s content or your service can only be used in your application or also be accessible outside for other developers:



And, of course, you can tell about yourself using the app store, app reviews or special resources like appprofessionals.ru :



(Generally speaking, the application store itself can be regarded as earnings for advertising - advertising applications placed in the store.)

Conclusion

Well, the final remark. Sometimes different approaches can be combined between each other, the line between functionality, service and content, as well as between their own and others, can be very conditional, erased or completely absent.

What exactly and how specifically to do? Nobody will give you a reliable answer to this question. Everything is learned only in practice, but it must be understood that different methods of monetization are suitable for different types of applications and the tasks they solve. Something is suitable for the lazy, but something requires capital investment and serious work. Something gives a quick return and quite large chunks, but something can be milked for a long time, slowly and in small portions. Somewhere you need to focus on the number of users, and somewhere on the number of returns. The world is complicated.