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

Monetizing, Advertising & Marketing Advertising Networks
41

ok here are my 2 cents:) i have 2 apps and from the start both had leadbolt and airpush ( i know, kind of brutal but i was limiting them to 1 push every 2 days plus app wall leadbolt between levels and app wall airpush on exit , for good measures…) . anyway - leadblot was getting about 3000 impressions a day with 4 out 5 days -ZERO $$$ … airpush was steady delivering day after day with eCPMs around $3 . then for still unknown reasons Leadbold suspended my account and is still suspended - no explanation , my AM couldn’t help , no answering my e-mails . i was mad for a day because i have some money in that account but then i got tired of waiting for response and took down leadbolt SDK completely . well. guess what - Airpush is working overtime and it is turbo charged !! that suspension was a blessing in disguise - the first few days airpush’s eCMP jumped to nearly $20 ! then as everybody here shared dropped big time for a few days but is back up - yesterday was a nice round $10 even! my point to all this story - just go with airpush - at least for me - absolutely NO comparison in eCPM and they pay weekly! i used to do the full page ad wall , now i’m only using the “dialog adds” - same great eCPM and its way less intrusive . plus for some reason - we were able to implement airpush much easier then leadbolt on our android apps , and could NOT implement it on the IOS at all. it just didn’t want to work…

speaking of less intrusive - maybe you can try startapps ,which turn out to be a hidden gem in my case . the user clicks once on install and then they probably forget its there ( just an “more games icon” )- you get your 5.5 cents and don’t forget to get your money every month with $50 minimum and that includes their great referral program . i have a link below if you want to try.

42

That’s weird that we’re getting so much difference in eCPM from LeadBolt. The other day I was getting $20 eCPMs from them, and even now when they’re down lower it’s sitting at $4-5 this week. I’ve pretty much done the opposite to you - stopped allocating traffic to other networks & gone nearly exclusively with LeadBolt! I’m just using the app wall though - no notifications.

How are your apps going with the Airpush EULA? I’ve been reluctant to try the Airpush smartwall and dialog ads, because I don’t want to show that scary EULA when I’m not using push notifications at all.

43

First day use of Leadbolt AppWall HTML ads (full screen interstitials):

3072 impressions
91 clicks
$1.18 eCPM
$0.02 EPC
2.96% CTR
$5.57 revenue

These would be all new users since this is the first version of the app using Leadbolt. I suspect over time users would get tired and conversion maybe less still …

Then around 8am EST (U.S.) Sunday morning, seeing these stats in the Leadbolt stats:

982 impressions
32 clicks
$0.76 eCPM
$0.02 EPC
3.26% CTR
$0.74 revenue

Reason for the lower eCPM maybe that just not enough clicks (statistical variation), or that most users are late night users (or non-U.S.) in early hours of the “day” (don’t know which time-zone Leadbolt calls “day” - perhaps U.K. if Leadbolt is based in the U.K. ?).

So the type of users, their likelihood of installing apps, may play a role.

Regarding the difference between apps - that may happen when you have over-presentation of the AppWall (users get jaded or tired of them) - while if other apps show the AppWall less often it may retain some novelty.

Also apps which have a high number of new users every day probably also have higher eCPM - since new users tend to click more often on “More Apps” (while recurring users know exactly what “More Apps” leads to).

I also have some revenue numbers for Getjar Rewards (similar to SponsorPay - where users earn coins by downloading apps - then use those coins to unlock features in your app).

The GetJar revenue is pathetic so far - so for comparison while Leadbolt AppWall gave $5 for a day - for the same users, the GetJar gave $1 or so (!).

However there are plenty of things to be optimized - GetJar is just too slow to load etc. (need to check out some sponsorpay apps to see how fast that process is …).

Of all the formats, it seems StartApp has the simplest (install and forget) type of ad models - the problem with StartApp is that their RPMD (revenue per 1000 installations of their shortcut on home screen/bookmark etc.) is stated as $0.050 per unit for U.S. and $0.010 for non-U.S. (though it averages $0.018 or so supposedly).

Their website currently says:

StartApp
$12 RPMD

That is, $0.012.

So this is the problem with StartApp i.e. no guarantee that it keep on paying that rate. Plus once unlock StartApp then may need to not show other ads (?). However folks here report 80% conversion rate (on your total downloads !).

44

My ad network stats are often completely different on the weekend. Sometimes they’re higher than during the week, sometimes lower, but I always know to expect a change come Saturday.
I’d be interested to hear if this “first-day” experience changes once we get to Tuesday or Wednesday next week.

45

Regarding updates for the revenue - while the impressions number seem to be updated regularly on the Leadbolt website, the revenue numbers seem to jump - perhaps it is “bursty” in reality - or maybe how Leadbolt does the counting (i.e. has to be assured that an app is opened and sometimes it maybe opened much later ?) - maybe that is why they update the revenue figures in bursts (or perhaps lagged ?).

Ok, I now have the data for (probably partial 26th Jan) and a full 27th Jan 2013.

Date App Name Views/Imps Clicks ECPM EPC CTR Revenue

01/26/2013 All Apps 3,072 91 $1.81 $0.06 2.96% $5.57
01/27/2013 All Apps 5,931 174 $0.65 $0.02 2.93% $3.87

So you can see that on Sunday the eCPM was lower (the EPC also lower - earning per click I am assuming).

The CTR seems stable at 2.9% or so.

Since revenue can be zero while CTR is non-zero - it suggests the CTR is the click-through rate for users who click on the apps in the appwall.

While the revenue is only counted once they actually install an app.

The first day, however ALL the users are new users - and so may have clicked more, while on second day would have similar number of new users PLUS some recurring users with the same new app version from the first day - however CTR is the same (probably because recurring users are small fraction or whatever ?).

Figures for another app:

01/26/2013 All Apps 3,630 92 $1.25 $0.05 2.53% $4.52
01/27/2013 All Apps 6,327 176 $1.03 $0.04 2.78% $6.54

Though the discrepancy is less.

So maybe the variation is just the STATISTICAL variation one expects from day to day (with the low numbers).

However the revenue numbers WILL vary hugely depending on the user demographics (how likely are the users for that app to want to actually download and run a new app).

  • so user interest
  • frequency of presentation of the interstitial (if presented too often, then number of impressions will be HIGH, but CTR i.e. users clicking will be low - and eventual clicking to DOWNLOAD and run those apps would be also low)

Frequency of presentation of the Leadbolt AppWall HTML ads

I am currently displaying the Leadbolt AppWall not more frequently than once every 3 minutes - usually during a period of inactivity.

Now, I COULD reduce this down somewhat as 3 minutes or thereabouts maybe a bit too often.

If I reduce that - the CTR SHOULD increase - but will overall user interest in downloading apps become greater (overall) ?

It COULD be that if one overpresents then users start to see the AppWall as a NUISANCE (this maybe behind the logic for AppBrain’s suggestion to only show the end-of-app “More Apps” interstitial once-every-3-days).

I was showing Greystripe interstitials earlier at the 3 minute interval type of thing - so I continued that with Leadbolt (perhaps the ad presentation scheme should be changed).

So the question is - will increasing the interval from 3 minutes to much longer - OR even to make it show once per session (or on onResume()) - if that will lead to MORE overall downloads of apps by users ?

Comparing Leadbolt AppWall HTML ads vs. Admob banner ads (and AppBrain banner ads)

For the app which has Leadbolt AppWall HTML ad revenues:

01/26/2013 All Apps 3,630 92 $1.25 $0.05 2.53% $4.52
01/27/2013 All Apps 6,327 176 $1.03 $0.04 2.78% $6.54

for this app - let’s look at the Admob banner revenue (73% of banner allocations) and AppBrain banner revenue (23% of banner allocations) using Admob mediation.

I just posted these figures on this thread - so copying figures from there:
http://forums.makingmoneywithandroid.com/advertising-networks/1032-insane-revenue-ctr-drop-admob-post7524.html#post7524

The new install/daily active users (DAU) figures from AppBrain stats for this app are:

2013/01/27 - 2213 - 4578
2013/01/26 - 2173 - 4285
2013/01/25 - 1825 - 3547

So about 50% of DAU are new installs, while 50% are recurring users.

Over the weekend the eCPM for Admob banner ads has been:

Date Revenue eCPM Requests Impressions Fill Rate Clicks CTR

2013/01/27 $2.88 $0.25 11,718 11,715 99.97% 71 0.61%
2013/01/26 $1.61 $0.15 10,668 10,660 99.93% 50 0.47%
2013/01/25 $1.82 $0.25 7,264 7,264 100.00% 45 0.62%

So eCPM varies but is below the earlier levels (prior to Christmas).

Admob banner ads are getting 73% of the banners (AppBrain getting 23% and 2% for various other like millennial media).
So the above impressions are essentially 73% of what they could be (if I gave 100% banner allocation to Admob banner ads).

But one can see that the Leadbolt ads are paying much more than the Admob banner ads (see in a wider picture).

Comparing Admob banner revenue vs. AppBrain BANNER revenue

AppBrain has both banner (“More Apps”) and end-of-app interstitials (set to show every time OR set to show at the suggested once every 3 days - that’s up to you).

I am currently giving 73% banner allocation to Admob and 23% to AppBrain banner ads (2% to various others like millennial etc.).
The reason giving 23% (only) to AppBrain banner ads is that I have seen (though one can never be sure - was just a hunch) that giving too much allocation to AppBrain banner ads does not give the same returns (i.e. there is a limit perhaps to how many times you can show “More Apps” banner ad and have people respond - so gut feeling is that perhaps it’s value is in the novelty vs. the “usual” Admob banner ads - so show the AppBrain ones sparingly).

For comparison here is the AppBrain revenue (the banner ads are the ones mentioned above 23% of total) while the “non-banner” revenue is the revenue from the end-of-app “More Apps” interstitial (set to appear at the suggested once every 3 days per user).

Date Banner impressions Banner Revenue Banner eCPM Clicks Installs Non-banner revenue Total revenue
2013 January 27 4,536 $1.43 $0.31 35 8 $1.17 $2.60
2013 January 26 4,496 $0.30 $0.06 39 6 $0.43 $0.73
2013 January 25 4,416 $0.98 $0.22 45 9 $1.71 $2.69

So you can see that the AppBrain revenue is comparable (i.e. same order of magnitude) as Admob banner revenue.

Just looking at ONLY the AppBrain BANNER revenue vs. the Admob banner revenue:
$1.43/2.88 = 0.49
$0.30/1.61 = 0.18
$0.98/1.82 = 0.53

So it varies all over the place - but is disproportionately higher than the 23% allocation I’ve given to AppBrain banner ads (vs. Admob’s 73%).

The question is then “if you increase AppBrain banner ad allocation to 100%” do you get MORE or is using a mix with AppBrain a smaller portion better".

One could run a test perhaps and see.

Comparing Leadbolt AppWall HTML ads vs. AppBrain interstitials (i.e. end-of-app once every 3 days version)

Looking at the AppBrain revenue figures above - at just the “interstitial” revenue (listed as “non-banner revenue”):

$1.17/2.88 = 0.40
$0.43/1.61 = 0.26
$1.71/1.82 = 0.93

So the AppBrain interstitial end-of-app once every 3 days version is delivering 50% or so of the Leadbolt HTML app (and note that this is ONCE every 3 days !!).

This suggests that at around 3 minute interval the presentation of the Leadbolt AppWall HTML ad maybe OVERKILL ?? (i.e. pissing users off more than attracting them to the appwall ?).

In any case, one could reduce the interval (or make that changeable using AppBrain Remote Settings - and then run tests etc.).

Comparing Leadbolt AppWall HTML ads vs. Greystripe

Looking at the Greystripe revenue/impressions graphs - for comparison those were:

When impressions were around 3000/day - the revenue was around $1.15 to $2.

So Leadbolt AppWall HTML ads ARE better than Greystripe - so at least that is clear (even with the high degree of overpresentation of the Leadbolt ads as outlined above).

Caveat - this is just for a partial day and a full day after that of Leadbolt AppWall HTML ads - and so perhaps maybe OVER-ANALYZING on very small real-world data.

46

Comparing Leadbolt AppWall HTML ads vs. StartApp

Given the above numbers, let’s see what StartApp would deliver - most users say here that they get an 80% conversion rate (i.e. 80% of users say “YES” to the StartApp shortcut on home screen/bookmark in browser stuff).

Repeating from above for this app:

01/26/2013 All Apps 3,630 92 $1.25 $0.05 2.53% $4.52
01/27/2013 All Apps 6,327 176 $1.03 $0.04 2.78% $6.54

The new install/daily active users (DAU) figures from AppBrain stats for this app are:

2013/01/27 - 2213 - 4578
2013/01/26 - 2173 - 4285
2013/01/25 - 1825 - 3547

Going by the 80% conversion rate and the current RPMD = $14 (revenue per mille download i.e. revenue per 1000 installations of their home screen/bookmark etc.).

This would give (using the “new install” figures - since the “conversion rate” of 80% is for lifetime of a new user presumably):
2213 x 0.8 x 0.014 = $24.78
2173 x 0.8 x 0.014 = $24.33
1825 x 0.8 x 0.014 = $20.44

This is considerably MORE than Leadbolt and Admob/AppBrain numbers mentioned above.

Comparing this revenue vs. Leadbolt AppWall HTML ads for the full day of Leadbolt revenue (Jan 27, 2013):

$24.78/6.54 = 3.78

That is, if one were to add StartApp one would get 3.78x the revenue !!

Now this is assuming conversion rate for StartApp is 80% still (may have become less now).

Presumably it SHOULD be possible to deliver to add StartApp as an EXTRA (I don’t know how egregious that would be).

So on top of:

  • banner ads
  • AppBrain end-of-app every 3 days
  • Leadbolt AppWall HTML ads as interstitial

one could conceivably add StartApp ON TOP of this (!??).

But what to do if a user DOES install StartApp …

I’ve seen apps using StartApp which do this a number of ways:

  • some ask the user yes/no and then work anyway without ads etc. REGARDLESS of the yes/no choice
  • other apps stop running if user says “No”
  • I think some apps may even choose to show the SAME amount of ads REGARDLESS of the Yes/No answer i.e. they are not rewarding the user - but are mainly considering it as a “donation” by the user (with no extra payback to the user).
47

Comparing Leadbolt AppWall HTML ads vs. GetJar Rewards

I’ve implemented GetJar also and these are the revenue figures (pathetic - but it MAY be improved somewhat by reducing the complexity of the GetJar process - the “Please Wait…” is too long there).

2013/01/26 - $0.18
2013/01/25 - $0.18

Good examples of apps using GetJar are Hill Climb Racing or Cut the Rope.

Clearly there is something wrong with a GetJar/Sponsorpay type system if users are MORE willing to download apps (for which they get NO credit) vs. systems like GetJar/Sponsorpay which give them something for downloading apps.

I think one of the problems is that GetJar SDK is very bulky/hard to implement - but WORST of all - their startup times are PATHETIC i.e. the “Please Wait…” that happens it just too long/slow to load etc.

GetJar Rewards allows users to earn coins for downloading apps - currently their GetJar Rewards app gives you coins for downloading just about any app (apps like Skype etc. even) - so GetJar is clearly trying to expand something or other here.

GetJar is also working to implement some type of buy-gold-coins-using-cash - which could theoretically help out developers in countries which don’t have Google Checkout yet (i.e. developers can’t sell their apps on Google Play). The way this would work is that THOSE apps (like Cut the Rope or Hill Climb Racing etc.) which can do Google Checkout - those apps will become a conduit for users to accumulate GetJar gold coins.

The advantage of that is that those gold coins will be usable in YOUR app as well - even though you don’t have Google Checkout capability you will still be able to sell.

Basically it suddenly makes the GetJar Rewards system - NO LONGER just a app download system (and in my view makes it instantly VIABLE since it can scale with demand etc.) - since it has a translation to cash available.

Eventually later even if there are no app downloads available to earn coins, users will still be able to earn coins by using Google Checkout.

This system WOULD NOT violate Google policy either - since Google would be getting their 30% cut or whatever.

While this system becomes irrelevant once Google Checkout is available in every developer country, there IS still a minor advantage - as it allows MICRO-PAYMENTS - and since Google Play is widely criticized for having “failed” in their in-app billing model (compared to Apple) - though Google is trying to fix this with newer Android versions by pushing users for early entry of credit card info etc. - however the issue remains that it is hard to pay someone $0.10 - which you CAN do with GetJar Rewards gold coins perhaps eventually - and MAY even become possible to trade them between users (so it becomes a universal currency ??).

In any case, it could solve a LOT of problems.

The problem thus far is that GetJar SDK is a pain to implement - PLUS the process of authentication is SLOW (on a GPRS connection) - plus they don’t seem to do anything intelligent like caching images of their buy/purchase webpages (most of it is webview based it seems - YET GetJar is not it seems caching those images - and the images are bigger than needs to be could have been 1/4 the size).

Also perhaps GetJar servers are slow - i.e. perhaps a Google-like efficiency at the server end would improve the whole user experience so it moves along fast - unlike the situation with GetJar today.

48

I’ve spent considerable time integrating GetJar and I can now attest that the performance is TERRIBLE.

Basically it is paying not even 1/10 of the ad solutions.

One factor (other is the app being bad or use of gold coins not in an intelligent way etc.) is that GetJar servers are REALLY slow.

On a GPRS connection it can take 30 seconds just to authenticate and then 15 seconds to show the product page which you want to buy - and there is no way to do that ahead of time (without showing their “Please wait” dialog box).

On a wifi connection it is much faster - i.e. 5-10 seconds.

However it suggests a design problem - that is they are probably transferring a lot of data in authentication etc.

Has anyone had experience with any other “gold coin” solution like GetJar/Sponsorpay - and if they know of any that are FAST i.e. very responsive performance of their servers etc.

From how GetJar is doing things - I like their setup in principle but it seems they are not paying attention to some basic things. Or perhaps they are aiming for the longer haul - where their gold coins are a type of micro-currency.

Or if folks know of a payment system that will work for those who are not enabled yet for Google Checkout (for in-app payment).

49

Has anyone tried Adfonic? They are the only network I have found, where I can set gender and age for the users.

Jumptap claims to have a lot of rich media ads, but I don’t see any insterstials on their developer panel. Has anyone used their ads?

50

Hi adforandroidapps,

My name is Joe I run engineering at Getjar. First I want to say your analysis in this thread is fantastic and while I wish you weren’t having issues with Getjar, I appreciate this feedback. It’s great information to help direct my team. To your specific concerns:

a) Indeed SDK 3.0 and 3.1 have network performance issues. We released SDK 3.2 today. We did (and continue to do) global measurements of the number of consumers who start auth that end up on the rewards page and SDK 3.2 dramatically improves this measure (nearly 100%). There were no server issues, but we did service call reduction, response compression, reduce re-authing, remove background processing, etc. Performance is a key metric for us and we will continue to measure and continue to make improvements. I would love to talk to you however and get some direct feedback.

b) In terms of the SDK implementation, as you pointed out, our goal is to be more than an ad/app downloading system. The notion of strong cross application user identity, buying gold and licensing separate us from others. We have built strong primitives but as you point out, they can be more difficult to implement particularly when our only sample is too big / too broad. To address these we are doing the following … first, we are creating a simplified sample which covers what most developers need. This should be done next week. Second, as part of our next revision of the SDK we have put together an API that makes it so the typical developer has less work to do but those who want more sophisticated control can get it.

Only other thing I wanted to point out is that the Getjar SDK is designed to increase in-app purchases for virtual goods or unlocks that you sell within your apps. It doesn’t replace an ad network just as an ad network doesn’t affect in-app purchases. In fact many apps have run ads in addition to selling in-purchases using Getjar. The marketing folks would have me say that Getjar has the highest revenue per user of any alternative payment or virtual currency system. That is really the area we play within.

I’m going to send you a private message so we can hopefully communicate directly. Rest assured my desire is to make an SDK that helps developers. We will do what we can to help.

Joe

51

Thanks for the reply - I think this is the first presence by GetJar here - and it is a good sign of developer-engagement at GetJar.

Firstly, you are right that there can be a number of hiccups with in-app billing (or as in this case use of GetJar to unlock content). Desirability of the unlock features, how the developer is phrasing things, and developer understanding of user stats i.e. how many users want this in first 10 seconds of use or such analysis.

Also it seems there maybe an inherent issue with in-app billing - as some developer-blogs are suggesting that for MOST apps the in-app billing model will not work and they are better off promoting OTHER apps which ARE doing the in-app billing model correctly (or which happen to have hit on the right formula - by design or by fortuitous circumstance - as happens in entrepreneurial matters also).

However if not the small developer - at least the well-designed app WILL need a good micro-payment solution.

Issues with GetJar

Let me get to the issues I see with GetJar - technically (i.e. the issues that are out of the control of the developer but which are glaring even for the naive developer):

  • “Please wait” dialog needs to be removed - there is almost NO justification for it. A method should exist in the SDK that does this in the background (in a separate thread). This will allow automatic authentication initiation which improve chances that authentication step has been completed by the time a user actually tries to buy.

  • User authentication on GPRS takes 30-35 seconds (!) and on WiFi it takes 5-10 seconds. This suggests it is not just an issue of latency, but of actual data size - a significant data volume is being transacted to do user authentication - which suggests some off-the-shelf products are being used instead of a custom/lean method of user-authentication.

The current GetJar SDK is not only difficult to implement - but it will be almost impossible to implement for a casual developer (but perhaps that is not your market - and having a difficult-to-implement SDK maybe a filtering mechanism). Developers are used to 1-2 line additions to their code to get things done, and GetJar is 10-20 times the effort in comparison. However you suggest this will be resolved. So that is welcome.

But really GetJar needs to focus on the user experience side of it - it should be FAST - both user authentication and the product page should load in a SNAP.

  • user authentication in background - a method to check if it has been completed and if not to try again (this time maybe with the dialog box showing) i.e.:
    userAuthenticateWithoutWaiting()
    userAuthenticateWait()

  • reduce graphic sizes by 1/2 i.e. total image sizes by 1/4 - maybe optimize the png images using the png optimization apps (if not done already - use “pngquant” for example) - and HERE also to use layout inflater to render the initial page in the background to a WebView. So if user clicks on buy - the product page appears in an instant.

For an example of how the Leadbolt AppWall HTML ads (which conventionally require a wait as the HTML loads) can be done in the background, check out:

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

Modifications to David’s code to make it prefetch in the background:
http://forums.makingmoneywithandroid.com/advertising-networks/740-leadbolt-app-wall-code-sample-activity-webview-html-ads-post7540.html#post7540
Title: code for INSTANT display of Leadbolt AppWall HTML ads (prefetch and display)

Supposedly every wait, and every extra step cuts down on the “conversion ratio” for such things - so from a developer perspective this is important.

Thanks.

52

Without knowing much more I would suggest that perhaps changing GetJar so it appears as a new activity MAYBE a good way to do it. However there maybe complications for some apps - which may not want to leave the game or something (?).

But if implemented as an activity - as in the Leadbolt code above - that would isolate the GetJar callbacks to that activity - and the app main activity etc. would not need to implement all that complex callback logic (the user authentication listener, that cascades to the licensing listener, to the product page which leads to the ResultReceiver on product purchase). Maybe there is some logic for not using a separate activity - I am just commenting from my limited viewpoint.

53

Interesting !!

I just checked GetJar SDK 3.2 - and immediately noted the absence of the (much maligned) “Please wait” dialog box.

I haven’t had time to look at it fully, but it seems BOTH the user authentication AND the licensing part (i.e. checking if a product been previously bought) are done WITHOUT the “Please wait” dialog box.

What this means is that - both these operations should be doable in the background.

The only wait would be in the product web page.

I will have to look into it further - but from the looks of it, this could cut down load time to 50% or possibly as low as 25% of what it was in GetJar SDK 3.1.

Great !!

54

Anyone else seeing a change in the Leadbolt AppWall HTML ads ?

Some hours back there was a “Yes/No” dialog box overlay over the AppWall - the “Yes” went immediately to Google Play for the first app in the list.

Now the same AppWall is not showing a “Yes/No” overlay - just the AppWall.

55

On an unrelated note, just thought of one way to use the HTML type of ads - for example the Leadbolt AppWall HTML ads.

Since I alluded to the possibility that much of the AppWall monetization MAY BE happening from the one-time users - the long-term users eventually “tuning out” the ads (i.e. get jaded and click on “No” reflexively).

One could run a test where one has 3 different HTML ads (Leadbolt seems to allow creation of multiple ads).

Then in the app - at app launch - check the launchCount or launchDate - and if is day 2 - then choose a different ad URL - on day 3 choose different one.

Looking at the stats for the 3 different ads - one would be able to judge “conversion rate” - and it may confirm that the first day users are the biggest consumers of the AppWall. Users coming back on day 2 and 3 may not be using it that much.

This suggest that one COULD basically scale back advertising for the long term viewers.

This is EXTREMELY NON-INTUITIVE to most programmer types and normal folks (who expect some “justice” in the world). In that the basic feeling most folks have is that “I will make an app and I will charge the users who use it the most or value it the most”.

However the dynamics of AppWall/apps/mobile maybe that - the real monetization with AppWalls is actually happening with the “non-interested” one-time users. That is, the 40% of users who use your app just once (as seen from Flurry stats) and are possibly moving on. This trait ITSELF would tend to make them MORE likely to click on the AppWall suggestion when it appears.

This is another reason some blogs suggest showing the AppWall early instead of later - as they want to monetize the “bored” crowd (!).

Now this is all very non-intuitive to a programmer - but is the type of thing a business type understands better perhaps.

In effect what is happening is that you are giving the app free to the most-interested and involved users - while making it costly to the ones who are not interested (or actually you are monetizing your REFERRAL potential for those users - by pointing them elsewhere to apps which ARE making money off in-app purchases like casino apps or the well-designed game with in-app billing well integrated).

This idea - that the AppWall type monetization may be MOST effective for first time users - and actually MORE for the non-interested users MAY in fact be behind the whole “reward user for reengagement” (for example coins being awarded for returning to the app).

Because while the award of “free coins” on return is ostensibly for increasing return for the user (increasing retention rates).

It MAY in fact have a dual purpose - if you have looked at your stats and KNOW that eventually NO ONE of your long-term users EVER clicks on AppWall or even ads - then you KNOW it is pointless to be showing them ads - it seems TRAGIC - but that is how it is - and this suggests an alternate strategy - that you essentially make the app FREER as it gets used more and more. That is, you start removing banner ads etc. Now you can do this suddenly - but giving the user some fraction of that benefit means you tell them in advance “this app is going to be free with 10 days of use” - and ONE way to do that is to give them “free coins” every day they return.

And so now with this long explanation - it comes full circle to the awarding of coins and it becomes apparent that the awarding of free coins may have a dual purpose:

  • ostensibly for reengagement increasing etc.
  • but dual role as an “indicator” of how the app is getting freer over time

This talk may all be speculative - but I get the feeling there is a germ of an idea in there - which is well understood by the developers who have been seeing their stats for 1-2 years. That is the reason they wind up doing things which are not apparent or “logical” to new developers.

The reason all this doesn’t seem reasonable to the new developer is that it doesn’t seem “fair” - i.e. why would you make an app free for doing nothing. However when seen in the light of stats it MAY make sense not because it causes any benefit for the developer - but that there is no HARM in making the app free over time - the slight benefit you get in return is the higher engagement and the “good feelings” the user get - and once practiced once maybe the developer then gets a sense of just HOW much beneficial this approach may be - for example it leads to better reviews or lower churn from the Active User base etc. (which leads to better rankings on Google Play - as don’t need nearly the same number of new installs to maintain your Active User base - which is always leaking users on a daily basis).

56

I’ve been seeing this Yes/No overlay for at least the past 12 months. Actually, come to think of it I can’t remember seeing the App Wall without it.

57

Probably a silly question, but… have you enabled javascript for the WebView ?

58

Probably a silly question, but… have you enabled javascript for the WebView ?

The same app that was earlier showing the Yes/No is now no longer showing the Yes/No. So nothing has changed and suggests the change is at the Leadbolt end.

The only “change” I did at the Leadbolt end was clicking on the “Add Ad” button to see if another AppWall HTML ad could be added - but I did not “Save” it but clicked on “Close” after confirming that another AppWall COULD be added.

But this was for one app - for two apps using AppWall (with different URL) - both are giving same behavior - which suggests Leadbolt may have changed the default behavior of the AppWall HTML ad to no longer show the Yes/No dialog box.

Anyone still seeing the Yes/No dialog box - which used to be the default for this ad type ?

59

On Fake iPhone 5 I’m still seeing the Yes/No dialog box every time I view a LeadBolt ad. Maybe it’s geo-targeted, or app-specific.

60

Thanks for checking - it could be as you stated (maybe a result of the Leadbolt “multivariate testing” ?).