PostHog tells you what people did. Intercom tells you what they said. Most product questions need both, and most teams answer them with two tabs open and a lot of scrolling. This guide is about reading the two as one body of evidence: what each can and cannot tell you, how to line them up, and which questions you cannot answer with either on its own.
Nothing here needs an integration. The last section shows where the same work lands in adduce, which reads both sources directly.
1. What each source can tell you
PostHog is the record of behaviour. It can tell you how many people reached a step, how many left, which properties they shared, and when the pattern changed. It is complete for the events you track and silent about everything else.
Intercom is the record of what people chose to say. It can tell you what a problem feels like from the customer's side, which step they were on when they wrote in, and the words they use for it. It is vivid, and it is selective: most people with the problem never write in.
Read them for what each is good at. Use PostHog for how many and when. Use Intercom for what and why. The mistake in both directions is the same: treating a count as a reason, or treating one conversation as a trend.
2. What each source cannot tell you
PostHog cannot tell you why. A funnel step with a drop-off is a question, not an answer. It also cannot see anything you did not instrument: a confusing error message, a slow page, a form that rejects valid input, unless an event fires when it happens.
Intercom cannot tell you how many. Four conversations about the same bug could be four people out of forty, or four out of four thousand. It also skews towards the customers who already talk to you: the largest accounts, the most patient users, the ones with a support contract.
The two tools rarely agree on who a person is. PostHog knows a distinct id and the properties you sent; Intercom knows an email and a company. Before you compare them, decide how you will match a conversation to a user, and write that rule down. The usual answer is the email on the account, and the usual gap is the users who are not the account owner.
3. Line them up on one timeline
Pick the window you care about, then put three things on one line: the metric from PostHog, broken down by the segment you suspect; every Intercom conversation from the same days that mentions the step; and every release that shipped. The order of events is the evidence.
| Day | PostHog · checkout, new mobile web | Intercom · threads about the address step | Release |
|---|---|---|---|
| Mon | 58% | 0 | — |
| Tue | 57% | 1 | Pricing page copy |
| Wed | 33% | 4 | Address form validation |
| Thu | 31% | 6 | — |
| Fri | 32% | 3 | — |
Read the table left to right. The rate falls on Wednesday, the threads start on Wednesday, and the release that touched the form shipped on Wednesday. The pricing change on Tuesday is on the table and is cleared by it: nothing moved that day.
4. The questions that need both
Some questions you can answer with one source. "How many people reached the address step?" is PostHog. "What did the customer on the enterprise plan say about it?" is Intercom. The questions that decide what to build next need both:
- Is this complaint a trend or a loud customer? Count the segment in PostHog, then read the threads from that segment in Intercom.
- Why does this step lose people? Find the step in PostHog, then search Intercom for conversations from users who left at that step in the same week.
- Did the fix work? Watch the step recover in PostHog, then check whether the threads stop in Intercom. A fix that moves the number but not the conversations has fixed a different problem.
- Who should we talk to? Take the segment that moved in PostHog and find the customers in it who already wrote in. They have the words and the patience.
| Question | From PostHog | From Intercom | What both say together |
|---|---|---|---|
| Why did checkout completion fall for new mobile visitors? | The drop starts Wednesday 14:00 in one segment; returning visitors are flat | Threads from Wednesday onward say the postcode field rejects a space | The address form release broke postcode entry for new mobile visitors; confidence high |
5. Keep the links when you write it up
Write the answer as a short case: the question, the segment, what the behaviour shows, what the customers said, and the release in between. Link every number to the PostHog insight and every quote to the Intercom thread. The reader should be able to open either in one click and see the same thing you saw.
Say how sure you are, in plain words, and say what would change your mind. "Confidence high; it would drop if returning visitors on the same form show the same fall next week." A case that names its own weak point is one your team can act on.
The checklist
- Decide how you match a conversation to a user, and write the rule down.
- Use PostHog for how many and when; use Intercom for what and why.
- Put the metric, the threads and the releases from the same window on one timeline.
- Treat a step with a drop-off as a question, and a single conversation as a lead, until the other source agrees.
- After a fix, check both: the number should recover and the threads should stop.
- Link every number and every quote in the write-up, and say what would change your mind.
In adduce
Where this lands in adduce.
An investigation tests each explanation against the records you connected, cites what it used, and says plainly when the cause is still unknown. You read the case, not the dashboards.
