If you're serious about product growth, you don't "add analytics later." You design the system that will decide what you build next before you ship the next feature. PostHog is the right backbone for that, because it bundles product analytics, feature flags, experiments, replays, surveys, and dashboards in one stack that developers actually like using.

Below is the opinionated setup we deploy for early-stage teams so AARRR (Acquisition, Activation, Retention, Revenue, Referral) is visible, testable, and directly connected to code.

Why PostHog Wins

Two reasons:

Decisions and delivery live in the same place. Feature flags back your A/B tests, so experiments flip on real code paths, not marketing simulacra. When you find a winner, you promote it. When you find a loser, you kill it. No redeploys, no theater.

First-party, developer-friendly plumbing. You can send events from servers or clients, route ingestion through your domain with a reverse proxy, and keep data residency in mind. This matters because client-side tracking keeps breaking and cookie rules keep shifting. Safari killed third-party cookies years ago. Chrome's been waffling. Either way, first-party wins.

The Must-Have Setup

Map AARRR to Events to Insights to Dashboard (Plus the Missing Pieces)

Start with a tiny, honest event schema that mirrors AARRR, but add two critical stages most teams miss:

Acquisition: session_started, landing_page_viewed, utm_* captured server-side where possible

Activation: Your crisp "aha" moment like created_first_project or invited_teammate

Habit: The repeated action that predicts retention: daily_active_3_days_straight, feature_used_5_times

Retention: weekly_active, feature_used, plus cohorts

Revenue: subscription_started, plan_upgraded

Referral: invite_sent, invite_accepted

Resurrection: user_returned_after_30_days, reactivation_email_clicked

In PostHog, wire these to Funnels, Retention, Paths, and Cohorts, then pin them to a single AARRR dashboard.

The power move: Create "goal chains," a sequence of saved insights that ladder up: Landing to Signup (Funnel) to Aha (Funnel) to Habit Formation (Trends) to Week-1 Retention (Retention) to Revenue (Trends) to Referral (Trends). One board, one story, one weekly review.

The advanced move: Run "Reverse Cohort Analysis." Look at your best customers and trace backward: what did they do differently in week 1? Build experiments to force new users down those exact paths.

Go Server-Side First (And Kill the Client SDK for Critical Flows)

Client-side events are increasingly lossy. ITP, blockers, storage limits. Server-side and first-party routing (reverse proxy on your subdomain) dramatically improves reliability and longevity.

The setup: Critical events: Send directly from your API/backend UI events: Route through e.yourdomain.com to PostHog Edge events: Capture at Cloudflare/Vercel edge, not just your server Result: 30-40% more data captured vs client-only

The extreme version: Every database write that matters should emit an event. State change equals event. Kill the client SDK entirely for critical flows. Every important event should be API-triggered.

Use Feature Flags as Everything (Not Just Features)

Flags aren't just on/off switches. They're your entire experimentation infrastructure AND your ops control plane:

Ship with a flag for any change that could move metrics (pricing walls, paywall copy, onboarding steps).

Flags as pricing levers: Every pricing variable should be a flag (trial length, included seats, feature limits).

Flags as ops tools: Rate limits, queue depths, cache TTLs, all flags.

Flag inheritance patterns: Parent flags that control child flags, enabling complex rollout strategies.

Target by cohort or group. Account-level flags ensure a whole company sees one variant.

Every A/B test gets backed by a flag. PostHog wires this by design.

Read results in Experiments and promote winners or kill losers without redeploys.

Build Reports That Guide Next Week's Sprint (Plus Anti-Metrics)

The minimum set to run the business:

Signup to Aha Funnel (by source, by device, by plan). Shows you where users drop and which channels actually convert.

W1/W4 Retention (cohort by acquisition channel and by "aha" speed). Tells you what sticks and what's just vanity traffic.

Feature Adoption (trends plus paths from "aha"). Reveals what activated users actually use vs what you think they use.

Revenue by Cohort (split by experiment variant). Shows which experiments actually move money.

Revenue per Experiment: Track total revenue impact of each experiment over time, not just conversion rates.

Referral Loop Health (invites sent/accepted per activated user). Measures if your viral mechanics work or just exist.

The Anti-Metrics Dashboard: What you're explicitly NOT optimizing for (support tickets, refunds, unsubscribes, rage clicks). Often more revealing than success metrics.

Save these as insights, pin to your AARRR dashboard, review weekly. No drift, no debate.

The Experiment Velocity Target

Most teams run 1-2 experiments per month. That's failure mode. You should be running 10+ experiments per week. Here's how:

Experiment Debt: Track how many decisions were made without experiments. This is debt, just like technical debt.

Compound Experiment Tracking: Most wins come from experiment chains (A enables B enables C). Track these sequences, not just individual tests.

Ghost Mode Experiments: Run experiments where the control group doesn't know they're in an experiment, but the treatment group is told they're getting "early access." Measures both the feature AND the psychology of exclusivity.

Session Recording plus Event Fusion: Every rage click in a recording should auto-generate an experiment to fix it.

The Implementation Checklist

Ingestion: Send key events server-side; proxy client SDKs via e.yourdomain.com; add edge worker instrumentation. Gets you reliability, first-party tracking, 30-40% better capture.

Schema: 10 to 15 events mapped to extended AARRR (including Habit and Resurrection). Less noise, faster insights.

Flags: Wrap risky changes; use for pricing, ops, and features; implement inheritance patterns. Safe rollouts plus clean experiments.

Experiments: 10+ per week minimum. Evidence beats arguments.

Dashboards: One AARRR board plus goal chains plus anti-metrics. Multiple stories the team can act on.

Who Owns This Loop?

Don't hand this to "whoever installed the snippet." You need a growth-minded product engineer who:

Designs event schemas and ships across the stack. Adds capture to APIs, edge workers, and databases, not just the front-end.

Wires feature flags for features, pricing, and ops with inheritance patterns.

Builds cohorts, funnels, and dashboards people actually use, including reverse cohort analysis.

Understands browser privacy realities and edge computing. Why first-party/server-side plus proxy plus edge beats tag soup.

Can ship 10+ experiments per week and track compound effects.

Internally, this person pairs with design/PM on activation targets, owns the weekly AARRR review, and opens the PRs to ship the next experiment. That's the point: analytics that can't change the product is theater.

Common Mistakes (And the Fix)

Too many events, no story. Start with extended AARRR and 10 to 15 events; expand only when a question demands it.

Client-only instrumentation. Move critical events server-side; proxy the rest; add edge capture.

Flags without experiments. Standardize: flag to experiment to promote/kill. Track experiment velocity.

Dashboards that drift. One AARRR board reviewed weekly; archive stale insights; add anti-metrics.

Analytics as afterthought. Instrument before you ship, not after you've lost the data.

Slow experiment velocity. If you're not running 10+ experiments weekly, you're leaving growth on the table.

Why This Matters Now

The tracking landscape shifted permanently. Safari blocked third-party cookies by default years ago. Chrome's been in flux. Ad blockers are mainstream. Privacy regulations multiply.

The stable strategy: first-party, server-side analytics plus edge capture plus controllable flags/experiments in one place. PostHog gives you exactly that. No enterprise theater. No tag manager soup.

But more importantly: the companies that win aren't the ones with the best product. They're the ones with the fastest learning rate. And learning rate equals experiment velocity times insight quality. This setup maximizes both.

Quick Start Resources

Core Setup: Product OS overview: Everything in one place Capture API and server-side: Send events from any backend Reverse proxy setup: Your domain to PostHog Edge worker examples: Cloudflare/Vercel capture patterns

Growth Infrastructure: Feature flags: Rollout controls, pricing levers, ops tools Experiments: Every test backed by a flag, 10+ per week Insights: Funnels, Retention, Paths, Reverse Cohorts AARRR primer: Extended Pirate Metrics and dashboard templates

Work with withSeismic

This is exactly what I build in a 6-week Growth Engineering Sprint: Extended AARRR event schema, server-side capture plus proxy plus edge, flags/experiments wired to real code, anti-metrics dashboards, and 10+ experiments per week velocity. Then we iterate on activation, retention, and revenue with evidence.

withSeismic (Doug Silkstone). Code shipped. Decisions instrumented. Growth on purpose.