Surveys
Contents
Surveys collect qualitative feedback from your users – NPS, product-market fit, churn reasons, or plain open text – and put it next to everything else PostHog already knows about them. Ask the right people at the right moment with targeting built on the same events, properties, cohorts, and feature flags you use everywhere else.
Because responses land as events, every answer carries the respondent's session replay, events, and person properties, so "the checkout is confusing" comes with the recording that proves it. Those same responses feed Self-driving, which clusters recurring themes into reports you can act on.
Where you can use it
You build surveys and read responses in the PostHog web app. The other surfaces let you create, launch, and analyze surveys without leaving your editor, your scripts, or your review queue.
PostHog Web
Build, target, and launch surveys, then read the results with replays attached.
Build a survey →PostHog MCP
Create, launch, stop, and summarize surveys from any MCP client or AI editor.
Manage surveys →PostHog Desktop Beta
Review the Self-driving reports built from recurring themes in your responses.
Review findings →Where its data comes from
Surveys run on the questions you ask, who you ask them of, and the responses that come back. SDKs render and display surveys in your product, targeting decides who sees what, and every answer is captured as an event you can query like any other.
SDKs
Show surveys in web, mobile, and framework apps with the SDK you already installed.
Install an SDK →Questions and targeting
Branch questions on earlier answers and pick who sees a survey with URLs, events, properties, and flags.
Design questions →Responses
Every answer is an event, so you can chart it, query it in SQL, or pipe it to Slack and webhooks.
View results →How surveys work with Self-driving
Your survey responses are a signal source for Self-driving. A dedicated scout watches active surveys for score regressions and abandonment spikes, and clusters open-text answers into recurring themes – five people complaining about the same checkout step becomes one report, not five you never read.
A survey finding is user sentiment, not a defect with a known fix. What to do about "checkout felt confusing" is a product decision – copy, flow, pricing, or nothing – so this scout stops at the report and routes it to a human reviewer rather than starting a pull request.
You write and launch surveys in the PostHog web app, and read the reports in PostHog Desktop or the Self-driving inbox. Other signal sources, like error tracking, do open pull requests – see the Self-driving docs for the full picture.