PostHog integration

Connect your PostHog and onboarding checkups show what dropped users did instead of finishing, with rage clicks, detours, and session replays as evidence.

Your onboarding funnel tells you where users drop off. Your PostHog knows what they did instead: where they navigated, what they rage-clicked, which errors they hit, and it has the session replays to prove it. Connect the two and every checkup diagnoses from evidence instead of guessing.

The integration is strictly additive. Without a connection, nothing changes; with one, sunboard analytics experience --enrich, the experience dashboard, and the /sunboard.analyze skill gain an enrichment block anchored on your biggest drop-off:

Events after the drop: which product actions dropped users took next
Where they went: the pages they left for (a detour to /settings/billing tells you the step asked too much, too early)
Frustration signals: rage clicks and exceptions near the failing step, including the element they rage-clicked
Acquisition skew: whether the drop concentrates in one traffic source (a targeting problem, not a step problem)
Session replays: direct links to watch real users fail the step, in your own PostHog

Connect PostHog

Create a personal API key

In PostHog, open Settings → Personal API keys and create a key scoped to the one project your app sends events to, with query read access only. Sunboard only ever reads.

Connect it to your project

In your Sunboard project dashboard, open Settings → Integrations → Connect PostHog: pick the environment (production is almost always the one you want), your PostHog region, the PostHog project id (the number in your PostHog URL), and paste the key.

Or stay in the terminal:

sunboard integrations connect posthog

The CLI walks through the same choices and reads the key from a hidden prompt (or SUNBOARD_POSTHOG_KEY, or --key-stdin for scripts). It is never accepted as a flag, so it never lands in your shell history.

Either way, the key is verified against PostHog before anything is saved, encrypted at rest, and never shown again. Disconnect any time from the same places.

Run a checkup

sunboard analytics experience <experience-key> --enrich

Or just ask your agent how onboarding is doing: the /sunboard.analyze skill pulls enrichment automatically once a connection exists. The experience page in the dashboard grows a "What dropped users did instead" panel too.

How users are matched

Sunboard and PostHog both identify users with your own user id, so for a standard posthog.identify(user.id) setup the join works out of the box.

To make it exact regardless of your identify conventions, @sunboard/react also notices when PostHog is on the page and records the current distinct_id alongside the Sunboard user. This is a pseudonymous pointer your page already holds; Sunboard never queries PostHog with it until you connect. You can override it or turn it off:

// Override detection with an explicit id
<SunboardProvider identities={{ posthog: distinctId }} ... />

// Or disable capture entirely
<SunboardProvider identities={false} ... />

Every enrichment result reports a join rate, the share of dropped users actually found in your PostHog, so you always know how much of the story the data covers.

Data handling

Your API key is encrypted at rest and used only server-side. It is never sent to a browser, the CLI, or an agent; after connecting, only a hint like phx_...k3Jd is ever displayed.
Sunboard stores none of your PostHog data. Queries run on demand when you ask for enrichment, return aggregates only, and results are cached in memory for a few minutes to stay well inside PostHog's rate limits.
Replay links open in your own PostHog, behind your own PostHog login.

One connection per environment

Connections are per environment, like everything else in Sunboard. Connect production: that is where real users drop off. Checkups read production data even when your agent is working in the sandbox.

Want another provider? See Analytics integrations for what's available and what's planned.