There is lots of Google Analytics track point in my android code, will it will affect the app's performance? I knew the GA is async, but there are hundreds of track points in my app, so not sure if I should add GA point more carefully in future.
Performance impact in this case would mainly depend on IO operations and not on how much tracking points are being added.
As the app collects GA data, that data is added to a queue and periodically dispatched to GA. Periodic dispatch may occur either when your app is running in foreground or background.
The default dispatch period is 30 minutes but you can provide your own interval in seconds by using "ga_dispatchPeriod" parameter in analytics.xml file, or by calling setDispatchPeriod(int dispatchPeriodInSeconds)
e.g. 60 (in analytics.xml)
GAServiceManager.getInstance().setDispatchPeriod(60); (in code)
The Google analytics SDK sends HTTP Gets or posts (I cant remember which) to Google. It doesn't wait for a response from the server mainly because the server doesn't return much of one.
It may require a tad more band width to send all these calls. I cant see it slowing your app down.
Related
Is there a way to tell Google Analytics that certain events shouldn't be counted towards session data?
Specifics: I have an Android app that uses Google Analytics. It has a service that crunches some data in the background, and reports stats on those tasks to GA. (The background tasks happen while the app is inactive). It seems that sending data this way is creating a ton of spurious sessions in GA, since it thinks that the events mean that the user is using the app and thus is initiating a new session.
How can I say to GA, "hey I'm sending you this event, but don't count it as a session"?
You should take a look at the non-interaction event flag. I'm not sure if it will do exactly what you're looking for (it's effect on bounce rate is all that's documented), but it's the closest thing I'm aware of to what you're describing.
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]
I am in the process of integrating GA with my game. At the end of each level, I send a won event, a timing to capture the time of the level, and a custom dimension to capture the user progress. This helps me with a clean API.
I am not sure how these method calls handled though, does the service sends three different requests to google, or is it smart enough to roll them in one?
On the other hand, if it is not smart, does it worth trying to minimize the calls, or it doesn't really matter.
By default the Google Analytics for Android dispatches the analytics events periodically (every 30 minutes).
You can also override the dispatch period as below.
GoogleAnalytics.getInstance(this).setLocalDispatchPeriod(60);
check out the documentation for more info
https://developers.google.com/analytics/devguides/collection/android/v4/dispatch
I was wondering about dispatch while implementing the new v2 of Google Analytics for my Android app.
If the default period is 30 minutes, and the data needs to be reported in like 24 hours or the data will not be processed, how do apps fare when they are only used like 2 times a week and for a duration of like 5 minutes?
From what I have read I can't seem to find that the app will be staying in the background waiting till the time is up and start submitting? Any insights? Otherwise I'll have to switch to manual dispatch.
I had the same question (though with the v1 GA, I think the issue is the same).
I chose to make the dispatch explicit. I try and use the same scale timeout to trigger the dispatch in the background (every 30 minutes), but I do a dispatch on certain events (like start and suspend, and when the app user hits certain internal milestones). Note that I just went with this for the same reasons you're thinking. I didn't find anything more definitive or do any tests that verified the behavior ...
An additional reason to do this to have a bit more control over the thread that is issuing the dispatch call (instead of just triggering as a side-effect of whichever thread is pushing some new stats into GA).
I don't think there is a 24h timeout on data stored locally that hasn't been pushed. In fact, I thought the problem was that data would get timestamped with its push time, not its actually recording time. But I'm not confident about this either way ...
I've created an app for the market on Android and ready to be released in the market.
I have used Google Analytics to track custom events that'll help me in upgrading the ap in the future.
I wanted to know how much data will Google Analytics consume to report back the events that I have defined?
My concern is it should not consume a significant amount of data for reporting that would adversely affect the app from a end user's perspective.
Does anybody know the consumption of data by google analytics in tracking?
Can it be reduced by increasing the dispatch period?
The data sent to Google Analytics is typically very small in size so as long as you aren't over tracking your app (reporting the location of every touch, silly, but I've seen it) you shouldn't have anything to worry about. If you do want the limit the data sent you can set a sample rate on the reporting to only send some events back to GA.. This will reduce your accuracy if you only have a small pool of active users but it is required by Google if you are reporting more than ten million events per month.
The most important thing to consider with GA is your dispatch time for battery life. If your app isn't already constantly accessing the internet then every time you report to GA you just drained a bit of extra battery by activating the wifi or cell antenna of the device.. the cool down on these is about 60 seconds so if your dispatch is set to 60 then you would slowly drain the users battery for no good reason.