How to set up your Product Analytics structure?
This is Part 3 of a long-form series of setting up Product Event Analytics correctly.
You could read Part 2 about the analysis of the tool that you want to use to draw up your insights on
If you’re already clear about which Products you’d want to instrument, feel free to skip over to the next part where I discuss how Product Analytics works
The correct structure of Product Event Analytics for a direct-to-consumer organization can depend on the Product Stack the organization uses. I’ve used a basic example of a ride-sharing product where users can book a cab online and a cab driver provides the service named ‘EasyRide’.
Let’s also assume that there’s another demand channel for getting ride bookings via local taxi stands which have been provided the same booking portal with the same inventory that helps them service their customers.
For the next few example scenarios, I’d continue to use the same use case of an online ride-sharing booking platform.
The Product Stack for such an organization would look like the following in this diagram -
Let’s assume that you want to analyze your user behavior across all these products. Let’s start structuring your Project space on a Product Analytics tool since that would come in handy and would prevent any future errors. Given, the above stack, let’s assume you have the following websites and applications combination -
Direct-to-Consumer App
The App exposed to the consumer for booking a cab ride. Let’s assume that this App is available both on Android and iOS.
Direct-to-Consumer Website
The website exposed to the consumer for booking a cab ride for users who haven’t installed the App or happened to book a ride using a desktop (Not probable)
Driver App
The App exposed to the cab driver which is used for fulfilling a service request, for navigating to the customer’s destination, and for other workflows like withdrawing the payable amount accumulated to their own bank account and uploading and editing their KYC information. In most of the above-mentioned use cases, Drivers would have an Android and iOS App but wouldn’t have a desktop/browser-based solution since that would be harder to use and would add the complexity of building and maintaining features for the engineering team.
Getting users to install an App wouldn’t be a major challenge since most Drivers would have their monetization tied in with the App. Some other features such as navigation are also mostly reliable only in native Apps and don’t function well on browsers.
Agent App
The App exposed to taxi stands around a specific city that uses the same booking system for booking cabs for their customers who happen to walk up to them on demand. Bear in mind that the pricing for booking a cab on this App may be different from the Direct-to-Consumer App depending on the terms agreed with taxi stands around. In most of the above-mentioned use cases, Agents would also only have an Android and iOS App and not have a desktop/browser-based solution for the very same reason.
Project Structuring
Project Structuring would be different for the tools that are being used. I’m briefly touching upon the Project structure that would be required for two types of Analytics tools. You’d observe that if you’re able to structure your project on these two types of Analytics tools, you’d be able to structure your projects for Amplitude and Posthog as well. A generic advice would be to configure either of your Analytics tools’ Administrator users from a generic email address so that the ownership of this email address isn’t employee dependent.
Using a central email address such as ‘administrator@easyride.com’ would also be beneficial since it’d be the central email address for allocating access to Google Analytics with different permissions such as ‘Viewer’ or ‘Editor’.
Staging Environments
I’d recommend setting up a staging environment property for each type of Product that you’re instantiating. These staging properties are exactly similar to the staging environment that engineering teams use to build, test, and deploy new features and fix errors. Each staging environment property would help your Product or QA team with testing out the event instrumentation implementation.
Google Analytics
For structuring Google Analytics, you’d need to create your project structures such that you create one account for your organization and then instantiate various properties, one for each Product in your Product Stack. Inside each property, you should instantiate various streams, one for each platform such as Android, iOS, and website. This should be the structure for configuring Google Analytics -
Let’s briefly also touch upon the nomenclature that Google Analytics encompasses —
Account
An Account is an entity that should have one organization’s entire data and user base. In the above example, Google Analytics would have one Account as ‘EasyRide Technologies Pvt. Ltd.’
Property
A Property represents one unique product with a set of customers. Even if your product is such that it has multiple logins for each user type, it should still be one single property. In the above example, Google Analytics would have multiple properties mentioned below —
- EasyRide D2C Staging
- EasyRide D2C Production
- EasyRide Driver Staging
- EasyRide Driver Production
- EasyRide Agent Staging
- EasyRide Agent Production
Stream
A Stream represents one unique platform that sends data to one of Google Analytics’ Properties. For Google Analytics, there’s a restriction to the number of streams that could send data to one Google Analytics Property. It has fixed three stream provisions on its User Interface. In the above example, we’d have three streams for the D2C Consumer platform, but only two each for Driver and Agent Apps since we won’t have a desktop/browser-based solution for our Drivers and Agents.
Mixpanel
For structuring Mixpanel, you’d need to create your project structures such that you create one account for your organization and then instantiate a Project once for each Product very similar to the setup of Google Analytics. However, there aren’t any streams to be associated with tools like Mixpanel and Amplitude. For sending data from three different platforms such as Android, iOS, and website Mixpanel uses a separate structure where the Project key to which data is being sent is used as the same. This project key is available in the Settings of each Project.
Account
An Account on Mixpanel is similar to an Account on Google Analytics. Therefore, Mixpanel should have the same account as ‘EasyRide Technologies Pvt. Ltd.’
Project
A Project on Mixpanel is analogous to a Property on Google Analytics. Therefore, Mixpanel would have the following projects —
A Property represents one unique product with a set of customers. Even if your product is such that it has multiple logins for each user type, it should still be one single property. In the above example, Google Analytics would have multiple properties mentioned below —
- EasyRide D2C Staging
- EasyRide D2C Production
- EasyRide Driver Staging
- EasyRide Driver Production
- EasyRide Agent Staging
- EasyRide Agent Production
Mixpanel has an advantage over Google Analytics in that you could theoretically use many streams to continue to send data to the same Project and collate all the data to analyze within the ambit of one single Project.
However, for this use case again we’d use the Project keys present inside the Settings page of a Project to initialize in our code base and send data to the same project for similar property type (For Example — Our code base for EasyRide D2C Production Website, Android App, and iOS App would use the same project key).
In order to perform a breakdown analysis of events into the three platforms, we could use an event property with each event type such as ‘EasyRide D2C Android Production’ and ‘EasyRide D2C iOS Production’ to perform a deeper analysis on one platform in isolation.
Summary
Setting up Project Structures for your Product Analytics tool can ensure cleaner separation and Product dashboard setup with good separation of concern between unrelated Products.
There might be cases where you have to set up more than one Account for organizations in two different businesses. However, please note that the structuring of Projects shouldn’t depend on the number of Business Units in your organization or on the internal segregation of responsibilities.
It should depend on the types of users that use your product and their objective.
In the next part, we’d discuss how this comes together and how a Product Analytics tool works
Do share your feedback with me at kshitj.saxena@gmail.com or connect with me on LinkedIn
