Results you can read the same day.

Charts per question, not one dashboard

Results are organised the way the survey is: question by question, in the order respondents met them. Each question gets its own chart and its own counts, so the thing you are looking at is always anchored to the exact wording people read. That matters more than it sounds. A “satisfied” figure detached from its question text is how survey findings get misquoted six months later.

Because the results follow the survey structure, the shape of your analysis is decided when you build. A matrix question that puts eight statements on one agreement scale will give you eight comparable series; the same eight asked as separate multiple choice questions will not line up as neatly. If you know you want to compare items against each other, ask them as one matrix.

Where people stop: the drop-off report

Counts tell you how much data you have. Drop-off tells you what the survey is doing to the people filling it in. The report holds four things: the completion rate, a split of complete versus still-unfinished responses, the median time to complete, and the number of answers recorded for each question in the order they were asked. The largest fall between two consecutive questions is highlighted.

That highlight is the useful part while a survey is still open. If far fewer people answered question 12 than question 11, question 12 is worth rereading tonight rather than after the consultation closes. The culprit is usually a question that is too long, too personal, or asked before the survey has earned it.

It is where attention was lost, not a precise funnel

This needs saying plainly. Conditional logic means not everyone sees every question, so a lower answer count on question 12 can mean that half the sample was legitimately branched past it. The report cannot tell the difference between “they left” and “they were never asked”, so it does not pretend to. Read the highlighted fall as where attention was lost, check your rules to see whether one explains it, and only then rewrite the question.

Save & continue blurs the edges the same way: an unfinished response may be someone holding a resume link who intends to come back after lunch. That is why the report shows complete and unfinished as two counts rather than one abandonment figure.

Median time is a by-product of the spam checks

The median comes from timing data that was already being collected. The dwell-time floor described on the spam protection page records how long a response took, so a submission arriving faster than a human could read the questions can be challenged. The median completion time falls out of that, so nothing extra has to be collected to produce it.

Use it against your own claim: if the invitation email says “five minutes” and the median is fourteen, either the email is wrong or the survey is. Timing is not compulsory, though — a missing value is never treated as spam, so older clients and resumed partials still submit normally and simply do not contribute to the median.

Counts, never a half-finished answer

Partial responses are aggregated by a SECURITY DEFINER database function. The partials table itself carries no row-level security policies and cannot be read directly; the function is the only way in, and what it returns is counts.

So the author sees how many people answered each question. They do not see the sentence someone typed into question 11 and then thought better of. Somebody who has not pressed submit has not agreed to be read. That is a deliberate design decision rather than a limitation, and it is not configurable.

Reading individual responses

Aggregate charts are for the pattern; individual responses are for the reason. You can browse responses one at a time, in full, exactly as they were submitted. This is where free text is actually readable — a word cloud will not tell you that four people wrote the same complaint about the same car park.

Individual responses also carry anything the survey collected quietly: hidden fields read from the query string, so you can see which link or which cohort a response came from, and any uploaded files, which stay in a private bucket and are reached through short-lived signed links rather than being served publicly.

Scores and bands

If the survey uses scoring, each answer option can carry a score, each question a weight, and the percentage the respondent ends on maps to a band shown on the thank-you screen. Scoring only counts questions the respondent actually saw, which means branching does not quietly penalise someone for a section that was hidden from them. When you come to compare scores across responses, that is the detail that keeps the comparison honest.

Get the test data out first

Everybody tests their own survey, several times, usually with joke answers. “Clear test responses” removes those, and removes their uploads and partial responses with them, so you are not left with orphaned files or half-finished sessions dragging your completion figure down. Do it once, immediately before you publish the real link. It is much harder to unpick a fortnight later.

Who can see results

Results are visible to members of the organisation that owns the survey, under the owner / admin / member roles. Row-level security applies throughout and organisation isolation is pinned server-side rather than trusted from the browser. Survey content and responses are stored in London on UK infrastructure, encrypted in transit and at rest.

Exactly one thing is deliberately visible to a respondent: their own band on the thank-you screen, if the survey is set up to show it. No count, chart or other person's answer is ever exposed to a respondent.

What reporting deliberately does not do

Being specific about the gaps is more useful than pretending there are none:

• No AI summary of free text. Open answers are read by you, not paraphrased by a model. AI helps you draft a survey; it does not analyse the answers.
• No spreadsheet view of responses. There is no sortable table of all responses in the app. You browse them one at a time or you take the CSV.
• No per-question timing. Time is recorded for the response as a whole, so you get a median for the survey, not a ranking of which question took longest.
• Reporting is per survey. Each survey has its own results view. Comparing two surveys against each other is a spreadsheet job, done from the exports.

Getting results out in real time is a separate mechanism rather than part of this view: each response can be posted to an https endpoint or announced by email, both covered on the webhooks and notifications page. And if the analysis is going to happen in a spreadsheet anyway, read how the CSV and PDF exports are structured before you design the survey rather than after.