How does Product Analytics Work?
This is Part 4 of a long-form series of setting up Product Event Analytics correctly.
You could read Part 3 about the criticality of project structuring and how to implement the most optimal structure here.
If you already have a functional understanding of Product Event Analytics tools, feel free to skip over to the next part where I discuss the various methods of implementation of Product Instrumentation.
Product Event Analytics works by either the Front end or the Back End of your application or website sending event information to a Product Analytics tool. A typical structure in flow looks like mentioned in the following diagram -
The above flow illustrates a typical flow of your EasyRide D2C App. As the diagram above indicates, both the Front End and Back End of your application and website are capable of sending event information of your users to your Product Analytics tool.
For processing any events from your application or website, a Product Analytics tool needs the following information -
User
A user is a user of your product in any form that is uniquely identified. A user’s uniquely identified by an Analytics tool by placing a unique tracking code against each user whenever your website or application is accessed by the user for the first time.
Event
All actions performed by a user identified on your product are classified as an event. By default, the Analytics tool that you’re using would need a unique identification with a user for which an event is being sent. All events sent thus, must be tied to a user uniquely.
Product Event Analytics concerns itself with the accumulation of actions or events performed by users and doing analysis of single or multiple event types or doing analysis of a single user profile or a group of similar user profiles usually called cohorts.
Parameter
A parameter is an extra information variable that can be added to an event to add more information to an event. These parameters actually add state information to a triggered event. For Example — For an event such as ‘Booking Confirmed’ which would be triggered when a user ends up booking a cab, further information to add richness to this event would be the addition of parameters such as ‘booking_amount’, ‘source’, ‘destination’, etc. for further analysis of this booking to be conducted.
User Identification
When the user accesses your website or application on which user event tracking is enabled, the process of user identification is started by the Analytics tool. If you want to understand how this tracking is enabled, please click here.
Now, once tracking is enabled, and once a user lands on any of your properties for the first time, the tracking tool assigns a unique code, mostly in 16-character format to the user. This code is most commonly referred to as an ‘anonymous id’.
In the case of a website, this code remains in the browser cookie and continues to track the same user until this cookie is cleared from the browser’s memory.
In the case of an application, this code remains in the local memory of the application and continues to track the same user until this local memory is erased by a user or the application is uninstalled from the phone.
User Identity Merge
While user identification is done by the Analytics tool on the Front End of your application or your website, this doesn’t cater to all the use cases which could prevent the correct data from being reported. Also, it has the problem of the same user accessing the website as well as the application and being marked as two different users.
To solve this problem, every Analytics tool provides you with a pre-defined method in code to be used each time you’re able to identify a user on a ‘signup/login’ event on your product. On such events, you should use this pre-defined method call to identify a user uniquely.
What happens when you call this method is that your unique user identified (primary key for a SQL database/Object ID for a nonrelational Database) is also passed into the call along with the ‘anonymous id’ assigned by the Analytics tool. At the tool’s end, these IDs are merged to create an Identity Cluster which contains all the ‘anonymous ids’ of the tool and your Database’s user ID. Hence, the next time, when the user accesses any one of your Applications or website, all the activities of that user no matter on any of the platforms (Android/iOS) or website, would be attributed to the same user on your Analytics tool.
In this example, as soon as the user lands on the Application and Website, he/she gets assigned an ‘anonymous_id’ by the SDK inserted into the code of the Analytics tool.
Let’s assume that the following IDs are assigned to the user -
- EasyRide D2C Android App — Anonymous ID — A1
- EasyRide D2C iOS App — Anonymous ID — A2
- EasyRide D2C Website — Anonymous ID — A3
- Primary Key — PK1
For all the events that the user performs, they’re automatically logged into the Analytics tool with the assigned anonymous IDs as discussed (A1/A2/A3) as applicable. Whenever the user signs up or logs into your system, your back end would be able to identify all the ‘anonymous ids’ with the same ‘primary key’ or ‘object id’. This at the end, creates the cluster which ties all of A1, A2, A3, and PK1 together.
Henceforth, all transactions completed by a user, add up to the same customer profile no matter which platform they’re performed from. Hence, the Lifetime Value Computation, Customer Segmentation, and accurate user base calculation are enabled.
You could find pre-defined methods and explanations of user identification for Analytics tools here -
Here’s a sample Identity cluster and User Event log as a result of the above-mentioned, correctly implemented Identity Management.
Event Streaming
As discussed earlier, events are always sent by default with an ‘anonymous id’ since it’s auto-inserted from the front end. All the events from one ‘anonymous id’ are accumulated together to form a customer’s profile. All events from all anonymous ids combined give the complete picture of one user’s complete event history.
Here’s a sample User Cluster with several ‘anonymous ids’ and a primary key which is a ‘distinct id’ with the entire user event log on Mixpanel —
Event Logging
There’s one more crucial aspect to discuss how Product Analytics work and what are the best practices while implementing the same.
Client-Side Events
Events sent from the client may have an inaccuracy in the complete reporting of all events since some may be blocked from being sent as a result of ad-blockers running on a web browser, the browser running in incognito mode, choice of browser such that it prevents any events from being sent, etc. Hence, all events that don’t have the mandate of accuracy while analyzing them and would be analyzed in aggregation and not individually per user should be chosen to be sent from the client end.
Server-Side Events
Events sent from the server are always accurate since a server would use the direct API of the Analytics tool and would always ensure that data is sent via a retry mechanism. Hence, all events that have a mandate for accuracy of reporting for analysis (For Example — Number of Orders received, Number of Tickets sold, Revenue Amount of Orders, etc.) should be sent from the server end. Here are some sample events which should be recorded from the server side —
- Login
- Signup
- E-Commerce/Food Delivery/Online Travel Booking Order
Server Side User Identification
Since server-side events ensure the most accuracy, the ‘Identify’ method pre-defined by most Product Analytics tools should be sent from the backend post the ‘Signup’ or ‘Login’ is confirmed for a user by the server.
Also, while sending the ‘Identify’ event from the backend, since the server wouldn’t have any information about the user’s client, the parameters like ‘anonymous id’ would have to be sent from the client to the server for the same to be available to be sent along with the ‘primary key’ or ‘object id’ at the time of ‘Identify’.
Please note that Identify isn’t logged as a user event on the user’s activity panel. Hence, ‘Signup’ or ‘Login’ as applicable in your flow should be sent after Identify to separately record and analyze ‘Signups’ or ‘Logins’ across your products.
Summary
Product Analytics Tools are mostly similar to each other in their functionality. They rely on ‘Users’ being identified by information supplied by your organization to perform ‘Events’ on performing certain actions of interest to you to record.
The identification of users needs to be implemented carefully from your server-side along with all events whose accuracy of reporting is important and therefore, there shouldn’t be a miss in reporting of a single instance of the same.
In the next section, we’d cover the various methods of implementation of Product Analytics.
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
