Survey completion rate: formula, example and drop-off diagnostic

Survey completion rate is the percentage of eligible survey starts that reach the declared completion event. Calculate it as completed surveys ÷ eligible starts × 100, publish the counts beside the percentage, freeze the rules for what qualifies as a start and completion, and inspect stage-level drop-off before changing the questionnaire. Keep it separate from response rate, which uses the invited or otherwise eligible sample as its denominator.

What is survey completion rate?

Survey completion rate measures how many people who began a survey reached its defined end. SurveyMonkey's current guidance distinguishes it from response rate: response rate evaluates invitation participation, while completion rate evaluates what happens after a respondent starts. Typeform's current performance documentation uses responses divided by starts, multiplied by 100.

The metric is only reproducible when start, completion, exclusions and the observation window are fixed. A platform that counts an opening-screen view as a start will report a different rate from one that waits for the first submitted answer.

Formula and required counts

Completion rate = completed surveys ÷ eligible starts × 100. Also report drop-off count = eligible starts − completed surveys and drop-off rate = drop-off count ÷ eligible starts × 100. Keep raw starts and every exclusion visible so another analyst can reconstruct the denominator.

Worked completion-rate example

A survey records 1,240 raw starts. The audit identifies 18 staff tests, 12 confirmed automated sessions and 10 exact duplicate starts under the predeclared identity rule. Eligible starts are therefore 1,200. Of those, 930 reach the recorded submission event.

930 ÷ 1,200 × 100 = 77.5% completion. The drop-off count is 270 and the drop-off rate is 22.5%. Publish all four inputs: 1,240 raw starts, 40 exclusions, 1,200 eligible starts and 930 completions. The arithmetic is illustrative, not a benchmark for a “good” survey.

Start-state decision table

How should screen-outs and branched endings be handled?

Do not force every route into one undifferentiated numerator. Record a terminal status such as complete_main, complete_screenout, complete_quota_full, partial, abandoned or technical_failure. Report the overall instrument-completion rate when every legitimate terminal route represents a designed end, and publish an eligible-main-route rate when the research question requires it.

Never relabel a screened-out respondent as an abandoned partial merely because they answered fewer questions. The screening specification should determine whether the route completed as designed.

Drop-off diagnostic

Stage drop-off uses the people who entered that stage as its denominator. The table reconciles because each advanced count becomes the next stage's entered count and the final 930 matches the completion numerator. Preserve route-specific counts when not everyone should enter every stage.

How do response rate and completion rate differ?

If 5,000 eligible people receive an invitation, 1,240 produce raw starts and 930 complete, the invitation-start rate is 24.8% before start exclusions, while the eligible-start completion rate is 77.5%. A completed-response rate using the invited sample would be 18.6%, but it must be named and calculated under the study's response-rate standard. Improving the invitation can change participation without changing the questionnaire experience; shortening the survey can change completion without fixing sample coverage.

Sixteen-field measurement log

Store survey_id, questionnaire_version, fieldwork_start, fieldwork_end, start_event, completion_event, observation_window, identity_rule, resume_rule, test_exclusion_rule, bot_rule, duplicate_rule, raw_starts, excluded_starts, eligible_starts and completed_surveys. Keep stage and terminal-route counts in a linked event table rather than overwriting the final status.

Ten reproducibility checks

1. The start event fires once per attempt and not on prefetch.
2. The completion event requires a stored terminal response.
3. Resume behavior attaches to the original attempt.
4. Refresh and back-button actions do not create duplicate starts.
5. Every exclusion maps to one written rule and retained evidence.
6. Screen-out, quota-full and main-complete routes have distinct terminal codes.
7. Stage counts reconcile from start to completion.
8. Device, source, language and version comparisons use the same definitions.
9. Deleted partial records do not rewrite historical denominators.
10. A rerun from frozen events reproduces the published counts and percentage.

Transparent method

We rechecked the sources on 19 October 2026. SurveyMonkey supplies the current distinction between response and completion rates and the finished-divided-by-started formula. Typeform supplies a current first-party implementation based on responses divided by starts. The CHERRIES reporting checklist supplies the earlier web-survey reporting definition based on finishing divided by agreeing to participate or submitting the first page. The start-state table, worked reconciliation, sixteen-field log and reproducibility checks are editorial synthesis.

Limitations

Completion rate does not measure representativeness, response validity, question interpretation or causal effects. Platform event definitions and retention policies differ. Cookie deletion, cross-device returns, shared devices and anonymous links can prevent perfect attempt matching. A high rate can coexist with biased recruitment or poor questions, while a demanding but necessary instrument may complete less often. Diagnose changes with questionnaire version, traffic source, device, route and fieldwork context; do not copy an external benchmark as a universal target.