Let me word it differently 
I’m getting between 1 cent and 2 cents for every new user who downloads my app. This is quite different to the eCPM (revenue per thousand ad impressions).
The eCPM varies between ad networks. The figure I came up with of $0.01 to $0.02 is the average of all the ad networks combined, for a single app.
Ok, that seems like another way to characterize it
And that maybe valuable when deciding between implementing interstitial (and all it’s accompanying impact on user-interaction etc.) vs. some other mode of advertising.
However in comparing between appwalls - perhaps the revenue-per-install maybe a better figure - as it drills down to the core figure there.
However, maybe I am missing some of the complexity introduced when the appwall folks are doing other stuff there as well - like Leadbolt or Airpush i.e. if they offer some combination - or if they not only require app install, but also that the app be run once by the user and that type of stuff (Tapjoy etc. ?).
So ok, that makes sense - $0.01-0.02 per user. In effect it also means that (if one were to suppose be advertising to buy those users counts) - then if one was paying above $0.01-0.02 per user that would be overpaying.
However even with this $0.01-0.02 per user x 100,000 = $1000-$2000. Now if this was a recurring figure i.e. per-month that would be acceptable (with enough apps that could sustain one developer). However are you suggesting that is the figure for the lifetime of the user (probably not what you meant - because the same user CAN keep contributing from more ads that they see) - unless you have observed in practice that they will usually only download one app in their lifetime of use of your app - and then get “wise” to it and not bother going through the appwall stuff.
So it is $0.01-0.02 per month or per lifetime user ?
[hr]
I think it is excellent approach if the interstitial is only additional ad type to other ads. It is not disturbing, no one complains about it and it pays quite well for sth shown so rarely.
[/quote]
Restricting the metric to revenue-per-install (so one can compare across similar types of appwall vendors) - if $0.5-$1.0 is the “expected” figure for the revenue from app installs - and you say portion goes to ad company - then I guess $0.18 per app install for AppBrain appwall - is then reasonable - right ?
Of course this is at the start - later the user base will get tired of More Apps type stuff - and perhaps revenue will be even lower.
Yes, I am only showing the AppBrain appwall once every 3 days !
However I was using their banner ads - and that was giving some app installs - and maybe greater than the AppBrain appwall was giving - this is something that I did not expect.
I also tested increasing the display of AppBrain banner ads (i.e. in comparison with Admob banner ads for example - adjusting the percentages via Admob mediation webpage). I don’t have anything conclusive from that yet, since I didn’t quite do it in a scientific way.
But my feeling is that perhaps if one is showing banner ads - through Admob mediation for instance - then one should NOT give more than 25% of the airtime to AppBrain banner ads - as some of the value fo these “More Apps” type of banners maybe in their novelty i.e. if they are presented in CONTRAST to some other ads that appear there.
In my app - by force of circumstance (my not setting things right or whatever) - the AppBrain banner ad is coming out stretched out (my app remains in landscape mode) - while the banner ads from Admob and Millennial Media and Greystripe (when they used to appear - currently they are not appearing) were all within the 350 x 50 size - while AppBrain was stretched out all across the width of the landscape mode. This may have made the AppBrain banner ad stand out from the rest of the banner stuff. I don’t know if this helps or not.
By the way the AppBrain banner ad only “varies” by changing color and slight design change - if it works it maybe an ingenious way to deliver ads - once delivered it may not even have to be delivered via internet (like other banner ads have to be delivered) - as the simple design (maybe 5 designs in total) could be autogenerated programmatically by the SDK.
Overall I find the AppBrain folks quite no-nonsense. The apps they show seem to be generally ok apps also - I wonder what the app quality is for Leadbolt and Airpush offerwalls - perhaps they are good also - as people here report them doing better than AppBrain offerwall even.
By the way, if you integrate AppBrain - you get a nice hourly feedback on your app installs - info you don’t get from Google Developer Console - though Flurry etc. may do something similar or better (have to look into that also).
Anyone here looked at ACRA - the bug reporting SDK (open source) etc. ?
In my app I am having some problems with supporting Audio recording for different android devices - a bug reporting system may have helped there.
Also AppBrain gives you nice feature - parameters.
Right - the Remote Settings.
The only negative is that you cannot test that prior to app launch on Google Play - because AppBrain requires you first register on Google Play before you can start to set the settings.
Though they are saying they are working to fix that.
A clean way AppBrain does things is that they use no “publication ID” etc. stuff - it is all linked to your package name. Perhaps THIS is the reason for that “already be listed on Google Play first” thing.
But for a simple setup - it is a clean setup (though use of publication ids may simplify other type of things - setting up different settings for different versions of the app etc. - which would not be possible in the current setup).
David’s comments i.e. the $0.01-0.02 type figures are troubling in a way - as that is for every new user.
That means an app that has 500,000 download will earn $5000 total !!
Now that may not seem bad - but you have to include the risks associated with getting an app to 500,000 - usually it will involve a lot of time getting the app setup so it is popular etc., then the promotion via social etc. i.e. a lot of time. That is, not every app may make to 500,000. Given all that $5000 is not a lot payback for all that effort - in the commercial sense.
There is a danger also from looking at the high download numbers for apps that it should be easy get to those figures.
However even if those numbers are reached does the Google Play download figure for apps include the ACTIVE user base or just a raw download count (which will double and triple count users because there are downloads from updates etc. also).
That is what I thought - but some apps seem to have DECLINING figures - that can only be if Google is also counting the uninstalls in that figure ?
If the situation is that bad, maybe one should abandon the caution about ads - and have the user generate one piece of ad revenue for that day.
If video ads pay $0.025 per view - to earn $100 per day would require 4000 impressions (which should be doable for even a small app).
So what is the catch in that ? Slow video players, low fill rate ?
Is there a feasible way to generate a guaranteed piece of ad revenue from every daily active user ?
My calculations at present are based on the total installs. So that’s $0.01-0.02 lifetime value of the user. But I’m basing these figures on my two biggest apps - one with over 5 million downloads, the other just passed 500,000. So the numbers I’m getting here are not necessarily representative of what you’d see in a more “normal” app with less downloads. I’m certainly hoping they aren’t! Otherwise it would be extremely difficult to make decent revenue unless you keep churning out “hit” apps.
Yep - I use ACRA in all of my apps these days, along with BugSense (I just signed up for their paid plan). It’s a fantastic tool to figure out which bugs are actually prevalent for your users, and decide on the priority fixes.
I am looking at my AppBrain stats and they give some interesting stats not available on Google Play.
Google Play Developer console gives total installs, and the active users (i.e. after uninstall whoever still has the app installed). Typically 50% of total installs.
AppBrain control panel webpage shows:
If you subtract the first from the second, you get the old users who used the app today.
Currently I seem to be getting 10% of the userbase recurring - rest are new installs for that day. But this is probably because of such a small user base.
As the user base grows - assuming the 10% recurring remains the same - you are going to have a greater number of users from your existing user base using the app on a given day.
If the user base becomes 500,000 then if 10% still recur then 50,000 of existing users will show up on a given day.
Add to that the new installs for that day - whatever that is later - let’s say that is 10,000.
So you wind up with 60,000 active users on a given day.
So you may have right now:
In 6 months it may be:
The difference between the two maybe that new installs are more likely to click on “More Apps” - while jaded recurring users may tune out the ads altogether.
So does this suggest that AppBrain type ads will do worse as you grow but daily active users are dominated by recurring users ?
It is conceivable that changes may take place with the daily active user mix changing in this way over time.
And the total install number (for example reaching 500,000 total installs as Google Play reports) may not by itself be enough of a guarantee that one will breakeven with the app.
The situation suggests that the real number to maximize is the daily active user count (recurring plus new installs for that day) - because these are the ones who see the ads for the day.
So to improve one needs:
to increase the recurring rate from 10% - so users want to play the game/app every day (Opera Browser - apps which become needed for everyday use, or addictive games that have a community which are played daily by users)
try to increase new installs - this is harder to do at scale (although with Android growth this maybe a possibility ? - however for this one needs to have ways to improve discoverability on the app store)
Then you need to maximize the ad revenue per user so the daily user count is leveraged correctly.
With this background (assuming I have not made a glaring mistake) - with your game one would think that one should analyze it by identifying the repeating (recurring) component, and the new install component.
That is, going beyond revenue-per-user add ($0.01-0.02), to a more nuanced:
With that understood one can then address the different parts of that daily revenue:
try to increase recurring users from existing user base (will boost daily user count greatly esp. if the user base is very big)
try to increase new installs (but once a large user base is achieved it maybe easier to convince them to play the game every day than to double daily installs to 50,000 ?)
try to increase ad revenue per daily user
Anyway, just some thoughts - does the thinking seem accurate representation ?
Yup, that’s the three pillars. ARM - acquisition, retention and monetization. Best to work on all three of them to achieve great results.
I recommend Flurry to measure retention. You can see how users retain over time. You can’t get it only from AppBrain - new/active will change over time as it takes all users ever into account. What you need is a rolling retention when you measure how many users stay after one week for example. Knowing that you can also try to optimize your app to better retain your users.
From my app I can see that the numbers that Google Play shows publicly for each app - are the total installs (and not the active installs - which are typically half that).
If that is so the install numbers graph should be monotonic (i.e. never go down) - but I have seen some apps have graphs that went down also - so does Google Play start to include active installs or what ?
[hr]
I assume Flurry and the ACRA bug reporting stuff are stable SDKs and don’t make the app unstable etc. - right ?
Max:
I still have to look into Flurry - is that easy to incorporate ? That is there some basic functionality that you get right off the bat (as with AppBrain) - or does one have to program it in ?
David:
With ACRA - same question - do you get some basic functionality just by including some init() call in your code - or you have to pepper your app with calls into ACRA etc. ?
Thanks.
[hr]
David:
Do you have insight into your recurring rate (% of user base who visit you again in a day i.e. is it 10% etc.) - using AppBrain/Flurry etc.
If you have 5M users in one app (assume the active user base is half that - so 2.5M user base).
With that many users i.e. 2.5M user base - say you get 10% recurring - that is 250,000 pre-existing users using your app.
Then you may have say conservatively 5000 new users coming in every day (new installs).
So you have 255,000 daily active users.
With AppBrain with 5000 active users, I am getting on a typical day:
5000 banner impressions delivered via Admob mediation - 100 clicks - 30 installs (very high conversion rate) - paying $4
The end-of-app interstitial that runs once every 3 days (AppBrain recommendation) is paying $2.5 (AppBrain doesn’t give further stats on that - just the revenue number).
So this is nearly $6 - however one difference is these are nearly all new users (since I have small user base) - who maybe more prone to click around on “More Apps” (i.e. are in search of apps anyway and are not staid long term users of the apps).
For your app - with 255,000 users - most are jaded users who may no longer look at ads - or are not in search of “More Apps” - so maybe they click less on “More Apps”.
If these were to click with the same enthusiasm, that would be (255,000/5000) x $6 = $306 per day.
For a month $306 x 30 = $9180. With 255,000 active users per day that is $0.036 per active user (per day) per month.
However I think your $0.01-0.02 per user lifetime was based on the total install number - so if we do that - that is $9180 for 5M users - $0.001836 per install per month.
In 6 months that gets you 6 x $0.001836 = $0.011 per install per 6 months. Or $0.022 per install per year.
Assuming your window of measurement is probably 6 months or so (to capture the full “lifetime” behavior of a typical user as their recurring use graph decays to near zero - i.e. they use it 1, 2, 3 times with less frequency over time) - this comes to nearly the same figures as David suggested i.e. $0.01-0.02 for lifetime of new install.
Obviously with more aggressive ads, maybe one can double the ad revenue - $6 above becomes $12 - even then these numbers go up by 2x etc. and not 10x.
These are very disappointing figures - not as bad if you have 5M users - but for 500,000 installs it is not so great (total of $5000 from a 500,000 install app).
The only thing positive is that maybe the android market will get so big that even the 500,000 install apps will “easily” (?) get to 5M downloads.
[hr]
While it does not make sense to count revenue per user lifetime - since revenue is being based on daily active user counts (which maybe radically different if the app has very high turnover or conversely very high allegiance user base). But perhaps if the analysis is done over a long enough period i.e. say 6 months - then it may capture the repeat behavior of a typical user (as they use the app say 6 times typically and then uninstall the app or stop using it).
This may explain why the commercial app publishers NEED to get on the top 25 lists. Because they NEED the new user influx not only to get big - but to keep the daily user counts healthy.
And while superficially those watching Google Play numbers maybe looking at the total installs that the app is going for - in reality those app publishers are going for daily active users.
This activity - as a side-effect then naturally over time increases the total download number also - which is what we see on Google Play for Angry Birds etc.
What this means is that there will continue to be jockeying between the big app publishers for the top stops on those Google lists.
And this is becoming like broadcast TV - few channels for app discovery - and Google is helping things on this way by recreating that model (one way they did that was by removing the New Apps category). In effect Google is supporting a “monolithic” or conservative approach. And that fits into their ad strategy as well - this way new app publishers HAVE to advertise if you want those coveted spots. And the ad universe becomes vibrant. However Google is not allowing the new app universe to bloom - so that users carry forward and pick apps from the new apps list.
However even with Google removing the “New Apps” category, that function remains - and is not still doable via twitter, youtube etc.
But that requires some extra skills efforts for the programmer.
Another reason for Google removing the “New Apps” category may have been that it would be a magnet for all kinds of manipulative activity to get apps placed there.
So now Google has relegated that to other means - i.e. let those apps be discovered in the twitter/youtube/facebook world - and let them handle that, and once it is famous there it will naturally rise on the Google Play lists …
How is the situation on the Apple App Store - I had read that the barriers to entry for new apps include disallowing apps that are similar to earlier apps already on App Store etc. - if so that would be a negative for users, but a powerful protection for existing developers - if you are a publisher who implements an idea first you get a bit of protection from the Apple team.
Anyone here compared the situation in this regard - app discoverability - and revenue per 500,000 install type of situations of the Apple App Store ? That is, for ease of visibility for new apps by small developers ?
And perhaps most importantly - how does the famous willingness of Apple App Store users to PAY change the whole dynamic ? Various articles point to even ad revenue being higher on iphone/ipad - however Android is not significantly lower (i.e. at most half and is not 1/10th). But how seriously does the pay market help a small developer in that universe - rather than 5M downloads they are able to achieve the same at 500,000 ?
You get a pretty impressive set of functionality right of the bat. Integration is very simple - check out the documentation on the ACRA wiki. With the simple initialization in your Application class, ACRA will automatically pick up any unhandled exceptions anywhere else in your app. You can also add optional code throughout the rest of your app, if you want to track “soft” errors (which don’t trigger an exception).
If you want to use ACRA with BugSense, check out the BugSense documentation.
Yesterday for Fake iPhone 5, I got 77,000 daily active users (according to AppBrain). Total installs (according to Google Play) were about 740,000, and active installs about 170,000 (yes, low active-install rate).
At first glance, this would seem to indicate 50% of people who still had the app installed used it yesterday. But in reality this isn’t the case, as I had about 40,000 new installs that day. Let’s say 90% of those new installs actually opened the app - that makes 36,000 new “active users” that day. So only 41,000 returning users. That’s about 25% of active installs, which sounds reasonable for a newly released launcher.
One thing that COULD change the equation drastically in favor is something that would charge every user once every day they use the app.
And it would have to be something that is NOT click based (banner click or appwall click/install) or “action” based (i.e. install and run etc.).
And that would be impression-based ads - and even those would need to be high-paying ones.
So it could be video ads - if they pay $0.025 per view or something - then 255,000 daily active users would generate 255,000 x $0.025 = $6375 a day for your app.
And for modest user bases like 5000 active users a day - it would be 5000 x $0.025 = $125 which fits the $100 a day goal for a modest app.
So the “problem” or gap between the revenue required to sustain development and the needs of users to not be bothered could be filled IF the right type of ad became available (perhaps ?).
Althought it WOULD be a drastic change to force every user to see a video ad or something siimlar every day they use the app - but if developers get desperate it might be the only way out (esp. if users are not willing to pay).
With Google also there is the inability to charge -or in-app billing for many countries and that is an impediment also (Apple has such facility for developers in many more countries).
[hr]
The problem with video ads - as I understand as I have not used them myself yet - is that of fill rate etc. and variability of performance between video ad networks.
Also there maybe problems of slow video player etc./startup time.
Adcolony claims some lightning technology - don’t know how effective that is.
Most of these companies are geared to satisfying the needs of ADVERTISERS.
In order for any one of these to fulfil the needs of developers they have to have high fill rates. Or there needs to be mediation libraries for easily switching between them. Perhaps Google Admob should provide that functionality. Though anybody else (or a new company could do the same as well).
What I find interesting is how Google Admob itself is so behind in implementing something as simple as banner ads for all ad networks. They should have a team doing that. But perhaps there are political reasons for not doing that or going slow - if google sees that as cutting into their ad platform or admob/adsense etc.
So a third company could do this.
Are there any companies offering libraries that do ad mediation - perhaps in order to suit small early developers they could have a system where their ads are shown (i.e. they get say 10% cut of the ads).
That’s good to know.
What does BugSense add if you have an off the cuff answer.
Yesterday for Fake iPhone 5, I got 77,000 daily active users (according to AppBrain). Total installs (according to Google Play) were about 740,000, and active installs about 170,000 (yes, low active-install rate).
740,000 total installs
170,000 active installs
So this is lower than the 50% typical - but it is perhaps expected for this type of app - i.e. majority of people looking at it would do out of curiousity. A certain percentage will keep it to show to someone else at the right time.
The app itself is not suited for continual use - as it would be used usually in social settings to show off and then immediately put back in pocket after the joke is over.
Now if you were to change it so it is an interface that a user uses all the time - that may change the dynamic altogether (though for those you may have to ask for payment - and I think some launchers do that well).
But coming back to what you have …
77,000 daily active users
40,000 new installs
So it has high turnover - or is akin to a “new app” in it’s early stages.
This may actually be good - as you have a fresh user base (who is not jaded with “More Apps” etc.) - and could conceivably get good results form a “More Apps” type of interstitial that perhaps run every time the user quits - most likely never to return so you may as well show the AppBrain interstitial ALWAYS at the end of the app.
40,000 new installs (25% of active installs)
The 25% of active installs is actually quite good - it means users are returning quite often to your app.
Either the high proportion of new installs is because you are experiencing very fast attrition (but that does not seem to be suggested by the 25% return rate of active installs above) - OR you are experiencing EXTREMELY high influx of users (which is probably what is happening since your app maybe a major upgrade etc.).
For 77,000 daily active users - compared to my 5000 daily active users - that is 15.4x.
So if my 5000 daily active users earn $5 from AppBrain banner ads and interstitials (once every 3 days at app exit) - then you should earn $77 per day.
But you may not have banner ads in your app - is that right ? (as that would spoil the look) - and only apps on exit.
Maybe you could do an ad on entry - or Airpush Smartwall type ad on entry - or a video ad on entry ?
David:
Do you get errors in the Google Play Developer Console Error link ? Is that a reliable place to look for errors ?
How does that compare to what ARCA does - i.e. reports only the worst of errors or what ?
So far I have seen one error.
Is this good or bad ?
[hr]
Wait a second - I made a mistake.
When I say I get $6 per day approx using AppBrain banner ad and the interstitial at end (once every 3 days as recommended by AppBrain) - that maybe a good way to compare FOR MY APP.
But it may make no sense for another app - as it’s use/reuse during the day maybe 1x or 2x different.
For your fake iphone app - one would think that there maybe little from banner ads - but if you had the appbrain interstitial at the end shown every time - perhaps it may generate reasonable revenue as a fraction will click and will download some app - giving about $0.10-0.20 per app install for the developer.
Not to derail the ongoing discussion, but I wanted to share my experience.
I got some very high earnings on my app with the Airpush smartwall first couple of days after integration. It’s gone down to pretty much nothing ever since, and I think I am losing users because of it. It’s so spammy. I’m going to remove it from my app.
That is what my impression is also.
My guess is that in the long run the only sustainable way to make money would be:
Maybe explicit instructions to user that a certain level of ads are going to be required (also if google could expand payment to more countries - would allow in-app purchase for those who don’t want to pay the “real value” of the app in ads - and prefer to just pay $1 and get it over with)…
I’m also waiting for google to expand to more countries… no idea if it will ever happen. If apple could do it, what’s holding google back?
Hi Rox,
Just to share, when icon ads came out, Airpush was giving $12 ecpm. It is gone to $3 - $4 ecpm with icon ads the last i checked. Same will happen with smartwall or any new ad they release. A gimmick to attract developers perhaps?
Anyone used the GetJar Rewards program - where you unlock premium content by paying with the “gold coins” earned in the GetJar Rewards app (which is available on Google Play).
Something like this is available for Slideme also - but there you have to download from slideme website.
The GetJar Rewards app is available on Google Play - which may make it easier for users to be directed to the Google Play page to download the app - and earn the gold coins - before coming back to the app to enable the upgrade to premium content by paying with those gold coins.
One of their slides suggests 100 gold coins = $0.9 in payment to the developer (they keep 10%).
It seems Tapjoy and Fiksu offer something similar.
How effective are these - and how willing are users to convert ?
david:
Would this not be a better model for your fake iphone 5 app ?
Guess that makes sense. Oh well.
It is difficult to characterize the benefits of some ad types by “eCPM” alone.
I’ll give you an example - if you are talking about eCPM for an interstitial ad - the eCPM BETTER be 4-5 times better than for banner ads !
In fact if the eCPM is equal to banner ads - you are doing WORSE with the interstitial.
The reason is that the interstitial is presented much less often - and at great disturbance to the user.
The eCPM makes sense when one discusses a similar format - for example comparing banner ads - that are refreshed at once per 120 sec or 60 sec.
Even when you present banner ads at different frequencies i.e. once per 60 sec or once per 120 seconds the eCPM figure starts to be skewed.
For example if you just show an ad from one company throughout the day in your banner ad space - at once per 120 sec (2 minutes) and get an eCPM of $X per 1000 impressions, then compare that to when you switch to refreshing at once per 60 seconds -you can see that your impressions will DOUBLE. The question is, will users also DOUBLE their clicking of your ad if it is flashing more often ? Probably not - so your revenue does NOT double by presenting the ad 2x times more.
The result your eCPM drops by half - because revenue is same or nearly same throughout the day, but the impressions delivered were double.
eCPM = revenue/impressions
So your eCPM will become half what it was.
It is clear that eCPM is NOT the only indicator to look at.
For interstitials - you will get opportunity to present them even LESS times during the day (during pauses in the game play etc.). If banner ads deliver N impressions during the day, then interstitials may deliver 0.25 x N impressions (i.e. 1/4).
So you can see if interstitials had same eCPM as banner ads you would get total revenue for that day that was 1/4 of the banner ad revenue.
Banner ad revenue is very low - so you can see that for interstitial or such formats to actually earn you significant money - they HAVE to have a eCPM figure that is VASTLY greater than that for banner ads.
When people are talking of eCPM for icon ads - what are the “impressions” here ? That icon is just sitting on the home screen. One can argue any advertiser talking about an “eCPM” figure in such cases is bullshitting you.
The best judge of how a different ad format performs is to actually use it and see how much revenue it will deliver during the day.
eCPM are inappropriate comparisons even when comparing banner ad performance (if you compare 60 sec refresh times with 120 sec refresh times) - and is even a worse indicator if you talk about interstitials (i.e. the eCPM figure quoted better be 10x more than for banner ads) - or icon ads or even notification ads.
The reason notification ads did well - as many developers have said they got good revenue from that - was because they ran ALL DAY regardless of whether you were running the app or not. This means while for most ad types you get opportunity to display an ad DURING game play - with notification ads you were crossing the boundary - out of the game app - and into the phone so it became part of the phone user’s life outside the game as well.
This is the reason why many people hated this format - and why those who didn’t mind it probably didn’t understand what was going on - and prior to Google changing the rules - most users may not have been able to identify WHICH app was responsible for the notification ads - i.e. general mayhem.
So this is the reason - I think it is more clear to think about the time your app is in front of users - and in that time what type of revenue each type of ad format can deliver.
Hope this helps.
[hr]
I was looking at GetJar recently. The way it works is you have a GetJar Rewards app (available on Google Play) installed.
In your app, you tell the user to earn credits in the GetJar Rewards app and then spend them in your app to unlock features.
You earn credits in the GetJar Rewards app by browsing for and downloading apps that are featured - you get 10 coins for any app - and 15 or more for some that are “featured”.
If you choose an app - it gets downloaded through Google Play - and once detected as installed, GetJar Rewards adds that to your credit.
So it becomes like a bank account or wallet - which you can then use on any app which has enabled GetJar credit etc.
Somehow Google is allowing this - as it is similar to incentivized installs - which was banned by Apple. GetJar is a silicon valley firm backed by some famous VCs - so hopefully they have done their homework - in their FAQ they point out how their system is different from incentivized installs or at least does not go against Google Policy - because they don’t encourage an alternative market - but point to Google Play to download apps.
HOWEVER, this is depriving Google of revenue - in the sense that it enables an alternate payment method - not based on cash - but on work done by the user. When a user pays your app 100 coins, the developer gets $0.9 (at least that’s what a slide there said).
Now 100 coins is quite an effort - would require about 10 apps be downloaded.
BUT perhaps Google may allow this if they themselves realize how slow they are in rolling out the merchant solution to more countries. While Apple IS allowing developers from those countries.
In addition there is a big chunk of Android users who cannot pay or DO NOT want to pay - now become a famous stereotype that Android users hate ads but hate paying even more.
So it can be argued that EVEN if a developer has the option to do paid apps - STILL on android it is not an optimal solution.
GetJar mentions this as well - in the examples they give - for Guitar: Solo they said it got 10M downloads but very little from the paid version. But after using GetJar they 4x their revenue - i.e. 3 coming from GetJar and 1 from GooglePlay.
I liked the GetJar concept - but their implementation is very weak - that is the GetJar app is slow takes a long time to load (shows a blank screen while doing that). Generally very little directions given to the user (not even a “loading data” type of prompt). And the app uses big icons needlessly and the background of their app is white all over. Plus their payment screen is confusing - with not enough emphasis given to the balance the user has - on some screens you cannot even see the balance (which should ALWAYS be shown on all screens in GetJar Rewards).
In addition, once you download an app - GetJar remembers that - and you will not get paid for downloading it again later (even if you have uninstalled it) - which is designed to prevent abuse - but is something wrong with that. In any case, why do they SHOW these apps in the Gold Rewards section if they are not going to pay anything (i.e. they start to show “Earn 0”). What’s the point of that ?
I would prefer if the AppBrain people had done something like this - they make clean minimalist stuff.
By the way GetJar is not generally known as an advertiser - but as an alternative app store - so in a way they are similar to AppBrain - would not be surprised if AppBrain also did something like this.
Unless there is something wrong with the GetJar model - i.e. can get banned etc. by Google eventually.
I’ve looked at a few apps that implement the GetJar - in fact most of the apps listed in their store are ones which seem to include GetJar payment - example:
Guitar: Solo Lite
Hill Climb Racing
Cut and Slice
And the implementation of GetJar is kludgy - i.e. it is presented on screens which take ages to load (if you are not on wifi) and give no feedback about what is happening. And their dialog boxes are not well designed i.e. confusing - should show the user gold coin balance all the time at the top etc. but show it in the same font.
Anyway … is an interesting alternative.
Thanks for that breakdown, adforandroidapps. Something to think about.
My guess is that the first couple of days after implementing Airpush Smartwall, a lot of people are unaware that it is advertising - especially those “Xhottie69 wants to chat with you” dialogue ads. I imagine that a good number check them out upon initial discovery, but very soon after they realize that these are just ads, and therefore ignore them. This would maybe explain the drop in the rate.
Anyway, just a theory.