Surveys in PostHog Web

The PostHog web app is where surveys are built, targeted, launched, and read. You write the questions, decide who sees them and when, watch responses arrive in real time, and every answer carries the respondent's session replay, events, and person properties.

Open Surveys in PostHog to see every survey in your project with its status, response count, and schedule. Start from a template – NPS, product-market fit, churn, or open feedback – or write your own from scratch, and preview it before anyone sees it.

Before you start

1. Set up Surveys – install a PostHog SDK so they can be shown to users.
2. Open the web app – no install needed, just sign in to PostHog.

What you can do here

• Create a survey – pick a type (popover, widget, hosted form, or headless API), write your questions, style the appearance, and launch it.
• Choose how it's delivered – a popover inside your product, an always-available feedback widget, or a hosted form with a shareable public URL for email, social, or a QR code.
• Target the right people – limit a survey by URL, event trigger, device type, person properties, cohort, or a linked feature flag, and set a wait period so you don't interrupt the same user twice.
• Branch on answers – send detractors and promoters down different question paths so nobody answers something irrelevant.
• Read the results – the results tab, a dashboard widget, or your own insights and SQL, each response linked to its replay.
• Send responses onward – post each answer to Slack, Discord, Microsoft Teams, or a webhook as it arrives.
• Run it on a schedule – launch once or set a recurring schedule with a response limit, and stop it when you have enough.
• Create surveys with PostHog AI – describe the survey you want in plain language and PostHog AI writes the questions, targeting, and display conditions. It's an interaction mode inside the web app, not a separate surface.
• Summarize responses with PostHog AI – pull themes, sentiment, and segment comparisons out of hundreds of open-text answers without reading them one by one.

Self-driving reports

A dedicated scout watches your active surveys, and when it finds something real – a score regression, an abandonment spike, or a theme several people keep raising – it files one report in the Self-driving inbox and routes it to a named human reviewer. To get these reports, set up Self-driving.

Unlike error tracking, this scout stops at the report. It doesn't open a draft pull request.

How feedback becomes a report

Surveys are direct user voice, so the bar for a report is deliberately high: a handful of converging open-text answers can outweigh a much larger analytics signal, but a wobble in a small NPS sample is not a report.

• Recurring themes – open-text answers clustered into one finding. Five people describing the same checkout step becomes a single report with a few verbatim quotes attached, not five you never read.
• Score regressions – NPS, CSAT, and rating drops measured against that survey's own baseline, with small samples held to a tighter bar than large ones.
• Response-volume drops and abandonment spikes – survey dismissed rising as a share of survey shown, or impressions stepping away from their usual range.

Every report names the surveys and questions behind it, the response counts, and the score deltas, so you can judge the finding against its own sample rather than taking it on trust.

Why there is no pull request

A survey finding is user sentiment, not a defect with a known fix. Someone telling you checkout felt confusing doesn't tell you whether the answer is different copy, a different flow, a different price, or nothing at all. That's a product decision a person has to make, and it's rarely a mechanical code change a coding agent could make on its own.

Survey responses are also personal data, and the cost of getting a "users hate feature X" report wrong is high. So the scout is built to hand you an investigation with the evidence attached and a reviewer already assigned, and to stop there. Other signal sources, like error tracking, do open pull requests.

What you can do with a report

• Read the report – the theme or regression, the survey and question it came from, the response counts and score deltas, and the replays and events behind the feedback.
• Ask questions – start a discussion with an agent about the report to dig further before you act.
• Follow the activity – the report's activity log shows what happened to it and when.
• Decide what happens next – change the product, rewrite the copy, ask a follow-up question, or dismiss the report. Nothing happens until you decide.

Related

• Get set up end to end in Get started with Surveys.
• Create and launch surveys from your editor over MCP.
• Manage surveys programmatically with the API.