Every panel operator knows the two numbers that decide whether a client renews: the geo-match rate and the duplicate rate. Get respondents from the wrong city, or let the same person answer twice, and the data is compromised — and the client finds out, because clients run their own duplicate checks. This post is about the operational setup that keeps both numbers clean: city-level proxy targeting combined with isolated browser profiles.

The operator's problem, stated plainly

Clients buy respondents matching specific geos — a metro area, a state, sometimes a ZIP cluster. Two things break this:

  • Geo drift: respondents recruited through generic VPNs or datacenter IPs whose geolocation doesn't match the quota cell. The respondent says Chicago; the IP says Ashburn, Virginia.
  • Duplicates: the same person entering through two doors — two emails, one device, one IP — and getting counted twice. At the respondent level it looks like two completes; at the data level it's one opinion counted twice.

Both are infrastructure problems, not people problems. Fix the infrastructure and the quality metrics follow.

City-level targeting: the geo layer

Country-level proxy targeting is not enough for panel work. Quotas are set at metro or state level, so the IP layer must resolve at least to the right city. What to require from a proxy provider:

  • City/state targeting in the dashboard — not just country.
  • Sticky sessions so a respondent's IP doesn't rotate mid-survey (a rotation reads as a different person and corrupts the session).
  • Residential IPs — datacenter ranges are the first thing client-side fraud checks flag, and they poison your panel's reputation with every major sample buyer.

Both providers covered in our proxy comparison offer city-level targeting and sticky sessions; the choice comes down to your volume and budget, not capability.

Isolated profiles: the identity layer

Geo targeting solves where. Isolated browser profiles solve who. The setup we recommend to panel operators:

  • One profile per respondent seat. Each seat gets its own browser fingerprint, cookies, and storage — the panel platform sees distinct devices, not one machine with a hundred logins.
  • One proxy per profile, geo-matched. The profile's timezone and locale match the proxy's city. A respondent seat "in" Dallas runs America/Chicago, en-US.
  • Naming that survives audits: PANEL_SEAT_CITY_NUMBER. When a client questions a complete, you need to trace it in seconds.

This is the same profile-per-unit discipline agencies use for client work (the brand ops guide covers the agency version); on the panel side the unit is the respondent seat.

The QA layer that proves it

Infrastructure gets you clean collection; QA proves it to clients. Run three checks on every complete:

  • Duplicate scan: fingerprint + IP + response-pattern matching across the entire panel history, not just the current study.
  • Geo verification: IP city vs. stated location vs. timezone — all three must agree.
  • Attention and speed: straight-lining detection and minimum-time thresholds per question block.

Report these numbers to clients proactively — duplicate rate, geo-match rate, attention-fail rate. Operators who report cleanly keep clients; the data quality conversation happens on your terms instead of theirs.

Team seats and handover

Panel operations outlive individual recruiters. Seats need roles (who can open which respondent profiles), a handover checklist (active studies, quota status, seat inventory), and 2FA on everything. When someone leaves, you revoke their seat — the profiles and respondent data stay with the operation. This is what team plans are built for; check the pricing page for how seats scale.

The honest economics

Per-seat infrastructure cost is small: proxy bandwidth per respondent seat is measured in hundreds of megabytes per month (see the cost math), and profile tooling is flat-rate. The expensive failures are re-fielding a compromised study or losing a client over duplicate data — both cost orders of magnitude more than the infrastructure that prevents them. Budget accordingly.

Operators: what are your current duplicate and geo-match rates? If duplicates are above 2% or geo-match below 95%, the infrastructure above is usually the fix — tell me your numbers and where you think the leak is.