
PostHog: Product Analytics for Small Teams
PostHog brings product analytics, session recordings, heatmaps, and feature flags together. What it includes, its monthly free allowance, and when to self-host.
What does it include?
The official repository README lists its main areas (GitHub: PostHog/posthog):
- Analytics: product analytics, web analytics, and group analytics.
- Replay: session replay, heatmaps, and a feature called Replay Vision.
- Observability: error tracking, logs, and tracing.
- Ship and iterate: feature flags, experiments, and early access features in beta.
- Talk to users: surveys, support, and workflows.
- Data: a warehouse, data pipelines, and endpoints.
- AI and agents: AI observability, MCP analytics (beta), and its own assistant, PostHog AI.
For a designer, the most useful pieces are recordings, heatmaps, surveys, and experiments. The observability and data areas are more engineering-oriented, but it helps to know they exist, because a technical error is also an experience problem.
Before you install it, decide who will have access to the recordings and event data. On a small team it is tempting to give everyone access, but recordings can show information about real people, so limit access to those who actually need it and review the privacy settings before you start recording (see “How do you protect privacy in recordings?” below).
How much does it cost?
The official pricing page shows that every month the first 1,000,000 product analytics events, 5,000 session recordings, 1,000,000 feature flag and experiment requests, 1,500 survey responses, 100,000 exceptions, 10 GB of logs, and 1,000,000 rows from data sources are free. The repository README publishes the same figures. Billing is usage-based: the paid plan has a $0 monthly base and you pay only for usage above each free tier, with no per-seat charges. The free plan needs no credit card, includes 1 project and 1 year of data retention, and has community support; the paid plan raises that to 6 projects, 2 years of retention, and email support (PostHog: Pricing).
Plans change often, and several third-party sites publish rates that do not agree with each other. Before you budget, check the pricing page and estimate your real event volume.
When does self-hosting make sense?
The README offers an open-source deployment that runs with one command on Linux using Docker. It also says that such deployments “should scale to approximately 100k events per month,” after which migrating to the cloud is recommended. It adds that the project does not provide customer support or guarantees for open-source deployments.
Self-hosting makes sense if your organization needs the data to stay inside its own infrastructure and has someone who can maintain the service. For a designer who wants to test a hypothesis this week, the cloud is more practical.
How does it fit a UX process?
PostHog lets you close the loop: observe, ask, and test. Each step has a concrete feature:
- Observe with funnels. A funnel shows how many people complete each step of a flow and where they drop off. Relative conversion between steps shows which ones have the most room for improvement, and you can open the list of people who completed or dropped off at a step.
- Watch the recordings. From a data point in a funnel you can open the list of people and, where available, watch their recording. You can also filter the Replay page by date, events, properties, or feature flags.
- Ask with surveys. A short survey to the people who left explains what the numbers do not.
- Test with experiments. Every experiment is backed by a feature flag that randomizes people into variants and records their exposure, and it computes results with Bayesian or frequentist statistics. Each variant links to the recordings of the people who saw it.
Many teams do that journey with four different tools.
It does not replace research with people. An experiment tells you what changed; an interview tells you why. Before you trust a result, review research bias, because a badly designed A/B test can give a very confident and wrong answer.
How do you protect privacy in recordings?
PostHog’s documentation describes three controls worth checking before you record:
- Input fields: masked by default. You can adjust which types are hidden with
maskInputOptions, or turn masking off withmaskAllInputs, which you should only do if you are sure. - Page text: not masked by default. With
maskTextSelectoryou choose which elements to hide, and"*"hides all text that is not an input field. - Specific elements: if you add the
ph-no-captureclass, they do not appear in the recording (they play back as a block of the same size) and they do not generate autocapture events.
Recordings can also capture network requests and responses, which may contain sensitive data. PostHog scrubs some headers automatically, and you can hide more with maskCapturedNetworkRequestFn. The fact that text is not masked by default is the point that surprises people most: if your product shows personal data on screen, review this before you turn recordings on.
When should you NOT use it?
- If you only need free recordings and heatmaps, Microsoft Clarity covers that role with less setup. Its documentation says it is free forever with no traffic limits.
- If your team has no clear metric to move, five dashboards will not help. Start with the decision you want to make.
- If the product handles sensitive data and you have no process for masking it in recordings, turn on protection before you install the script, not after.
- If nobody reviews experiments, feature flags pile up and the code becomes hard to read.
Illustrative example
Illustrative example: a medical appointment app has a low confirmation rate at the time-slot step. The team checks event analytics and sees that half the people who reach that step go back to the previous screen. They watch three recordings of those sessions and notice the time picker is hard to use on small phones. They send a short survey to the people who went back. Then they test a list picker, behind a feature flag, with half the users. The variant wins on confirmations, but the survey reveals that some people expected to see the full date. The team fixes that before rolling the variant out to 100%.
If you need to organize how you will test that hypothesis, a research plan with clear questions keeps the experiment from becoming a list of metrics without direction.
Common mistakes
- Installing the tool without defining which event means success.
- Trusting an experiment with a small sample and checking the result too early.
- Accumulating feature flags that are never removed.
- Measuring clicks without asking why they happen.
- Forgetting that analytics also involves personal information, and checking what gets sent.
What you can do tomorrow
- Define one event that means a person completed your product’s main task.
- Check whether the event volume you generate fits the free allowance, with the pricing page open.
- Create a feature flag for a small test and set a date to decide whether to keep it or delete it.