1.png){kind=small}
Client-IP trust boundary
Use the server-observed address, or a deliberately configured trusted-proxy path, to avoid treating arbitrary forwarded-IP claims as authoritative.
Survey quality & respondent integrity
Understand the checks behind each response.
Connect audience screening, in-house quality signals and clear project rules. Know what was observed, what needs review and how an outcome will be reconciled.
Five connected layers
What we assess, and why it matters.
First-party observations and configured network intelligence support the agreed screening and quality policy. Review the available control set before traffic opens.
01 Network and entry checks
Assess the network context of an attempt while keeping the source and limits of that evidence clear.
Geo-IP and country fit
Compare available network-country evidence with the study's permitted markets. IP location is an estimate; it does not establish residence or precise physical location.
VPN, proxy, Tor and hosting indicators
Configured IP intelligence can identify known network-risk classifications, including hosting or data-centre traffic. Coverage and successful provider lookup matter; no list identifies every disguised connection.
ASN, ISP and reputation context
Available connection and abuse indicators help investigate unusual traffic. A risk score supports the project policy; it is not a verified probability that a person is fraudulent.
Optional WebRTC consistency
With trusted STUN endpoints and browser support, public network-candidate observations can add context to IP consistency. This is observation-only evidence, not a universal VPN detector or DNS-leak test.
Availability: network enrichment needs a configured provider; WebRTC is optional and may be unavailable or inconclusive.
02 Duplicate and session controls
Same-study re-entry
Account, attempt and browser-session history help recognise repeated participation in the same project.
Repeated IP and entry velocity
Review repeated project IPs and unusual entry frequency associated with IP or device evidence under project-specific rules.
First-party browser identifiers
Cookie-derived observations can connect recorded attempts. Returning-browser evidence may also provide context when network addresses change.
Rendering-repeat evidence
Available Canvas and WebGL observations contribute consistency evidence alongside other recorded signals.
IP duplication and respondent duplication are different questions. Households, offices and mobile networks can share an IP; browser identifiers can be reset, restricted or shared.
03 Browser and device consistency
Canvas and WebGL
Supported rendering and graphics-environment observations help compare browser environments. Privacy settings can restrict these signals.
Fonts, display and browser environment
Limited font/display probes and browser-exposed environment attributes add supporting context. These are not a complete installed-font or hardware inventory.
Language and timezone context
Browser settings can support consistency review when comparable network evidence is available. Different settings alone do not prove a false identity.
Automation and storage hints
Available automation flags, cookie and storage observations are interpreted under the configured policy. Missing storage or a privacy-protected browser is not inherently malicious.
Optional media-device counts
Respondents may opt in to sharing browser-visible microphone, camera and speaker counts. This check collects no device labels or IDs, records no audio or video and does not inspect installed drivers. Browser permissions can limit what is visible.
Device fingerprints are probabilistic observations. They do not establish a universal physical-machine identity, hardware ownership or confirmed VM/RDP use.
04 Interaction and response quality
Screening activity
Observable visibility and pointer, keyboard and form-event totals on platform-controlled screening pages provide supporting activity context.
Completion timing
Unusually fast, late or conflicting returns can enter completion review. Estimated LOI is a planning measure, not a universal minimum valid completion time.
Qualification and response review
Agree eligibility, consistency and relevant open-ended response checks for the study. Client-hosted answers require suitable access or client-provided data for review.
Screening observations do not measure continuous activity inside an external client's survey. Missing callbacks are unresolved return evidence, not proof of inactivity or abandonment.
05 Decisions, exceptions and recovery
Agreed policy actions
Project rules distinguish monitoring, review and blocking. Some configured rules can prevent participation; observation-only controls remain supporting evidence.
Clear evidence states
Keep detected, clear, disabled and unavailable observations distinct. Unavailable evidence establishes neither a clean result nor fraud.
Recorded outcomes and review reasons
Use available evidence and documented reasons to investigate exceptions, review held completions and reconcile client validation.
Agree who can review or change an outcome, which evidence is required and how outstanding cases will be handled.
A practical quality checklist
Quality belongs across the fieldwork journey.
Before launch
Agree the rules.
Confirm audience eligibility, permitted sources, quotas, device requirements, redirect tests, available controls and review responsibilities.
During fieldwork
Follow the evidence.
Monitor source outcomes, quota movement, qualification patterns, available signals and exceptions. Check what changed before intervening.
At handover
Reconcile the outcome.
Separate provisional results, reviewed cases and accepted delivery. Document relevant exclusions, corrections and unresolved records.
Genuine participation
Leave room for context.
Shared networks, ordinary timing variation, accessibility tools and changing mobile connections need fair consideration. A changed IP or missing browser signal is not automatic proof of fraud. Review routes and configured blocking rules should be understood before launch.
Technical boundaries
Describe what is observable.
Browser checks do not reveal MAC addresses, hardware serial numbers or a full driver inventory. Rendering hints do not confirm virtual-machine use. WebRTC observations are not DNS-resolver testing. Our quality plan should reflect the evidence actually available.
Start with your study
Agree a quality plan your team can assess.
Share the audience, countries, sample size, LOI, source restrictions and client validation requirements. Agree the configured checks, reporting scope, unavailable-evidence handling and review process before launch.