SaaS Product Analytics: PostHog vs Mixpanel 2026
TL;DR
PostHog for most SaaS in 2026: replaces Mixpanel + FullStory + LaunchDarkly + Hotjar with one platform, and the free tier (1M events/month) is excellent. Mixpanel if you need advanced funnel analysis and cohort tracking with a dedicated product analytics team. Custom events to your database for simple tracking when third-party analytics is overkill.
What Product Analytics Actually Answers
Without analytics, you're guessing:
- Why do users sign up but never use the core feature?
- Where does the onboarding funnel drop off?
- Which features drive Pro upgrades?
- Why do churned users leave?
Analytics gives you data to answer these questions — but only if you track the right events.
PostHog: The All-In-One Platform
PostHog is the fastest-growing product analytics platform. It combines:
- Event analytics (like Mixpanel)
- Session recording (like FullStory)
- Feature flags (like LaunchDarkly)
- Experiments/A/B testing
- Heatmaps
Free tier: 1 million events/month. This covers most indie SaaS.
// lib/analytics.ts — PostHog client
import PostHogClient from 'posthog-node';
export const posthog = new PostHogClient(
process.env.NEXT_PUBLIC_POSTHOG_KEY!,
{ host: process.env.NEXT_PUBLIC_POSTHOG_HOST! }
);
// Type-safe event tracking
export function trackEvent(
event: string,
userId: string,
properties?: Record<string, string | number | boolean>
) {
posthog.capture({
distinctId: userId,
event,
properties,
});
}
// Client-side — auto-track pageviews + capture events
'use client';
import { usePostHog } from 'posthog-js/react';
export function UpgradeButton({ plan }: { plan: string }) {
const posthog = usePostHog();
const handleClick = () => {
posthog.capture('upgrade_clicked', {
plan,
location: 'pricing_page',
$current_url: window.location.href,
});
};
return <button onClick={handleClick}>Upgrade to {plan}</button>;
}
Critical Events to Track
Every SaaS should track these events at minimum:
// lib/analytics-events.ts — standardized event names
export const Events = {
// Acquisition
USER_SIGNED_UP: 'user_signed_up',
USER_SIGNED_IN: 'user_signed_in',
// Activation
ONBOARDING_STARTED: 'onboarding_started',
ONBOARDING_COMPLETED: 'onboarding_completed',
FIRST_CORE_ACTION: 'first_core_action', // First time user uses main feature
// Retention
DASHBOARD_VIEWED: 'dashboard_viewed',
CORE_FEATURE_USED: 'core_feature_used',
// Revenue
UPGRADE_CLICKED: 'upgrade_clicked',
CHECKOUT_STARTED: 'checkout_started',
CHECKOUT_COMPLETED: 'checkout_completed',
PLAN_UPGRADED: 'plan_upgraded',
PLAN_CANCELLED: 'plan_cancelled',
// Sharing/Viral
INVITE_SENT: 'invite_sent',
} as const;
// Usage
trackEvent(Events.PLAN_UPGRADED, userId, {
from_plan: 'free',
to_plan: 'pro',
method: 'stripe_checkout',
mrr_added: 29.99,
});
PostHog Funnel Analysis
Once events are tracked, PostHog shows the drop-off at each step:
Onboarding Funnel:
Sign Up → Verify Email → Connect Account → First Action → Invite Team
Results:
100 users signed up
82 verified email (82% → focus: reduce friction here)
45 connected account (55% → BIG drop: investigate connection flow)
30 took first action (67% → okay)
12 invited team member (40% → growth lever)
This tells you where to invest engineering time.
Mixpanel: The Analytics Specialist
Mixpanel is purpose-built for product analytics. More powerful funnel/cohort features than PostHog, but only does analytics (no session recording, no feature flags).
import Mixpanel from 'mixpanel';
const mixpanel = Mixpanel.init(process.env.MIXPANEL_TOKEN!);
// Event tracking
mixpanel.track('Plan Upgraded', {
distinct_id: userId,
from_plan: 'free',
to_plan: 'pro',
revenue: 29.99,
});
// User identification with traits
mixpanel.people.set(userId, {
$email: user.email,
$name: user.name,
plan: 'pro',
upgrade_date: new Date().toISOString(),
$revenue: 29.99,
});
Choose Mixpanel when:
- Dedicated product analytics team that needs advanced cohort analysis
- Need complex behavioral cohorts (users who did X but not Y in last 30 days)
- Already using Mixpanel across your organization
- Budget is fine ($25/month for growth plan)
Custom Event Tracking (Simplest)
For early-stage SaaS, storing events in your own database is often enough:
model AnalyticsEvent {
id String @id @default(cuid())
event String
userId String?
properties Json @default("{}")
createdAt DateTime @default(now())
@@index([event, createdAt])
@@index([userId, createdAt])
}
// lib/track.ts — store events in PostgreSQL
export async function track(
event: string,
userId: string | null,
properties?: Record<string, unknown>
) {
await prisma.analyticsEvent.create({
data: { event, userId, properties: properties ?? {} },
});
}
// Query: how many upgrades this week?
const upgrades = await prisma.analyticsEvent.count({
where: {
event: 'plan_upgraded',
createdAt: { gte: subDays(new Date(), 7) },
},
});
When custom tracking is enough:
- Simple event counts (signups, upgrades, feature usage)
- You'll query it with SQL
- Total events < 1M/month (won't strain Postgres)
- Team is comfortable writing SQL queries
When to upgrade to PostHog:
- Need visual funnel analysis without writing SQL
- Need session recording to understand user behavior
- Need feature flags tied to analytics
Boilerplate Analytics Defaults
| Boilerplate | Analytics | Provider |
|---|---|---|
| ShipFast | ✅ | Vercel Analytics (basic) |
| Supastarter | ❌ | — |
| Makerkit | ✅ | PostHog |
| T3 Stack | ❌ | — |
| Open SaaS | ✅ | PostHog + Plausible |
Identifying Users and Companies: The Identity Graph
Analytics only becomes useful when you can ask "why are users from companies in fintech churning faster than average?" or "what's the retention rate for users who completed onboarding vs those who didn't?" These questions require proper identity setup.
// Identify users when they sign up or log in
export async function identifyUser(user: User) {
// PostHog person properties — persisted to user profile
posthog.identify(user.id, {
email: user.email,
name: user.name,
plan: user.plan,
createdAt: user.createdAt.toISOString(),
company: user.company,
companySize: user.companySize,
signupSource: user.signupSource, // How they found you
});
}
// Group analytics — track behavior by organization
export async function identifyOrganization(org: Organization, userId: string) {
posthog.groupIdentify('company', org.id, {
name: org.name,
plan: org.plan,
memberCount: org.memberCount,
industry: org.industry,
mrr: org.mrr,
});
// Associate user with their org
posthog.capture('$groupidentify', {
$group_type: 'company',
$group_key: org.id,
});
}
Call identify on login — not just on signup. Users who clear cookies or log in from new devices start as anonymous. The identify call links their pre-login anonymous activity to their known profile.
Group analytics (company-level) requires PostHog's paid plan or Mixpanel's group analytics. It lets you segment by company characteristics — churn rates by company size, feature adoption by industry, revenue by acquisition channel.
What Not to Track: The Signal vs Noise Problem
The failure mode of well-configured analytics is tracking too much. A dashboard with 200 events is useless for making decisions. The signal is buried in noise.
Don't track:
- Individual UI state changes (dropdown opened, tooltip hovered)
- Admin-only actions that don't reflect user behavior
- Events that happen in every session (page loaded, session started)
- Errors in detail (use Sentry for error tracking, not analytics)
- Highly sensitive user data (don't put PII in event properties beyond what's essential)
Do track:
- Actions that represent intent or commitment (started, completed, abandoned)
- Transitions between product stages (free → trial → paid, inactive → active)
- The "aha moment" — the first action that correlates with long-term retention
- Anything you'll build a funnel or cohort around
The right number of events to track for a new SaaS product is around 15-25. The signup funnel, the onboarding flow, the core product usage actions, and the revenue events. Start narrow and add events when you have a specific question to answer.
Analytics and Privacy: What You Need to Know
In 2026, analytics compliance is non-optional for products with EU users (GDPR) and increasingly important for US products (CCPA and state-level regulations).
Third-party analytics (PostHog Cloud, Mixpanel): Requires consent for EU users under GDPR when using persistent identifiers (cookies, user IDs). Most SaaS products include analytics consent in their Terms of Service and privacy policy rather than implementing explicit cookie banners — this is acceptable if you don't use tracking pixels or advertising trackers.
Self-hosted PostHog: Hosting PostHog on your own infrastructure means user data never leaves your servers. GDPR compliance is simpler (no third-party data processors). The downside: infrastructure cost and maintenance.
Privacy-first analytics (Plausible, Fathom): For page-level analytics without user tracking, Plausible and Fathom are GDPR-compliant by design — no cookies, no persistent identifiers. They don't support user-level analytics but are appropriate for marketing site traffic analysis.
For a standard B2B SaaS with EU customers: PostHog Cloud with a data processing agreement (DPA) is the standard path. Include PostHog in your privacy policy's list of data processors. If you're building for healthcare or financial services, consult with legal counsel before choosing an analytics provider.
Feature Flags: Analytics and Experiments Together
PostHog's feature flag system is worth using even if you're primarily interested in analytics. Decoupling feature releases from code deploys reduces risk and enables gradual rollouts. More importantly, when feature flags live in the same tool as your analytics, you can directly correlate flag variants with conversion metrics.
// Check flag and track simultaneously
const showNewOnboarding = await posthog.isFeatureEnabled('new-onboarding-flow', userId);
if (showNewOnboarding) {
// PostHog automatically associates this event with the flag variant
posthog.capture('onboarding_started', {
$feature_flag: 'new-onboarding-flow',
$feature_flag_response: 'test',
});
}
Without feature flags in your analytics tool, measuring the impact of a UI change requires comparing before/after time windows — which conflates the change with any other events in that period. With A/B flag variants and integrated analytics, you compare control vs. test groups simultaneously, eliminating time-based confounds.
The practical startup use case: ship a new onboarding flow to 10% of users, watch the onboarding_completed rate for both variants in PostHog's experiment view, roll out to 100% if the test variant converts better. No separate LaunchDarkly subscription, no exporting data between tools.
Setting Up Analytics in a Boilerplate: A Practical Checklist
Most SaaS boilerplates ship without analytics or with only pageview tracking. Adding proper product analytics to an existing boilerplate is a half-day task if done systematically.
Install and configure (30 minutes): Install posthog-js for the client and posthog-node for the server. Add the PostHog Provider to your root layout. Configure the distinctId to use your auth user ID after login.
Identify users on login (1 hour): Add an identify call wherever you confirm a user's identity — the auth callback, the session restore, the first authenticated server request. Pass the user's email, plan, and signup date as person properties. This enriches all subsequent events with user context automatically.
Instrument the core funnel (2 hours): Add tracking to signup completion, onboarding steps, the first use of your core feature, and plan upgrade. These five events power 80% of the analytics questions you'll actually ask.
Verify in PostHog (30 minutes): Create a funnel in PostHog from signup to first core action. If the funnel shows unexpected drops, investigate before shipping to real users. Catching instrumentation bugs in development is much cheaper than realizing your entire analytics history is corrupted after 3 months.
The common mistake: adding analytics as an afterthought after launch, then realizing the data needed to answer "why are users churning?" simply doesn't exist. Instrument before launch, even if you don't analyze the data immediately.
Measuring the "Aha Moment"
Every successful SaaS product has an activation event — the moment when a user realizes the product's core value and becomes significantly more likely to retain. For Slack, it was sending 2,000 messages. For Dropbox, it was adding a file to one folder. Identifying your own aha moment is the most valuable thing analytics can tell you.
The process: define a set of candidate activation events (e.g., "created first project," "invited a team member," "ran first analysis"), then build retention cohorts in PostHog for each. Split users into those who completed the action within their first week and those who didn't. The action with the largest difference in 30-day retention between the two cohorts is your aha moment. Once you identify it, you reorganize onboarding to get users to that event as fast as possible. This is the most direct path from analytics setup to measurable retention improvement.
Key Takeaways
- PostHog replaces four tools (Mixpanel + FullStory + LaunchDarkly + Hotjar) with one platform and a generous 1M events/month free tier
- Mixpanel wins for teams with a dedicated product analytics team that needs advanced behavioral cohorts
- Custom database event tracking is sufficient for early-stage products under 1M events/month
- Instrument these five events at minimum: user_signed_up, onboarding_completed, first_core_action, plan_upgraded, and plan_cancelled
- Feature flags + analytics in the same tool (PostHog) allows correlating experiment variants with conversion metrics
Find boilerplates with analytics setup in our best open-source SaaS boilerplates guide.
See our guide to SaaS observability for the broader monitoring stack that analytics plugs into.
See how analytics connects to billing events in our SaaS billing models guide.
Check out this boilerplate
View PostHogon StarterPick →