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:
- Send events more often, which would in theory stop them from backing up and losing some events (as per the logcat entries I saw in development).
- Save battery by sending any GA events while the mobile radio was active.
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.
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.