PostHog Tutorial: Complete Beginner's Guide (2026)

The Gap Between Installed and Useful

Every PostHog tutorial starts the same way: create an account, paste the snippet, watch events flow in.

And every PostHog implementation ends the same way: a product team staring at a dashboard full of pageviews and clicks, wondering why the numbers don't help them make a single decision.

The installation is not the implementation.

This is the gap that kills analytics initiatives.

PostHog gives you a powerful platform. Autocapture tracks every pageview, click, and form submission automatically.

Session replay records user sessions. Feature flags let you control rollout.

But the moment you ask a question like "how many enterprise customers completed activation this quarter?" or "what's the correlation between first-week feature usage and 90-day retention?", autocapture falls apart.

You need custom events. You need designed properties. You need a taxonomy that answers business questions, not just technical ones.

Over 90% of PostHog companies stay on the free tier.

The reason isn't generosity — it's that most implementations never generate enough signal to justify upgrading.

They installed the tool. They looked at the data. They didn't find what they needed. They moved on.

This guide covers the full implementation — from account creation to your first business decision.

The 5-minute installation is step one. The 2–4 weeks after that is where the actual work happens.

The PostHog Implementation Framework

The path from installation to insight follows five stages.

Each builds on the previous. Skipping stages is the second most common implementation mistake (after stopping at autocapture).

Stage 1: Install and Configure the SDK

Go to posthog.com and create an account. You can sign up with Google, GitHub, or email.

PostHog offers both cloud-hosted and self-hosted options — start with cloud unless you have specific compliance requirements.

Once created, you'll receive a JavaScript snippet with your project API key and instance address.

Drop it into your application head:

posthog.init('<ph_project_api_key>', { api_host: '<ph_instance_address>', autocapture: true })

That one line initializes the SDK with autocapture enabled.

You're now collecting pageviews, clicks on every element (with CSS selectors and text content), and form submissions automatically.

PostHog's tutorials cover how to capture and filter events, track pageviews in single-page apps, create actions using CSS selectors, and track common metrics out of the box. These are worth bookmarking.

What autocapture misses:

• Business-specific events like "subscription_created," "feature_activated," or "report_generated"
• Properties on events that answer follow-up questions — plan type, user role, feature category
• Server-side events — emails sent, payments processed, API calls made

This is why autocapture is a starting point, not a strategy.

It gives you a baseline. To answer business questions, you need custom events.

The insight: Installation is not implementation. The snippet gets you data. The custom events get you answers.

Stage 2: Design Your Event Taxonomy

This is the most consequential step in your PostHog setup.

Get it wrong, and you'll spend weeks re-instrumenting later. There are three decisions to make:

Naming Convention

Pick a convention and commit to it. We recommend snake_case with verb-noun structure:

• signup_completed — clear, consistent
• subscription_created — business event, not technical
• report_generated — action-based
• pricing_cta_clicked — specific, no ambiguity

Avoid:

• Inconsistent casing like SignUp
• Verb-noun inversion like ClickedPricingButton
• Version numbers like click_pricing_btn_v2 — these create maintenance nightmares

The Entity Model Decision

PostHog tracks four entity types:

• Persons — individual users, identified by email or user ID
• Groups — organizations, workspaces, teams, accounts
• Sessions — individual browsing sessions
• Cohorts — dynamically updating user segments

The critical decision is person-level vs. group-level tracking.

If your product is team-based (Slack, Notion, Figma), group-level tracking is essential.

If your product is individual-based (personal finance, solo tools), person-level tracking is sufficient.

This decision cannot be easily undone.

If you track everything by person and later need to answer "how many teams completed activation," you'll need to re-instrument.

Think about the questions you'll ask in 12 months and design for those.

Event Property Design

Every event should have properties that answer follow-up questions:

posthog.capture('subscription_created', { plan: 'pro', billing_cycle: 'annual', price: 99, previous_plan: 'starter', change_type: 'upgrade' })

Without these properties, the event tells you that a subscription changed but not what changed, how much, or from where.

Properties are where event data becomes useful.

The insight: The entity model decision can't be easily undone. Design for the questions you'll ask in 12 months, not just the questions you're asking today.

Stage 3: Instrument Custom Events

Once you have your taxonomy, instrument the events that matter.

Start with these five categories:

1. The Activation Event

The single action that predicts 90-day retention.

This is different for every product:

• For Slack: a team sends 2,000 messages
• For Stripe: processes their first $100
• For your product: find it by analyzing retained vs. churned users

Find your activation event by correlating early behaviors with long-term outcomes.

Look at users who stayed active at 90 days and users who churned.

What did the retained users do in their first week?

posthog.capture('activation_completed', { activation_metric: 'first_report_sent', time_to_activation: 144, user_role: 'admin' })

2. Feature Adoption Events

Track when users try each core feature for the first time:

posthog.capture('feature_first_used', { feature_name: 'export_report', feature_category: 'reporting', user_plan: 'pro' })

3. Revenue Events

Track subscription changes, not just payments:

posthog.capture('subscription_created', { plan: 'pro', billing_cycle: 'annual', mrr: 99, change_type: 'new' })

posthog.capture('subscription_cancelled', { plan: 'pro', mrr_lost: 99, cancellation_reason: 'too_expensive', tenure_days: 180 })

4. Error Events

Track when things go wrong:

posthog.capture('feature_error', { feature_name: 'export_report', error_type: 'timeout', user_plan: 'free', retry_count: 2 })

5. Support Events

Track when users ask for help:

posthog.capture('support_ticket_created', { category: 'billing', priority: 'high', user_plan: 'pro' })

The insight: The activation event is the single most important event to instrument. Everything else is secondary to knowing whether users reach the value that predicts retention.

Stage 4: Build Your Dashboard Architecture

PostHog provides framework guides for Android, Angular, Astro, Bubble, Carrd, and more — plus embedded analytics and data visualization options.

Use them as starting points, not destinations.

We recommend four core dashboards:

Building a dashboard in PostHog:

• Click Dashboards in the left nav
• Click New Dashboard
• Click Add graph
• Select the insight type — trends, funnels, retention, paths
• Select your events and filters
• Save to the dashboard

The most common dashboard mistake: building dashboards that answer "how many" questions instead of "why" questions.

"How many people signed up this week?" is a vanity metric.

"How many people who signed up this week completed activation, and how does that vary by signup source?" is a decision metric.

The insight: Every dashboard should enable a decision. If you can't name the decision a dashboard enables, redesign it.

Stage 5: Turn On Session Replay

Session replay shows you what users actually did in your product.

It's the qualitative complement to quantitative analytics.

Where dashboards show you patterns, replays show you the specific sessions behind those patterns.

Session replay is enabled by default when you install the PostHog SDK.

You can configure masking for privacy:

posthog.init('<api_key>', { session_recording: { maskAllInputs: true, maskInputOptions: { password: true } } })

The key to using session replay effectively: never watch random sessions.

Watch sessions of users who exhibited specific behaviors:

• Dropped off at step 3 of onboarding
• Hit a billing error
• Used a feature for the first time

Look for patterns: rage clicks (repeated clicks on non-responsive elements), confusion points (cursor movement suggesting uncertainty), broken flows (navigation that leads nowhere).

The insight: Session replay without a specific question is entertainment. Session replay filtered by behavior is research.

The Numbers Behind PostHog Implementations

The gap between installation and useful analytics is measurable.

Teams that follow the framework above report different outcomes than teams that stop at autocapture.

The difference is in the questions they can answer.

PostHog combines product analytics, session replay, feature flags, A/B testing, and surveys in a single platform.

This is structurally different from tools like Mixpanel or Amplitude, which focus primarily on event analytics.

The consolidation matters because it removes the context-switching tax between understanding what happened (analytics) and seeing how it happened (replay) or testing why it happened (experiments).

"An engineer's job is not to build what the product manager asks for. An engineer's job is to deeply understand the problem the product manager is trying to solve, and then build a solution that addresses it."

— PostHog Newsletter, An Engineer's Guide to Product Management

The free tier is substantial.

It includes 1M events, 5,000 session replays, and 1M feature flag requests per month.

For most early-stage products, this is enough to run a full analytics implementation.

$50K in startup credits is available for qualifying companies — enough to cover analytics through Series A without cost concerns.

The startup credits are worth applying for.

They remove price as a constraint during the critical first 12–18 months when you're figuring out your event taxonomy and building your dashboard architecture.

You want to be evaluating whether PostHog works for your product, not whether you can afford the next tier.

The timeline is consistent across product types.

B2B SaaS, B2C apps, developer tools — the stages are the same.

The variance is in how long each stage takes, which depends on engineering bandwidth and how well-defined the product is.

What to Do Instead

The most common PostHog implementation failure is starting without a plan.

Teams create an account, install the SDK, watch autocapture data flow in, and then spend months wondering why the numbers don't help them make decisions.

The fix is not better dashboards. The fix is better events.

Here is what to do instead of the default path:

Design before you instrument.

Spend a week mapping the questions you need to answer before writing a single line of event code.

What are the top 10 product decisions you need data to make?

Work backward from those decisions to the events and properties you need.

This is slower upfront and much faster overall.

Start with one dashboard, not four.

Teams that try to build all four dashboards at once end up with four partially-useful dashboards.

Pick the one that answers your most urgent question.

Build it well.

Add the second one when the first one is producing decisions.

The dashboards should evolve with your understanding.

QA before you trust.

Before you make a single decision based on PostHog data, run a QA pass.

Are events firing when they should?

Are they NOT firing when they shouldn't?

Are properties populated correctly?

Are person and group properties merging correctly?

Bad data leads to bad decisions, and bad decisions are expensive.

Connect session replay to your analytics.

Session replay and event analytics are complements, not substitutes.

Use funnels to identify where users are dropping off.

Use session replay to understand why.

This is the loop that produces insight — the quantitative identifies the problem, the qualitative explains it.

The alternative to the default path is simple: treat PostHog implementation as a product decision process, not a technical setup process.

The questions come first. The instrumentation comes second.