Cohorts, flags + multi-project routing

Cohort-targeted bets

By default, a bet's predicted impact is measured against the whole user base. For most decisions that's right — "lift checkout conversion" applies to everyone who hits checkout.

But sometimes you only care about a slice: "lift activation for new signups in the last 30 days", "reduce churn for users on the Pro plan", "improve mobile conversion for first-time visitors". The PostHog cohort picker scopes the bet to just that slice.

How to pick a cohort

1. In Findry, open the bet form (either the promotion form or an existing bet's Edit predicted impact).
2. Scroll to Predicted impact → Cohort (optional).
3. The dropdown loads up to 100 saved cohorts fromGET /api/projects/N/cohorts/?limit=100 on first render. Pick one (e.g. "New signups in last 30 days").
4. Save. The bet'spredicted_impact.posthog_cohort_id is set, plus a small chip on the bet card shows the cohort name.

If PostHog isn't connected, the cohort picker hides gracefully — no error, just absent.

If your PostHog project has more than 100 cohorts, the picker shows the most-recently-updated 100. Most workspaces have far fewer. If you genuinely need search across hundreds of cohorts, let us know.

Where the cohort flows

The cohort ID is propagated through every adapter call:

• Event mappings — the HogQL query gets aWHERE person_id IN (SELECT person_id FROM cohort_people WHERE cohort_id = N) filter automatically
• Template mappings — the template's HogQL builder threads the cohort filter through. Activation rate with a cohort filter measures activation just within that cohort
• Insight mappings — Findry passes the cohort as a query parameter to PostHog's insight endpoint
• Funnel + raw HogQL — the cohort filter is not auto-injected (funnel events list is what you provided verbatim, raw HogQL is yours to shape). To scope a funnel to a cohort, write the join into your funnel events or use the raw HogQL escape hatch

Feature flag import

PostHog feature flags are how most teams gate experimental features. Findry Tests are how PMs document what they're validating. The flag-import flow connects them: the flag is where the rollout happens, the Test is the decision the rollout is informing.

Import a flag as a Test

1. In Findry, open the hypothesis you're validating with the flag.
2. Click + New Test.
3. In the test type picker, choose A/B experiment.
4. In the experiment-tool field, pick PostHog.
5. The flag list loads via GET /api/projects/N/feature_flags/?active=true&limit=100. Pick the flag.
6. The Test row stores the flag's experiment_external_idand links to the parent hypothesis.

If your team uses PostHog Experiments (the typed experiment wrapper around feature flags), the same picker surfaces those — they appear in the flag list with their experiment metadata attached.

Nightly state sync

The posthog-flags cron runs daily at 06:45 UTC. It pulls the current state of every imported flag and updates the linked Test:

• Flag still active: true → Test stays inrunning status
• Flag flipped active: false → Test moves tocomplete status; PM is prompted to record a conclusion (supported / refuted / inconclusive)
• Flag deleted in PostHog → Test stays in its last known status with a note "flag deleted in PostHog"; no auto-archive
• Flag's experiment results landed (PostHog Experiments only) → Test gets a structured result row with the variant lift + confidence interval, ready for the PM to apply

The sync is one-way: flag state → Test state. Findry never writes back to PostHog flags. If you want to deactivate a flag, do it in PostHog and the next sync picks up the change.

Multi-project routing

By default, every Findry project in a workspace queries the same PostHog project — the one you connected. For workspaces with one analytics surface, that's the right shape.

Some teams have multiple PostHog projects per analytics surface (B2B + B2C, web + mobile, prod + staging-with-real-traffic). The per-Findry-project routing lets you point Findry project A at PostHog project 12345 and Findry project B at PostHog project 67890 — same workspace connection, different destinations.

When to use it

If you find yourself wishing Findry could measure two unrelated analytics surfaces with one connection, this is the feature. Most workspaces never need it.

• B2B + B2C surfaces — your B2B PostHog project tracks dashboard usage; your B2C PostHog project tracks the marketing-funnel conversions. Two Findry projects, two different metric surfaces, one workspace
• Web + mobile — separate PostHog projects per platform is a common PostHog pattern. Findry projects can mirror that split
• Prod + staging-with-real-traffic — rare, but if you want a Findry project that measures decisions against a staging analytics surface, the override gives it

The workspace connection is still one (one host + one API key). The override only changes which project ID the adapter targets per Findry project.

Setting up an override

1. Settings → Integrations → PostHog tile → Per-project overrides
2. The list shows every Findry project in the workspace. Each row has a PostHog project ID field.
3. Empty field → falls back to the workspace-level default project. This is the right choice for projects that share the default analytics surface.
4. Filled field → Findry pingsGET /api/projects/<override>/ to validate access + cache the project name. Save unblocks once the ping comes back green.

After save, every PostHog-related call from that Findry project honors the override automatically:

• Outcome metric pulls (event / insight / template / funnel / raw) hit the override project
• Survey imports listed by the surveys tile come from the override project
• Annotations pushed for bets in this Findry project land on the override project's timeline
• Cohort + flag pickers in this project's bets list cohorts + flags from the override project

Removing an override (clearing the field + saving) reverts that Findry project to the workspace default for all future calls. Existing annotations stay put on the project they were originally pushed to — Findry never deletes external state on its own state changes.