CapabilitiesUpdated July 28, 2026

Deep-capture studies

Bounded, cohort-scoped session recording in your own PostHog — justified by one assumption, approved by you, armed for a set window, then switched off again.

Analytics tools capture everything and let you search it afterwards. Sightspool works the other way round: granular telemetry exists only as a deep-capture study, and a study exists only because a specific assumption couldn't be settled any other way. Justify, then capture — never the reverse.

What this means for your users' privacy

Purpose limitation is usually a policy promise. Here it is the mechanics of the product, and it is worth being precise about what that buys you.

  • Recording is never switched on speculatively. A study can only be created from a committed register entry, through an approved research brief — no assumption, no deep capture.
  • Only a human can arm it. An agent can propose a study; it cannot approve or arm one. No approval, no arming.
  • It is scoped to a named cohort — a fixed, finite set of people snapshotted when you arm it, not a rule that keeps recruiting new people while the study runs.
  • It is bounded twice: a window (after which it stops itself) and a sample rate. An unbounded deep-capture study cannot be represented in the system at all.
  • It is observational. Recording changes who is captured, never what anyone sees; the experience of every user is identical whether or not a study is running.
  • The recordings are yours. They live in your PostHog project, under your retention, masking and redaction settings. Sightspool stores none of them — only the pointers it needs to switch recording off again.

What you need

A live PostHog connection plus a separate capture key on the Connections page: a personal API key scoped project, feature_flag and cohort (read + write). It is deliberately not the read key — reading your events and reconfiguring your capture are different powers, and one shouldn't quietly become the other. Leave it blank and deep capture is simply unavailable.

Running a study

  • An assumption the standard watch can't settle escalates to research, which drafts a brief. A researcher completes the design with the method set to deep-capture.
  • You approve the brief. Nothing is armed until you do.
  • At launch you name the cohort (the same audience builder the survey path uses), the window in days, the sample rate and an optional minimum session length.
  • Sightspool creates three things in your PostHog: a static cohort of exactly those people, a feature flag targeting it, and a session-recording trigger group that fires only for that flag.
  • Recordings appear in your own replay UI within minutes. The study card links straight to them.
  • At the end of the window it stops itself: the trigger group, the flag and the cohort are all removed.

How stopping works, and why it can fail loudly

Because recording lives in your project rather than ours, "stopped" is a claim about your project — so it is checked rather than assumed. Teardown removes the trigger group, re-reads your live configuration, and only then marks the study stopped. If any of that fails, the study stays open and says STILL RECORDING with the reason, and retries every worker tick. A study will never read stopped while your users are still being recorded.

Two related guarantees: teardown removes exactly the group Sightspool added, so a recording rule you set up yourself during the study survives untouched; and recording is only switched back off if Sightspool was the thing that switched it on.

Closing a study

A stopped study doesn't leave you with a folder of recordings to work through. Choosing “Stop & synthesise” disarms recording first if it is still on, then reads the cohort's sessions back out of your PostHog and writes one finding into the feed — proof-gated like every other finding, citing the exact numbers it read.

  • What it reads: how many sessions and people the cohort produced in the window, session-level engagement (clicks, keypresses, console errors, active time, sessions with no interaction at all), how many sessions carried each friction event your project actually tracks, and the assumption's own signal re-read for just this cohort over just this window.
  • What it can't read: anything the assumption didn't point at. Every query is built from the entry's own signal plus a fixed friction set, so a study cannot wander off into whatever else looked interesting.
  • The finding separates what was observed from what it might mean, names at least one alternative explanation, and never states a confidence percentage.
  • The study settles the assumption's research state, not its verdict. Ruling the assumption stays yours.

Once your cohort's membership is snapshotted at arming time, it stays recoverable from the study's own record even though the cohort itself is deleted from PostHog when the study stops. The deletion is the point — nothing about the study outlives it in your project — and the synthesis still knows exactly whose sessions it read.

What it costs

Recordings are captured and billed by PostHog against your own allowance. That is why the window, sample rate and minimum duration are explicit choices you make at launch rather than defaults buried in a config — and why Sightspool never arms a study on its own.