Loading tutorials…
Loading tutorials…
PostHog is generous on the free tier but expensive when you outgrow it without realising. This walks through account setup, region choice (US vs EU), org structure, and the billing-cap settings that stop a runaway event from becoming a $4,000 surprise.
Who this is forFounders, product managers, and engineers spinning up PostHog for the first time. Especially relevant if you handle EU data, need SOC 2-grade isolation, or expect to scale past 1M events/month within 6 months — the choices you make on day one are hard to reverse.
What you'll need
Step 1
PostHog Cloud has two completely isolated regions: us.posthog.com and eu.posthog.com. Pick based on where your users live and your compliance posture — you cannot migrate later.
Open posthog.com → Get Started. Before signing up, decide on region: US Cloud (data in AWS us-east) or EU Cloud (data in AWS eu-central, Frankfurt).
Choose EU Cloud if: you have EU users and want simpler GDPR posture, you are pursuing SOC 2 / ISO 27001 with EU data-residency commitments, or your customers are likely to demand a DPA citing EU storage.
Choose US Cloud if: your users are primarily in the Americas, you do not have a GDPR data-residency requirement in customer contracts, or you want the marginally lower latency (most US apps).
The two clouds have completely separate accounts, projects, API keys, and pricing — they are effectively different products. There is no migration tool between them.
If you cannot decide, default to US Cloud and add a contract note that migration would require ~3 days of engineering. EU Cloud is the safer call for any B2B SaaS that might sell to the EU.
Step 2
Sign up with company email. PostHog creates an Organization (billing entity) and a Project (data container). One org can have many projects — use this for prod / staging separation.
Sign up at us.posthog.com or eu.posthog.com depending on your region choice. Use a company email — invite-flow and SSO work better with a verified domain.
On first login you create an Organization (e.g. "Acme Inc"). The org is the billing unit and the home for SSO config, team members, and audit logs.
PostHog auto-creates one Project (e.g. "Default Project"). Rename it to something explicit like "Acme — Production". Project Settings → General → Project name.
Create a second project called "Acme — Staging" or "Acme — Dev". One project = one data namespace. Mixing dev events with production events poisons your funnels and inflates the bill.
Note your Project API Key (Project Settings → Project Variables). This is the public key clients use; it is safe to ship in JS. The Personal API Key (under Account → Personal API Keys) is a secret and stays server-side.
Step 3
PostHog bills by event volume, recording minutes, feature flag requests, and survey responses. Set a hard cap on each in Billing → Subscriptions before installing the SDK.
Go to Organization Settings → Billing. You will see four metered products: Product analytics events, Session replays, Feature flag requests, and Surveys.
For each product, click "Set up billing limits". Set a soft alert (e.g. 80% of expected monthly volume) AND a hard cap (e.g. 150% of expected) that PAUSES ingestion.
Realistic starting caps for a small SaaS: 1M events ($0 free, then $0.00031/event after), 5,000 recording minutes ($0 free for first 5K, then $0.005/min), 1M flag requests, 250 survey responses.
The free tier is generous — 1M events + 5K recording mins + 1M flag requests per month forever. But a single buggy `posthog.capture` in a useEffect loop can blow past that in an hour. Hard caps protect you.
Save the caps. Then enable email alerts at 80% so you hear about the problem before the cap kicks in.
Step 4
PostHog has Member, Admin, and Owner roles at the org level, plus project-level access. Invite engineering and product as Members; marketing as Members with project-read; finance as Billing Admin only.
Organization Settings → Members → Invite member. Enter the email and pick a role: Member, Admin, or Owner.
Owner: full access including billing and deletion. Limit to 2 humans + a shared inbox.
Admin: can manage members, integrations, and projects but cannot delete the org. Engineering leads and product leads here.
Member: can use the product (build insights, run experiments, view replays). Default for ICs.
For non-technical users like sales / customer success, create a separate project with restricted data and invite them only to that project (Project Settings → Access control).
Enable SSO via SAML if you have an IdP. Organization Settings → Authentication → SAML. This is on the Teams add-on; if you are on the free tier, use Google OAuth.
Step 5
Default retention is 7 years for events and 30 days for recordings. Override per product if you handle health data, PII, or have GDPR commitments.
Project Settings → Data Management → Data retention. Default for event data is 7 years.
For GDPR / privacy-light products, drop to 1 year or 2 years. Most B2B analytics questions can be answered with 18 months of history.
Session replays: default is 30 days. The free tier maxes at 30 days. Paid plans allow up to 1 year — but recording minutes get expensive at that retention.
Set up PII suppression at the SDK level (covered in tutorial #2): never capture password fields, mask any element with class `ph-no-capture`, and use `respect_dnt: true` to honour Do Not Track headers.
If you handle health or financial data, also configure session-replay masking: Project Settings → Session Replay → Privacy → set all input fields to "Mask" by default.
Step 6
Slack alerts, Sentry error linking, and your data warehouse (BigQuery / Snowflake / S3) are best set up before real users land — they pay for themselves week one.
Project Settings → Integrations → Slack. Add a webhook for a #posthog-alerts channel. Use this for billing-cap alerts and experiment-significance pings.
If you use Sentry, install the Sentry integration. PostHog will auto-link Sentry errors to the matching session replay — invaluable for debugging.
Data Pipelines → Destinations → BigQuery (or Snowflake, Redshift, S3). PostHog can stream every event to your warehouse in near-realtime. Set this up on day one — backfills are painful.
If you use a CDP like Segment or RudderStack, you can either run them as the source-of-truth and forward to PostHog, or use PostHog as source and forward elsewhere. Pick one direction and document it.
Step 7
Before installing the SDK across the product, fire a single test event from the API to confirm the project is alive and the API key works.
Open a terminal. Run: `curl -X POST https://us.i.posthog.com/i/v0/e/ -H "Content-Type: application/json" -d '{"api_key":"phc_YOUR_KEY","event":"setup_test","distinct_id":"setup-validator","properties":{"source":"manual"}}'` (use eu.i.posthog.com for EU Cloud).
In PostHog → Activity → Live events, you should see the `setup_test` event appear within 30 seconds.
If it does not appear: check the API key (Project Settings → Project Variables → Project API key — starts with `phc_`), check the region (us vs eu), and check that you are not on the wrong project.
Once confirmed, move to tutorial #2 (Install PostHog tracking) for the real SDK install.
Common mistakes
Picking the wrong region for compliance reasons
What goes wrong: You signed up on US Cloud, then a year later landed an EU enterprise client who requires EU data residency in the DPA. You now need to migrate, which takes 3-5 days of engineering and breaks historical attribution. Cost: ~$3,000-5,000 in engineering time + lost data continuity.
How to avoid: Pick EU Cloud upfront if there is any chance you sell to EU enterprises. The latency penalty for US users is 50-80ms — almost never noticeable.
No billing cap, then a runaway capture loop
What goes wrong: A developer ships `posthog.capture` inside a useEffect with a bad dependency array. It fires on every render. By the time someone notices, you have ingested 40M events at $0.00031 = $12,400 in overage charges.
How to avoid: Set a hard cap (Billing → Set up billing limits → Pause ingestion) at 150% of expected volume BEFORE installing the SDK. PostHog will pause rather than charge you into the ground.
Mixing prod and staging in one project
What goes wrong: Dev events pollute production funnels. Your "checkout completion rate" reports 240% because QA runs the funnel 50 times a day. Real product decisions get made on garbage data.
How to avoid: Create one project per environment (prod / staging / dev). It is free — projects do not cost extra, only the events inside them do. Use a different `phc_` key per environment in your env vars.
Everyone is an Owner
What goes wrong: When the developer leaves and you offboard them, they accidentally still have Owner because no one tracks it. They could delete the org and wipe all your analytics history. (Real incident at a Series B in 2025 — took 6 weeks to restore from a warehouse mirror.)
How to avoid: Owner is for 2 people max (CEO + CTO, or founder + ops lead). Everyone else gets Admin or Member. Audit Members quarterly: Organization Settings → Members → sort by role.
Skipping PII masking on session replay
What goes wrong: You enable session replay before configuring masking. The next day a user types their credit card on a checkout page that is not flagged as PCI. The CC number is now in your PostHog recording, which triggers a PCI scope expansion and ~$8,000 of audit work.
How to avoid: BEFORE turning on session replay: Project Settings → Session Replay → Privacy → set "Mask all input fields" to true and add class `ph-no-capture` to any element with sensitive data. Then enable replay.
Recap
Done — what's next
How to install PostHog tracking across web, mobile, and server
Read the next tutorial
Hand it off
Account setup is the smallest part of getting PostHog right. Instrumentation, event-naming conventions, feature-flag hygiene, and experiment design are where teams burn the next 60 days. If you would rather hire someone who has set up PostHog for 50+ teams, EverestX matches you with a vetted analytics specialist in 48 hours, from $14-16/hr.
See specialist rates
There is no native migration tool. You export events via the API or BigQuery sync, recreate the project on EU Cloud, and replay the events with original timestamps. It works but breaks session-replay history (those cannot be replayed) and costs 2-4 days of engineering. Plan ahead.
For a sub-Seed startup with under 100K monthly active users, yes — the free tier (1M events + 5K recording minutes + 1M flag requests per month) is generous. Past Series A, you almost certainly upgrade to a paid plan to unlock SSO, longer retention, and higher caps.
PostHog is event-volume priced (~$0.00031 per event after free tier). Mixpanel is monthly-tracked-user priced ($0.28-$0.83 per MTU). For high-event-volume products (gaming, IoT) PostHog is much cheaper; for high-user-count-but-low-event products (B2C apps with passive users) Mixpanel can be cheaper. See tutorial #9 for the full breakdown.
No — Google OAuth is the easiest start for sub-10-person teams. SAML SSO (Teams add-on, +$0.20/seat/mo on top of the plan price) becomes worth it once you have 10+ users or any compliance commitment that requires SSO enforcement.
Project API Key (starts with `phc_`) is the public client key — ships in browser JS, used by SDKs to capture events. Safe to expose. Personal API Key is a secret tied to your user account — used for server-side queries, exports, and admin work. Never ships to the client.
PostHog
PostHog has a one-line install — and a hundred ways to get it wrong. This walks through web, Next.js App Router, React Native, and the server SDK (which you need for any event that can't be lost). With the autocapture gotchas that show up at month two.
PostHog
Most teams ship 50 events in week one, then spend month four rewriting them because the names made no sense in retrospect. This walks through an event taxonomy that scales, a property schema that does not drift, and the identify flow that keeps your funnel reports honest.
PostHog
Self-hosting PostHog looks cheaper on paper. It almost never is. This walks through the real cost math, the operational burden most teams underestimate, and the 3 scenarios where self-hosted actually wins.
PostHog
DIY PostHog is the right call up to a point. Then it isn't. This is the honest framework: when the cost of self-managing exceeds the cost of hiring, and how to tell which side you're on.