I've been uploading apps to the Google Play for a couple of months now. I've added Admob banner ads in all of my ~30apps. I'm getting my first payment this month, and I'll get a "big" one (+2000$) in January.
So, I've been doing my research. I've found AdMob closed LOTS of profitable accounts this year, so I'm a bit scared. I'm following their rules: no fraud clicks, banner always at the bottom of the app (shown in a fixed region, no matter if ad is served or not).
My only "but" is the refresh rate. Admob RECOMMENDS applying a 60 second refresh rate. I load an ad in every "onCreate" call of all my Activities. So, if an user enters my app in Activity A and Ad will be shown. If 5 seconds later, he navigates to Activity B, another Ad will be served.
I developed a while ago an static function, based on shared preferences, which doesn't allow the app to request an Ad faster than once in X seconds. That solves your problem! Nope.
Most of my aps have 4 or 5 Activities, one of them is shown 80-90% of time. I don't want the Ad to be server for an activity that is shown 2 or 3 seconds and then I wouldn't ask for another ad in the main activity because I still need to wait another 57 seconds.
I wonder how you guys solved this issue, I can't be the only want "fighting" against this.
The easiest solution (and a pretty good hueristic) is to just show ads in the activity that is shown 80-90% of the time. If the user is only in one of your activities for 2-3 seconds, chances are they aren't looking to click an ad in that activity. Do right by your users and don't annoy them with ads in the main menu or setting menu of your app.
Related
I use the strategy of preloading interstitials and rewarded videos at application startup, and this means that the user doesn't have to wait for an ad to load when it's time to display it. However, this also causes many ads that were requested to the admob network to not be displayed (because it was not the user's will or the time did not come), resulting in a low "show rate".
I've seen people saying that Admob can penalize profits if the "show rate" is low, but I haven't seen it anywhere making that clear
No you wont be penalized for low flow rate. However, i am on a 30 day suspension with admob for having to many ads displayed. It is called invalid clicking. So if you have your app show ads continuously without the user consent or point of interest you can get a suspension for displaying to many ads.
If they punished you for having to low of ads then no one would ever use them. Too many ads will get you in trouble.
I'm about to integrate Admob in my app and I know this isn't a "coding error question" but I need some clarification on Admob from someone that use it.
I'd like to know how Impressions work and calculate it.
They just count 1 impression when the Ad appear? So If I keep that Ad only for some seconds or 60 seconds is the same thing? Sound strange to me.
More fair seem to me that Impressions are calculated with the seconds that they were shown...
Someone can explain to me How the thing work?
Impressions are a count of the number of times an ad is shown to a user, regardless of the duration it is displayed.
In my experience ad is rotated after some time - giving you more impressions
When talking about interstitial ad, an impression is counted every time the user see it regardless of the time it being presented
Banners are different, on the admob dashboard you can define refresh intervals when the default is 60 seconds, which mean that every 60 seconds a new banner will be called and when shown it is counted as impression
banner refresh
Google Analytics (using iOS SDK version 3.14 and it's built in sessions tracking) is reporting a significant percentage of app sessions as 1 second.
Maybe users are launching an app to view a page and (effectively) then instantly leaving the app, but that seems unlikely (that it should continue as the top use case. You think such users would stop using or uninstall.)
Initially I suspected this was related to "background fetch" but when I look at a prior incarnation of the application (that did not have background fetch enabled or used) I still see these (seemingly) bogus sessions also. That application (pre iOS9) had no universal links.
The (obvious) reason I don't want to see these sessions (especially if from automated action not user action) is it removes all value of "user behavior"; i.e. loyalty, recency and skews "average session length". These are the main reasons I want to use GA, i.e. to see if folks are using it more/valuing it more.
My questions:
What might these sessions be caused by? Are they bogus?
If bogus, how can I stop them?
Can I ensure new "background fetch" code doesn't somehow trigger them?
Some things I've considered / looked into:
I am seeing a similarly large set of "short sessions" on an Android application (this application's peer) and again with extremely high numbers. I've been wondering if this was a result of a web searches & site links, with those site links automatically loading the app, and the a (very) quick user "move on". (Universal linking is something the new iOS application is working towards, but doesn't see much of yet.) Given it is not that on iOS I am starting to doubt that it is that on Android.
There is a "optOut" option on GA. That feels like a sledgehammer solution to this walnut problem. It is also a persistent setting, which feels risky to use for a transient situation. I could attempt to toggle it at applicationDidEnterBackground / applicationDidBecomeActive (and will if it is deemed the solution) but worry it could have negative side-effects.
One can have multiple trackers. I am planning to attempt one for human foreground activity and one for background operations (which might allow time /event tracking when in background, w/o impacting human user tracking numbers. That said, I don't know / believe this is the cause of the bogus sessions. )
One can manage sessions manually and also customize the sessions interval timeout, but I don't see why this application should need any custom behavior. It is a normal application.
The application isn't reporting crash totals to match these numbers; it is a generally well liked 4/5 star app w/ few crashes.
Google Analytics measures duration as the time between interactions.
This means that in order to be able to measure duration, Google Analytics needs a minimum of two interactions to measure between. But they still need to collect data on one-interaction Sessions, and from the reporting perspective, every session starts the same - with an interaction. It's just that some don't go any further. To account for this, Google Analytics keeps a running total of Session duration.
When a user first interacts, that total is set to 0.
31 seconds later, they interact again. That total is updated to 31 seconds.
10 seconds later, they interact a third time. Total is now 41 seconds.
35 seconds later, they quit. This is not measurable, and hence not an interaction. Google Analytics waits faithfully for 30 minutes, before deciding that they aren't coming back.
Your total Session Duration is recorded as 41 seconds, as that was the last point at which you checked in. There's no way of knowing that you stuck around an extra 35 seconds.
This isn't an issue if you looked at 4 or 5 pages, but if you had only looked at 1 page, we would have been left with a Session Duration of 0. This is what happens with every 'Bounce'; every Session with only one interaction is measured '0' seconds long.
Throw into that a handful of people who interacted 8 or 9 seconds later, and you have an average of 1 second for the '0 - 10' category.
Turns out the problem was inside the Google Analytics SDK. A new version has been posted:
[Google Analytics SDK issue with short sessions][1]
For the last couple of days i'm stuck with what i call, overthinking :
FireBase is dedicated to be a "Real Time" communication platform. I'm trying to understand what is the right approach for the follow up situation.
In my PVP game, two users suppose to start the game at the same time. I'm already making a "pre check" to make this two events as close as possible(promote both of the users to click a button, observe specific value change, and only than start).
Yet, both of them starting with a small delay of 1-2 sec.
Even tho FireBase suppose to act as a "Real Time" platform, should i assume(/code) within this perspective? Or should i assume Delay is going to be a common issue?
2. Is there an avg delay/time, assuming FireBase works as he should and my code is efficient, for each listenValue "call"?
UPDATE
NOTE* Each user "listen" to the other device "ready" state, so when the "last" device click ready, the game will automatically start
Since as there is a small delay between player sync. Which I think I because when you attach your second player to the game it triggers must be starting the game as soon as second player is registered. I think you need a small delay between adding your second player to the game and starting the game. Posting some code might help a little more to understand the exact problem.
I would like to implement a feature in my application that allows the user to use the app for two weeks, then forces the user to do an in-app purchase, or the app no longer works. Is there a way to do this? Here were a couple of options I thought of (that I don't really like)
submit an update after two weeks that has in app purchasing as a must (I don't like this option because it seems like a good way to piss off users)
use a timer, but I don't want to force the app to run in the background for two weeks just to keep an accurate count of the two weeks.
Any better suggestions?
You don't really need to change it to in-app purchase exactly after two weeks. You just need to not allow the user to use that feature without in-app purchase after two weeks. So you don't need to necessarily keep an accurate count of the two weeks, just check the time before using the feature (or periodically while running). The only problem with this is the "accurate count of the two weeks" part since the user could presumably change the device clock. I'm guessing you probably already require internet access already, so this can be worked around by just getting the time from a server.
Can't you store the current time (eg. System.currentTimeInMillis()) in Flash (SharedPreference) the first time the application runs?
And trigger the in-app purchase whenever the current time is 14 days after the stored value?