Product Analytics in 2026: PostHog, Amplitude, and What Teams Actually Track

Most analytics setups fail not because the tool is wrong but because the event taxonomy is wrong. Teams fire 200 events in the first month with inconsistent naming, then spend six months fighting the data instead of learning from it.

This is a guide to product analytics in 2026 — which tools make sense for which teams, how to structure events so future-you doesn’t curse present-you, and what to actually measure in a SaaS product.

The Current Landscape

Three tools dominate for SaaS products in the mid-market:

PostHog is the open-source option. Self-host it on your own infrastructure or use their cloud. The self-hosted path gives you full data ownership and no per-event costs; the cloud tier is generous for smaller products. PostHog bundles session replay, feature flags, A/B testing, and a data warehouse connector into a single platform.

Amplitude is the established enterprise player. Strong funnel analysis, cohort retention curves, and a polished UI. More expensive per-event than PostHog cloud, but the analysis tools are deeper. Typical for Series A and beyond when someone on the team has used it before.

Mixpanel sits between them. Better than Amplitude on price at lower volumes, less full-featured than PostHog at self-hosting. The free tier is useful for early-stage products.

Tool	Self-host	Free tier	$0.0003/event starts at
PostHog	Yes (Docker, k8s)	1M events/mo	Cloud: 1M+ events
Amplitude	No	10M events/mo	Paid plan only
Mixpanel	No	20M events/mo	Growth plan

Note: pricing changes frequently. Verify current numbers on each tool’s pricing page before committing.

PostHog for Self-Hosting Teams

If you have a privacy-conscious customer base, operate in a regulated industry, or simply want to avoid per-event cloud costs at scale, PostHog self-hosted is worth the setup.

The minimal deployment runs on a single VM (DigitalOcean $24/month droplet handles moderate traffic):

# One-line install on Ubuntu/Debian
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/posthog/posthog/HEAD/bin/deploy-hobby)"

For production, use the Helm chart on Kubernetes with separate ClickHouse and PostgreSQL instances. PostHog’s data volume grows fast — 1 million events per day is manageable on a $100/month setup; 100 million events per day needs real ClickHouse cluster sizing.

Integration in a TypeScript app:

// lib/analytics.ts
import PostHog from 'posthog-js'

export const analytics = PostHog.init(process.env.NEXT_PUBLIC_POSTHOG_KEY!, {
  api_host: process.env.NEXT_PUBLIC_POSTHOG_HOST ?? 'https://app.posthog.com',
  capture_pageview: false, // Handle manually for SPAs
  capture_pageleave: true,
  loaded: (ph) => {
    if (process.env.NODE_ENV === 'development') ph.opt_out_capturing()
  },
})

// Type-safe wrapper
export function track(event: string, properties?: Record<string, unknown>) {
  analytics?.capture(event, properties)
}

export function identify(userId: string, traits?: Record<string, unknown>) {
  analytics?.identify(userId, traits)
}

For Next.js server-side events (API routes, background jobs), use the Node.js client:

import { PostHog } from 'posthog-node'

const posthog = new PostHog(process.env.POSTHOG_KEY!, {
  host: process.env.POSTHOG_HOST,
})

// In an API route
await posthog.capture({
  distinctId: userId,
  event: 'subscription_upgraded',
  properties: {
    from_plan: 'free',
    to_plan: 'pro',
    mrr_change: 49,
  },
})

Event Naming That Ages Well

The most common mistake: event names that describe UI actions rather than user intents.

Bad:

button_clicked
modal_opened
form_submitted

Better:

subscription_upgrade_started
subscription_upgrade_completed
feature_first_used
onboarding_step_completed

Name events after what the user accomplished, not what UI element they touched. When you redesign the UI in 18 months, you won’t need to rename the events.

A naming convention that works at scale:

<object>_<action>

Where object is the thing being acted on and action is past tense:

project_created
project_deleted
member_invited
member_removed
payment_failed
export_completed

Avoid compound nouns that are hard to scan. user_settings_billing_plan_upgrade_clicked is too long. subscription_upgraded is enough.

What Properties to Attach

Every event should carry the minimum context needed to answer future questions you haven’t thought of yet.

Core properties to include on all events:

// Attach these automatically in your analytics wrapper
{
  user_id: string           // Your internal user ID
  organization_id: string   // For B2B: which org the user belongs to
  plan: string              // 'free' | 'pro' | 'enterprise'
  environment: string       // 'production' | 'staging'
  app_version: string       // Your deploy version
}

Skip generic browser properties — PostHog captures those automatically. Focus on product-specific context.

For B2B products, also identify at the organization level:

analytics?.group('company', organizationId, {
  name: org.name,
  industry: org.industry,
  employee_count: org.employeeCount,
  plan: org.currentPlan,
})

This lets you answer “what percentage of enterprise companies used feature X in the last 30 days” without counting individual users from large orgs.

The Events That Actually Matter

Most products need fewer than 30 events to answer the questions that drive decisions. The trap is instrumentation sprawl — tracking everything and analyzing nothing.

For a typical SaaS product, start with:

Acquisition funnel

• signup_started — visited the signup page
• signup_completed — created an account
• email_verified

Activation funnel (reaching the “aha moment”)

• onboarding_step_completed + step_name property
• first_<core_action> — whatever the core action is in your product
• onboarding_completed

Engagement

• <core_action>_completed — your product’s key value event
• feature_discovered — first use of secondary features
• session_started

Revenue

• trial_started
• subscription_upgraded
• subscription_canceled + cancellation_reason
• payment_failed

Retention signals

• login is an okay proxy, but returning to do the core action is better

This gives you sign-up to activation conversion, activation to trial, trial to paid, and churn analysis — which covers most product decisions.

Querying Retention in PostHog

The retention view in PostHog shows the percentage of users who return to do an action after doing it initially. This is the clearest signal of whether your product has genuine value.

A working retention configuration for most SaaS products:

• Initial event: onboarding_completed
• Return event: <core_action>_completed
• Period: weekly

If week-1 retention is under 30%, the activation funnel is the priority. If week-4 retention is under 20%, the product itself isn’t retaining value. Knowing which problem you have tells you where to focus.

GDPR and Privacy Compliance

Self-hosted PostHog keeps all event data on your own infrastructure — no third-party data transfer to worry about. For cloud PostHog and Amplitude/Mixpanel, you need to address data processing agreements and user consent.

The practical minimum:

• Display a cookie/tracking consent banner before initializing analytics
• Respect opt-out signals
• Include your analytics provider in your privacy policy
• For EU users, ensure data is stored in EU regions if you use cloud providers

PostHog cloud has EU hosting available. Amplitude has EU data residency on paid plans.

// Only initialize analytics after consent
if (hasAnalyticsConsent()) {
  track('page_viewed', { path: window.location.pathname })
}

What PostHog Does That Amplitude Doesn’t

PostHog’s feature flags are genuinely good. You can run A/B tests, gradual rollouts, and target flags by user properties — all from the same tool that shows you the event data.

const flagEnabled = await posthog.isFeatureEnabled(
  'new-onboarding-flow',
  userId
)

if (flagEnabled) {
  // Show new flow
}

And after rollout, you can query exactly how the variant affected activation rates in the same interface. With Amplitude, you’d need a separate A/B testing tool and manual analysis to connect them.

A Concrete Recommendation

For a product under $1M ARR with a small team: PostHog cloud. The free tier is enough to get started, the feature flags and session replay are included, and you can self-host later if you outgrow it.

For a product with a privacy-first customer base or in healthcare/finance: PostHog self-hosted from day one.

For a growth team that has used Amplitude before and needs to move fast: Amplitude. The analysis tools are better for non-developers on the team.

The event naming and instrumentation patterns above apply regardless of which tool you pick. Get those right first.