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.
Related
I'm trying to prevent creating new session, while firing a Google Analytics event, when app is in Background (or killed state). Events like "PushNotificationReceived" need to be fired when app is not opened (or in background). But these events would increase session count.
Though it is possible to make user segment and filter out these sessions in Google Analytics Dashboard. But I'm looking for alternate way.
What should be the best approach to track these type of events without impacting session count or active users, etc.
The whole idea of Google Analytics events is that they supposed to be part of a session so there is no obvious way to set a tracking like that.
Like google analytics has setSessionimeout where all the vents are grouped together and at the end events are dispatched.Is there anything similar for Flurry analytics,As flurry hits the flurry server instantly,I want it to bunch together all the events in a session (Suppose of 30 min ) and then disptach them.
It is not possible to force the Flurry SDK to report analytics session data at specified time. A Flurry session is defined by
"If the app pauses or moves to the background for more than 10 seconds, the next time the app runs, Flurry agent will automatically create a new session and end the previous session. Otherwise, Flurry agent will continue the same session. This can be updated via the setSessionContinueSeconds method. If the app is terminated, a new session will be created when the app runs again."
The only way to control the session reporting is through the app lifecycle. But generally I would expect all of the events to be reported in a single batch per session. You can observe this behavior by watching the event log in the Flurry UI as the app is closed and/or reopened.
setSessionContinueSeconds is really only useful for cases where you would want the Flurry session to continue for longer than 10 seconds while the app is in the background. For instance an app that plays music in the background.
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.
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
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.