Including tracking and metadata in surveys

Tracking data collected during a pilot is cheap insurance against problems that only become apparent in main fieldwork. Collect it by default, evaluate it later.

What tracking and device metadata to collect in surveys, why to collect it even when you do not expect to need it, and how to use it for fraud detection and data quality monitoring.

Ben White, 09.07.2026

What tracking data is and why it matters

Tracking data is metadata about the survey session - device type, browser, IP address, completion time, cookie presence, mouse movement, and similar signals that are independent of the respondent's answers. It does not record personal data about the respondent; it records characteristics of the session.

Tracking data is most useful when something goes wrong - when a quality problem emerges in the data, when fraud is suspected, or when response patterns are unexpectedly different across subgroups. At that point, the presence or absence of tracking data determines whether the problem can be diagnosed and corrected.

Collect by default, evaluate later

The cost of collecting tracking data is negligible - a few lines of JavaScript and a hidden variable per tracking element. The cost of not having it when you need it is potentially the entire study. This asymmetry makes the decision straightforward: collect it by default.

Tracking collected during the pilot is particularly valuable. The pilot is the opportunity to identify which tracking signals are informative for the specific study population. If the pilot shows high VPN usage or unusual device profiles, tracking can be used to screen respondents in main fieldwork.

TLDR Quick links

Fraud detection in DCE fieldwork

Diurnal activity patterns as a fraud indicator

What to collect and how

Cookie detection: set a cookie on survey entry and check for it on return. Respondents completing the survey twice from the same browser are flagged. Implement as a JavaScript check on the first page with a redirect to a screen-out page for returning respondents.

Device type: capture screen width and user agent string. Flag mobile respondents if the survey is designed for desktop. Flag unusual screen dimensions that may indicate emulated devices.

Browser type and version: capture navigator.userAgent. Flag outdated browser versions and headless browsers (typically used by bots).

Completion time: record timestamp at survey entry and at each page navigation. Calculate total completion time and per-page times. Flag respondents below the minimum plausible completion time.

Mouse movement: for studies where respondent engagement is critical, track mouse movement and click patterns. Very low or very uniform movement patterns indicate automated completion.

CAPTCHA: add at survey entry to block automated completions. Standard implementations are a single HTML embed. Evaluate during the pilot whether the CAPTCHA is generating false positives with legitimate respondents.

Using tracking data to diagnose a fieldwork problem

A health preference study shows an unexpected spike in completion rate on day 3 of fieldwork. Tracking data collected during the pilot is applied to the main fieldwork dataset. Analysis shows 71% of day-3 completions originate from the same IP subnet, 89% used the same browser version, and the median completion time for the day-3 group is 40% below the pilot median.

Without tracking data, the quality problem would have been identified only in analysis - after the full budget had been committed. With tracking data, the suspicious completions are identified within 24 hours and the panel provider is contacted to investigate the source. The day-3 completions are excluded from the analytical dataset.