Reputation: 47749
I'm using google analytics for android with a dispatch interval (ie. tracker.startNewSession("xxxx", 10, this);
). However, I noticed during development that the SDK kept printing something about the database being full and the last event not being stored in LogCat. So I decided to call the .dispatch()
method manually after every API call figuring it would kill two birds with one stone:
Once I released that, I noticed that my GA stats (pageviews, et al) were about 35% higher; which can only mean one of two things, either lots and lots of GA events were being lost before, or it's now doubling up on sending some events erroneously.
anyone have any thoughts on a good way to troubleshoot this? If it's now doing a better job of reporting mobile pageviews and visits, then this is great. But if it's not accurately tracking the data now because I'm manually calling .dispatch()
, then that's bad and I should revert this change.
Upvotes: 1
Views: 1397
Reputation: 13529
The EasyTracker sample app uses AsyntTask and network queues to improves performances. As mentioned by bitbox this could improve battery life and have less lost tracks without have to manually dispatch.
You can download the jar and source of EasyTracker from https://code.google.com/p/analytics-api-samples/downloads/list
Upvotes: 0
Reputation: 1876
That's what I saw too when I increased the rate at which I manually called dispatch. Plus it does make sense : since they are storing data locally and batch-sending to the server, I wouldn't be surprised if some data got stuck for a few days. And since data is associated with the day it was sent and not generated you get skewed stats.
PS: Have you taken a look at the new example app then provide for the Android SDk ? They run everything in AsyncTask in order to improve dispatching and to not hit the Main thread with network access. I've further improved that by storing all events in a queue and running only one AsyncTask... need to put it on Github but haven't cleaned it up yet.
Upvotes: 1