PostHog

Data & Analytics

Four PostHog KPIs selected to track data-driven development practices at the individual contributor level, with the selection criteria made explicit.

4 available indicators

Indicator Object Type Formula Unit
Feature Flags Launched Number of active, non-deleted feature flags created by this user. Feature_flags Leading COUNT count
Experiments Started Number of experiments placed in running status by this user. Experiments Leading COUNT count
Experiments Completed Number of experiments run to conclusion (status complete or stopped) by this user. Experiments Lagging COUNT count
Surveys Launched Number of surveys launched (start date set, not archived) by this user. Surveys Leading COUNT count

PostHog exposes a broad range of objects: events, persons, feature flags, experiments, surveys, session recordings, cohorts, and dashboards. The vast majority of this data concerns end-user behavior — what customers do inside the product — and cannot be attributed to a specific internal team member. This integration is scoped to the three object types where individual attribution exists: feature flags, experiments, and surveys. Four KPIs were retained, selected against the same criteria applied across all integrations: ability to attribute to an owner, resistance to gaming, and balance between leading and lagging indicators.

Progressive delivery and experimentation cadence

Feature Flags Launched measures how many active, non-deleted flags a team member has introduced. Experiments Started measures how many running experiments they have initiated. Experiments Completed measures how many of those experiments have reached a conclusion — either complete or stopped — rather than being left open indefinitely. These three indicators describe a full cycle of data-driven development: proposing a safe delivery mechanism, formalizing a hypothesis, and following that hypothesis through to a decision.

The tension between Experiments Started and Experiments Completed is structurally important. An engineer who consistently starts experiments but rarely completes them is accumulating open hypotheses without generating decisions. Read in isolation, a high Experiments Started count appears favorable; paired with a low Experiments Completed count, it reveals an experimentation backlog and a failure to close the learning loop. Feature Flags Launched reinforces this reading: a team member who launches flags without tying them to experiments may be shipping incrementally but not measuring outcomes. The three indicators together distinguish between shallow adoption of the toolset and genuine hypothesis-driven practice.

User feedback collection

Surveys Launched measures how many surveys a team member has actively deployed — distinguished from created but not started, or archived. Launching a survey is a deliberate act: it implies a defined user question, a targeting decision, and a commitment to act on responses. A PM or product engineer who regularly launches surveys is systematically closing the feedback loop between product decisions and user reality. This KPI is lower frequency than the experimentation indicators — most team members will run a small number of surveys per quarter — but its presence ensures that user research activity is visible alongside delivery and experimentation cadence.

Scope and limits of the integration

PostHog's core data — event volumes, funnel conversion rates, retention curves, session recordings — is not included in this integration. These metrics describe product performance at the company level and cannot be attributed to an individual team member through the API. Including them would require a proxy (such as assigning a feature to an owner and attributing its downstream analytics to that person), which introduces an attribution chain long enough to lose reliability. The integration is deliberately narrow: it measures how actively a team member uses PostHog's own toolset, not what the product achieves as a result.

Attribution is also creation-time only. The owner of a feature flag or experiment is the person who created it; if ownership transfers informally, PostHog does not record that change. A team member who inherits a project mid-flight will not receive credit for experiments or flags they did not create, even if they carried the bulk of the operational work. As with all integrations, the reliability of these KPIs depends directly on how consistently the team uses PostHog: a team that centralizes feature releases and experiments through the platform generates meaningful signal; a team that uses it selectively produces data that reflects tool adoption as much as actual development practice.