How to add analytics to iOS apps

In the last few months we added a third party app analytics solution i.e. Firebase to My Day To-Do and soon we realised that Firebase may not work every time. Hence we tried to abstract the analytics (decouple/separate) solution from the rest of the app code i.e. the app code can log analytics data without knowing about what analytics solution is in use. In this post I will talk about how to add analytics to iOS apps, our analytics solution and provide some code examples for an iOS app with Firebase analytics. The aim of the code is to provide an example of how to abstract the analytics part from the rest of the app. Hence without further a due let’s get to it.

In June 2017, we added a third-party analytics solution i.e. Firebase analytics to My Day To-Do for tracking app usage i.e. we wanted to know what aspects of our product do people use the most. At this stage I am the only developer at My Day To-Do and it was the first time I had worked with an analytics solution. Anyway I added an analytics solution and it was all fine and dandy but then I relied that Firebase may in all situations (e.g. China). At this point, I thought why not abstract the analytics solution from the rest of the app, so the app code does not care about what analytics solution is being used. This lead me to  embark on a quest to restructure the app analytics solution in My Day To-Do.

Design an analytics solution in the app such that you can change the existing (third-party?) analytics solution without effecting the code for the rest of the app.

First let’s examine how Firebase Analytics was initially integrated into My Day To-Do,

Firebase Analytics let’s you log events and when I first added it to my app, I had  a method called logEventWithFirebase in one of the classes coupled with the rest of the app code. The Firebase event that I used the most was select_content which accepts 3 parameters (id, type, name). The code to log a select_content event is the same every time, the only thing that changes are the 3 parameters, so when designing that I thought let’s just store the 3 parameter values for different select_content events in one location.

struct ANALYTICS_CONSTANT {
    var id = ""
    var type = ""
    var name = ""
    init(id:String, name: String, type: String) {
        self.id = id
        self.name = name
        self.type = type
    }
}
static let A_TODO_VISIT = ANALYTICS_CONSTANT(id: "a_tab", name: "TodoTabVisit", type: "PageView")

btw that’s Swift code from the My Day To-Do iOS app 

this is what the logEventForFirebase function look like,

func logEventForFirebase(analyticsConstant: AnalyticsConstants.ANALYTICS_CONSTANT) 
{
    Analytics.logEvent(AnalyticsEventSelectContent, parameters: [
        AnalyticsParameterItemName: analyticsConstant.name as NSObject,
        AnalyticsParameterItemID: "id-(analyticsConstant.id)" as NSObject,
        AnalyticsParameterContentType:  analyticsConstant.type as NSObject
    ])
}

and now for how it’s called in code

logEventForFirebase(AnalyticsConstants.A_TODO_VISIT)

At this point we have events being logged with Firebase, all the different moving parts are in place and it all works, but I noticed something. I noticed that despite a large number of downloads from China the app usage in China is fairly insignificant compared to say ‘Germany’ which has far fewer downloads. The reason being that Firebase Analytics is when it comes to reporting , therefore I may need to change the analytics solution from Firebase to something else. At this point, I decided to re-think this entire process, actually let’s go back to the basics and examine this entire process starting with…

Now we can look at the UI design, logical app flow, storing data etc as smaller problems that we need to solve to solve a bigger problem i.e. building an app. Therefore it’s not too difficult to think of our app as a big solution composed of a number of smaller solutions, consequently we can see adding app analytics as another smaller solution.

After thinking about it that way, it would make sense to add analytics to our app via a single class that stores all the methods to log analytics data which the rest of the app code can call. This leads to the thought of having the AnalyticsHelper, which looks like this,

static func logEvent(analyticsConstant: AnalyticsConstants.ANALYTICS_CONSTANT) 
{
    Analytics.logEvent(AnalyticsEventSelectContent, parameters: [
    AnalyticsParameterItemName: analyticsConstant.name as NSObject,
    AnalyticsParameterItemID: "id-(analyticsConstant.id)" as NSObject,
    AnalyticsParameterContentType: analyticsConstant.type as NSObject
    ])
}

So whenever we need to log an event for our app, all we do is call AnalyticsHelper.logEvent that’s all. The logEvent method can log the event to any analytics service, it could be Firebase, Fabric, Google analytics or whichever other solution, the app code does not need to know that.

Having said that the app does have one dependency and that’s AnalyticsConstants, but that’s unavoidable and needless to say that AnalyticsHelper and AnalyticsConstants need to know about each other. Therefore it would only make sense to store them under the same folder for ease of understanding, so let’s create a folder in our app called Analytics and have both the files in there.

In the interest of clarity I think it would make sense to look how all this code fits together in an iOS app, let’s look at our viewController

import UIKit
class ViewController: UIViewController {

    override func viewDidLoad() {
        super.viewDidLoad()
    }
    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
    }
    @IBAction func todoVisit(_ sender: Any) {
        AnalyticsHelper.logEvent(AnalyticsConstants.A_TODO_VIST)
    }
}

It’s fairly self-explanatory, it’s has a an event that’s triggered when the button is pressed and we are logging that event using our AnalyticsHelper. Next let’s look at our AnalyticsConstants class

import Firebase

class AnalyticsHelper {
    static func logEvent(analyticsConstant: AnalyticsConstants.ANALYTICS_CONSTANT) 
    {
        Analytics.logEvent(AnalyticsEventSelectContent, parameters: [
        AnalyticsParameterItemName: analyticsConstant.name as NSObject,
        AnalyticsParameterItemID: "id-(analyticsConstant.id)" as NSObject,
        AnalyticsParameterContentType: analyticsConstant.type as NSObject
        ])
    }
}

and finally the AnalyticsConstants class

import Foundation
/*
Acronyms
A = access i.e. access a section
P = push i.e. button push 
*/
class AnalyticsConstants {
    struct ANALYTICS_CONSTANT {
        var id = ""
        var type = ""
        var name = ""
        init(id:String, name: String, type: String) {
            self.id = id
            self.name = name
            self.type = type
        }
    }

    static let A_TODO_VISIT = ANALYTICS_CONSTANT(id: "a_tab", name: "TodoTabVisit", type: "PageView")
    static let P_LOGIN = ANALYTICS_CONSTANT(id: "p_login", name: "Login", type: "Button")
}

The only additional property is if we were tracking user login, also I have just named the variables with the starting letter for the type of event it’s associated to i.e. “button push” and “access” certain sections of the app.

p.s. if you need to know more about that entire where it’s extensively discussed.

Summary