Skip to content

7 min read

One participant, one row.

A repeat response can come from a refresh, a missing completion code, or someone who is unsure whether submission worked. It can also be deliberate. This guide explains how to prevent common duplicates and review the ones that remain.

How duplicate responses happen

The honest accident. A slow confirmation can lead someone to submit again. A missing completion code can lead them to retake the survey. Check the ending before assuming a repeat submission was deliberate.

The panel loop. A returned or withdrawn submission may reopen a panel slot. An earlier partial or complete response can remain in your survey data if the person returns.

The shared link. Someone may post or forward the survey link outside the panel. Those visitors can arrive without participant IDs, so decide how to handle responses that lack one.

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.

The three layers, weakest to strongest

1. Make completion clear. 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.

2. Remember the browser. A cookie or localStorage flag can block repeat visits in the same browser. It helps with accidental duplicates, but private windows and other devices bypass it.

3. Check the participant ID. 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, blocks repeat use of that ID across browsers and devices. The check must run atomically on the server so two simultaneous submissions cannot both pass.

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.

Design 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.
  • Count completes, not starts: someone who comes back begins a fresh response, and the abandoned partial never reaches results or exports.

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.
  • Leave duplicate checks until analysis when you could enable them before launch.

Detection, 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.

Document how you checked for duplicates, the exclusion rule, and how many responses it removed.

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 can stop repeat submissions from the same browser while its storage remains intact. Another browser, private window or device can bypass it. Use a participant-ID check as well when your recruitment process provides one.
Should I collect IP addresses to catch duplicates?
IP addresses are unreliable identifiers: people on shared networks can have the same address, and one person can use several. Collecting them also adds privacy considerations. Use the panel’s participant ID when one is available and disclose its use.
What do I do with duplicates I find after the fact?
Set a rule before collection, such as retaining the first complete response per panel ID. Keep the original data, report the number excluded, and handle payment under the panel’s rules.

Keep reading: Catching low-quality responses · Completion codes, set up right · Academic research · Screening participants

Start

Put it into practice.

Start free →

Start with 100 responses a month free. Pro includes 10,000 responses and the advanced research controls described in these guides.