LaBrowser / Docs
Examples Console

Participant Experience

What participants see and experience when using LaBrowser in a study.

Join Flow

  1. Researcher shares a join link (e.g., labrowser.app/join/my-study)
  2. Participant opens the link in their browser
  3. Page shows: study title, description, a unique start code, download links for macOS/Windows
  4. Participant downloads and installs LaBrowser (if they haven't already)
  5. Opens LaBrowser, enters the start code
  6. LaBrowser loads the study's start URL — participant begins browsing
Each participant gets a unique alphanumeric start code. This links their browsing session to the study without requiring personal information.

Install Help

Participants should always install LaBrowser from the join page they were given for the study.

  • If the download link fails, refresh the join page and try the same platform button again.
  • If the app says it is out of date, return to the join page and install the latest build from there before entering the start code again.
  • If macOS or Windows blocks launch unexpectedly, the participant should contact the researcher or study team rather than trying ad-hoc workarounds.
If a participant gets stuck, the safest next step is to return to the join page they were given and follow the install and launch steps there.

The Browsing Experience

LaBrowser looks and feels like a normal browser:

  • Tab bar with new tab button
  • Address bar with back, forward, refresh buttons
  • Full-page web content
  • Everything familiar — participants shouldn't feel like they're using a special tool

If the study has an experiment pane configured, it appears as a side panel alongside the browsing area. The panel can contain markdown instructions or an embedded web page (e.g., a Qualtrics survey).

Domain Enforcement

When a participant tries to navigate to a domain not in the allowed list:

  • The navigation is blocked
  • A friendly message explains that the site is outside the study scope
  • The blocked URL is logged as a NAVIGATION_BLOCKED event
  • The participant can go back or navigate to an allowed domain
Participants see a clean, non-technical message. They won't see error codes or stack traces.

Session Timeouts

If max_session_length_seconds is configured:

  • A warning appears when the session nears its limit (e.g., at 75% and 90%)
  • When time expires, browsing is disabled and a completion message is shown
  • All events up to that point are preserved

Data Upload

Events are captured locally first, then uploaded in batches:

  • Upload happens automatically in the background
  • If the connection drops, events queue locally and retry
  • When the session ends, a final upload sends any remaining events
  • Upload status is visible to the participant (subtle indicator)

Failure Recovery

If LaBrowser is interrupted, the usual participant experience is simple:

  • Study activity is saved continuously during the session
  • If the internet connection drops, uploads retry automatically when the connection returns
  • If the app closes unexpectedly, reopening LaBrowser can resume the session and continue syncing

Email Anonymization

When anonymize_emails is enabled (default):

  • Any email address typed by the participant is replaced with a deterministic token: [email:XXXXXX]
  • Same email produces the same token within a session (preserves analytical value)
  • Different sessions generate different tokens (prevents cross-session tracking)
  • Anonymization happens before data is stored — the plain-text email never touches disk