How to set up product analytics from scratch - Data Research Analysis Collection

TL;DR

You can have working product analytics running in a weekend. The whole process takes roughly 4-6 hours of focused work: writing a tracking plan, picking a tool, instrumenting your app, and building your first funnel and retention chart. The core stack you need is PostHog or Mixpanel for event tracking, plus a spreadsheet or simple BI tool for dashboards.

What You Need Before You Start

A live product, whether a web app, mobile app, or SaaS tool, with at least a handful of real users
Admin access to your codebase or a tag manager like Google Tag Manager
A PostHog Cloud account (free tier, 1M events per month, no credit card required) or a Mixpanel Starter account (20M events per month free as of 2026)
A Google Sheet or Notion doc for your tracking plan
Node.js 18+ or Python 3.10+ if you plan to fire server-side events
Optional: a Segment free account (up to 1,000 MTUs) if you want one pipeline feeding multiple downstream tools
Optional: a BigQuery sandbox (1TB queries per month free) if you expect high event volumes within six months
Write access to your app’s codebase is required; database access is helpful but not mandatory at this stage

Step 1: Write a Tracking Plan Before You Touch Any Code

Most founders skip this step and end up with a pile of inconsistently named events three months later. A tracking plan is the one thing that separates analytics you can trust from analytics that just exist.

A tracking plan is a simple document, usually a spreadsheet, that lists every event you want to track, what properties it carries, and the business question it answers. You do not need a dedicated tool for this. A Google Sheet with four columns is enough.

Set up columns for: Event Name, Trigger (when does it fire), Properties (key-value pairs to send with it), and Business Question (why do you need it).

Start with no more than 10 events. A solid starting set for a SaaS product looks like this:

user_signed_up        { plan, source, referrer }
onboarding_completed  { steps_completed, time_to_complete_seconds }
feature_used          { feature_name, plan }
file_uploaded         { file_type, file_size_kb }
subscription_started  { plan, amount_usd, billing_period }
subscription_cancelled{ plan, reason, days_since_start }

Use snake_case for all event names. Use past tense. Keep property names consistent across every event that shares a concept. If one event uses plan and another uses plan_name, you will regret it when you try to filter a funnel.

You should now see a clean list of 6-10 events mapped directly to questions like “what percentage of signups complete onboarding?” and “which features do paid users actually use?”

Step 2: Pick Your Analytics Tool

For a startup under 50k monthly active users, two tools dominate the decision.

PostHog is open-source, ships with session replays, feature flags, and A/B testing in one product, and has a genuinely useful free cloud tier. If data privacy is a concern, you can self-host it on a single server. It is the right default for most early-stage founders.

Mixpanel has a cleaner UI for funnel and retention analysis and requires no SQL knowledge to explore data. The Starter plan covers 20M events per month free. Pick Mixpanel if your team is non-technical and will be doing their own analysis without help.

Amplitude is worth knowing about but its free tier got restrictive in 2025. Hold off until you have budget or a specific need for its behavioral cohort features.

If you need one tracking snippet that feeds multiple tools at once, add Segment in the middle. Otherwise, adding Segment at this stage is over-engineering.

You should now see a created project inside your chosen tool with an API key ready to copy.

Step 3: Install the Tracking Snippet

For a web app using PostHog, install the JavaScript SDK:

npm install posthog-js

Initialize it as early as possible in your app, ideally in your root layout or entry file:

import posthog from 'posthog-js'

posthog.init('phc_YOUR_PROJECT_API_KEY', {
  api_host: 'https://us.i.posthog.com',
  person_profiles: 'identified_only',
})

If you use React, wrap your root component in the provider:

import { PostHogProvider } from 'posthog-js/react'

export default function App() {
  return (
    <PostHogProvider client={posthog}>
      <YourApp />
    </PostHogProvider>
  )
}

For Python backend tracking, install the server-side library:

pip install posthog

from posthog import Posthog
posthog = Posthog(project_api_key='phc_YOUR_KEY', host='https://us.i.posthog.com')

Find your API key under PostHog project settings > Project > Project API Key.

You should now see events appearing in the PostHog Live Events tab within 30 seconds of loading your app in a browser.

Step 4: Identify Your Users

Anonymous events are useful for aggregate analysis. User-level data is where product analytics actually gets actionable. You need to tie events to a specific user as soon as they log in.

Call identify immediately after a successful login, before any other events fire:

posthog.identify(
  user.id,       // your internal database ID, not email
  {
    email: user.email,
    name: user.name,
    plan: user.subscriptionPlan,
    created_at: user.createdAt,
  }
)

Use your internal database ID as the distinct_id, not the user’s email address. Emails change. Users merge accounts. Database IDs do not move.

On the server side in Python:

posthog.identify(
    distinct_id=str(user.id),
    properties={
        'email': user.email,
        'plan': user.plan,
    }
)

Pass properties that will be useful for filtering later: plan, company size, signup source. Do not pass passwords, payment card numbers, or anything you would not write to a log file.

You should now see named user profiles appearing in PostHog’s Persons tab with their properties populated.

Step 5: Fire Your Core Events

Return to your tracking plan from Step 1 and implement each event at the right moment in your code. Here is a signup event fired from a Python backend:

posthog.capture(
    distinct_id=str(user.id),
    event='user_signed_up',
    properties={
        'plan': user.plan,
        'source': request.GET.get('utm_source', 'direct'),
        'referrer': request.headers.get('Referer', ''),
    }
)

And a feature usage event from JavaScript:

posthog.capture('feature_used', {
  feature_name: 'csv_export',
  plan: currentUser.plan,
})

Work through all 10 events in your plan one at a time. For each event, open your app, trigger the action manually, then switch to the PostHog Live Events tab and confirm the event arrived with the correct properties.

Fire subscription events like subscription_started and subscription_cancelled from the server, not the client. Ad blockers affect 30-40% of technical users. Server-side events cannot be blocked.

You should now see all 10 events firing correctly in Live Events, each with consistent property names matching your tracking plan.

Step 6: Build Your First Funnel

A funnel shows what percentage of users move from one step to the next. The most important funnel for a SaaS product at this stage is signup to activation.

In PostHog, go to Insights > New insight > Funnels. Add steps in this order:

user_signed_up
onboarding_completed
feature_used

Set the conversion window to 7 days. Click Calculate.

You will see a bar chart showing how many users made it through each step. If 200 users signed up and 40 completed onboarding, your activation rate is 20%. That number is your baseline. Every product experiment you run from here should be aimed at moving it.

Filter the funnel by plan or source to find patterns. Free-tier users converting at 12% while paid trial users convert at 55% is a meaningful signal worth investigating.

You should now see a funnel chart with conversion percentages at each step, filterable by any property you passed with the event.

Step 7: Set Up a Retention Chart

Retention tells you whether users come back after their first session. A product that loses most of its users by week two has a problem that more acquisition will not fix.

In PostHog, go to Insights > New insight > Retention. Set the retention event to feature_used or whatever your core action is. Set the date range to the last 8 weeks.

The resulting grid shows cohorts by signup week on the left and columns for week 1, week 2, and so on through week 8. A healthy early-stage SaaS product typically shows 20-30% week-4 retention. Below 10% means stop acquiring users and fix the product first.

Look at whether retention improves for more recent cohorts. If week-4 retention was 8% in January and is 18% in April, your product improvements are working.

You should now see a retention grid with week-over-week return rates for each signup cohort.

Step 8: Set Up a Weekly Dashboard

Pull your most important metrics onto a single page so you can review them without rebuilding the analysis every time.

In PostHog, go to Dashboards > New dashboard. Name it “Weekly Product Health.” Add these widgets:

New signups (trend, last 30 days)
Activation funnel (signup to first feature use)
Week-4 retention for the latest cohort
Top features by usage (breakdown by feature_name property on feature_used)
Daily active users

Pin the dashboard. Set a recurring calendar event every Monday morning to open it with your team for 15 minutes. A dashboard nobody reviews on a fixed schedule becomes stale within weeks.

You should now see a single page with five charts that gives you a full picture of product health in under two minutes.

Step 9: Export Raw Events for Deeper Analysis

Dashboards inside PostHog handle day-to-day monitoring. When you need to join product data with Stripe revenue or segment users by dimensions that PostHog does not natively support, you need raw event data.

PostHog’s HogQL editor lets you query events directly with SQL. A query to pull all signups in the last 30 days:

SELECT
  distinct_id,
  properties.plan AS plan,
  properties.source AS source,
  toDate(timestamp) AS signup_date
FROM events
WHERE event = 'user_signed_up'
  AND timestamp >= now() - INTERVAL 30 DAY
ORDER BY signup_date DESC

Export the result as CSV. Paste it into Google Sheets alongside a CSV export from Stripe. Use VLOOKUP or INDEX/MATCH to connect each user to their revenue. This is how you find out which acquisition source actually brings paying customers, not just signups.

For automated exports, PostHog supports direct pipelines to BigQuery and S3 under Data Pipeline > Destinations.

You should now see a downloadable CSV with one row per event, ready to join with revenue, support, or marketing data.

Common Mistakes To Avoid

Tracking 50 events on day one. You’ll end up unable to answer any single question cleanly. Start with 10 events tied to specific business questions, then expand when those are answered.
Using email as the user ID. Emails change. Users create duplicate accounts. Always use your internal database ID as distinct_id and pass email as a property.
Firing events before calling identify. Events that land before identify attach to an anonymous profile. Call identify first, then capture.
Skipping server-side tracking for critical business events. Subscription changes, payment completions, and API usage events must fire from the server. Browser events are blockable by extensions.
Building dashboards nobody reviews. Attach your analytics review to a recurring calendar event with a fixed attendee list. Otherwise the dashboard will be ignored within a month.
Ignoring session replays for qualitative context. Numbers tell you where users drop off. PostHog’s session replays show you why. Watch 10 replay sessions of users who abandoned your onboarding flow before drawing conclusions from the funnel data.

When To Level Up

The setup described here works comfortably up to around 100k monthly active users or until your team grows past five people who all need different data cuts.

At that point a few things start to break. PostHog’s HogQL is capable but it is not a full data warehouse. Joining product events with Stripe billing, Intercom support data, and your CRM requires a proper pipeline. Different teams start needing dashboards that are too specialized to live in a single shared PostHog project.

The next step is a warehouse-first analytics stack: Fivetran or Airbyte to centralize data from all your sources, BigQuery or Snowflake as the central store, dbt for data modeling, and Metabase or Looker Studio for self-serve dashboards on top.

That architecture costs more time and money to maintain, but it scales with your business and lets every team access the data they need without waiting on an analyst. When you are ready for that move, the full breakdown of tools and tradeoffs is at /category/data-analysis/.

You can also read about specific warehouse decisions in our guide to choosing a data warehouse for startups and our Metabase vs Looker Studio comparison.

Frequently Asked Questions

Do I need a paid plan to get started with product analytics?

No. PostHog Cloud covers 1 million events per month on the free tier and Mixpanel Starter covers 20 million. Both are more than enough for an early-stage product. You will hit a ceiling on features before you hit a ceiling on volume, and even then most startups stay on free tiers through their first year of growth.

Can I use Google Analytics 4 instead of PostHog or Mixpanel?

GA4 is built for marketing attribution, not product analytics. It has funnel and retention reports but they are harder to configure for custom events and the data model does not support user-level querying the way PostHog or Mixpanel does. Use GA4 on your marketing site and a dedicated product analytics tool inside your app.

How many users do I need before the data is meaningful?

You need at least 100 users to complete a given action before conversion rates are statistically meaningful. With fewer users than that, one or two outliers will swing your percentages significantly. Focus on user interviews and session replays until you hit that threshold.

What if my product is mobile rather than web?

PostHog has native SDKs for iOS (Swift) and Android (Kotlin). The concept is identical: install the SDK, call identify on login, capture events at the right moments in your code. Session replays are not available on mobile, but funnels, retention charts, and dashboards work exactly the same way.

Should I track events from the frontend or the backend?

Both, for different things. Track user-facing interactions like button clicks, page views, and feature opens from the frontend. Track business-critical actions like subscription changes, file processing completions, and API responses from the backend. Backend events are more reliable because they cannot be blocked by browser extensions or network failures.

Bottom Line

Setting up product analytics from scratch comes down to four things: writing a tracking plan before you write code, installing one tool (PostHog is the right default for most startups in 2026), firing consistent events with well-named properties, and reviewing the data on a fixed schedule every week. You do not need a data warehouse, a dedicated analyst, or a six-figure analytics budget to get useful insights. A signup-to-activation funnel and a week-4 retention chart will tell you more about your product than any amount of intuition. Start small, add events only when a specific question demands them, and keep your tracking plan updated as your product changes. When your team or data complexity outgrows this setup, the data analysis guides at /category/data-analysis/ cover the full warehouse-first path in detail.