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
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.
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.
I try to send an event just before disabling the Google analytics in android. But, the event doesn't show up in the real-time GA console.
tracker.send(new HitBuilders.EventBuilder()
.setCategory(category)
.setAction(action)
.setLabel(label)
.build());
//disable GA
GoogleAnalytics.getInstance(this).setAppOptOut(true);
Thanks for any advice.
If you enable Google Analytics logging you can see that when you call setAppOptOut(true) Google Analytics will clear all queued hits since it last sent hits to the Google Analytics servers:
V/GAV4﹕ Thread[GAThread,5,main]: clearHits called
As you noticed yourself dispatchLocalHits() doesn't help since it does nothing with Google Play Services installed. What you need to do is to wait with calling setAppOptOut(true) until after your hits have been dispatched. However as you don't know when the hits are dispatched it's not an easy thing to do.
You can specify what dispatch period your app should have with the ga_dispatchPeriod setting (with the default being 30 minutes). If you wait for longer than the configured dispatch period you should be fairly certain that your event has been sent, however this is not guaranteed since GA may wait with sending the data even longer if you do not have any network connection at the moment.
If you would take this approach you must make sure that the wait works across sessions since Google Play services is a separate service on the device and it will hold on to your hits even if you restart your app. So opting out on next startup of your app will not work either.
However waiting with opting out for more than 30 minutes might not be very nice to your users since that gives a lot of time for data to be gathered and submitted after the user thinks that they have opted out.
A better approach might be to have your own internal Google Analytics wrapper class that all parts of your app calls to report data. Then each reporting method could have a check if Google Analytics is enabled, never call any of the real Google Analytics methods.
This way you can be sure that you final event is sent to Google Analytics while no more events are sent after that even though you don't call setAppOptOut(true).
Do note that this only works if you do not rely on any automatic tracking like automatic reporting of uncaught exceptions or automatic screen measurement.
My app has one activity and many fragments. I've read about ALL topics about this question, and no one worked as I can see.
I've tried with both ga v3 and v4, following the
The problem is that BOTH ways, analytics retrieve only the first call I perform. When I change fragment, and perform another call in the same way, the 'real-time' analytics doesn't change.
Both snippets are executed from onStart() method in every fragment.
// Using ga v4
Tracker t = GoogleAnalytics.getInstance(this).getTracker("UA-XXXX-1");
t.setScreenName("/home");
t.send(new HitBuilders.AppViewBuilder().build());
// Using ga v3
EasyTracker _tracker = EasyTracker.getInstance(getActivity());
_tracker.set(Fields.SCREEN_NAME, "/discover");
_tracker.send(MapBuilder.createAppView().build());
Any suggestion would be highly appreciated!
Actually I think I might found the way to make it works. Reading the documentation: https://developers.google.com/analytics/devguides/collection/android/v4/dispatch
By default, data is dispatched from the Google Analytics SDK for
Android every 30 minutes.
Yes, my thoughts were "What???? 30 minutes? Is not suppose to be real time?" Anyway, reading a bit more:
To set the dispatch period programmatically:
// Set the dispatch period in seconds.
GoogleAnalytics.getInstance(this).setLocalDispatchPeriod(15);
To set the dispatch period in the XML configuration file:
<integer name="ga_dispatchPeriod">30</integer>
What more...
Setting a negative value will disable periodic dispatch, requiring that you use manual dispatch if you want to send any data to Google Analytics.
// Disable periodic dispatch by setting dispatch period to a value less than 1.
GoogleAnalytics.getInstance(this).setLocalDispatchPeriod(0);
Ok, maybe you have found a controversial here, negative value or less than 1? I tried, it is less than 1! (0 or negative number will disable periodic dispatch).
If you prefer then the manual dispatch, that would be, for example:
tracker.setScreenName(TAG);
tracker.send(new HitBuilders.AppViewBuilder().build());
GoogleAnalytics.getInstance(getActivity().getBaseContext()).dispatchLocalHits();
Notice that you can call dispatchLocalHits() whenever you want (even make a button that calls that function). By the way, that piece of code it's on my fragments (in the onResume() method).
Also the documentation says:
If a user loses network access or quits your app while there are still hits waiting to be >dispatched, those hits are persisted in local storage. They will be dispatched the next >time your app is running and dispatch is called.
But I was not sure if this applies to both manual and periodic dispatch. I tried it, both seem to be working :)
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 ...