Mixpanel to PostHog: how it went for Choose Your Horizon

Short version: we moved product and marketing analytics from Mixpanel to PostHog over July and August 2026, kept Segment as the instrumentation hub so the switch was low-risk, and we now get native experiments, feature flags, dashboards, session replay, and ad-spend attribution out of one tool. The surprise favorite: a Claude Code integration that lets us build reports against our code and our analytics at the same time.

Why we're glad we did it

• One tool instead of several. Product funnels, LP experiments, feature flags, session replay, error tracking, and marketing attribution all live in PostHog now.
• HIPAA-workable. PostHog Cloud US on a signed BAA, plus a server-side pattern that keeps PHI out of analytics entirely (below). This was make-or-break for us and probably is for you.
• Low switching cost. Because Segment stays the hub, we changed destinations, not client instrumentation. Same track/identify/page calls, new backend.
• The Claude Code + PostHog MCP combo (below) is the thing we did not expect to love as much as we do.

The transition, mechanically

• Segment stays the single source of instrumentation (one track/identify/page API across web funnels, patient dashboard, and mobile). PostHog was added as a Segment destination; Mixpanel is being retired, not ripped out.
• PostHog Cloud US under a countersigned BAA. Production ingestion only started once the BAA and security baseline were in place.
• History preserved. Live PostHog data started early July 2026; about two weeks later we backfilled historical events from Mixpanel (back to ~Feb 2026), so we did not lose trend history.
• Staged rollout: LP experiments first (cheap, low risk), then product funnels, then marketing and attribution.

Gotchas worth knowing up front (so you skip our stumbles): budget for the BAA and security-baseline lead time before prod ingestion; plan the Mixpanel backfill so "last 30 days" is not silently short during the gap; and lock an event taxonomy and naming convention early (we had a mid-flight snake_case to Title Case cutover that split some event names).

Experiments and feature flags

The HIPAA-safe pattern is the important part for a health company: the feature flag is evaluated server-side, exposure is logged through Segment, and the browser never talks to PostHog directly. So we get real randomized experiments with PostHog's stats engine (Bayesian win probability) without any PHI, or even a PostHog snippet, touching the patient's browser.

What we've run:

• Landing-page CTA copy test ("See If You Qualify" vs "Start Assessment") on our Meta/Iceberg LPs. Clear winner: "See If You Qualify" won click-through 19% to 24% at 99.9% probability, and it carried downstream (form-start 16% to 20% at 99.7%), so it was real lead quality, not just clicks. Shipped, now rolling to all Meta LPs.
• Native-app-onboarding experiment (feature-flag-gated, sticky 50/50): routing new patients into in-app onboarding vs web. Native onboarding completes ~91%+, far above web, so we are expanding who gets the app path.
• Checkout-redesign tests: won on one funnel, lost on another (reverted). Exactly the "kill it fast" call the stats engine makes easy.

Feature flags do double duty: the same flag gates the experiment and the rollout, sticky per user, so shipping the winner is just widening the flag.

Reports and dashboards, and the Claude Code superpower

This is the part we are most excited about. We drive PostHog from Claude Code via the PostHog MCP, and because Claude Code also has our codebases open, it can query our product analytics and read the code that emits those events at the same time. In practice:

• We ask a question in plain English ("of the users who clicked Continue in App, how many never actually got into the app and never onboarded?"), and Claude writes the HogQL, runs it against PostHog, cross-checks it against our database, and reads the relevant component to explain why, in one pass. Reports that used to be a half-day of manual funnel-building take minutes.
• We built repeatable Claude "skills" (slash commands) on top of this: a weekly funnel review that pulls PostHog and revenue data into a one-page agenda, a split-test runner that creates/monitors/concludes a PostHog experiment end to end, and a meeting-recap that turns funnel-meeting notes into tracked Linear issues and doc updates.

Standing dashboards we lean on: landing-page insights (visits, CTA rate, form-start), a mobile-onboarding funnel, and a marketing attribution board (below).

Ad-platform spend and attribution

PostHog's marketing analytics pulls spend straight from the ad platforms (Meta, Google, Bing) and joins it to on-site conversions, so CAC and ROAS by channel live in the same tool as the funnels. We wired UTMs plus first/last-touch attribution and click-ID inference onto our conversion events (UTM coverage on purchases went from ~0% to ~44% after that work), so we can finally see channel-level funnel performance and per-channel value. Multi-touch is our next step. This replaced a pile of spreadsheet reconciliation and gives marketing a self-serve spend-to-conversion view.

Other things we got largely for free

• Session replay to watch where users actually stall (paired with experiments, it tells you the "why" behind a drop-off).
• Error tracking and product logs in the same place.
• Surveys.
• HogQL / SQL access to the raw event warehouse when a question does not fit a canned insight.

Net

For a health company specifically, the combination of a signed BAA, a PHI-safe server-side experiment pattern, and the Claude-Code-plus-MCP workflow is what makes PostHog more than a Mixpanel swap. Happy to walk through the HIPAA setup or the Claude skills if that would help.