∴ Integration · PostHog
PostHog tells you what happened. Trevo tests what to do next.
PostHog can show where a funnel loses people. Trevo pairs those events with the code behind the drop-off, proposes a test, and writes the approved variant as a pull request.
pull events · funnels · experimentsfunnel view → cart → checkout → paidleak checkout → paid drops 62%read CheckoutSummary.tsx · lib/cart.tswrite proposal: quote tax before paymentship PR on trevo/* — your review is the gate
How does the PostHog integration with Trevo work?
Trevo connects to your PostHog project and pulls the events, funnels, and experiments you already track — no re-instrumentation. It pairs that analytics picture with what it reads in your GitHub repository, so a funnel drop-off maps to the actual component and server code behind the leaking step. From there Trevo proposes experiments with the evidence cited, and an approved proposal becomes a pull request with the variant implemented behind a feature flag. PostHog remains your source of truth for what users did; Trevo closes the loop by testing what to change.
How it works
From a PostHog funnel to a merged experiment, without re-instrumenting anything.
Connect PostHog in onboarding
One connection pulls your events, funnels, and experiments into Trevo. The metrics you already trust stay the metrics — nothing is renamed or re-tracked.
Trevo pairs data with code
The repo scan maps each funnel step to the components and server logic behind it, so “checkout drops 62%” points at files, not just a chart.
Drop-offs become proposals
Each proposal names the leak it targets, the mechanism it bets on, and the code it read. Approve, and the variant arrives as a pull request.
Results you can read in both places
Exposure and outcome events flow like the rest of your analytics, and the experiment is decided with always-valid sequential statistics.
Your instrumentation is the starting line, not a rebuild
Teams sink weeks into re-tracking events for each new tool. Trevo consumes the PostHog taxonomy you already maintain — the funnels you built are exactly what its proposals aim at.
- ✓Events, funnels, and experiments pulled straight in
- ✓No renaming, no double-tracking, no migration
- ✓Works alongside the lightweight Trevo SDK or instead of it
events 48 tracked · 12 used in funnelsfunnels activation · checkout · upgradenorth star revenue_per_visitorstatus proposals grounded in these
Analytics that ends in a diff, not a dashboard
A funnel chart is a to-do item with no owner. With Trevo attached, the leak gets a hypothesis, the hypothesis gets a pull request, and the pull request gets a decision — the loop your analytics was always missing.
- ✓Every proposal cites both the funnel and the code
- ✓Variants ship behind flags on trevo/* branches
- ✓Losers removed by automatic cleanup PRs
// funnel: checkout → paid (-62%) <TotalRow label="Total" value={subtotal} /> <TotalRow label="Total incl. tax" value={subtotal + estimatedTax} /> <TaxNote estimated />
What this looks like in practice
Illustrative proposals of the kind Trevo writes from a PostHog funnel — yours come from your own data and code.
Δ funnel
Answer the biggest drop-off first
Target the step with the largest absolute loss in your checkout funnel, with the fix argued from the component behind it.
measures → your existing funnel conversion
Δ activation
Activate the event you already track
Use your activation event as the primary metric and test the first-run flow that leads to it.
measures → signup → your activation event
Δ navigation
Promote the path your data likes
Your events show which entry path converts; the experiment makes it the default and measures the difference.
measures → entry → conversion by path
Frequently asked questions
Does Trevo replace PostHog?
No — it completes it. PostHog stays your analytics: events, funnels, session context. Trevo consumes that picture and adds the missing half of the loop: proposing, implementing, and deciding the experiments your funnels suggest.
Do I need the Trevo SDK if I already have PostHog?
The PostHog connection covers the analytics picture Trevo reasons from. The lightweight Trevo SDK is what powers assignment and exposure for experiments themselves; Trevo writes its setup as a pull request, so adding it is a review rather than a project.
What exactly does Trevo read from my PostHog project?
Events, funnels, and experiments — the aggregate shapes it needs to ground proposals. It reads through the official API with a key you control and can revoke; your project remains the system of record.
Can Trevo use my PostHog funnels to pick what to test first?
Yes — that is the point of the integration. Proposals are prioritized against where your funnels actually leak, not against a generic playbook, and each one names the funnel step it targets.
We use PostHog experiments today. Why add Trevo?
PostHog experiments give you the rails; your team still writes every variant. Trevo writes the variant — as a pull request in your repo, full-stack, with cleanup handled when the test concludes. Keep using PostHog for what users did; let Trevo do the experimenting.
Keep reading: GitHub + Trevo · Trevo for growth teams · Onboarding & activation experiments · How the statistics work · Trevo vs GrowthBook
Bring Trevo one real funnel problem.
Connect the repo and the first proposals arrive in under fifteen minutes, each one naming the exact files a full-stack experiment would change. Not ready? A free scan previews the ideas on your domain first.