Skip to content

PostHog

Follow what people do in your app from signup to their first useful result. Define the events, build a funnel and check what identity and event limits change.

Visit PostHog

Which product events tell you whether people get started?

Track the point where a person gets a result they came for. For a booking app, send one event when the account is created and another when its first shareable booking page is published.

A click can be useful when you are investigating the page. For a publish event, send it only after the app saves the page and makes it available. A failed form or a refreshed confirmation screen should add no successful publish event.

In a PostHog funnel, put the two events in order and choose a time window such as seven days. Use the same event names and counting rules over time. If you mean one per business account and several people can work in that account, decide whether you need to count accounts instead of individual users.

How do you prove the funnel counts the right thing?

Run the same two steps yourself in a disposable project. Check the event list before reading a chart.

  1. Start with a test destination
    Confirm the test app and fake accounts connect only to a disposable PostHog project. The Cloud Free offer includes one project, so keep a production project separate from this exercise. Install the web library with the test project settings. Leave replay and automatic interaction tracking off for this check.
  2. Send the two events deliberately
    Create one fake account and publish one page after a failed attempt. Choose where each success event fires so the browser and the app server do not both send it. Refresh the page and verify it did not count another success.
  3. Read the Activity list and build the funnel
    Open the received events and inspect the time, account and properties. Verify the two successes appear in the right order for the fake user. Build a funnel with those two event names and check the expected user appears once at each step.

How does PostHog know which actions belong together?

The browser starts with an anonymous identifier. Your app can identify a signed-in person with a stable account value. PostHog can then associate earlier browser activity with that person when the earlier activity was collected under a compatible setup.

Use an app-generated value instead of an email address. Reset the browser’s identity when a person signs out. Try two fake accounts on one device and sign in on a second device. Check that the right activity stays together and one person does not inherit another person’s history.

A count of tracked identifiers is not automatically a count of people. A visitor using a different browser, blocking capture or clearing stored data can leave gaps or be counted separately. State which population your funnel covers before comparing it with a signup count in your own database.

What should you check before you enable more capture?

Start with the few events that answer your question. PostHog lets you control automatic clicks, page views and session replay separately. Turning off automatic clicks alone can leave page views on.

Set up the consent behavior you actually want and test it before enabling more data collection. Web capture can support an opt-out, but its cookieless configurations behave differently. If declined means send nothing, verify that across browser and server events instead of assuming a cookie setting stops every request.

For replay, verify what happens to typed text, private details printed on the page, and any console or network data you choose to collect. Keep collection off on a private route unless you can verify the result with test data. Keep a process to remove data from the project and any exports you control.

Which actions add to the PostHog Cloud bill?

Cloud meters analytics events and replay recordings separately. Usage from multiple projects shares the organization’s monthly allowance. A signup, three page views and two clicks can produce six events if you collect all of them.

If you send 1.2 million anonymous analytics events in one month on pay-as-you-go, the 200,000 beyond the free allowance would cost $10 USD at the first paid rate, before other products and taxes. A product billing limit can stop ingestion, which leaves a permanent gap in that history.

Cloud usage examples as of November 11, 2026
UnitIncluded each monthWhat happens beyond it
Analytics events1 million per organizationOn Free, extra events are dropped. On pay-as-you-go, the first paid tier for anonymous events is $0.00005 USD per event. Identified event processing can add a charge.
Replay recordings5,000 per organizationReplay has its own usage allowance and pricing. Leaving it off does not change the analytics event allowance.

On a small screen, scroll the table sideways to read every column.

How long can you keep events, and what can you export?

Cloud Free keeps event data for one year. New paid plans from November 5, 2026 default to two years. If you were already on a paid plan before that date, you keep seven years while you stay on your plan and package or upgrade the package. Switching to Free or a lower package moves you to the default for the new plan.

A batch export can send event rows and person mappings to a destination such as BigQuery or an S3 bucket. If you need the current identity mapping, export it separately. An event row remembers its fields from when it was received. The export does not rebuild your funnel rules and dashboards in the next tool.

Set up exports before events expire. Old events brought in from another service can expire based on when they happened, even if you just imported them. Check replay history separately because its retention differs from events. A self-hosted option moves updates, infrastructure, scaling and recovery to you. PostHog describes that deployment as self-managed and unsupported. Verify the export and definitions you need before switching.