Setting up Product Analytics: A Complete Guide

Introduction

Back in the spring of 2021, we convinced our company to invest in product analytics. At the time we were talking to customers every week, running surveys, and getting some great insights. But we were missing something big: real live- data on how our customers were actually using the platform. Were they using Feature A or B? How long did it take them to reach that "aha" moment after signing up?

Setting Up the Analytics Infrastructure

We were starting completely from scratch, with not much experience, user events or analytics tools in place. The only data we had was stored in our SQL relational database and BigQuery warehouse. Which meant there were several key decisions to make:

1. Infrastructure: Are we using a data platform (buying) or built integrations ourselves (building).

2. Defining metrics & outcomes: Identifying what we needed to track, specifying the data to be collected, and naming events.

3. Choosing tools: Deciding which analytics tools would best suit our needs, considering options like MixPanel and Amplitude.

We had multiple sources since we were working with both web and mobile applications. A key requirement for us was to track each user and their events across these platforms seamlessly. We concluded that we needed a data platform that centralises the customer data from all sources, to do that we chose Segment and for our analytics platform we chose Amplitude.

It gave us a few advantages:

• Save a ton of developer time

• Segment comes with hundreds of integrations

• Compliance (Data storing, GDPR etc)

Setting up Segment was straightforward. Using their JavaScript source and mobile SDKs, the initial setup was a breeze. Once everything was tested and we implemented the needed tracking calls, we moved on to setting up specific user events for each key feature or action.

Initially, we implemented all events on the client-side, though we later found this approach to be less reliable.

Client-side events can be blocked by browsers, ad blockers, and privacy settings, impacting accuracy. Client-side tracking is estimated to be around 80% accurate.

This became a problem as the count of signups was lower through events than that we raw queried the database for example. To resolve this, we switched core events, such as signup and revenue-related events like subscription - started, to server-side tracking, which provided much higher accuracy. This server-side setup took more development time, so we kept less critical events on the client side.

Connecting Destinations

Setting up destinations was incredibly simple. Since all user events are funneled into Segment, we could configure destinations with just a few clicks, without requiring developer input. This approach gave our teams the flexibility to integrate their preferred tools and receive the events they needed.

For example, our customer success team used Intercom to receive activation events for campaigns, while our marketing team connected Google Ads to capture events and optimize campaigns effectively.

Creating a tracking plan

A tracking plan is a document or spreadsheet that organizations use to create a standardized approach to data tracking.

The first things we did is figuring out what base data we would like to track for each user. This is called the "identify" call.

Basically when someone is logging or updates their info we can see a bunch of data for that user. This becomes invaluable for personalising the user experience and for retargeting efforts plus we can also create cohorts of users based on these traits.

Upon this identify call you can attach user traits, such as their name, email, industry, subscription_type and many more custom traits. We store this information in our tracking plan and update where needed.

Then we defined all events that we’re relevant to us to track. We started small and gradually added events so we didn’t create too much noise or unnecessary events in the beginning.We quickly learned that, when it comes to tracking, less is often more.

💡 Pro tip - Use naming conventions. This makes your life and your team(s) so much easier. Here you store all user properties, user events and the context.

For example some naming below. we use all lowercase and we always start with a keyword that easily shows which part of the product the user is in.

• onboarding - register form

• onboarding - register submit

• onboarding - register success

For our invoicing product, we applied similar logic:

• invoice - start

• invoice - finish

• invoice - send

Analysing and using the data

With Segment and Amplitude integrated, we could finally dive into real-time insights and analytics. Our team and myself began by building custom dashboards tailored to our core KPIs, such as user engagement, activation rates, and feature adoption.

What was super valuable to us was funnel analysis and identify huge drop-off points. Specifically our onboarding journey was super complex and lenghty. Whilst it had it’s advantages customers just got too much friction before even seeing a glimpse of the product.

Example of customer progress through the signup journey. Source

What positive effects did it have?

• Increased user activation and retention: With a clear view of how users interacted with the product, we were able to identify underperforming features and make real-time improvements. We discovered crucial friction points in the user journey and adjusted onboarding flows to increase activation rates.

• Company wide data-driven approach: This setup empowered teams across the organisation to access valuable insights through analytics. They could easily create charts, graphs, and cohorts based on the available events and user traits. On top of that, the customer success team used these insights to identify and target customers who were likely to churn.

RENÉ HESSELINK I'm a Product Director at a FinTech SaaS company, focused on driving growth. Passionate about simplifying complex problems and turning them into solutions that everyone can understand.

renehesselink.com | LinkedIn