Findry
Get started
Platform

PostHog deep dives

Findry talks to PostHog in both directions. PostHog is the analytics source you measure outcomes against, and PostHog is the analytics canvas you stamp Findry decisions onto. These four guides cover the full surface.

2 min overview · 34 min deep dive
Contents
PostHog deep dives
On this page

What you can do

One PostHog connection per workspace unlocks every PostHog-related surface in Findry. After connecting:

  • Read events → outcome verdicts. Bind any Findry metric to a PostHog event, saved insight, baked-in template, inline funnel, or raw HogQL query. The outcome-sweep cron pulls the metric, computes baseline + significance, and assigns a verdict.
  • Auto-import survey responses → Signals. Pick the PostHog surveys you care about; nightly cron pulls new responses and inserts them as Signals you can link to hypotheses.
  • Push Findry events → PostHog timeline. Bet promoted, bet shipped, and outcome verdict each drop a labeled vertical line on every PostHog metric chart.
  • Pick a PostHog cohort in the bet's predicted-impact form to scope variance to that cohort.
  • Import active feature flags as Findry Tests, with nightly state sync.
  • Route different Findry projects at different PostHog projects on the same workspace connection.

The four guides

Read in order if you're new to the integration. Skip around once you're past Connect.

1. Connect PostHog5 min
Personal API Key setup, host + project ID, troubleshooting the validation ping.
2. Metrics + mappings12 min
The metric library, the five mapping kinds (event · insight · template · funnel · raw HogQL), and how outcomes get computed.
3. Surveys + annotations9 min
Auto-import survey responses as Signals (in) and push Findry events to the PostHog timeline (out).
4. Cohorts, flags + multi-project routing8 min
Scope a bet to a PostHog cohort, import feature flags as Tests, and route different Findry projects at different PostHog projects.

The closed loop

Closed loop between PostHog and FindryPOSTHOGSurvey response▲ AnnotationSignalHypothesisBetOutcomeFINDRYbet.promotedbet.shippedoutcome.verdict
The PostHog ↔ Findry closed loop

A single workflow that exercises every PostHog surface, in order:

  • A PM in PostHog publishes an NPS survey. 60 responses come in.
  • In Findry, the PM enables that survey for import. The next nightly cron lands all 60 responses as Signals in the project.
  • The PM reads the new Signals, writes a Hypothesis, and links the five strongest signals to it.
  • In Settings → Metrics, the PM creates a "Mobile checkout completion" metric. In Settings → Integrations → PostHog, they map it to a 4-step funnel.
  • The PM promotes the Hypothesis to a Bet. PostHog gets a "▲ Bet promoted" annotation immediately.
  • The Bet ships, the PM sets the ship date. PostHog gets a "▲ Bet shipped" annotation at the ship date.
  • 30 days later, the outcome-sweep cron pulls the funnel from PostHog, computes a +12.3pp lift with p=0.0003, and assigns verdict hit. PostHog gets a "● Outcome verdict" annotation at the measurement timestamp.
  • The PM scrolls the PostHog complete_checkout chart. The spike lines up perfectly with the ▲ shipped annotation. The chain is closed both directions.

What is not yet

Three deliberate deferrals:

  • Cohort-segmented outcome measurement. Cohorts filter the bet's predicted impact today, not the post-ship measurement. Tier B, deferred until a customer asks.
  • Session recording deep-link in Signals. Attach a PostHog recording URL as the verifiable source. Tier B, deferred.
  • Auto-create a Test from a feature flag tagged with a hypothesis ID. Tier B, deferred.

PostHog OAuth is also queued behind first-customer-asks — Personal API Key works for everyone today, and the client interface is already OAuth-compatible so the swap is a one-file change.

PreviousIntegrations