Most startups fail, and most startups that win do it by accident.
We can do better.
A strong approach to product analytics lets us win on purpose. We define success as a number we can measure, then describe the user behavior that feeds that number.
This allows us to track if a product is meeting its business goals over time, and use that information to iterate into more impact for customers and profitability for ourselves.
Here's how.
North Star metric
We start with a number that represents the health of our immediate goals.
It's not going to be revenue.
Instead, we want to count something that's a precursor to revenue. Something where, if it doesn't happen, we don't have a business. Examples from businesses you've heard of:
Facebook: Daily active users
Airbnb: Nights booked
Uber: Number of rides
See how easy it is to understand these numbers? A good North Star is measurable and easy to communicate. Everyone on the team, no matter their role, grasps their relationship to it.
If you're super early, you could start with a metric like signups: how many people care enough to try your product?
What does traction look like for your business?
Which metric corresponds to traction right now? Call that your North Star metric.
Defining our v0 metrics tree
With a North Star in mind, we can back out to the user behavior that feeds it.
Events are things that users do that we can track in code, and then measure across all usage of the product.
Example: ride sharing
Uber can't make money if no one launches the app. app_launched, then, becomes, an essential event for them keep track of.
But there's still no money until ride_requested happens.
Even that doesn't quite get us to a ride. We need a couple more: ride_accepted and ride_began
It's these events together that give us a picture of how people use the product to get a ride. While counting only ride_began would give us enough to measure our North Star, it would not be enough to learn how to influence it.
Funnels
Because events often happen in a predictable sequence, we can use that sequence to learn if users are getting stuck or bailing out.
This is called a funnel.
Funnels are simple: they measure successful progress between events. More people will launch the app than start a ride, but you still want to maximize the progress from one to the other. A funnel lets you understand how well that's going.
If there's a sharp drop between, say, accepting a ride and starting one, that could point to an issue that needs to be fixed in the product.
Funnels give us the information we need to diagnose problems and measure the impact of new solutions. We'll want to make sure we capture just enough event data to measure the critical path between starting in our product and succeeding with it.
Recap your traction goal and North Star metric, then think about the events that drive that metric.
These are the events that must be captured as part of integrating PostHog.
Integration planning
Now:
- We know what we're measuring
- We know why we're measuring it
- We know what events lead to the outcome we want
With these details in-hand, we can make a plan to capture the data we need. This data collection will help us understand how users interact with our product, and how well our product meets our goals.
Ideal event names are self-explanatory, avoiding strange abbreviations or codes. Don't stuff data into event names – they should be comparable across all users of your product. Instead, we want to tuck additional data into properties on events.
What unique identifier should be used to identify users? Ideally, this is an ID from the database that won't change, but an email address can work too.
Where will identify() be called? Typically identify() is invoked in the client, but some architectures, like SSR web apps, will call it on the server.
Integration references
For more detail on PostHog's data model, identifying users, and general integration guidance, check out our docs:
Gotchas
Integration is straightforward, but things can get messier as time goes on. Here are a few things to watch out for.
Event naming
Pick a naming convention and stick with it! There isn't a right choice here, only a wrong choice: different people on your team using different event names or conventions to describe the same behavior.
Be warned: PostHog's event storage is 'write only' for all practical purposes. You can't edit existing events, so it's important to design against naming drift. Otherwise, you may find queries much harder to work with down the road.
User identity
Complex authentication flows and tracking anonymous users from both client and server can complicate identifying users.
PostHog enforces some rules use of the identify function to prevent users from being merged incorrectly. Learn more about Alias if you intend to provide more than one of your own IDs for a user, or you need to merge identities on the server.