PostHog is one of the Data Sources cards on https://lengrowth.com/integrations. As with the other company-bound sources in LenGrowth, the user has to choose a company workspace before the connection can be attached. If no company exists yet, the page asks the user to create one first. That company-first pattern is consistent across the integrations page and keeps the product’s source data aligned with a specific business profile.

The backend usage metadata describes PostHog as activation, retention, and product-behavior signals from the connected project. It says the source is used in founder reporting activation and retention sections and in existing recommendation and task evidence for onboarding and retention issues. The metadata also says it extends the current reporting and recommendation system first. In other words, PostHog is used as product analytics context inside LenGrowth rather than as a separate analytics product.

The setup form on the integrations page is more detailed than the Google-based sources. It includes fields for Project ID, Personal API key, Host, Signup event, Activation event, and Retention event. That tells the user exactly what LenGrowth expects: not just a project credential, but also the event names the company considers important. The frontend API posts those values to /integrations/posthog/connect. Because the product asks for explicit event names, the setup is only useful if the team has already agreed on the exact PostHog events to treat as signup, activation, and retention.

Before connecting, the backend guidance says to use a PostHog admin who can view the target project and its event naming conventions. It also says to decide which signup, activation, and retention events LenGrowth should track before connecting. That is a good rule because the integration is only as useful as the event mapping behind it. If the wrong event names are entered, the source may technically connect but the reporting and recommendation logic will not have the right behavioral signals.

The backend guidance also tells the user where to find the information: open the target project settings to copy the project ID and personal API key, then review the Events screen or data management docs to confirm the exact event names. The Host field matters too, because the backend expects the company to point at the correct PostHog instance. The page gives the user the chance to supply all of those values directly rather than hiding them behind a generic connect button.

Once connected, the integrations page can show the selected project and the sync state. The metadata says the connection unlocks activation and retention signals in founder reporting and helps product-led execution tasks move out of waiting once LenGrowth can sync the right document stream. That is the main reason to use the source. It gives LenGrowth behavioral data that can help explain onboarding friction, retention problems, or activation gaps in a grounded way.

The route structure is /integrations/posthog/connect for setup, /integrations/posthog for connection state, and the same base route for disconnect. That confirms the source is treated as a standard company-linked integration. The app is not using a special PostHog dashboard route or a separate analytics area. It is using the connected project as one more real source inside the normal reporting and recommendation architecture.

If setup fails, the backend guidance says to verify that the project ID, host, and personal API key all come from the same PostHog project. It also says that if metrics look empty, the signup, activation, and retention event names should be checked against the events actually firing in PostHog. Those are the key problems to watch for. Because the source depends on specific event names, even a technically successful connection can still be useless if the event mapping is wrong.

Use PostHog when the company is product-led and wants LenGrowth to understand activation and retention behavior. If the team has not settled on event naming or the project does not contain the right behavioral signals, it is better to fix that first. Once the setup is correct, PostHog becomes a grounded way for LenGrowth to reason about onboarding and retention work instead of guessing at the product story.

The setup is intentionally explicit because product analytics only helps when everyone agrees on the event meaning. By asking for the signup, activation, and retention names up front, LenGrowth can keep the source aligned to the company’s actual lifecycle instead of inferring it later. That makes the integration more useful for teams that want reporting and recommendations to reflect the same event language they use internally.

It also makes it easier to revisit the setup later and see whether the event naming still matches the current product flow. If the team changes its onboarding or activation definitions, the integration page is the place to update the source rather than guessing from stale analytics labels.

Related pages: