10,000 full screen interstitials per day, what shouldI be earning?

For AppBrain I can see that there are:

  • clicks (how often an app icon is clicked that takes users to Google Play)
  • installs (how often users install)

So it could be something similar for Leadbolt AppWall - i.e. you COULD have users clicking on the AppWall - and that takes them to Google Play - but they may not be installing the app.

I don’t know if Leadbolt etc. pay you per install or something more complicated like whether the user runs the app.

AppBrain it seems pays per install - and the figure is generally around $0.18 per app install.

Hi there David,

I thought you were using the actual interstitial format from Leadbolt. So, basically you are only using their app wall as an interstitital ? Why do you say there are only two ad formats suitable for interstitials ?

Is there actual interstitial in Leadbolt? I couldn’t find (at least not in HTML) it and am also using appwall as an interstitial…

A Leadbolt App of me:
Again here you can see my problem with >0 clicks and $0.00 revenue.

BTT: Looks like they have interstitials :wink:

App Ad (SDK)
App Ad #1 - Interstitial (Chrome) – 1 0 $0.00 $0.00 0.00% $0.00
App Ad #2 - Alert (Simple) – 6 0 $0.00 $0.00 0.00% $0.00
App Ad #3 - App Wall (Light) – 10 0 $0.00 $0.00 0.00% $0.00
App Wall (HTML)
App Wall #1 - App Wall (Dark) – 31 4 $0.00 $0.00 12.90% $0.00
App Audio (SDK)
App Audio #1

Seems like I get paid when someone installs AND opens an app.

That seems like a greater burden than what AppBrain required (i.e. just that the app be installed).

Though it seems the install AND open requirement maybe becoming the norm - as even GetJar requires that users install AND open the app to earn coins.

My assumption thus far was that AppBrain is still paying per install (and not install AND open).

However bottom-line is that David/Magnesus etc. are reporting higher revenue per impressions etc. (than AppBrain) - which would suggest either higher revenue per install (and open) - or that the Leadbolt AppWall is just better designed that it elicits a better conversion rate from the users (than AppBrain).

I have yet to convert to Leadbolt AppWall from AppBrain - but I will try it soon.

David,

What AppWall formats work better - Dark or Light or some custom colors (have you used the Leadbolt “multivariate analysis” - if that does the color selection etc. ?).

Since one is using the url version of the AppWall (HTML) - I assume one does not need to include ANY of the Leadbolt SDK .jar files then - and not require any modification to the proguard file either ?

The urls that one gets don’t immediately work:
“This content is not available for viewing at this time.”

It seems they may work after the app has been made “Active” - Leadbolt requires a download url for the APK for their manual approval process - I assume one would not put it on Google Play without testing with working ads first - so one should place the APK on a server etc. first and once approved and then tested - only then put on Google Play (basically how it works ?).

I just put the apps on Google Play without testing ads. Leadbolt is really quick with the approval.

That’s right, I’m using their App Wall as an interstitial. They do have other “proper” interstitial formats (alert dialog, content unlocker) but I couldn’t use these as they don’t scale well in my particular app. The two formats I’ve been using are both HTML-based: the square banner ads, and app wall.

I don’t use the multivariate analysis at this stage. But I have tried a few different colour schemes and title text. In my experiments, light colors seemed to perform marginally better than dark. But the biggest difference was actually the wording of the title.

For the HTML App Wall I tried two different titles:
1.) “Help Support This App” - eCPM of $8.25
2.) “Top Apps/Offers of the Day” - eCPM of $5.27
(Across a total of 25k impressions.)

So my conclusion is - the title of the ad unit makes all the difference. People are more likely to click the ads if they realise that it supports future development of the app, rather than just seeing the ads as spam.

That’s correct. You only need to include the SDK if you want to use some of their other ad formats (e.g. notifications, alert dialogs, rich media unlockers, etc.).

When I’m working on a new app, I get a very simple ad integration up & running, then upload an APK to my server so that I can request approval from LeadBolt. As Magnesus says, they are very quick to approve new apps (I usually get a response within an hour or two). After the app has been approved, I can work on further integration. Although any customisations I make to the default ad templates also have to be approved before they will display.

David and Magnesus,

That is excellent feedback.

David:

The title suggestion is great.


That’s right, I’m using their App Wall as an interstitial. They do have other “proper” interstitial formats (alert dialog, content unlocker) but I couldn’t use these as they don’t scale well in my particular app. The two formats I’ve been using are both HTML-based: the square banner ads, and app wall.

You picked AppWall (HTML) as the higher eCPM variety out of the usable types - how well do the alert dialog etc. from your info ?

Given what I have seen with AppBrain, I would guess that AppWall formats WOULD be the better paying - but who knows - with all the new formats Leadbolt is delivering i.e. Audio Ads etc.

I haven’t even tried the new formats in a live situation yet. When I implemented alert dialogs in my app, they wouldn’t scale properly. Due to the graphics I’m using, I was unable to implement the workaround that LeadBolt suggest, so I had to stick with the HTML offerings.

Ok, graphics scaling of the other formats was the issue.

Regarding the ad networks - while I think Leadbolt gives some vague “pays more” type explanation for the various ad formats, what is lacking is actual metrics - which probably vary by app, but it would help if the ad networks showed the metrics for a couple of the apps - this way developers would have a ballpark figure.

I guess for that reason you have Airpush SmartWall type solutions where the developer is doing the optimizing - but even here if the developer is not doing the optimizing, but the ad network is doing that - then it is all based on trust.

Ideally there would be some universal SDK - and then you just flip some AppBrain Remote Settings type stuff and can choose between radically different ad formats.

Realistically apps can vary a lot - so may not be doable, but just seems like a shame when every developer is doing the SAME type of optimizing all over again - again this is where a big publishing house will have advantage (in-house expertise) as will developers who have a couple of apps under their belt.

I guess there can be a number of differences between apps - recurring user rate (new users more likely to click everywhere than jaded users of the app) - the type of app/user demographics and their likelihood to click (young/old user base) - and the type of ad format (if it is appealing) - in your case it is similar i.e. Magnesus/David using Leadbolt - but as David mentioned the use of different titles (i.e. “Please support the developer” doing better than “Try out new offers”).

I have generally seen (and reported by others) - that new users tend to click more - and that is the case with newly released apps as well.

And as the user base increases and the DAU (daily active users) start to get a greater share from recurring users (as “active user” base increase you will or should have linearly increasing recurring users). So this means over time you may move from 0% recurring users (for a new app since there is no installed user base) - to say 25% to 30% recurring user base (number will be higher if app has high playability and attracts recurring users - number will ALSO be high if the app has been on the market for long and has built up say 1M installed “active users” base).

One element that MAY help for recurring users is if the ad formats were to change perhaps - i.e. that may be enough of a jolt to maybe make recurring users also click on some banner ads or what ? (because with continued exposure users tend to censor out the ad areas - as happens with browsing of webpages).

Thus you will probably get higher click rate from “new users” as well as users who are low-tech users (I am guessing).

The low-tech thing also perhaps affects stuff like StartApp clicking on “Yes” on EULA - as naive users would tend to click more - while others more wary of security etc. would just ignore an app which requires something to be changed in their browser (or at least would have higher hostility to that).

We have examined before how total downloads can be misleading - as those go up monotonically over time (i.e. never fall) - while your “active users” base may be 25% to 35% of the total downloads only (recurring users will arrive from this group). The recurring users (which maybe 25% or so of the DAU) and new install users will make up the DAU (daily active users).

Generally one would want a high recurring user rate (i.e. low churn rate) - it will be high for apps which have a loyal user base.

HOWEVER, given the attributes described above - it is possible for apps which have a high daily new install rate to still do well (even if they have an abysmal or not that great recurring user rate).

And that may happen if the app uses StartApp type stuff - as reported the conversion rate of 80% would get revenue from more than the users who will become recurring users (which suggests users ARE probably clicking on “Yes” in error - or are not aware as much about security or such matters - or their phone is already a dumping ground for such apps and they have stopped worrying about messing up their phone environment - this may be different for more tech type users who may be more careful).

And if an app has a high new install user ratio - since THAT group tends to click more on Leadbolt AppWall HTML ads etc. (or banner ads) etc. - it may be more valuable to have a high new user rate also (well it’s not that you don’t want recurring users - but just that as far as ad revenue conversion - if you are getting new users every day - that maybe more important than that they become recurring users).

Obviously with in-app purchasing models - you WOULD want the recurring users to be high also.

Anyway, just are some thoughts …

my short experience with leadbolt and airpush . i had them both in one of my apps and leadbolt was suppressing airpush for some reason … contacted support a few times and it was all installed correctly . i was getting the some “great” numbers with leadbolt - ZEROS all across the board with about 500 + clicks on their wall per day … since i got rid of leadbolt my airpush is working overtime:) my average eCPM is $4.30 for the last month and it even started much stronger( about $8) but as i was mentioning in a different post - its down big time lately… i can make a suggestion - try Startapp - easy to implement code and they pay per install, nothing intrusive like airpush or leadbol, just one app icon a bookmark . here is the linky StartApp - Developer Register .Good luck either way

The discrepancy in eCPM between David and Magnesus figures for Leadbolt AppWall HTML ad format may also be affected by how often they show the AppWall.

I suspect as you increase the frequency of presentation of the appwall, the eCPM will start dropping (i.e. novelty per-presentation is reduced as users get fatigued).

Though overall revenue generated may STILL increase (i.e. diminishing returns from over-presentation, but eCPM x higher presentation may still give overall higher revenue). But eCPM should probably drop somewhat from over-presentation.

As with banner ads etc., perhaps again the figure to watch maybe revenue per DAU (daily active user) - and even that can vary between apps since the DAU maybe of different demographics, and the app may have different interest for those users.

However in analyzing the optimal ad presentation frequency, generally one would have other things about the app/demographics being the same - just scaling up the frequency of presentation and seeing how much impact it have - of course over-presentation also leads to lower usage-quality (users being pissed off).

The discrepancy in eCPM between David and Magnesus figures for Leadbolt AppWall HTML ad format may also be affected by how often they show the AppWall.

I suspect as you increase the frequency of presentation of the appwall, the eCPM will start dropping (i.e. novelty per-presentation is reduced as users get fatigued).

Though overall revenue generated may STILL increase (i.e. diminishing returns from over-presentation, but eCPM x higher presentation may still give overall higher revenue). But eCPM should probably drop somewhat from over-presentation.

As with banner ads etc., perhaps again the figure to watch maybe revenue per DAU (daily active user) - and even that can vary between apps since the DAU maybe of different demographics, and the app may have different interest for those users.

However in analyzing the optimal ad presentation frequency, generally one would have other things about the app/demographics being the same - just scaling up the frequency of presentation and seeing how much impact it have - of course over-presentation also leads to lower usage-quality (users being pissed off).

I have tried to modify the code provided by David for Leadbolt AppWall HTML - to allow preload of the ads. Then at the appropriate time for presentation of the appwall, one can query to see if ads are available (and thus display of appwall will be instant).

The trick is to do all the stuff in the UI thread - and the loadUrl() part (see David’s code) in a separate thread (loadUrl() is the time-consuming part).

David’s code:
http://forums.makingmoneywithandroid.com/advertising-networks/740-leadbolt-app-wall-code-sample-activity-webview-html-ads.html
RE: LeadBolt App Wall Code Sample - Activity with WebView for HTML Ads

Once I get it right, I can post the code.

Any ideas regarding “when” the presentation of the appwall is acceptable - i.e. at start of app, end of app.

And should I replace the current AppBrain end-of-app “More Apps” interstitial (which only appears once every 3 days) by the Leadbolt AppWall.

That is, try to present it as close to the beginning and once at the end - is this reasonable ? (though for longer games etc., one could present it at some occasional natural break i.e. when scores are presented/level etc.) - but is beginning/end reasonable way to do ?

EDIT: Another question - the default behavior with David’s code (if I recall correctly) seems to be to exit the AppWall when user pressed the back button (i.e. just like any activity). Does this work out well - i.e. the use of an “X” is not really essential - the back key behavior seems the simplest from the user point of view.

But the use of “X” may have been designed by the ad networks to ensure the user interacts with the dialog boxes or something (don’t know if it impacts the conversion ratio that much) ?

Any thoughts on this ?

Thanks.

My suggestion would be - leave the AppBrain prompt at the end of app. But add the LeadBolt App Wall as an interstitial between levels, or wherever there is a natural “pause” in app usage.

Even better - put a button on the main menu and between every level, which links to the App Wall. You could make the button text randomly chosen from a list, like this:

“Get Free Apps”
“Support This App”
“Download New Apps”
“Get More Cool Apps”

The random variation in text might add some interest, and avoid “ad-blindness” :slight_smile: And because the user’s clicking a button, they won’t get annoyed by an interstitial popping up when they don’t want it.

Anyway, that’s my two cents.

Good points.