Google Analytics for Android. Behavior

Today I got an opportunity to organize analytics for one rather big commercial project. Even though I have enough experience in such events, I had to deal with some surprises. The first one was a new GA SDK v4, which, by the way, the SDK Manager didn't even offer to update, considering v3 to be the latest. But this is logical, because at the moment all the tools for GA are in Google Play Services SDK.

So, I decided to write a short tutorial. I'm not going to duplicate manuals and documentation... Well, maybe just a little bit. Basically I'm going to talk about those general aspects which I didn't find in manuals.

To work with the GA you need to set up your project with the Google Play services SDK. You might want to read the instructions first, which are, by the way, surprisingly useful. The analytics will work even on those devices that don't have the services.

Now let's get to the philosophy. Analytics is a significant part of any project. Thanks to the analysis of collected data about user activity, a developer has an opportunity to rationalize further improvement on a product. If you don't determine the metrics or miss something important before the release, it will be very difficult, or maybe even impossible, to understand how exactly users use the functionality, or whether they are using it at all. It would be impossible to understand how to improve the situation at that point.

It is necessary to determine what will be sent to the server in the form of statistics. It's great if you already have specific metrics from the customer, but in practice they are always insufficient. That's why I recommend covering the majority of user actions in your UI.

Let's begin with screen tracking. Almost nothing new in the latest SDK version, just a few options for automatic tracking. I don't think them to be essential, because fragments are not identified automatically. Can you imagine a complex project without several fragments? I can't. So, I recommend doing everything manually. In that way later you can analyze users’ behavior on the map in the corresponding section of the analysis:

You can see users flow, screens they go to and percentage of those who left the application. Convenient, don't you think? Later it's possible to see users actions on any screen. But how should I bind an action to a certain screen? No answer in the manual, so I had to think logically.

Tracking of all actions, screens and timers is done by instance of a class Tracker. This is sort of container in which the data is put through an appropriate builder, such as: HitBuilders.EventBuilder(), HitBuilders.AppViewBuilder(), HitBuilders.TimingBuilder(). This object is initialized by the singleton pattern. When calling .send() the task is put into the pool, which is limited. The problem is that you don't know how limited, because the documentation says that "you cannot send many events in a short period of time". Everything that goes beyond the bounds of the pool is lost in the infinity of the universe, and the data, filling the tracker, isn't overwritten between calls .send(). The event that you send after screen tracking will snap to this screen. That's why you should manually track the screens — so you will always be able to control which particular event will bind to the screenshot. The data leak with the pool isn't as bad as it seems. According to my calculations, the data will be lost when trying to send about 20 events per second.

For convenience, all game events can be put into a separate category ui_actions, and, respectively, for tracking runtime server requests — api_calls, and for runtime background jobs — background_task.

Why is it important to track time? We can estimate how our product behaves in different fields, such as a nasty link or a rather old device, which gives us the opportunity to polish the roughness and track results. All of this can be conveniently evaluated in the relevant section of the analysis — "Application speed".

That seems to be all about user activity that is not described in the manual. I dare to hope that this guide will put someone on the righteous path when implementing analytics.