New World for Mobile App Analytics 4: Testing

, Posted by Phil Craig in Phil Craig, Web Analytics

In the final part in the series, Phil describes the debugging and testing process, and summarises his findings.

Last week I talked about the implementation process for mobile app analytics, along with a few set-up tips and tricks. This week is all about how we get it live.

How do we debug?

This is the hardest part. As you know, with the lovely GTM debugger tool for web, we can see everything that is going on, and with the help of other tools like WASP and Google Developer tools, we have all the issues sorted. If there is a data layer, we can see it firing. We can see when it isn’t firing and let the dev team know.

Mobile apps: not so easy. It’s kind of like walking into a room and trying to find the light switch and then realising you might be there for a while, falling over a few times and walking into assorted pieces of furniture (and cursing under your breath). There isn’t enough documentation on Google Analytics debugging for apps, unless I’m not interneting properly. So, the following tips are in line with debugging from our end (not the developers).

From my experience, the best way to debug is:

  1. Trust your developers have done a good job with your implementation guidelines and data layer naming conventions
  2. Trust yourself and your GTM naming conventions
  3. Get a proxy debugger like Charles or Fiddler
  4. Understand how to use them. This may win an award for the least helpful bullet points of all time.

Basically, without going into more head-scratching detail, using your proxy tool will show the server calls sent from your mobile app. Just for clarification, the debugger  will be on the desktop and the information will be shared across the network your mobile and desktop are using.

Here’s another diagram for your delectation:

Proxy Debugger

If your implementation is successful, you will see a list of Google Analytics server calls coming from your mobile. To get a bit more detail, our chums* over at LunaMetrics wrote a smashing blog about how to debug GA using Charles.

Another thing to note is that sometimes the app will not necessarily send the calls until you have exited the app. Then all calls might be sent in bulk. This is, I believe, a battery-saving feature, but during most of my implementations, I haven’t seen it, so fingers crossed.

Things to be aware of

Don’t expect to have all the answers for app developers. Living in a JavaScript world is far easier to understand for the web-focused analyst. You will become aware that most developers don’t take analytics into consideration, so might need to lean on your expertise in terms of implementations. You might have to explain that the majority of the work is done from GTM to calm them down, as they actually have to do a bit of work to get the SDKs in there first.

The data layer is king here. Make sure you have a good naming convention and keep a structure to make things easy for yourself in GTM. Also, obviously in web-based implementations, you can do a lot of stuff in the GTM interface without ever talking to a developer.

The main takeaway is that the debugging process isn’t easy and you will need to explain that to the stakeholders and developers.

Safe on the silicon shore

Well, that was a long journey, but now we’ve landed safely. Just be aware that the brave new world contains lots of things that want to sting you and eat you whole. But once you learn how to avoid them (or eat them instead) you will find gold. Happy apping.


*They don’t know that they’re our chums.