Most profitable ad solution for live wallpapers?

We have 2 ad alternatives for our live wallpapers:

1)Offerwall ads from Appbrain or any other company in the settings menu.
We could enable all of the settings in the free versions and encourage the users to experiment with the settings. The offerwall ads would be shown everytime the user accessed any of the options in the settings area.
The full version would be ad free.

The advantage with this would be that we could get much downloads, since users got all of the settings for free. But maybe there would be less purchases, since people would not be willing to pay to skip the ads. I am not sure how many times the settings are actually used.

2)Notification ads from Senddroid. This would give a lot more fast revenue. The users would then be warned before the installation in an opt in dialog that the app contains notification ads. This would result in a decrease of downloads. Maybe 40% wouldn’t want to install it? The app would be listed as virus from DrWeb and other virus companies and get bad reputation. The app would probably never be really succesful and get any top ranking.

Maybe alternative 1) would pay off better in the long run, since there would be more installs and better rankning. Or what do you think?

And what about a third alternative ?

Send your own notifications while the wallpaper is running so as to comply with the new Google Policy and then you don’t have to show an opt-in. The notification could be a link to the Appbrain appwall or any other appwall or everything you want… I was thinking about doing exactly this a few days ago.

Another alternative I saw yesterday came from the official Halloween wallpaper (Michael Myers). In this wallpaper everytime the user touches the screen a ghost-like icon is shown at the top right of the screen. If you click on that icon an offer wall is opened. If you don’t click on it, the icon vanishes after a few seconds.

Wouldn’t notifications without opt-in warnings result in bad reviews even if the notifications are only shown when the live wallpaper is running? We used Leadbolts notification ads before and that resulted in bad reviews.

Maybe your other alternative could work. Our live wallpapers are touch responsive, most of them are 3D rides through space. The user can change the speed by touching the screen. Maybe we could display an offerwall some of the times when the user touched the screen. But I am not sure how to implement it and maybe it would be very time consuming to get it to work?

As someone who will not install an app if it gives a notification I would recommend going with option one. While you may not generate as much revenue you would get better ratings and more people trying out the app and recommending it to others.

So you uninstall all apps that send you notifications ? Google Play, the Alarm of your phone, your antivirus, your battery monitor, everything ? You must be a real “notification hater” man.

I have found a another alternative. It is called Alert ad pro and it is an ad format from Senddroid. It is not a push ad, here is how it looks like:

http://youtu.be/bqHe-zmkoRo

What do you think of this alternative?

It’s just a dialog with a banner. I don’t think users are going to accept a dialog showing up on their home screen while they are doing something. It’s far worse than notification ads. Also, AFAIK dialogs require an Activity Context, and you don’t get an Activity from a WallpaperService. You might still do it with a transparent activity though…

Hey Androider,

it doesn’t appear on the home screen.

It is an in App ad.

You can configure when and how many times to display it but ONLY within the app estate.

Hope that clarifies.

Cheers

Yes, I know it’s not meant to be used outside of apps. I was just telling MobileVisuals it was not probably a good idea to use dialog outside of apps.

For live wallpapers:

  • in-app billing (Google - if your country supports it)
  • some other “payment” solution like Tapjoy/GetJar/SponsorPay which uses “gold coins” people earn for completing offers (Tapjoy) or downloading apps (GetJar/SponsorPay).

The payment solutions are probably apt - as you could lock the app after user has tested and ask for payment.

  • AppBrain as others suggest here - however if you cannot present it often enough how will users know - putting in settings MAY get some interest but how often do users select settings …
  • From discussions recently in another thread it seems StartApp maybe an option for you - they basically pay per download from $0.05 to $0.014 per download of your app. The disadvantage is that you can only charge a maximum of that per user (once). That can be a problem for other apps which require continual payments/subscription or which require MORE payment per user than $0.05 or $0.014 etc. However with a theme/wallpaper if you are content with that price (note this is per download) - so it could give a reliable revenue. The problem is that gives user a dialog explaining what is being done - they basically place shortcut on home screen, few bookmarks in browser and may also change default homepage for the phone’s webbrowser. StartApp supposedly uses that to drive traffic to their search site etc. One advantage StartApp has is that it is “instant” i.e. no more steps as the changes can be done immediately once the user accepts the changes …

The virtual currency solutions maybe a good choice as well (Tapjoy/GetJar/SponsorPay above).
[hr]
How does one do notifications (for apps that are not running) - I think it is now called Google Cloud Messaging - is that the standard way to do it - assuming one wants there to be an announcement if say you are running a special deal for the app etc.

StartApp seems like a good alternative! But would that risk bad reviews or decrease of downloads?

I am not sure what type of in-app billing you mean. Do you mean selling the full version from the free version?

Wouldn’t the virtual currency solutions have the same problem as with appbrain, that the ads only can be shown in the settings screen?

Here’s the deal

Users should know and understand that if they’re going to use a free version of the app, they will have to deal with ads. And if they don’t like the ads, they can spend a dollar and get the ad free paid version.

It is quite ridiculous for users, in my opinion, to complain about seeing ads which they can simply clear away with a single tap and not pay a dollar to get the paid version.

The key is of course that the users SHOULD know what they will be facing when they download the app and what options are available.

There is a developer I know who has had this kind of a deal even before the Google TOS came out.

When the user downloads the app, he/she is shown a dialog box stating that the app is going to send Push Ads and that is how he makes money. If the user doesn’t want to put up with the ads, then the user is given the choice to either get the paid version or not use the app.

That in my opinion is a simple and plain solution.

I completely agree with you. The problem is that current “notification networks” don’t allow you to know if the user accepted the opt-in or not, so you are not able to force the uninstallation of the application. People seem to think that because something is intangible (digital) they don’t have to pay for it.

I have thought about that issue.

This is why I particularly focused on forwarding that information to the developer so they can limit or decline access to the app in the event that the Opt In is rejected. So our SDK will give you that information.

But the problem is that most people use multiple networks and if you want that functionality, then you need to be sure that all SDKs do that.

By the way, with these notification networks (Leadbolt/Airpush/Senddroid) - does the developer get paid once or do they get a share of the notification ad revenue.

What is the typical revenue per installation of their SDK. I suspect “eCPM” numbers for this type of ad are inappropriate - and the metric should perhaps be what the earnings is per installation of the notification SDK on that phone. Adding later: ok, it seems you get paid if user clicks on notification ad (so is similar to banner ads etc. in that respect).

What happens if a phone already has another app which installed an ad. Does the user get 2x as many ad notifications (labelled by the app name - according to the new Google policy). Or does the user get paid less in that case (presumably if all devices got saturated with Leadbolt/Airpush notification ads and Senddroid/StartApp etc. then there would be no more money to be made ?).

By in-app billing I meant just locking the features until user pays via Google (if that is supported in your location).

Virtual currency solutions based on app downloads (Tapjoy the app offers part/GetJar/Sponsorpay) differ from AppBrain in that AppBrain does not tell you if a user has downloaded an app. You are paid for it but you don’t know if a particular user did that - so you cannot do an in-app reward (i.e. unlock features or credit him etc.) for that.

With AppBrain you have to make space in your app for reasonable amount of presentation of their app offerwall - so that users eventually click on something there (and you get paid). So in that sense it is similar to a banner ad - where you are hoping that people like an ad and click on it.

Now if AppBrain started giving feedback to developer immediately that user downloaded an app - THAT would make it similar to virtual currency solutions.

Because then you are in a position to reward the user (unlock a feature/remove ads etc.).

Because AppBrain is similar to ad - there is a requirement that you present it enough times so user “feels” like clicking and downloading an app. With virtual currency you can just use an “unlock” button - which leads to the offerwall for the virtual currency. You don’t have to show the virtual currency offerwall all the time or even once. Though one could show perhaps a reminder that more features could be unlocked. Or have features that stop working after X tries with reminder that they can be unlocked etc. …
[hr]

I wonder if there is a side-benefit of having notification push ads having to mention the offending-app’s name (according to new Google policy).

Since users get those notifications even for dormant apps (app not used in a while), I wonder if it could work as a reminder to the user that “hey they should try out that app again” ?

I think the best way is to use appwall on setting page as “Other games” button and put it when user change wallpaper. You need to build everything to make users want to go to settings page (options to customize it). Be aware that users clicking on “Other games” will have better CTR because they already have the intention to install an app.

Since wallpaper has low playability the conversion ratio will be low - unless the live nature of wallpaper prompts them to tweak settings etc.

How about wallpaper that issues notification to inform user to pay etc. ?

Done using Google Cloud Messaging etc. ?

Yes, we could enable all of the settings in the free versions and encourage the users to experiment with the settings. But maybe there would be less purchases, since people would not be willing to pay just to skip the ads. They would already have all the features of the live wallpaper, since all the settings would be enabled.

What do you mean with “put it when user change wallpaper”?

[hr]
I have implemented the code for Alert ad pro in a live wallpaper, but the ads are not shown. Are you sure that this works on live wallpapers?

Hi MobileVisuals,
if you join on irc you can talk with Mat86 that is doing exactly that with appbrain.

Check last post on the website! :slight_smile:

Cheers,
Gabriele

I don’t know much about live wallpapers - but I am guessing this is something where the user maybe happy with your default settings and you are not monetizing their continual use with default settings.

The solutions that seem appropriate would seem to be:

  • push notification ads Leadbolt/Airpush - where you get paid for “installs” (even those not engaging with your app wind up paying) - here you get paid for the notification ads over time (just like banner ads etc.).

  • one-time “payment” solutions like StartApp - which places icon on home screen, shortcuts in browser and changes home screen on browser - pay $0.05 or $0.014 per download of your app (means you cannot charge more than this per user). The advantage here is the payment is “instant” i.e. instant enablement of your app if users agree to those terms (which many users who don’t use browser wouldn’t mind, while others may).

  • one-time payment when they first run the theme/wallpaper etc. - using Google payment (if your country supports it) or using Tapjoy/GetJar/Sponsorpay type “virtual currency” where they make the effort and pay you before they can use the app - now my guess is you would want the user to use your app first and not scare them away with payment stuff - in that case, perhaps a solution where you let them install but then issue notification “reminders” that they can pay using Google payment/Tapjoy/GetJar/Sponsorpay.

If you get some stats on what works, if you could share that here - that would be helpful for us.

Thanks.