What are the methods of implementation of Product Analytics?

8 min readAug 7, 2023

This is Part 5 of a long-form series of setting up Product Event Analytics correctly.

You can read Part 4 to understand the workings of Product Analytics Tools here.

If you’ve implemented your Product Instrumentation already or are clear about the method of implementation, you could skip over to the next section where I discuss User Identity Management and the best practices for the implementation of ‘User Events’.

Before discussing the methods of implementation, I’d briefly describe downstream tools.

Downstream Tools

Downstream tools are the tools that take data from your Product as events and process them to arrive at a desired action. Some of the types of downstream tools are mentioned below —

Product Analytics (For Example — Mixpanel, Amplitude, Google Analytics, etc.)
Attribution Tools (For Example — Branch, AppsFlyer, etc.)
Advertising Tools (For Example — Google Ads, Facebook Ads, etc.)
Customer Relationship Management Tools (For Example — Zoho CRM, Hubspot, etc.)
Marketing Automation Tools (For Example — Clevertap, Moengage, etc.)

Without going into too much detail about the intent of all of the above types of tools, they take data as events from your Products and help you with gauging user behavior, targeting, optimizing, retargeting, and automating these flows.

While trying to send your data to your Product Analytics tool, in the modern Product stack, you’d also need to stream the same events to some of the mentioned tools.

We can finally start discussing how to implement your Product Instrumentation. There are a few methods to implement your Product Instrumentation.

The implementation of your Product Instrumentation can be done by any of the following methods -

Native SDK

A Native SDK implementation is when you choose to insert the SDK of the Product Analytics tool of your choice directly into your code base and then keep using an instance of the object of the SDK to send events to the same tool. This is the most straightforward and easiest method of implementation where your engineers would need to set up this SDK once and continue to add events as and when new features are added to your product. I’ve linked the Native SDK implementation methods from the most commonly used Analytics below -

The problem with using native SDK integrations is that for each type of new downstream tool added to your Product stack, you’d need to add another SDK into your code base. This increases your development time, time to go live with every build publish, increases complexity of maintenance of your code base, and increases the size of your build for installation to your user base.

Tag Manager

Tag Managers are basically wrappers or containers around your Event Analytics structure.

Tag Managers make your Product Events independent of the underlying architecture and let you connect your single event to multiple destinations or multiple downstream tools (For Example — Clevertap/Moengage for Re-Engagement, Google Ads/Facebook Ads for Retargeting Conversions, etc.)
Another advantage of using Tag Manager is that they overcome the limitation of native SDKs in that they eliminate the need of inserting SDKs each time a new downstream tool needs to be added to the Product Stack.

Google Tag Manager is a topic unto itself and I’d be covering the complete functionality of Google Tag Manager in a separate topic. Here, I’d be briefly touching upon the functional flow of Google Tag Manager.

ProductAnalyticsGoogleTagManagerFunctionaFlow

As depicted in the diagram, the data layer sits between the code base where your developer works and the Google Tag Manager where you can configure your Analytics in the form of ‘tags’, ‘triggers’, and ‘variables’.

Google Tag Manager works with the following concepts —

Container

In part 3, we discussed the structure of setting up Google Analytics and discussed how Google Analytics has 1 property for each Product that you want to instrument and analyze. Analogous to the Streams and Properties combination, we have containers for Google Tag Manager. A container represents one unique Product and platform combination. Following would be the containers in our example of EasyRide online cab booking platform -

EasyRide D2C Staging Website
EasyRide D2C Staging Android
EasyRide D2C Staging iOS
EasyRide D2C Production Website
EasyRide D2C Production Android
EasyRide D2C Production iOS
EasyRide Driver Staging Android
EasyRide Driver Staging iOS
EasyRide Driver Production Android
EasyRide Driver Production iOS
EasyRide Agent Staging Android
EasyRide Agent Staging iOS
EasyRide Agent Production Android
EasyRide Agent Production iOS

Trigger

A Trigger is the action upon which a Tag needs to be fired. Triggers are fired via the code by providing a specific name to them. A trigger needs to be registered on Google Tag Manager User Interface and is matched with a name or other specific conditions as well, to fire the corresponding Tag with which they’re associated on the User Interface. A ‘Trigger’ is what makes Google Tag Manager, a multi-destination tool. A ‘Trigger’ can be associated with multiple tags at once and multiple tags can be created for each destination tool event.

For Example, the following Triggers could be defined for our sample EasyRide D2C App -

Ride Book Clicked
Destination Selected
Ride Booked

Variable

A variable is a parameter for an event. Each variable needs to be registered on the Google Tag Manager User Interface. A variable sent through the data layer from code would be sent along to the ‘Tag’ and eventually to an event if it matches the name of the variable defined on the Google Tag Manager User Interface.

For Example, the following Variables could be defined for our sample EasyRide D2C App -

amount
discount
source_name
destination_name

Data Layer

The data layer is the code layer where your developer would have to write the code for the event to be inserted. The data Layer adds event triggers along with parameters that enable the same to be processed via the Google Tag Manager. The ‘Trigger Name’ is matched with the ‘Trigger’ defined on the UI and then an event is sent to a destination tool.

The major disadvantage of Google Tag Manager is that all downstream tools across all platforms (Android/iOS/Web) aren’t compatible with Google Tag Manager and hence, you’d have to write your own customization to take care of the same.

Customer Data Platform

A Customer Data Platform is an infrastructure product that is used to connect data sources to destination tools. A Customer Data Platform essentially sits in between all the sources and destinations and transfers data by managing all integrations with the Downstream tools.

Apart from making your Product Event Anlaytics independent of the underlying code, Customer Data Platforms give you the additional advantage of doing your Identity Management, and Event Streaming once and manage every tool’s underlying Identity Management and Event Streaming via their customized integrations.
They eliminate the need for native SDK insertions and are perfectly inplemented for each implementation platform (For Example — Swift, Java, Kotlin, React, etc.)

Customer Data Platforms work with the following concepts —

Source

A source is a generator of event streams for a Customer Data Platform. These are usually our code bases from where events can be sent for processing by any of our downstream tools.

Taking the same example of EasyRide cab booking platform, the following are the suggested sources of event streams —

EasyRide D2C Website Production
EasyRide D2C App Production Android
EasyRide D2C App Production iOS

It must be noted that we could also have the following staging sources for testing our event streams -

EasyRide D2C Website Staging
EasyRide D2C App Staging Android
EasyRide D2C App Staging iOS

In part 4 we discussed the events being split between your client and server. Hence, a point to be noted here is that we could’ve had a source as our ‘Back End’ of Easy Ride for all types. However, it’s not recommended to have a source as a ‘Back End’. You should instead, have the Back End send events using the source key from your CDP to one of the three sources mentioned above according to which platform (Webs/Android/iOS), the event is coming from. This will ensure that any backend event will always be tied to the front-end platform from which the event is being sent. Additionally, it’d ensure tying up a back-end event to a front-end session so that the event can be incorporated into one front-end funnel.

Destination

A destination is a receiver of event streams from a Customer Data Platform. These are the tools that are meant to achieve some objective as mentioned in this article above.

Taking the same example, let’s assume that we’re using two downstream tools -

Mixpanel
Clevertap

For these two downstream tools, you should create the following 6 destinations on your Customer Data Platform -

EasyRide D2C Website Production Mixpanel
EasyRide D2C App Production Android Mixpanel
EasyRide D2C App Production iOS Mixpanel
EasyRide D2C Website Production Clevertap
EasyRide D2C App Production Android Clevertap
EasyRide D2C App Production iOS Clevertap

Please note however, that even after creating these three destinations each for Mixpanel and Clevertap, the three destinations would all refer to the same project on Mixpanel as well as Clevertap so that all the data of potentially the same customer on different platforms (Android/iOS/Web) can be analyzed on the same project on Mixpanel and Clevertap.

The way of accomplishing this would be to use the same project key while creating each destination on Mixpanel or Clevertap.

Summary

Customer Data Platforms are expensive as both the other solutions of inserting the native SDK or using Google Tag Managers come with no additional cost. However, with additional expense, Customer Data Platforms help solve a lot of integrations complexity problems which make it simpler and cleaner to just plug and start up with a plethora of downstream tools.

In the next section, we’d discuss in detail the best practices for Event Instrumentation Implementation by taking a use case of a sample Product in action.

Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn