A Protocol Oriented Analytics Layer

This article is roughly based on John Sundell’s article on Building an enum-based analytics system and Fernando Martín Ortiz’s article on Architecting an Analytics Layer. Both of these articles are a must-read before reading mine.

Why use analytics anyway?

The growth of any product depends on how much you can cater to your customer’s needs without doing too much. To do this you need to be able to know what your customer wants. Analytics is the best way to make this happen, and because there are a lot of Analytics SDK’s out there depending on your needs you might have a situation where you would install more than one SDK in your app, and you wouldn’t want your code to have multiple lines doing the exact same thing as sending an event but to different SDK’s. This solves exactly that.

The Protocols

An event needs to have a name, which is usually a String, and a set of parameters in the form of a dictionary.

An analytics engine needs to be able to do two things, one is the ability to be initialized the other is the ability to send an event using any SDK.

Sample Implementation

Now implementing this would be as easy as conforming to these protocols. As such I will give an example using Facebook’s App Events SDK.

Usage

Now that an implementation has been created, initialization would be as simple as adding a line in our UIApplicationDelegate’s application:didFinishLaunchingWithOptions: method.

Initialization

Tracking

Great! Now we have an enum based Events list, but what if we want to have parameters to be sent to the service? The AnalyticsEvent needs to be altered into an enum with associated values.

Best of all event usage still doesn’t need to change

With this, we now have the basics of what an analytics engine needs.

The Advanced Implementation

Usually, there is only a need to implement one Analytics service in an application, but sometimes an SDK might not have a feature of another SDK you might need. For example, Intercom has automated push notification sending depending on the events that are being received by their servers.

We wouldn’t want to have different analytics services all around our codebase, being used to call the same analytics event over and over again. The optimal way is to have just one class to be used to send all the events.

The existing protocols now would need to be upgraded in order for this to happen.

A Catch

Even if the isTrackedOnAnalyticsServices is empty by default, calling FacebookAnalyticsServcice.shared.send(event: AnalyticsEvent.userLoggedIn) would still work. With this in mind, I will now use a manager class, that uses the Decorator pattern and is introduced by Fernando Martín Ortiz in his article, which will be used to manage all of your services.

Another Analytics Service Example

For this next one, I’ll use Fabric as an example.

The new implementation on the UIApplicationDelegate would look like this

isTrackedOnAnalyticsServices

Now AnalyticsManagerService.shared.send(event:_)will not be able to send any event anywhere because isTrackedOnAnalyticsServices is by default, empty which is why AnalyticsEvent needs to be updated or else.

Using the analytics

Conclusion

With this all the analytics services are now being handled by only one class, the code is encapsulated and clean, and the events are placed all only in one enum in a declarative and readable way.

If you want to try some Analytics services out there, a few notable SDKs that I’ve had the experience of using are Fabric (can be integrated with Firebase Analytics), Facebook Analytics, and Intercom.

This is available on Github and installable through Cocoapods

If you have any suggestions please write a comment below. 👇🏼