PostHog

Founders note: I’m deep in the mix on this one — the basic install is trivial, but what I actually run (identity stitching, cross-domain sessions, Postmark loops) is where the value and the risk both live.

What PostHog is

PostHog is product analytics built for engineers — but the Product OS bundles a lot more: session replay, feature flags, a managed warehouse, SQL, and CDP-lite activity feeds. I use it for something narrower: first-party cookies on my domain, session tracking, and identify on login so anonymous browsing backfills onto the same person in CRM.

That matters when you run multiple surfaces — content site, booking, gated posts — and you want to know how someone moved before they ever signed in.

First-party cookies you control

PostHog lets me set cookies on my domain. I can state in terms and privacy policy exactly what I track and why — not hand reuse semantics to a third-party cookie model I don’t control. For a founder-owned stack where Postmark, Supabase, and BookTime already share a subscriber id, that’s the honest way to close the loop.

Session → identify → backfill

Anonymous visitors get a PostHog distinct id in the browser. When they log in, I call identify with the CRM subscribers.id — the same id BookTime and engine Connections use, not the Supabase Auth uuid. PostHog merges prior anonymous events onto that person. I can see who was on what page and when, including activity from before auth.

On the content site that’s wired in posthogIdentify.ts; in engine, posthog-subscriber-activity pulls the timeline back into the CRM UI.

Postmark + click tokens

Couple PostHog with Postmark and you can set tokens on email links, track the click, and attribute public or anonymous site activity to an individual when the loop closes. Powerful — and dangerous if your privacy policy doesn’t say you’re doing it. If usage is clear and stated, it’s fine. If it’s buried, it’s not.

MCP and the debug loop

PostHog works well with MCP. I can run prompts across Sentry → PostHog → code — trace an error, pull the person’s activity, land back in the repo with context. That’s operational value, not a dashboard vanity metric.

At a glance

• What it is: First-party product analytics with optional Product OS depth — capture, sessions, identify/backfill, and CRM-facing activity when wired to your stack.
• Best for: Founder stacks that already own email (Postmark) and CRM ids and need cross-domain behavior without GA-style cookie ambiguity.
• Not a fit: Teams that want a one-line tag and no policy work; or anyone who won’t write honest tracking disclosure before turning on identity stitching.

When to reach for it

Reach for PostHog when first-party cookies and login-time attribution matter — and when you’ll wire identify to your CRM distinct id, not just fire pageviews. Tell Cursor you want PostHog on Astro; add identify on auth callback; only then add Postmark click attribution if your privacy terms cover it.

Watchouts

Identity stitching is a feature that can creep people out if they didn’t consent to what you said you’d do. Product OS breadth creates lock-in temptation — replay, flags, warehouse — even if you only needed analytics. Ease of use stays low until someone on the team owns the mental model.

See it in the stack

• Snowflake CRM tech stack — PostHog next to Supabase, Postmark, Inngest, and Cursor.
• Snowflake CRM — why cross-domain first-party tracking replaced Beehiiv-style analytics gaps.

Related playbook entries

• Postmark — click tokens and webhooks that close the email → site attribution loop.
• Supabase — CRM subscriber id and edge functions that feed PostHog activity back into Connections.
• Cursor — vibe-code the snippet, identify hook, and MCP debug chain.

AI prompts for vibe coding

Tech Stack Clarity Check (15 min) — Book a slot if you want a second pair of eyes on first-party analytics, identify/backfill, or Postmark attribution without blowing up privacy terms.