App Tracking and Analytics: Demystifying the SDK
Recent trends reveal a market shift away from cost-per-click and cost-per-install as pricing models begin to reflect the growing demand for in-depth in-app analytics through cost-per-action – pricing on user engagement.
At the same time, app analytics have become increasingly more sophisticated to cater to these campaigns.
For some time now, SDKs have been perceived as a necessary evil. A poorly built SDK will crash apps, introduce incompatibilities and may rely on techniques that become deprecated – and developers cannot analyse these risks themselves as SDKs are often distributed as a closed-source binary. Choosing an intelligent SDK, however, can provide significant analytics benefits and frees developers from having to maintain tracking and data collection, allowing them to focus on building a great app.
Paul Müller, CTO and Co-founder of adeven, a leading app analytics firm, explains that while app tracking faces some fresh challenges with the adoption of the IDFA, analytics companies have been prompted to develop even more streamlined business intelligence platforms. The key is that these companies know the challenges and make it their business to solve them.
At the core of these analytics is one rudimentary question: What is a session and how can it be measured accurately? Session counting is key to understanding the changes we have discussed here, and over the years, reporting sessions in an app, and from an SDK in that app, has become increasingly more complex.
At first it was easy: apps were either on or off, and when the user left the app, the session was closed. When platforms started to support multi-tasking, these status changes became more diffuse. Just because the app is put in the background doesn’t mean that the session is over. With the inclusion of the notification centre, push messages and even in-app purchases, users increasingly flip between different states such as ‘resume’, ‘background’ and ‘foreground’. Figuring out what counts as a session has become considerably more chaotic.
adeven chose to define a standardised session as a continuous stream of actions and state changes with no more than a 30-minute gap in between. This, of course, requires analytics to gather information on a variety of state changes and events, and keeping these up to date is a job the developer should not need to do.
Additionally, network connections to phones are, in fact, generally very poor. With package loss and connections to the server dropping more often then we realize, the SDK has to make sure that data actually reaches the server. This includes accounting for data gathered while offline and relaying it when online. Even when the SDK isn’t fully offline, requests aren’t fire-and-forget: they are sometimes lost and need to be repeated. What if Angry Birds never saw the sessions that happened on the subway?
Developers especially prefer an open-source SDK, and for very good reasons. An open-source SDK gives developers some security in the knowledge that they can see exactly what they are implementing into their app and how to work with it. Developing an intelligent SDK that understand these definitions and aggregates sessions in this way is no easy task. Here is where intelligent SDKs from dedicated analytics outfits come in, and why choosing the right SDK is a big concern.
While SDKs are indeed necessary, they are far from an evil. We would go so far as to say that the intelligent open-source SDK could be a developer’s best friend.