"Prevent duplicate responses." "Limit to specific people." "Set a deadline." These come up constantly in survey design.
Google Forms has restriction settings — but almost all of them assume a Google sign-in, which hurts response rates when you send to external audiences. This guide covers the settings and gets into the actual cost.
The full scope of Google Forms response restrictions
| Restriction | Supported? | Required setup |
|---|---|---|
| One response per person | Yes | Google sign-in required |
| Specific domain only | Yes | Workspace |
| Response deadline | Yes | Workspace (or manual close) |
| Response count cap | No | Not native (Apps Script workaround) |
| IP restriction | No | Not possible |
| Password protection | No | Not possible |
Surprises some people: no response count cap, no IP restriction, no password. The Google Forms design philosophy assumes "verify identity via Google account." That assumption is the fork in the road for tool choice.
How to set up "one response per person"
1. Open Settings
Top tab "Settings" → "Responses" section.
2. Turn on "Collect email addresses"
Select "Verified." This means the respondent's Google account email is auto-recorded.
3. Turn on "Limit to 1 response"
Confirm the "Google sign-in required" notice appears.
That's it. A second submission from the same Google account is blocked with "You've already responded."
What this actually costs — the price of forcing Google sign-in
"One response per person" is convenient. It has side effects.
Side effect 1: Assumes everyone has a Google account
Google accounts are widespread among business users and younger demographics globally, but older audiences, certain industries, and some international markets still react with "Google login? what?" more often than you'd think.
Side effect 2: "I don't want to sign in" drop-off
The most material problem in practice: a non-trivial fraction of users close the form the moment a sign-in is required. Reasons:
- Don't want to use a personal Google account for work
- Worry "the company will see"
- Sign-in is friction they won't endure
- Security-minded refusal
Field reports put the drop between 10–30%. For many surveys, that loss outweighs the duplicate-prevention upside.
Side effect 3: Respondent's Google account gets logged
"Verified" means the respondent's real Gmail address is captured. Branding the survey as "anonymous" while logging a real Google identity creates a structural conflict that can erode trust in your anonymity claim.
Domain restriction (Workspace)
If you're on Google Workspace, you can require "Restricted to users in your organization":
Settings → General → "Restrict to users in [your-domain.com]"
Now only @your-company.com users can access. Ideal for internal surveys, useless for external.
Setting a response deadline
Workspace
Settings → Presentation → "Stop form on" scheduled close.
Free accounts
No scheduled close — you close the form manually. Apps Script automation:
function closeFormAtDeadline() {
const form = FormApp.getActiveForm();
form.setAcceptingResponses(false);
}
Set a trigger to run at the deadline. Works, but ops-heavy.
Response count cap (Apps Script)
For "first 100 respondents only," use Apps Script:
function checkLimit(e) {
const form = FormApp.getActiveForm();
const responses = form.getResponses();
if (responses.length >= 100) {
form.setAcceptingResponses(false);
form.setCustomClosedFormMessage('Sorry — we have reached capacity. Thank you for your interest.');
}
}
Trigger: "On form submit." Each submission rechecks the count and closes the form once the cap is hit.
The real topic — the trade-off between "restrict" and "respond"
Tighter restrictions cost response rate. This is unavoidable.
| Restriction strength | Typical response rate |
|---|---|
| No restrictions | 100% (baseline) |
| Deadline only | 95–100% |
| One per person (Google sign-in) | 70–90% |
| Domain restriction | 70–90% of eligible |
| One per person + deadline | 65–85% |
So the real question: is it worth sacrificing 30% of responses to prevent duplicates?
For example:
- Need n=100, audience of 500 → no restriction is the faster way to hit n in time
- Need n=100, audience of 200 → restrict to preserve data integrity
- Anonymity is a priority → "one per person" already conflicts with that
Don't reflexively reach for restrictions. Design with the response-rate / integrity trade-off in mind.
Cookie / IP-based duplicate prevention as an alternative
"Prevent duplicates without forcing sign-in" requires a tool with cookie- or IP-based detection:
- Cookie-based — block re-submissions from the same browser (no identity exposed)
- IP-based — flag mass responses from one network (problematic for shared office IPs)
- Device fingerprinting — survives cookie deletion (powerful, ethically contested)
These combine "no sign-in + duplicate prevention," which Google Forms structurally can't.
Decision flow
Q1: Is this an internal survey?
- Yes → Google Forms (domain restriction) works
- No → continue
Q2: Do you assume every respondent will use a Google account?
- Yes → "one per person" is fine
- No → continue
Q3: What matters more, duplicate prevention or response rate?
- Prevention → cookie/IP-based tool
- Rate → no restriction, accept some duplicates
Restrictions in Repoan
Repoan handles "duplicate prevention without sign-in" plus flexible restriction design.
- Cookie-based duplicate prevention — block same-browser resubmissions without Google sign-in
- Auto-stop at response cap — "first 100" set via standard UI
- Scheduled open/close — no-code time-window
- IP-based throttling — usable as bot defense
- Required URL parameter — "access only via the link in our email"
- Password protection — simple way to limit distribution
Wrap-up
Google Forms response restrictions:
- "One per person" forces Google sign-in → response-rate trade-off
- Domain restriction is Workspace + internal only
- No native response count cap, IP restriction, or password protection
The moment you decide "prevent duplicates," the gap between Google Forms' philosophy (account-based) and real-world respondents (some of whom refuse to sign in) becomes visible. Go back to the goal and decide whether you optimize for rate or integrity.
Related reading: