PostHog Step-by-Step: Events, Funnels, Session Replays & Flags
PostHog combines product analytics, funnels, session replays, feature flags and A/B tests in one tool. This tutorial walks you from setup to your first funnel.

👁 114 reads
PostHog is a suite of tools for understanding your app users: event analytics, funnels, session replays, feature flags and A/B tests in one place. This tutorial takes you from installation to your first funnel and first flag, following PostHog’s official documentation.
Before you start: write down your questions
PostHog collects a lot of data right after installation and it’s easy to drown in it. Before you install, write down three questions you want answered, for example: how many new users complete registration, which feature is used most often, where people abandon checkout. For each question, note the events you’ll need. These will become your first custom events.
Also agree on an event naming convention with your team, because it’s hard to change later without breaking your charts.
Step 1: Installation
The fastest route according to the documentation is a wizard you run in your project directory with a single npx command. It also works with AI assistants like Cursor. The alternative is a code snippet you paste into your page, in the head section, with your project key and server address, or a library installed via npm.
The documentation also recommends a reverse proxy, which reduces the risk of ad blockers intercepting events. PostHog provides one free for cloud users.
Step 2: Events collect automatically
After installation, automatic collection is enabled by default: page views, clicks, form submissions and session data. You don’t need to configure anything to see your first data. You send custom events, like “registration completed”, with a single line of code containing the event name and its properties.
Step 3: Your first funnel
A funnel shows how many people move through successive steps and where they drop off. In the menu you go to Insights, from the list next to the new chart button you select funnel. You start with the first event, add intermediate steps and end with an event marking success. Example: landing on registration page, filling out form, confirming email.
Your first funnel usually immediately shows the step where you lose the most people. That’s where you should look at session replays.
Step 4: Session replays
You enable session replays with a few lines of configuration. They record clicks, scrolling, typing and navigation between pages. You filter replays, for example by frustrated repeated clicks, JavaScript errors, custom events or feature flag variants. The fullest support is on websites; mobile apps have some limitations.
Step 5: Feature flags
A flag lets you enable a new feature for only some users. You create it in the PostHog panel, and in your code you check whether it’s enabled for a given person. The documentation recommends gradual rollout, starting with 5 to 10 percent of users and increasing the share when everything works. For testing you can enable the flag for your own email address.
Step 6: Experiments
You create an A/B test in the experiments section. The wizard has three steps: description with hypothesis and flag key, variants with percentage split, and metrics, for example conversion from a funnel. In your code you check the flag variant, and PostHog automatically collects data and calculates the result.
Example: why people don’t complete registration
You install PostHog with the wizard, wait a day for data and build a registration funnel. The funnel shows that half the people drop off at email confirmation. You filter session replays of people who dropped off, and you see they return to the form because they don’t know where to look for the email. You add a message behind a flag for half your users and after a week you compare results in an experiment.
In this example the sequence matters: first numbers from the funnel, then replays, finally the change. If the team had started with a change based on intuition, for example redesigning the form, they might have improved a step that wasn’t the problem at all. The funnel pointed to the place, replays explained the cause, and the experiment checked whether the fix works. Each of these three steps takes little time, but together they turn guessing into knowledge.
Common mistakes
- No custom events for the most important actions.
- Releasing features to everyone at once instead of gradually.
- Replays without filters, so you lose hours in them.
How to evaluate your first week
After a week, check whether you have an answer to at least one of your three questions. If yes, move on to session replays of people from the problematic step. If not, you’re usually missing an event or it’s named incorrectly.
Also check whether the data matches reality. For example, compare the number of registrations in PostHog with the number of accounts in your database. A large difference is usually ad blockers, and the reverse proxy described in the documentation helps with that.
If you have a small app and little traffic, don’t draw conclusions from a few days of data. A funnel with twenty people can show random differences. Better to wait a few weeks or focus on session replays, which even with low traffic show specific problems.
More on this from QUANTSLANT
guides·Railway Step-by-Step: Deploy from GitHub with DatabaseRailway deploys your GitHub repository in minutes: point to your project, Railway builds and runs it, and you add a database with one click.

