GUIDES7 MIN READ
One participant, one row.
Duplicate responses are quieter than bots and more common than fraud. Most are not even malicious — a back button, a refresh at the wrong moment, a participant who genuinely isn't sure their submission went through. But every duplicate is a row that violates the first assumption of nearly every statistical test: independent observations. This guide maps where duplicates come from and the three-layer defense that handles them without collecting anything invasive.
01Where duplicates actually come from
The honest accident. A participant submits, the confirmation is slow, they hit back and submit again. Or they lose the completion code and retake the whole study to get another one. On panels this is the most common source, and the participant is blameless — your flow was ambiguous.
The panel loop. Submissions get returned (timed out, withdrawn) and the study slot reopens — sometimes to the same person under panel rules, which may or may not be what your design wants. Meanwhile the earlier partial or complete data is already in your dataset.
The shared link. Your survey URL leaks out of the panel — posted in a Discord, forwarded to a friend — and now people with no panel ID at all are answering, some of them repeatedly, because outside the panel there is nothing to stop them.
The incentive chaser. Rare but real when payment or a prize draw is attached: second accounts, incognito windows, multiple devices. This is the only category that actively works against your defenses, and it is why the strong layer has to live on the server.
02The three layers, weakest to strongest
Layer 1 — make the honest path unambiguous. Most accidental duplicates disappear when the ending is unmistakable: a clear thank-you screen, the completion code displayed, the redirect firing. Nobody retakes a survey to find a code that is printed in front of them.
Layer 2 — browser memory. A one-response-per-browser flag (cookie or localStorage) politely turns away repeat visits from the same browser. Cheap, invisible, and defeated by incognito mode — which is fine, because it only exists to catch the casual case.
Layer 3 — identity you already have. On a panel, every participant arrives carrying a stable pseudonymous ID in the URL (PROLIFIC_PID, Connect's participantId, MTurk's workerId). Enforcing one response per panel ID, on the server, is the control that actually holds: it survives incognito windows, second devices, and cleared cookies, and it requires collecting nothing beyond what the panel already sent you. The enforcement must be server-side and atomic — two tabs submitting in the same second should still produce one row.
In Plumeform, layer 2 and layer 3 are the two checkboxes under Limits (“one response per browser”, “one response per panel participant”); the panel-ID check runs inside the database under a lock, and a returning participant is turned away at the door with a courteous already-responded screen rather than after ten minutes of answering.
03Design rules
DO
- Enforce one-per-panel-ID server-side; it is the only layer a motivated duplicate cannot route around.
- Show the completion code AND redirect — most retakes are people hunting for a lost code.
- Turn repeat visitors away at the first screen, before they spend effort answering.
- Decide the tie-break rule in advance (keep the first complete response) and report exclusions.
- Keep partial saves on, so a return-and-resume is a resume, not a fresh row.
DON'T
- Rely on cookies alone for anything with payment attached.
- Collect IP addresses as your dedupe key — noisy both directions, and an ethics-review cost.
- Punish the participant for your ambiguous ending; approve the person once and clean the data quietly.
- Forget the open-link case: if the URL escapes the panel, responses without a panel ID need their own decision rule.
- Deduplicate by hand in a spreadsheet at 2am. That is what the toggle was for.
04Detection, for the rows that got through
Whatever slips past prevention, catch in analysis. Sort by panel ID and look for repeats (including near-misses with whitespace or case differences — a hand-typed ID artifact). Compare submission timestamps: two completions from one ID minutes apart is a retake; identical open-text answers across different IDs is link-sharing or something worse. Response-quality flags help here too — retakes are often speeders the second time through, because the participant has seen every question before.
Then write one sentence in your methods: how duplicates were prevented, how many were excluded, and by what rule. Reviewers do not expect zero duplicates; they expect you to have looked.
Quick answers
Doesn't Prolific already prevent the same person taking my study twice?+
Prolific prevents the same account taking the same study twice through its own interface. Duplicates still arrive at your survey via back buttons, refreshes mid-submit, returned-then-retaken submissions, and links shared outside the panel. The panel controls its side of the loop; your survey tool controls yours.
Is blocking by cookie or localStorage enough?+
It stops the casual case — the same browser, same device, uncleaned storage. It does nothing against a second browser, incognito mode, another device, or anyone motivated by a payment. Treat browser checks as a courtesy layer, not a control.
Should I collect IP addresses to catch duplicates?+
It is weaker than it sounds and costs more than it looks. Households, offices, and mobile carriers share IPs (false positives), VPNs rotate them (false negatives), and storing IPs raises your privacy and ethics-review burden. A panel ID is the honest identifier — unique, consented, and pseudonymous.
What do I do with duplicates I find after the fact?+
Keep the first complete response, exclude later ones, and write the rule down before you collect ("first submission per panel ID retained"). Report the count. If payment is involved, approve the person once — they are one participant, however many rows they created.
Keep reading: Catching low-quality responses · Completion codes, set up right · Plumeform for researchers
Put it into practice.
250 responses a month free. Every control in these guides is built in.