Hi Guys,
did anyone of you get paid by StartApp on 2/1/2013?
My payments still show up as “pending” and the support seems to ignore questions about payment, I am waiting for an answer for 5 days now - as another ticket (which was not realted to payment) has been answered within 24 hours.
greets
skeet
Hi there skeeter, do they owe you big bucks ?
i got paid yesterday. but i noticed that they have deduced $29 from my payments. i checked my bank account and noticed that they have always charged $29 from the payment. support said my bank may have charged that but it’s not the case. waiting for a replay for 4 days now. do you have the same issue?
Generally how much income was generate with 1000 installations on the assumption that no one is in the U.S.? Because I know that they pay only for the “new” users…
In my case, $6.20 per 1k installs… but you need 1400 actual installs for Startapp to count 1000 conversions
Edit: In this app I have only 5% US installs
So for 3000 new installs a day on my 2 apps, it would get:
3 x $6.20 = $18
Which will make it the same as nearly all other ad revenue from Admob banner + Leadbolt AppWall + AppBrain.
And it will not interfere with that other income - so maybe ok to double the revenue per day.
However, it is falling over time it seems - for all the reasons originally analyzed about StartApp - eventually they will reach saturation or a point at which the payout will become much smaller - and developers will stop using.
Since I have already encountered StartApp in many apps by chance on Google Play - that suggests StartApp is ALREADY quite prevalent.
So $6.20 RPMD maybe approaching the eventual limit - which may eventually become something like $2 RPMD - which may become the point of “equilibrium” i.e. developers will be in two-minds whether to implement it or not - and at that point will have some stability - as new developers will be adding StartApp, while others will be removig it because they think it is not paying enough and is costing them more in terms of pissing off users (or being on antivirus radar screens).
Indeed. When I started using Startapp it was quite a bummer, because I’ve been reading a lot and I expected a minimum of $0.01 per install, and I was getting an average of 0.006 … not cool. I even went through their entire T&C and couldn’t find an explanation. A couple of days later they started showing the “$0.005 per non-US returning install”… aparently I arrived in the middle of a payout cut, and I am pretty sure it’s going to happen again.
NOTE: The pay per new US install increased, however, it was 5 cents, and now it’s $0.055
How often does one encounter a fresh user who doesn’t already have StartApp ?
Do developers see a proportion of U.S/non-U.S. and breakdown by fresh user/returning user ?
I think that’ll depend on the niche… some are more exploited than others. I happened to try Startapp on a very exploited category, and also, with very little US traffic… but I can’t complain. This app would be earning probably the same or less with airpush… and most users don’t even realize they have new bookmarks or a new homepage installed in their browsers.
And yes, you can see the global distribution in the sats, which only counts fresh users. Then you have simple graph bars with the total installs.
So you have to guess what the non-fresh installs are worth - by subtracting from the total revenue or what ?
You think the 80% conversion rate still applies to StartApp these days ?
Also I assume the “best” setup for conversion rate is to show the Yes/No on each start (i.e. set a local variable - if it is set to default that suggests app was taken out of memory and start again - or better to do by last launch time etc. … !?).
I have seen some app which fail to proceed if user says “No” - this probably convinces many users to say “Yes”. However is it any better than the other alternative i.e. to always ask Yes/No on startup - the idea probably behind this is that a user will eventually press “Yes” by mistake if nothing else.
However the “do not run” philosophy may have better traction for this reason: because about 50%-60% of new installs usually may uninstall the app after first use - so this approach would monetize these as well.
You have any thoughts on best strategy for Yes/No presentation, not allowing to proceed etc.
By the way, the not allowing to proceed if user says “No” might be in violation of Google policy to not prevent usage of free apps - anybody care to clarify this ?
So you have to guess what the non-fresh installs are worth - by subtracting from the total revenue or what ?
Yes, that’s what I do… still you have no actual way to tell if your traffic is returning or new… so they can put any numbers there and there’s nothing one can do about it.
You think the 80% conversion rate still applies to StartApp these days ?
Well I think 70% is more realistic if you do the most usual implementation (EULA pop-up when app starts). I haven’t really experimented with it yet, but I’m planning to. Probably the best way (and google policy complaint) to increase conversions would be making the EULA annoyingly persistent… but that may result in very bad ratings.
By the way, the not allowing to proceed if user says “No” might be in violation of Google policy to not prevent usage of free apps - anybody care to clarify this ?
Maybe this applies as “poor user experience”?
Forcing the user to click on ads or submit personal information for advertising purposes in order to fully use an app provides a poor user experience and is prohibited. Users must be able to dismiss the ad without penalty.
Right.
So the annoyance can be something which ENABLES better performance over the default I am guessing.
But it should not completely bar the user from proceeding with a certain minimal level of performance - so the “No” to EULA preventing app from starting would qualify as bad I am guessing.
Annoyances have -almost- always given better results in terms of monetization, but if you have a serious application that you don’t want banned or badly rated, a 70% CR isn’t too bad.
I would rather not display EULA at all than blocking the application until user opts-in…Chances are the app gets banned anyway
I meant that an annoyance shouldl be ok by Google policy.
But the apps which exit the app if the user says “No” might be in violation of Google policy.
PLUS, they may not gain too much in terms of total people saying “Yes” - since on multiple use the user WILL eventually wind up clicking on “Yes” (if nothing else then by mistake).
Hey guys,
I would like to clarify our most recent payments per download:
For full integration, we pay $0.055 for each new U.S install , $0.01 for each new install from any other country. For partial integration, we pay $0.04 for new U.S installs and $0.008 for new installs from any other country. A returning user (with the StartApp SDK on his device) will grant you $0.01 each from the US and $0.005 for all other countries for both full and partial integration.
Ryan- StartApp’s solution keeps the app “clean” of adds and doesn’t annoy end users compared to other ad networks solutions. You can check your reviews and see that end users are very tolerant with StartApp’s additions.
I agree that some categories are less profitable than others but I can ensure you that you can still generate a lot of money. Don’t forget that you can continue using other ad networks besides Startapp while using StartApp’s SDK.
adforandroidapps- StartApp is 100% complaient with Google’s policy, meaning that if the user says “no” the app will still be downloaded but without the SDK.
This keeps your users satisfied and your apps safe and complaint with Google’s policy.
If you have any other questions, feel free to ask.
Cheers,
kfir
I didn’t say the opposite. I was just suggesting that presenting the EULA multiple times (in case they say “no”), would result in higher conversion rates, but may annoy a bit the end user. It’s a call the developer should make.
I did not suggest that it was a fault of StartApp - the specific case I was referring to is when apps exit if the user says “No”. THAT particular implementation may be in violation since it is forcing the user.
In contrast presenting the Yes/No every time the user starts may be ok - since it is just a reminder. Probably presenting it every time also raises the odds of user inadvertently clicking on “Yes”, OR being such a pain that the user decides to click “Yes” - either way this is probably not going to violate Google policy either.
Regarding users being irritated, that is a possiblity, however I found the wording of StartApp Yes/No dialog reasonably appealing - in which the developer is just asking the user for “support” type of thing - so it may be considered legitimate appeal by users.
Though there will probably be users who complain - but I have not see that many complaints on apps which use StartApp.
I have not implemented it yet, but may in some future app - but I suspect their rates will keep going down as StartApp saturates the market and new apps encounter more and more “returning user” (i.e. where the shortcut etc. already installed).
By the way, why does StartApp say that an “SDK is installed” - when it seems to be a shortcut and a home page for the browser.
Is there a way to set up partial integration to exclude the home screen icon? Icon ads are an area of conflict with Airpush, who do not allow stacking icon ads and push notifications. I normally run StartApp along with push notifications from Airpush (I don’t really see how I’m stacking icon ads, but nevertheless), that disqualifies me from Airpush weekly payments. Would you consider having an option for partial integration that excludes the home screen icon?
Hey Rox,
Startapp offers at this time both in her full integration and in her partial integration the icon ad. At this time an option that excludes the home screen icon doesn’t exist.
OK, thanks for clarifying.