We’ve all been there: we have just published our brand new app and we have dreamed of the perfect love story with our users. We provide them a valuable service, and we hope them to love us back falling into our arms wounded by Cupido’s arrow. Of course the more money they leave behind the better, as after all we aren’t in this game for the sake of it! However users seem to ignore our snuggles so we try to to use our last resort love potion hoping to finally win their hearts: push notifications. So said and done, we incorporate a whole notification system to our wonderful app, we launch it and… oh my! Instead of surrendering to our charms users uninstall our app and go use the competition!

In this article we’ll unveil why users hate (or love) push notifications, and what steps we should take to correctly use push notifications to rise user retention and monetization in our app.

Common mistakes when using push notifications

Push notifications, as any other tool, must be correctly used to achieve the objectives we pursue. I’m sure it hasn’t come to your mind to use a hammer to get rid of a headache, and yet sometimes I have seen push notifications used that way. Obviously if you do this not only the headache will not go away, but it will get worse. And that’s exactly what happens when we misuse push notifications: instead of raising our users retention we may be pushing them directly to the competition (pun intended).

But what are the most common mistakes people make when using push notifications? And how do these mistakes affect conversion and retention? Urban Airship is a globally recognized provider in the area of push notifications. They regularly publish studies on the impact of push notifications in user retention, and among those studies we have The BadPush Guide.

Based on this guide and in my own experience we will make a brief summary of the biggest mistakes people make when using push notifications:

• Ask for permission at the very beginning: It is very common to install an application, run it for the first time and meet a grim message where the app asks for permission to send push notifications. Wait, are you serious? I still don’t know what you have to offer me, I don’t know if I like the application, and you’re already asking for permission to annoy me whenever and however you want? No thanks! Obviously this practice is not the best way for users to accept push notifications, and therefore you will be missing a very important channel of communication with your users.
• Use push notifications to force a user behavior: You want the user to return to your application, so what do you do? You bombard him with push notifications just telling him long time no see, or reminding him that he would be having a blast if he just opened your application. Do you think this is the best way to make the user return to your application? First of all, have you thought about why the user does not return to your application? He probably won’t be drawn enough to your app to use it frequently, so bombarding him you’ll obviously only get him to deactivate notifications or uninstall the app.
• Notify about irrelevant content: I still remember the case of an insurance company that wanted to include in its application a notification to alert the user that he had not paid the last bill. We are talking about direct debit payments. If you think twice about it, it was something like: “Hey, it looks like you have no money left in your account to pay our bill. You’re probably having a hard time to make ends meet. But you know what? We don’t care how badly it’s going for you, just remember to pay our bills”. If someone does something like that to me I would probably change company. Ah! And then I’d delete their application!
• Notify relentlessly: Have you ever have experienced digital bullying? I have. It was an application of the Internet of Things that decided I would be interested in each and every one of the changes that occurred in my devices. I was tempted to delete the application. Finally I turned off push notifications, which probably should have been disabled by default since the beginning.
• Use notifications as a sales channel: You have in-app purchases, so what better way to sell than using notifications as advertisements for your products? Better yet, you can use your notifications for your marketing campaigns so you let your users know that there are new items in which to spend their money! NO, NO, NO! What makes you think that if a user does not buy on your platform he will do after bombarding him with ads? Using push notifications to do indiscriminate advertising is a direct path to the suicide of your application.

The astute reader will have noticed that all these mistakes have something in common: we abuse user’s trust to try to force a behavior that only benefits us in a totally intrusive way. It is the digital equivalent of that moment when Rex Kramer arrives at the airport in Airplane!. Each punch Rex delivers is an application gone from his phone. And I’m sure you do not want to end up like that, do you?

What is the impact of a bad use of push notificacions?

Urban Airship also regularly publishes studies on the proper use of push notifications, as The Good Push Index. In these studies they give us some interesting numbers on the impact of a good implementation of our push notifications strategy. We’re highlighting just one number:

293% greater push influenced app opens from highly targeted pushes vs. broadcast messages. This increment reaches 500% in certain industry verticals (e.g. gambling, entertainment or games)

Yes, you read right. A highly targeted push notifications strategy multiplied by 3 (in average) the number of conversions of notifications, or said another way, the number of times a user opens your application from a push notification. If that push notification is related to a sale, you’d multiply your income by 3. And who doesn’t like to multiply his income by 3?

We should also notice that for this comparison Urban Airship only takes into account the percentage of users the notifications are addressed to. According to them a highly targeted campaign is defined as a campaign addressing less than 5% of the audience of an application, while an indiscriminate campaign addresses more than 95% of the audience. That is, they don’t take into account other factors such as those we have included in the bad practices, so a well designed strategy compared with a bug-ridden strategy may multiply conversions by a much higher factor than the 293% stated above. In short, making mistakes in your push notifications strategy may mean that you are letting go piles of money.

So how do I have to use push notifications to drive user retention?

We all want users to love our application, and to that end users must also love our push notifications. How do we achieve it? It’s quite easy, we just have to follow some basic guidelines:

• A great notification strategy must be backed by a great application: No push notification strategy will take the user to your application if the application does not provide a valuable service to the user. So before you think about increasing retention using push notifications, think about why the user does not return to your application. You may need to fix many things in it before even thinking about adding push notifications.
• Always think first of the user: Push notifications are not a tool to fulfill our own selfish goals. Well, in fact they are. But as long as we always think first of the user, not us. I.e., push notifications should provide a valuable service to the user, and only in that case the user will perceive them as something deserving his attention. If this is not the case, your notifications will end up in the purgatory of ignored notifications, suffering an endless agony.
• Ask for permission at the right time explaining the benefits for your user: Your user just bought a ticket to a concert in his city using your application. What better time to ask for permission to send him notifications? Specially if before asking you explain him that thanks to notifications he will be informed of any concert of his favorite groups in his town, and he will never be left without tickets due to oversight or misinformation. I am sure that most users will accept to receive notifications. Why? Because they already know you, they have had a positive experience of your service, they have made a commitment to you and you’re proposing something of their interest. Compare that to asking permission to send them notifications without providing any other information just after running your application for the first time. If done correctly you can get push notifications acceptance percentages close to 100%.
• We should only notify the user when we have something to say IMPORTANT FOR HIM at an APPROPRIATE TIME: Has your user bought tickets to the last four concerts of Joe Satriani in the city and tickets for the new gig are selling out? Notify. Has the user a meeting in no time and there has been an accident in his way that could slow him down? Notify. Will your user host a dinner for 4 guests on Monday and today is shopping Saturday? Notify. In case this isn’t clear enough, the time the notification is performed is as important as the content of the notification. The timing has to be right for the user to perform the action to manage the event that caused the notification. And of course the content has to be of interest to him: If your user only watches Wim Wenders’ movies perhaps you shouldn’t notify him when they release the latest The Rock’s movie, don’t you think?
• Restrain your urge to notify: If you are hesitant about whether it is a good idea or not to send a notification to a user in a given situation, do not. You have to be absolutely sure that your user will be glad to receive your notification, that the notification will be useful and that when he opens your application he will think: “thank God they have warned me, they have just saved my life”.
• Let the user configure notifications: If you have met all the above points your user will be more than happy to receive your notifications. Moreover, he won’t probably be able to live without them. Still, it’s always a good idea to allow the user to configure notifications so that he may disable them easily and effortlessly. There are moments in our lives when we do not want to be disturbed even by the people with the best will in the world, so remember that we are here to provide the best possible service and respect the will of your users.

If you follow these guidelines you’ll see your users retention skyrocket, and that only means a thing: more money in your pocket!

Shameless plug

We at OPEN input are obsessed with this kind of details, because we know these things make the difference between a poor and a great app. The first application I published was a gratitude journal. One of the things we cared the most was the notifications strategy: we designed a notification system where we remembered the user that the benefits of a gratitude journal were obtained only with perseverance, and these notifications were sent only when the user seemed to forget to write for a couple of days or a week, at the time they would usually write (the end of the day). After two weeks we sent a final notification regretting that he had not acquired the habit, saying goodbye to him and telling him that we would never bother him again. It is the only application that I remember in which users praised notifications in the reviews of the application.

If you want us to help you with your mobile strategy, either regarding push notifications or anything else, please contact us. I’m sure you will not regret it.

The post How (not) to use push notifications to drive user retention appeared first on OPEN input.

Now that we are in the middle of the WWDC with the introduction of iOS 7 the blogosphere is in full swing supporting or despising the latest novelties from Apple. It’s always funny, whenever Apple introduces a new product, to read the myriad of articles from Android fanboys going like “this can already be done in Android”, “there are much more powerful Android devices”, etc. Unfortunately all these people still think that Android may compete against Apple creating a better operating system, smartphones with more cores or better cameras, or tablets with more storage options thanks to multi GB SD cards. They don’t notice that Android is not a competitor for Apple, because Apple sell neither smartphones nor tablets. Apple sell neither iPods nor iMacs nor MacBook Pros. No. Apple does not sell devices.

Apple sells the pride of pursuing perfection in every single thing they do. They sell the possibility of reaching millions of people worldwide, improving their lives in ways that were inimaginable a few years ago. They sell the magic of sharing your life’s best feelings and emotions with the people around you. Apple sells happiness, emotion, the longing of improving day after day to help us create a better world. If you think that this is nonsense, please, spend just 10 minutes watching the following video:

You may think this is just marketing, worthless sentimentality or plain silliness compared with your quad-core Samsung Galaxy S4. I would like to explain you why you are wrong, but I’m sure that Simon Sinek will do it far better than me:

To sum up, Android will never be a competitor to Apple as long as people in charge of Android still think that the best way to fight against Apple is to create better operating systems, smartphones and tablets. Apple plays another game.

The post Android is not a competitor of iOS and Apple appeared first on OPEN input.

PocketGamer.biz has just published an interesting infographic regarding the language being used by most of the users of mobile devices, as well as the current trends regarding downloads, emerging markets, etc.

One of the most interesting facts is that 100% of the top grossing applications in Japan are localized to Japanese. This clearly shows that in order to give service to a global market we have to make an effort to localize our application to the language, customs and traits of our target market. Either that or forget about the Chinese and Japanese market, currently encompassing 25% of all the downloads of mobile applications. What do you think? Do you localize your applications or do you just publish them in English?

The post Do your applications speak your user’s language? appeared first on OPEN input.

When we are about to develop a new iOS application one of the first things to consider is which should be the minimum iOS version to support. Supporting an old iOS version may mean more users for our application but sacrificing the latest platform functionalities or conditionally using them, making development harder.

It’s clear that in order to make a decision you should have access to the market share of all the different iOS versions. But things get tricky here. Apple, contrary to what Google does with his Android statistics, does not publish official data about the market share of iOS versions, so we must search for this information elsewhere. What are our options?

• First of all, if we already have a published application we can extract our own statistics… you are already doing it, don’t you? Any way this will only work if our application already has support for all the iOS versions we would like to measure and has a good amount of monthly downloads.
• If this is not your case, you can also wait for some blogs to publish information about the market share of different iOS versions, although this only happens from time to time and when there is an important iOS version change. For example, Chitika, an online marketing network, publishes from time to time reports about iOS adoption, as the one published on October 2nd where they report a 60% adoption of iOS 6 on iPhones, with iPads and iPods lagging a bit behind.
• Finally, some developers publish their own statistics based on their products. For example, David Smith, developer of Audiobooks with more than 100.000 monthly downloads, publishes his statistics of iOS versions limited to those versions his application runs in. On October 2nd iOS reaches almost 60% for all the available devices (although he doesn’t gather statistics for versions lower than 4.x)

Once we have this information we may take an informed decision about the minimum version our application will support, weighing on one hand all the iOS functionalities we’ll have available and their impact in the user experience as well as in development time, and on the other hand, the percentage of users that will be left out in the cold.

Do you know any other source to check regarding this? If so, share it with us!

The post Which should be the minimum iOS version supported by my application? appeared first on OPEN input.

With all the fuss made of HTML5 many clients ask us to use it to implement mobile application so they can reduce their costs when targeting several platforms. Our answer? No. In our opinion, in spite of the apparent advantages of having only one codebase running on different platforms, the drawbacks talk out of not following that path. Are we crazy? Do we go against the rest of the world that is on his way to a perfect Internet implemented in HTML5 in all its glory? We don’t think so. And we are not alone. Facebook recently made a step back and has published its iOS application, completely rebuilt from scratch as a native application, forgetting about HTML5. Why? Tobie Langl, Facebook UI architect and a core member of  Prototype, gave a list of reasons in the W3C mailing list that are mostly the same reasons we give our clients when they ask us about this kind of implementations:

• Lack of diagnosis tools when the application fails in the mobile device, causing a greater development time spent trying to diagnose those failures.
• Horrible performance in screens with scroll: mobile platforms are optimized to only load the content that is currently shown on screen when we scroll through lists with a lot of elements. If we use HTML5 we must load the whole content the same way it’s done with a web page, causing a performance hit due to high memory usage. The alternative solution is to implement some kind of Javascript logic to alleviate the problem, turning into increased development times.
• It is impossible or extremely difficult to accelerate certain content types using the GPU (Graphics Processing Unit) so we lose performance and smoothness in our application.

In addition to these problems we must keep in mind another very important issue: user experience. Creating only one application using HTML5 means putting native components and their associated experience aside. Or to put it another way, the user will face a weird interface that won’t match the rest of the platform. All of this makes us to spend the money and time saved having only one codebase in solving performance problems, adapting the interface to all the target platforms, etc. And worst of all, we may lose a lot of users due to a slow or confusing application that doesn’t follow the platform guidelines.

So, can using HTML5 be ever a good idea? We don’t have any doubt about HTML5’s bright future, but right now we think it’s only a fit for extremely low budget applications which doesn’t have to show a lot of data and where user experience is not a priority. But if this is your case, maybe you should rethink your mobile strategy.

The post Native or hybrid application? appeared first on OPEN input.