Choose the first useful result before choosing events
An account registration proves that somebody registered. It does not prove that the person experienced the product's value. PostHog's activation guidance makes this distinction and recommends identifying the behavior that represents a meaningful result for your product.
For an illustrative approval app, creating a workspace is preparation; sending a real request and receiving an approval is closer to the promise. Start with first approval completed as a candidate activation event. Treat it as a hypothesis to review against actual customer behavior, rather than borrowing another business's definition of an activated user.
Decide whether you are measuring people or customer workspaces. One manager sending a request and a colleague approving it is a team outcome involving two people. A funnel defined around one person's events may not answer that team-level question without a deliberate measurement design.
Write a small event contract
For each essential step, specify its name, trigger, responsible system, and minimal properties. Send a success event when the underlying operation succeeds. A button click and a saved request deserve different names because one can happen without the other.
Keep sensitive document contents out of event properties. An internal workspace identifier and a broad request type can answer the workflow question without copying the approval text into analytics. Give somebody responsibility for changing event definitions so a renamed event does not silently split one reporting period into two incompatible measures.
| Event | Trigger | What it establishes |
|---|---|---|
| Account created | Account creation succeeds | A person has registered |
| Request saved | The backend stores the request | A request exists |
| Request sent | The product completes its send operation | The workflow has progressed beyond a draft |
| Approval completed | An authorized approval is stored | The proposed customer outcome occurred |
Check identity before interpreting the chart
PostHog documents anonymous identifiers and identifying a person with a stable distinct ID. Choose an application user identifier that remains consistent across the relevant client and server events. Its guidance also recommends resetting identity on logout, so later activity on a shared device is not attributed to the previous user.
Walk through the flow with two test accounts. Check which person owns each event and whether signing in changes the reporting identity as intended. If a server emits Request saved for one identifier while the browser emits Request sent for another, an apparent funnel drop may be an instrumentation gap rather than an abandoned task.
Build the funnel around required steps
In PostHog, create a funnel insight and add the events that represent the required sequence. Its documentation recommends starting simply and avoiding optional steps. Set the filters and conversion window to match the question, then save those choices with the report so future comparisons use the same definition.
For a one-person task, a fictional example with 100 starters, 60 saved requests, and 18 completed outcomes has 18% overall conversion. The final step converts 30% of the 60 people at the previous step. PostHog distinguishes overall conversion from conversion relative to the previous step; these two percentages describe different denominators.
Validate missing and repeated actions
Run a complete task, an abandoned task, and a repeated action with synthetic data. Confirm that refreshing the success screen does not produce another backend completion event. Exclude or identify your own test activity before reviewing customer behavior.
Give recent starters enough time to complete the selected window before comparing them with older cohorts. Record the sample size alongside a rate. An illustrative change from one completion out of four starters to two out of four is too little evidence to declare that a redesign doubled the product's effectiveness.
Use the report to choose one investigation
When a step has fewer completions, examine the relevant flow and speak with suitable users before prescribing a feature. A missing permission, confusing request form, or broken notification could produce similar funnel shapes. The chart helps locate a question; it does not establish its cause.
PostHog is worth evaluating when event-level product questions justify the instrumentation and maintenance. Begin with a report somebody will review and an action they can take from it. Broaden collection after that report is trustworthy, rather than treating a large event catalog as evidence of better measurement.
Sources and editorial method
Official sources linked in this guide were checked on October 27, 2026. Features, interfaces, and commercial limits can change. The examples are proposed workflows and illustrative calculations, not customer results or a hands-on product benchmark. Confirm the current documentation before implementing the workflow.