Combining Responses From Multiple PostHog Surveys Into One View
There is no native view that shows responses from two or more PostHog surveys as one stream. Each survey is its own object with its own results page, its own response count, and its own chart. Run an NPS survey in Q1 and a follow-up NPS survey in Q2, and PostHog will show you two separate scores, not one trend line. An open feature request from a PostHog customer, "Combine responses from two surveys," confirms this directly, noting that without it, a team running two NPS surveys "can't use the Survey's analytics platform" for a blended score and has to fall back to a spreadsheet.
The workaround isn't in the UI. It's underneath it. Every survey response, regardless of which survey sent it, is captured as the same kind of event, so a query written against the event data can cross survey boundaries even though the results page can't. That gets you partway. Getting the rest of the way, specifically the parts of "one view" that involve who answered and what else that person has said elsewhere, is a different job, and it's worth knowing exactly where the query stops helping before you build a process on top of it.
What PostHog actually stores per response
Each survey response fires one of four events: survey shown, survey sent, survey dismissed, or survey abandoned (the last one only if partial-completion tracking is on). The event that carries the answer, survey sent, stores each question's response under a property named $survey_response_{question_id}, and PostHog documents a getSurveyResponse() SQL helper built specifically to pull that value back out by question index or ID.
The part that matters for combining surveys is that survey sent is one event type; it doesn't fork into a separate event per survey. A survey-specific identifier lives on the event as a property, not as a different event name, which means a single query against the events table can, in principle, select survey sent rows across any set of surveys at once. PostHog's own API docs describe exactly this split, noting you can "list a survey's responses, pull per-survey stats, or fetch project-wide stats across every survey". Per-survey and project-wide are explicitly two different things, and only one of them lives on the results page you'd normally look at.
The two ways to approximate a combined view
HogQL against events. Write a query that filters survey sent events to the survey IDs you want to combine, pull the response property for the question you care about, and group however you like: by month, by account property, by anything else already attached to the event. This is the only way to get a blended NPS across two surveys short of PostHog shipping the feature request above, and it works. It also means someone has to write and maintain that query, know which survey IDs belong in it, and update it every time a new survey gets added to the comparison.
Export and combine by hand. Pull the CSV off each survey's results page and stack the rows in a spreadsheet. No query skill required, but it's a manual step every time you want an updated number, and it inherits whatever inconsistency crept into how each survey named its questions.
Neither approach touches the open GitHub issue's actual ask, a button that does this for you. Both are ways of doing by hand or by query what PostHog hasn't built a UI for yet.
issue filed·
report writtenNaomi Colque runs three surveys and one leadership update
Naomi Colque is head of product at Corridor Health, which builds scheduling software for outpatient clinics. Corridor runs three PostHog surveys at once: a post-onboarding NPS survey, an in-app CSAT survey scoped to the new appointment-reminder feature, and a quarterly open-text churn-reason survey sent to anyone who downgrades. Leadership wanted one number for the monthly update: "how are customers feeling," not three separate charts.
Naomi's first attempt was opening all three results pages side by side and eyeballing it, which fell apart the first month the NPS survey's response count moved in the opposite direction from the CSAT survey's. Nobody could say whether that meant anything without knowing if the same accounts showed up in both.
Naomi, in the team's product-analytics channel: Can someone write a query that gets me one NPS-style number across the onboarding survey and last quarter's follow-up? I don't want three tabs open every time leadership asks.
Backend engineer: Yeah, that's a HogQL query against
eventsfiltered tosurvey sentand both survey IDs, pulling the score property. I'll have something Thursday, but it's not going to tell you if it's the same clinics showing up in both surveys unless I also join on distinct_id, and that's a second query.
The first query worked and gave her the blended score she wanted. The second one, matching a churn-reason respondent back to the same clinic's earlier NPS answer, needed another afternoon of engineering time, and it only covered the three surveys that existed that quarter. The next survey Corridor launches starts the whole thing over.
Where the query stops being worth maintaining
The HogQL approach is genuinely good for a fixed number of surveys and a stable question you're asking repeatedly. It stops paying off at a predictable point:
- Every new survey means a query edit. The list of survey IDs in the
WHEREclause is manual, and nothing warns anyone when a survey gets left out. - Cross-referencing respondents is a separate, harder query. Getting one score is easy. Confirming "is this the same account complaining in both surveys" means joining on identity, and PostHog's own identity graph has known gaps when
identify()isn't called consistently before a survey fires. - The result lives next to nothing else. The blended score answers "how are customers feeling," but not "is that the same account that filed three support tickets this month," because the query only ever touches survey events.
That third point is the one that keeps showing up. A combined survey number is still just a number about surveys. The context that would make it useful, the same person's support history, their Slack messages, their sales calls, lives in different systems and was never part of the query.
Where Modem picks it up
We build Modem, so weigh this section accordingly. Modem's PostHog integration queries product analytics, feature flags, experiments, and error tracking; it doesn't read survey text directly, and combining surveys inside PostHog's own data model isn't something it does either. What changes the picture is PostHog's own survey destinations feature, which can push each response, survey name, question, and answer included, to a Slack channel or webhook the moment someone submits. Point every survey's destination at a channel Modem is already reading, and the "which survey did this come from" question stops mattering, because every response, from any of Corridor's three surveys, lands in the same context graph as the account's support tickets and Slack threads. The combination point moves outside PostHog entirely, so adding a fourth survey next quarter doesn't require anyone to touch a query.
That doesn't replace HogQL for anything PostHog's own analytics does better, like a precise blended score computed straight from raw events. It solves the adjacent problem this guide is actually about, seeing all of it across every survey next to what the same people are saying everywhere else, without a query someone has to remember to update. The open-text side of this same gap, turning free-response answers into counted themes, is covered in how to analyze open-text PostHog survey responses at scale, and the wider comparison of tools built for pairing PostHog data with customer feedback is in the six best tools to pair PostHog data with customer feedback.
The smallest version you can start this week
If you're set on the native path, write the HogQL query once, save it as an insight, and put the survey IDs in a comment above it so the next person knows where to add a new one. If you'd rather not maintain that query at all, point your surveys' Slack destinations at one channel and see how far that gets you before deciding whether you need the query too.
