What is a partial quiz response?
A partial quiz response is an explicitly stored record from a journey that has not reached the declared completion event. It may contain one or more answers, a session or completion identifier, a saved-at time, a quiz version, and a status. It is not automatically a lead, a valid result, a qualification decision, or permission to send marketing.
Products implement partial state differently. Typeform documents a mode that captures after every question and creates a partial response after about seven minutes of inactivity, while its separate save-and-return behavior can preserve progress in browser storage for 15 days. Those are useful implementation examples, not universal defaults: define the site's own trigger, purpose, disclosure, and lifecycle rather than inferring them from a vendor label.
Related: Find the first material journey loss · Choose where to request contact details
Sources: Typeform Help Center, Capture partial responses after every question · Typeform Help Center, Save and return to your form later
Use a purpose-first decision matrix
Begin with the purpose and the smallest record that can support it. The ICO's data-minimisation principle says personal data should be adequate, relevant, and limited to what is necessary, and its storage-limitation guidance calls for documented retention periods, review, and deletion or anonymisation when the data is no longer needed. Both pages state that the guidance is under review after recent UK legislation, so recheck the applicable source before relying on it.
| Proposed purpose | Minimum useful state | Permitted action | Do not do |
|---|---|---|---|
| Resume on the same device | Local session key and progress | Restore the declared path | Create a contact record without need |
| Participant-requested return link | Contact channel, permission for that delivery, progress token | Send the requested recovery message once | Treat delivery permission as marketing consent |
| Support recovery | Stable record ID, quiz version, saved step, error state | Diagnose or restore the journey | Expose unnecessary answer content |
| Funnel diagnosis | Pseudonymous journey ID, step, time, version | Measure step loss | Export direct contact data to analytics |
| Sales or marketing | Completed eligibility and applicable permission | Act only after the declared state is reached | Route an incomplete record merely because contact data exists |
Sources: ICO, Data minimisation principle · ICO, Storage limitation principle
Define the partial-response state contract
Use one authoritative state and preserve its transition history. A started journey exists only in the active experience. An in-progress state may be recoverable locally. A saved partial is a durable incomplete record. Completed means the declared terminal event occurred. Expired means the retention or recovery window ended. Deleted or anonymised means the identifying state is no longer available.
Promotion from partial to completed must be idempotent: the same completion or retry cannot create two leads, two result emails, or two analytics successes. If a vendor sends a partial record to an integration, label it as partial at the destination and update or reconcile it under a stable identifier instead of silently appending a second completed person.
| State | Entry evidence | Allowed next states | Action guard |
|---|---|---|---|
| Started | Journey initialized | In progress, abandoned | No lead action |
| In progress | At least one valid interaction | Saved partial, completed, abandoned | Local recovery only unless disclosed |
| Saved partial | Durable record and saved-at time | Completed, expired, deleted | Purpose-specific actions only |
| Completed | Declared terminal event | Corrected, deleted | Apply qualification and permission rules |
| Expired | Retention or recovery window elapsed | Deleted or anonymised | No operational follow-up |
| Deleted or anonymised | Deletion log or irreversible transform | None | Do not recreate from a public analytics record |
Related: Prevent duplicate people, completions, events, and actions
Sources: Typeform Help Center, Capture partial responses after every question · ICO, Storage limitation principle
Decide in five steps
Document the decision before enabling capture. A partial-response feature is not automatically beneficial simply because the builder offers it.
- Name one operational or participant purpose and its owner.
- Prove that aggregate step events or local storage cannot meet the purpose with less personal data.
- Define the exact trigger, fields, identifier, disclosure, permission, retention, and deletion behavior.
- Declare every state transition, downstream action, retry rule, and failure state.
- Run synthetic abandon, resume, complete, expire, delete, integration-failure, and duplicate-retry cases before release.
Worked example: recovery without premature lead routing
A six-step qualification quiz asks for an email at step five so a participant can request a return link. The participant reaches step five, asks for the link, then leaves. The system stores a partial record with the quiz version, current step, stable journey ID, email, requested-delivery permission, saved time, and expiry time. It sends one recovery message and does not add the person to nurture or sales.
When the participant returns and completes, the same journey ID is promoted to completed exactly once, the result is calculated from the final answers, and marketing follows only if its separate permission and eligibility rules pass. If the participant never returns, the recovery state expires and the identifying record follows the declared deletion or anonymisation rule. This is a synthetic process example, not a conversion benchmark or legal conclusion.
Related: Keep requested results separate from later promotion · Test consent and suppression at send time
Measure partial state without changing the denominator
Report started journeys, saved partials, resumed journeys, completed journeys, expired records, and deleted records as separate counts. A partial-capture feature can increase stored rows without changing completion. Keep a stable start definition and calculate resume rate only from partial records eligible to resume; calculate completion rate from the same declared start cohort and observation window used before the change.
Do not interpret a higher number of partial records as more leads. Compare downstream quality only after completion and eligibility under the same definitions, and preserve quiz and rule versions so a release boundary remains visible.
Related: Define denominator-safe funnel metrics · Measure downstream lead quality
Partial-response release checklist
Enable durable capture only when every control has an owner and a testable result.
- The purpose, data owner, and participant benefit or operational need are explicit.
- The trigger distinguishes active, abandoned, partial, completed, expired, and deleted states.
- The record contains only fields necessary for the declared purpose.
- The interface explains saving, recovery, errors, and expiry in clear text and accessible status messages.
- Requested recovery or result delivery is separate from marketing permission.
- Partial records cannot qualify, route, or enter nurture without the declared eligibility state.
- Promotion, integration retries, and messages are idempotent.
- Retention, review, deletion, and anonymisation rules are documented and tested.
- Metrics preserve stable denominators and label partial state separately.
- A correction path and responsible owner are visible.
Sources: W3C, Multi-page forms · W3C, Understanding status messages · ICO, Storage limitation principle
What this method cannot decide
This method does not establish that partial capture will improve completion, guarantee reliable recovery across devices, determine a universal inactivity interval, or provide legal advice. Vendor behavior, integrations, browsers, retention duties, and applicable marketing rules vary.
The examples are synthetic and the vendor documentation is used only to show that implementations differ. Test the actual configured journey, integration, storage, and deletion behavior before release.
Evidence
How to reproduce the method
A purpose-first decision matrix, six-state lifecycle contract, permitted-action guardrails, five-step decision method, worked recovery example, denominator-safe measurement plan, and blocking release checklist, verified against current Typeform, W3C, and ICO primary guidance on October 12, 2026.
Limitation
Where this conclusion stops
The method does not prove that saving incomplete records improves completion, choose a universal inactivity or retention period, guarantee cross-device recovery, or provide legal advice.
Sources and verification
What this guide relies on
- Typeform Help Center, Capture partial responses after every question
- Typeform Help Center, Save and return to your form later
- W3C, Multi-page forms
- W3C, Understanding status messages
- ICO, Data minimisation principle
- ICO, Storage limitation principle
- The Lead Quiz Review editorial methodology
Sources and method checked October 12, 2026. External standards are linked to their primary publishers. Request a factual correction.