PostHog → Attio: the CRM finally reflects product usage

PostHog knows who used your product today. Attio doesn't. That asymmetry is why CSMs are always chasing stale context and why marketing campaigns keep targeting users who already churned. We bridge PostHog into Attio so product events become CRM signal. Cohorts, feature usage, activation milestones, and power-user flags all land on the right Person and Company - automatically, continuously, without anyone remembering to sync.

Direction

PostHog → Attio (events, cohorts, feature flags)

Stack

PostHog API, Attio API, n8n

The what

What this integration actually does

PostHog events stream into Attio as activities (or field updates, depending on the event). Cohort membership syncs as list membership. Power-user detection, churn risk, and activation status become queryable fields in Attio that drive lifecycle automations.

The how

How we build it

  1. 1

    Audit your PostHog event taxonomy - which events drive decisions in Attio.

  2. 2

    Pick the integration path: PostHog webhooks for real-time, cohort API for periodic sync, or both.

  3. 3

    Design the Attio field model: activation_date, last_active, mau_flag, at_risk_flag, feature_xyz_used.

  4. 4

    Build the pipeline in n8n - batched where possible (PostHog generates a lot of events; batching is essential).

  5. 5

    Map cohorts to Attio lists: "active last 7 days", "paid but not activated", "power users".

  6. 6

    Wire the automations on the Attio side - at-risk accounts trigger CSM outreach, newly activated accounts get a congrats email, etc.

Under the hood

What lives inside the pipeline

  • Event batching - one Attio write per user per hour, not one per event.
  • Cohort-to-list sync so "active last 7 days" in PostHog is always the same list in Attio.
  • Identity resolution - PostHog distinct_id to Attio Person via email or custom ID.
  • Feature flag state exposed as Attio field for targeting.
  • Anonymous-to-identified event replay when a user eventually signs up.

Hard-earned lessons

What we learned the hard way

  • Don't sync every PostHog event. Pick the 10 that matter. The rest are noise in the CRM.
  • PostHog's cohort recalculation is not instant - build your Attio logic assuming up to an hour of lag.
  • Identity resolution is the hardest part. A PostHog session that was anonymous then became identified creates two personas - merge carefully.
  • Feature flags change. If you're storing flag state in Attio, rebuild the sync when you change the flag, or you'll have stale state.

Case study

Early-stage SaaS tracking activation

Problem

PostHog knew exactly who activated and who didn't. The CRM treated every signup the same. Trial-to-paid conversion emails were going to users who had never logged in.

Solution

PostHog cohorts for activation stages synced to Attio lists. Trial reminder emails only fire for users who've hit at least one activation milestone.

Outcome

Email engagement up, unsubscribes down. The sales team stopped chasing dead trials.

FAQ

Questions we get

Yes. Same API surface; just point the integration at your instance.

For the PostHog→CRM slice, yes. For full CDP needs, Segment and PostHog can coexist - we'll wire both.

Same pattern ports. PostHog is our reference because it's what we run on our own products.

Want this running on your Attio?

Book a free 30-min call. We'll map your use case to what we've already shipped and tell you whether this fits - honestly.

Book a 30-min call