Reporting

The reporting functionality is accessible through the Reports menu in the left sidebar. Clicking it opens the reports list directly with all available reports, including the Quota Report. The reporting page provides the following options:

Note: All interactive analyses now live under the Analysis menu (see Section 10): clicking it opens a hub with Contingent valuation, Discrete Choice Analysis and Interactive Dashboard. The Discrete Choice Simulator is reached from the Discrete Choice Analysis Report itself (see Section 10.4) since it consumes the model that was just estimated. Careless-responding analysis lives in this Reports page too — the Generate Careless Indices / Careless Indices Report rows (see Section 9.12) — since it produces a downloadable artefact.

9.1 Complete Report (SPSS Export)¶

Generates a comprehensive Excel file containing all survey response data. This report includes all respondent states: Complete (Done), Early Screen Out, Low Quality, and Quota Full. The file is formatted for easy import into SPSS or other statistical software. A progress bar is displayed during generation for large surveys.

Important: This report only includes respondents who advanced beyond the first step of the survey. If a respondent views the first screen but abandons without advancing, no response data is recorded and they will not appear in the report. This means the number of respondents in the report may be lower than the total number of views shown in the survey listing.

9.2 Quota Filters Report¶

Downloads an Excel report showing the current status of personalized quota filters, including how many slots have been filled and how many remain for each filter combination.

9.3 Translation Report¶

Generates an Excel file containing all configured texts in the survey with identification codes. This report is used for the manual translation workflow: download the report, translate Column 4 into Column 5, and upload the translated file to a duplicated survey. See Section 2.11 - How to Translate the Survey for the complete translation process.

9.4 Step Times Report¶

Downloads an Excel report with average response times per step. This is useful for identifying steps where respondents spend too much or too little time, which can indicate problematic or confusing questions.

9.5 Workflow Graph¶

Displays the survey's step-and-rule structure as an interactive visual graph. Features include: - Zoom and pan navigation - Node selection with outgoing branch highlighting - Tooltips on branches showing the condition for each transition - Contextual help button (?) explaining all available interactions

Clicking the question IDs next to a node opens a "Step N Questions" tab that lists every question on that step. At the top of this list a "Preview all questions" eye button opens a modal that renders the whole step exactly as a respondent sees it (the same respondent-preview used by the eye icon in the question list), so you can review the step's wording and layout without leaving the report.

Coverage badge per node¶

Each node carries a small pill above it that reports how the survey is being covered by the completed respondents (those whose final state is Done). The pill shows two numbers separated by a middle dot — the count of distinct completers that visited that step, and the percentage over the total of completes. For instance 42 · 78,5% reads as forty-two of the completers went through this step, which is 78.5% of all completers.

The header of the report also shows the denominator explicitly (Coverage based on N completed responses) so the percentages can be re-checked at a glance.

Three visual states tell the researcher what is happening: - White pill with the numbers — normal state: completers are reaching the step. - Red pill 0 · 0% — the step is in the workflow but no completer ever reached it. Useful during piloting to spot orphan branches: a rule pointing to a step nobody can satisfy, a condition typo, or a section that became unreachable after a structural edit. - Gray "no completes" pill — the survey has zero Done respondents yet. Common while configuring the workflow before launch; the badges will populate once respondents start finishing the survey.

The data is recomputed on every load of the Workflow Graph report (no manual refresh needed) directly from the per-step traversal table that the runtime keeps for every respondent — no XML iteration involved, so it is fast even for surveys with thousands of respondents.

Drop-off pill per node¶

Below each step, a small amber pill ↓ N appears whenever there are respondents whose last visited step was this one but who did not finish the survey. It complements the coverage badge above the node — the white pill tells you who reached the step among completers, the amber pill tells you who got stuck on that step among non-completers.

The pill is silent when nobody dropped off there: a step where every visitor moves on shows no amber pill at all. This way the markers only appear where they carry information.

Hover the node to see the full breakdown by terminal state in the tooltip:

Stuck on this step:
  In progress: 5
  Early Screen Out: 4
  Quota full: 2
  Quality terminate: 1

How to read each state: - In progress — respondent opened the survey, reached this step, and never finished or quit. A high count concentrated in one step is usually a sign of UI confusion or an unexpectedly hard question. - Early Screen Out — respondent was rejected by a screen-out rule. Concentration on a particular step is generally expected (that step is the screener) and confirms the screener is working. - Quota full — respondent met a quota that was already full. Same logic as Early Screen Out: concentration on the quota step is normal. - Quality terminate — respondent was kicked out by a quality rule (careless answers, speeding through the survey, etc.).

Rule firing count on each edge¶

Every edge of the graph (every rule) gets its firing count appended to its label, e.g. $P5 == 'R5_1' · 47x. The number is the count of distinct completed respondents that walked that transition during the pilot.

This breaks down what the coverage badge alone cannot show: when a step receives several incoming rules, the badge says "100 completers reached this step" but doesn't tell you whether they came 80/20 from one branch or 50/50. The edge labels do.

A rule with 0 firings in a survey that has at least 5 completed responses is painted in orange as a dead rule. That is a strong hint that something is off: - The condition references a question that is never answered the way it expects (typo, wrong response code). - The rule is unreachable because an earlier rule with a broader condition always fires first. - The branch is intentionally rare — in which case orange is a reminder to confirm the design rather than evidence of a bug.

Below 5 completes the orange tint is suppressed (the data is too thin to claim a rule is dead) and rules just appear in the default gray.

Survey Design Review Agent — pre-pilot static validation¶

Sibling of the Pilot Review Agent below, but runs before the pilot starts. Use it as soon as the workflow tree is configured to make sure the design itself is consistent — orphan steps, dead-ends, paths that never reach a final step, rules referencing questions that don't exist or aren't asked yet, $condUserX flags read by a rule but never set in any preceding Groovy script, and similar structural issues. Detection is purely deterministic (no respondent data needed, no LLM in the analysis loop, no false positives in the catch).

The shield-icon Run Survey Design Review button lives on a new Design Review tab right next to Workflow Graph. Clicking it analyses the workflow in seconds and produces a table of findings grouped by severity. Each finding includes a plain-English explanation and, where applicable, a concrete suggested fix — these come from a small Gemini call that runs after the deterministic analyser; if Gemini is unavailable, findings are still saved with their technical title (you'll see "narrative unavailable" in the metadata line).

Severity levels:

error — the workflow is broken in a way respondents will hit: the analyser is sure something is wrong (orphan step, undefined question reference, $condUserX never set, etc.).
warning — the workflow runs, but the design looks suspect: a question declared in the survey but never assigned to any step, or a condition the static parser couldn't fully analyse.

Each issue is presented with the affected step / rule, the referenced token (e.g. $P3, $R1_2, $condUser5), the rule's condition verbatim, and the suggested fix. Re-runs are free and idempotent — fix an issue, re-run, the issue disappears from the table.

Unlike the Pilot Review Agent, the Design Review tab is open to every researcher with access to the survey — there is no superadmin gate. The button just needs you to have the survey selected in your session.

Dismissing a false positive. Some error-level findings are intentional — for example, a step you deliberately left unreachable so it is never shown to respondents. Because the Audit and Pre-pilot pipeline gates require 0 open error-level findings before you can advance, an intentional finding would otherwise block the pipeline. Each finding row therefore has a Dismiss action: click it (optionally adding a reason) to mark the finding as an intentional false positive. Dismissed findings are struck through, drop out of the open-error count, and stop blocking the gate; the gate detail then reads e.g. "0 open errors (1 dismissed) / 0 warnings". Use Restore to undo a dismissal.

Dismissals are stored per survey by the finding's signature (its type + step + rule + referenced token), so they persist across re-runs: when the Design Review re-runs automatically on entering Audit / Pre-pilot, the same intentional finding stays dismissed. If the underlying design actually changes (so the finding's signature changes), it reappears as a new open error and blocks again — exactly what you want. Every dismissal records who did it, when, and the optional reason. A dismissal that no longer matches any finding is simply ignored.

Pilot Review Agent — AI-assisted inconsistency detection¶

Once you have a handful of completed responses (typically during piloting, before the full launch), the magic-wand button Run Pilot Review Agent (5 random Done) on the Workflow Graph toolbar runs an automated review of 5 randomly-sampled completers. The analysis sends the survey definition, the workflow tree, the Groovy scripts attached to steps, and the actual answers + trail of each respondent to a large language model and asks it to flag any inconsistency between what the rules dictate and what the respondents really did. It takes about 2 minutes. Re-running the analysis draws a new random sample, so successive runs broaden the coverage and may surface different findings.

Three families of finding are reported:

Wrong destination — the respondent went somewhere the rules, evaluated against their actual answers, would not have routed them. Most common cause: a typo in a condition, or a rule with broader scope that intercepts before the intended one. This is the most actionable type — usually a real bug.
Unevaluable condition — a rule's condition references a question that doesn't exist or wasn't answered yet at that point in the trail. Suggests a stale rule from a question that was renamed or deleted, or a rule that depends on a Groovy script that didn't run.
Unmapped transition — the respondent took a step that no rule from the previous step contemplates. Typically the back button (benign), but flagged so you can confirm.

When the same problem affects several respondents (e.g. four people with P3 = R3_2 all routed to the wrong step) they are grouped into a single finding labelled with the affected user IDs. This surfaces systemic bugs rather than burying them as isolated cases.

Each finding includes a plain-language explanation of why it is inconsistent and which rule or Groovy script is implicated, so the researcher can jump straight to the fix without having to re-read the workflow.

The findings live on a new Pilot Review tab next to Workflow Graph and Questions. The tab carries metadata (when the run happened, how many findings, how many respondents analyzed) and a filter dropdown by finding type. The same edges that have findings are painted purple on the graph; clicking a purple edge filters the table to show only the findings for that specific transition, so you can drill from the visual to the detail in one click.

Re-runs are allowed at any time (the Re-run button on the tab) and create new run records — the old runs are kept in the database for traceability so you can see findings shrink as you fix bugs.

The button is disabled until the survey has at least one completed response, and the cost of each run is a fraction of a cent (Gemini Flash). The analysis is pilot-targeted by design: 5 random respondents per run are enough to detect systematic bugs without being overkill for an interactive review action — and rolling the random sample on each re-run lets the researcher steadily widen the inspected population over multiple runs.

Generating the PDF Pilot Review Report¶

Once the agent has been run at least once, the Pilot Review tab gains a Pilot Review Report (PDF) section near the bottom. The magic-wand button Generate Pilot Review Report (PDF) triggers a Gemini-written narrative summary that wraps everything together: the survey state breakdown (completed, in progress, screened out, quota full, quality terminate), the workflow coverage, the drop-off per step, the rule firings on each transition, and the routing inconsistencies the agent detected — all bundled into a single PDF that lives in the survey's data folder. Generation takes 1-2 minutes.

After generation the PDF is listed in a small table below the button, with download links and timestamps. tickStat staff sees an additional Send to admin + shared button next to each report; clicking it dispatches the PDF by email to the survey administrator and to the colleagues with whom the survey has been shared, with a mandatory cc to tickStat support. Researchers without tickStat staff role do not see the Send button — the dispatch is gated as a deliberate human review step before the report leaves the platform.

The report itself includes: - Cover page with survey name, id and generation date. - AI narrative with executive summary, an interpretation of how the pilot is going, a synthesis of the agent's findings, and a prioritised list of recommendations. - Tabular data: respondent state counts, per-step coverage, per-step drop-off broken down by terminal state, edge firings per transition, and the full list of agent findings.

Re-running the agent or the report generation produces a new PDF without overwriting the previous ones — the folder accumulates the history so the researcher can compare snapshots over time as bugs get fixed.

9.8 Interactive Dashboard¶

Displays survey results as interactive charts and graphs with cross-filtering capability. Click on any value in a chart to filter all other visualizations. Supports radio, checkbox, matrix (radio, checkbox, dropdown, numeric), dropdown multiple, predefined-list (listaValores), and importance question types — list-based demographics such as country, region, or province are now available both as charts and as cross-filter chips. Includes an Export PNG button to download the dashboard as an image.

Per-widget download and copy. Every chart card has two small action buttons in its top-right corner:

Download as PNG (download icon) — saves a high-resolution PNG of just that widget (chart, stats line and header). The filename is built from the survey id, the question code and a short slug of the question title — e.g. dashboard_1304_P5_satisfaction_overall_2026-05-15.png — so you can drop several files into a folder and still recognise them.
Copy image to clipboard (clipboard icon) — copies the same PNG to the system clipboard so you can paste it directly into a document, slide, email or chat (Office, Google Docs, Slack, etc.) without going through a file. A green check briefly replaces the icon when the copy succeeds, a red cross when it fails (older browsers without the Clipboard image API will see the cross — fall back to Download as PNG in that case).

The buttons are hidden during capture so they never appear inside the exported image. Use them when you need to share a single widget (a specific question's distribution, the Survey Completion time box plot, an Importance histogram, …) without exporting the whole dashboard.

The dashboard exposes two sync controls:

Refresh Data runs an incremental sync — it processes only respondents whose surveys have been completed since the last sync. Use it to bring fresh answers in without reprocessing what is already there.
Reset Data wipes all dashboard data for the survey, leaving the dashboard empty. After confirming the reset, press Refresh Data to repopulate from the first respondent. Use this when a backend update adds support for new question types (so already-synced respondents include the new fields) or when the data looks inconsistent.

Tabs. The dashboard is split into three tabs that share the same stats bar, filter chips and toolbar (Refresh / Reset / Export PNG):

Questions (default) hosts the per-question chart grid and the question selector.
Timing hosts two survey-wide widgets that read live timing data from the per-step log (no sync needed). Any cross-question filter applied in the Questions tab automatically narrows the sample used by both Timing widgets.
Attention hosts the Attention Score widget (see below), available when the Attention Index feature is enabled. Like Timing, it reads live data and honours all cross-question filters.

Respondent segments (Questions tab): A fixed group of bar-chart cards pinned at the top of the Questions tab that let you segment results by respondent metadata rather than by an answer. Five dimensions are shown, each collected automatically:

Source — where the respondent came from (the seed/origin passed in the entry URL as &o=...), shown exactly as the panel sent it (e.g. cint, netquest) and matching the value exported to SPSS/Excel; respondents who arrived without an origin are labelled Direct.
OS — the respondent's operating system (Windows, Mac, Android, iPhone, …), detected from the browser.
Browser — the respondent's browser family (Chrome, Firefox, Safari, …), detected from the browser. Versions are not split out, so all builds of the same browser group into one bar.
Attention widget — whether the attention gauge was shown to this respondent (Shown / Not shown), i.e. the experimental arm when the gauge is sampled to a percentage of respondents.
Attention index — the respondent's AI attention score (the average of their completed per-step ratings, 0-10) bucketed into fixed 1-point bands (0-1, 1-2, … 9-10); respondents with no completed AI evaluation yet appear as Not rated. Because the score keeps updating while the AI evaluation queue processes the field work, bands are refreshed automatically on every Refresh Data — a respondent can move from Not rated to a band, or between bands, until all their steps are evaluated.

Each dimension behaves exactly like a question chart: bars are the distinct values (sorted most frequent first), and clicking a bar cross-filters the entire dashboard — every question chart, the Importance/NPS widgets and both Timing widgets re-scope to only the respondents in that segment, and a filter chip appears at the top. Click the same bar again (or remove the chip) to clear it. You can combine a segment filter with question filters (e.g. "OS = Android and Q5 = Very satisfied"). Values with an unrecognised browser/OS are grouped under a single Unknown bar. Respondents synced before this feature existed are backfilled automatically on the next sync — just press Refresh Data (no Reset needed) and the segments will cover every synced respondent.

Survey Completion Time widget (Timing tab): A full-width box-plot widget summarising how long respondents took to finish the survey. Only respondents with status Done are included; total time is the sum of all per-step durations recorded for each respondent. The header reports six statistics — Mean, Median, P25, P75, Min and Max — formatted as human durations ("45 s", "12 min 34 s", "1 h 5 min"). Below, a box plot draws the interquartile range (Q1–Q3), median, and whiskers from Min to Max, with jittered dots for individual respondents when the sample is 200 or fewer. Respondents who paused and resumed the survey contribute their full elapsed time (including idle gaps), which can inflate Max; the Median absorbs that bias and remains a robust summary. The widget is hidden when no Done respondents exist yet.

Time per Step widget (Timing tab): A vertical stack of per-step cards, one for each step of the survey, each card structured identically to the Survey Completion Time widget — full stats line (Mean / Median / P25 / P75 / Min / Max) and full-size box plot with Min / Q1 / Median / Q3 / Max markers and jittered respondent dots. Every step card is drawn on a single shared X-axis (with the global range printed above the stack) so the box positions can be compared directly: the step whose box sits furthest right is the slowest in absolute terms. The axis is capped at the P95 of all per-step observations to keep the boxes readable when a single sleeper respondent (someone who walked away mid-survey and resumed hours later) would otherwise stretch the scale; the few values above P95 pin to the right edge of the plot, and the note above the stack reports the maximum observed when this clipping is in effect. The "View questions →" link in each card's header opens a modal that previews all the questions on that step rendered exactly as a respondent sees them (the same respondent-preview used by the eye icon in the question list), so you can jump from "which step is slow?" to "what does this step actually ask?" in one click — without leaving the dashboard. The same Done-only and cross-question-filter rules as the Survey Completion Time widget apply; steps that no respondent reached under the current filter show a placeholder note instead of a box plot.

Attention Score widget (Attention tab): A full-width box-plot widget summarising the AI attention score per respondent. Each Done respondent contributes the average of their per-step AI ratings (0-10); the instant heuristic pre-scores are never used here — only completed AI evaluations count. The widget mirrors the Survey Completion Time layout: a stats line (Mean / Median / P25 / P75 / Min / Max), a box plot on a fixed 0-10 axis with the gauge's color zones drawn as background bands (red below 5, yellow 5-7, green above 7), and jittered respondent dots for samples of 200 or fewer. Below the plot, three clickable zone chips — Low (<5), Medium (5-7) and High (>7) — act as cross-filters: clicking one narrows the entire dashboard (question charts, Timing widgets, stats bar) to the respondents in that attention zone, with a filter chip appearing at the top, so you can instantly see how low-attention respondents answered compared to the rest. An Avg Attention stat card in the stats bar shows the mean score of the currently filtered sample. The tab shows an explanatory empty state until Done respondents have AI-evaluated steps.

Attention Queue widget (Attention tab): A monitoring card that shows how the AI scoring queue is keeping up with fieldwork. AI ratings are computed asynchronously — each screen a respondent submits is queued and scored shortly afterwards — so during intense fieldwork the scores can lag the responses. The chart shows, for the last 24 hours, two bars per hour — Enqueued (screens submitted by respondents) and Completed (screens scored by the AI) — plus a red Backlog line on the right-hand axis with the number of screens still waiting at each hour's end. When the two bars track each other and the backlog line stays near zero, scores are effectively real-time; a rising backlog means the queue is catching up and recent respondents will show their attention index with some delay (the queue always recovers on its own — no action is needed). Above the chart, a stats line reports the current queue state: Pending now (screens waiting), In flight (currently being scored), Failed (permanently failed evaluations, normally 0), Avg call latency (1h) (how long one AI evaluation takes) and Avg time to score (1h) (end-to-end time from a screen being submitted to its score being available). Unlike the rest of the dashboard, this widget reflects the queue itself and is not affected by cross-filters. The card is hidden when the survey has no attention data at all.

Importance widget (Questions tab): Dedicated widget for Importance of Topics questions (see Section 3.11), with two variants depending on how the question is configured:

Discrete scale (radio buttons): a histogram of all integer values on the scale (e.g. 1 to 11 by default), built with Chart.js. Click any bar to set it as a cross-filter for the rest of the dashboard. Bars use the same blue palette as radio question widgets, with the active filter value highlighted in dark blue. The stats line above the chart reports Mean and Median, and Don't know and No answer responses are counted separately so you can see at a glance how many respondents opted out of the scale.
Slider (continuous) variant: an SVG box plot drawn on a horizontal axis from the question's minimum to maximum, with the standard markers (Min, Q1, Median, Q3, Max) labelled on top of the box and jittered individual dots below the axis when the sample is small enough to be informative. The stats line shows Mean, Median and the observed Range, plus the same Don't know / No answer counters. The slider variant produces a continuous distribution that a histogram would bin away — the box plot preserves the spread and asymmetry of the responses.

Both variants honour any cross-question filter set in the Questions tab and respect the same Refresh / Reset sync model as the rest of the dashboard.

Data Quality tab (careless indices): Visual summary of the careless-responding indices computed by the Careless Indices Report. Because those indices are generated on demand on closed surveys, the tab starts with a coverage header that always states where the data stands: an explanatory empty state when no indices exist yet ("generate from the Reports section"), an amber banner when the snapshot covers fewer respondents than the survey's current completes ("Careless indices cover X of Y completed respondents — regenerate to refresh"), or a green line with the computation date when coverage is complete. Below it:

Distribution histograms for IRV (low = straightlining), Longstring max run (high = straightlining), Mahalanobis D² — with the portion of each bar belonging to respondents flagged as 99% outliers stacked in red — plus Even-Odd inconsistency and psychometric synonyms/antonyms when the survey's design makes them computable. An index that could not be computed (see the NA semantics in Section 9.12) simply hides its card.
A clickable "Mahalanobis outliers (99%)" chip that acts as a cross-filter, exactly like the attention zone chips: activate it and the whole dashboard — question charts, Timing, Attention — narrows to the flagged respondents, so you can inspect how they answered everything else.
A "Respondents to review" table listing the most suspect respondents (Mahalanobis flag first, then lowest IRV, then longest identical run) with their index values and item coverage. Deliberately without automatic cutoffs: the platform surfaces candidates, the researcher judges.

All Data Quality widgets react to the dashboard's active cross-filters like every other tab.

9.9 Access Statistics¶

Displays respondent traffic data for the survey, including total accesses, completed surveys, in-progress count, early screen-outs, quota full, and quality terminates. Shows daily access trends and hourly distribution for the most recent day.

9.10 Attention Index Report¶

Downloads an Excel report with all Attention Index ratings for respondents in the survey. This report is available when the Attention Index feature is enabled in the survey settings. The report includes: - Respondent ID and Step: Identifies which respondent and step each rating belongs to - Gauge Shown: Whether the attention gauge was presented to that respondent (Yes/No). Useful when the gauge is shown to only a percentage of respondents, to compare those who saw it against those who did not. See Showing the Gauge to a Percentage of Respondents. - Gauge Value Shown / Gauge Steps (AI) / Gauge Steps (Heuristic) / Gauge Visible: The exact running average served to the gauge after each step, which steps composed that average from the AI rating vs the instant heuristic pre-score (comma-separated lists), and a client-side confirmation that the gauge was actually on screen showing a real value during the step. These columns are filled for all respondents — including those who never see the gauge — so treatment and control groups carry symmetric data; whether the value was actually displayed is given by Gauge Shown plus Gauge Visible - Rating and Justification: The attention score (0-10) and the LLM's reasoning - Flags: Any attention flags detected (e.g., rushing, straightlining) - Heuristic Rating and Flags: When the instant heuristic feedback is active (see Instant Heuristic Gauge Feedback), each step also stores the rule-based pre-score and its rule flags alongside the AI rating, so you can compare both methods a posteriori - Survey User Number: The respondent's number within the survey (the n used in exports and data files), shown next to the internal Respondent ID on every row - Interaction Metrics: Click count, scroll count, focus/blur times, response changes - Mouse/Touch Metrics: Mouse distance, speed, pauses, hover on options (desktop) or touch count, distance, taps (mobile) - LLM Metrics: Latency, token usage, and model used for the evaluation

The workbook also contains a Summary sheet with one row per completed (Done) respondent: their survey-level Attention Index — the mean (0-10) of all their evaluated steps — together with the gauge-shown flag and how many steps the mean covers (Steps Rated). The index is stored on the respondent record and updates automatically as the evaluation queue completes each step, so once a respondent's last step has been evaluated the value is final. Respondents with no evaluated steps appear with a blank index. This per-respondent mean is the natural variable for comparing attention between groups (for example, the gauge-treatment arm against the control).

The Attention Index is computed by a Google Gemini model running on Google Vertex AI within the EU region (data stays in the EU). To keep scoring stable and reproducible, every evaluation uses a fixed seed and a low temperature, so identical inputs yield consistent ratings. Superadministrators can review the exact LLM configuration (model, temperature, top-p, seed, etc.) read-only in Settings > Quality Control.

Each screen produces at most one rating per respondent: if a respondent navigates back and submits the same step again, the new rating replaces the previous one (the latest interaction wins). Backward navigation itself ("Previous" button) never generates a rating — only forward submissions are evaluated, so partial visits do not lower the respondent's average. If an evaluation fails temporarily (e.g. the AI service is momentarily unavailable), it is retried automatically up to 3 times; after that the rating is marked as failed and excluded from the respondent's average.

Important — upload images before fielding. For steps that contain images, the Attention Index sends those images to Gemini from Cloud Storage. If the survey images have not been uploaded to the cloud, the affected steps fail silently and produce no rating. Before launching, press "Upload Images to Cloud" in Settings > Quality Control. When the Attention Index or Gauge is enabled, the Pre-pilot stage of the Experiment pipeline shows a dedicated checklist item reminding you to do this.

Respondent Gauge with Trend Indicator¶

When the Attention Index gauge is enabled, respondents see a small floating semicircular gauge that shows their average attention score (0-10). The gauge includes a trend indicator that compares the latest step rating with the previous one: - ▲ Green arrow: The last evaluated step scored higher than the previous one - ▼ Red arrow: The last evaluated step scored lower than the previous one - ● Yellow dot: The last evaluated step scored the same as the previous one

This visual feedback encourages respondents to maintain or improve their attention throughout the survey.

Gauge Position¶

The gauge position is configurable from the survey Settings (Quality Control section). There are two available positions:

Bottom-right corner (default): The gauge floats in the bottom-right corner of the screen. On desktop, it automatically shifts up when the Next/Finalizar button is visible to avoid overlapping.
Above Next button: The gauge is displayed inline, directly to the left of the navigation buttons (Previous / Next). On mobile devices, the Previous button is shortened to an arrow icon (←) to save space.

To change the position, toggle the "Gauge position: above Next button" checkbox in Settings. When unchecked, the gauge appears in the bottom-right corner.

Instant Heuristic Gauge Feedback¶

The gauge score normally comes from the AI evaluation queue, which can lag behind when many respondents answer at the same time (each AI evaluation takes several seconds). To keep the gauge responsive during large fieldwork waves, the platform can compute an instant rule-based pre-score (timing percentile against other respondents of the same step, tab switching, rushing signals, matrix straightlining, paste detection) and feed it to the gauge immediately.

Set "Heuristic gauge: min records per step (0 = disabled)" in Settings (Quality Control section). Default is 50: the heuristic activates for a step once at least 50 respondents have crossed that same step, because the pre-score is anchored on the step's own population baseline (timing percentiles). Steps with fewer records stay AI-only. Set 0 to disable the heuristic entirely.
In practice this means the heuristic "lights up" progressively from the first steps towards the last ones as the respondent wave advances through the survey.
The gauge is progressive: each step shows the AI score as soon as it is available and the heuristic score meanwhile — the value silently converges to the AI-based average as the queue catches up.
Every step is always evaluated by the AI regardless of this setting; the heuristic never replaces the AI rating in reports. Both values are stored per step for method comparison (see the Attention Index Report).

Showing the Gauge to a Percentage of Respondents¶

You can show the gauge to only a configurable percentage of respondents, instead of all of them. This turns the gauge into an experimental manipulation: one group sees the gauge (treatment) and the rest do not (control), so you can compare attention and behaviour between them.

Set "Show gauge to % of respondents (0-100)" in Settings (Quality Control section). The default is 100 (everyone sees it).
The decision is made once per respondent, at random, when they enter the survey, and stays the same for all their steps. For example, 50 shows the gauge to about half of respondents. With a few hundred respondents the split stays well balanced.
Whether the gauge was presented to each respondent is recorded per respondent so you can separate the two groups in your analysis.
This setting only affects the visual gauge. The Attention Index data is still collected for every respondent whenever the Attention Index feature is enabled, regardless of whether they saw the gauge.
When previewing the survey as a researcher, the gauge is always shown so you can check its appearance, ignoring the percentage.
Respondents in the gauge (treatment) group are shown a short informative message on the entry screen, telling them they will see an attention indicator and where to find it (the wording adapts to the configured gauge position: bottom-right corner or above the Next button). For these respondents this entry screen is shown even if no other pre-survey verification option is enabled (it appears together with the consent, reCAPTCHA or audio checks when those are enabled). Control-group respondents do not see this message.

Mobile Layout¶

On mobile devices (screens narrower than 768px), the gauge automatically adapts: - In above-button mode, it appears inline with the navigation buttons, aligned to the left. - The gauge size and border match the navigation buttons for a consistent look.

Internationalization¶

The gauge label ("Your attention") is automatically displayed in the respondent's language. The following languages are supported: Spanish, English, Catalan, Basque, Galician, French, German, Italian, Polish, Portuguese, Swedish, Greek, Croatian, Montenegrin, Slovenian, and Czech.

9.11 Enrichment Files¶

The Enrichment Files screen lets you attach external Excel files to a survey so their columns are merged into the Complete Report (Section 9.1) at generation time. Use it to add panel-side metadata, follow-up survey results, third-party validation, demographic enrichment or any data you keep outside tickStat but want to see alongside the survey responses.

Opening the screen¶

From the Reports list, click Enrichment Files. The screen has two sections: the table of files already uploaded for this survey and the upload form below.

Uploading a file¶

Pick an .xlsx file (max 5 MB). The first row must be the header — every data column you want in the report.
Once the file is selected, the Excel key column dropdown is populated with the file's headers. Pick the column whose values identify the respondent.
In Survey match variable, pick the survey-side variable to match against the Excel key. The dropdown lists the default report columns (Number of survey, Id User, Status, etc.), common URL parameters (lat, lon, id) and each question's variable name. If your join key is a custom URL parameter that doesn't appear in the dropdown, type its exact name in the text field below — the custom field takes precedence.
Click Upload. The platform validates the file and, on success, lists it in the table above.

Validation rules¶

Each upload is checked end-to-end. If any rule fails the file is rejected with a clear message and nothing is stored.

The file must be a parseable .xlsx with a header row and at least one data row.
Every header cell must be non-empty and unique within the file.
The chosen Excel key column must exist in the header.
The values in the key column must be unique across data rows.
No column in the Excel (apart from the key) may collide with:
a default report column (Number of survey, Init date, End date, Lat, Lon, Duration, Status, Source, OS, Browser, Id User);
any question's variable name in this survey;
a column added by a previously uploaded enrichment file in this survey.
The filename must be unique within the survey — delete the previous file first if you want to replace it.

Multiple files per survey¶

You can upload as many enrichment files as you want. Each one is joined against its own pair of (Excel key column, survey match variable), so different files can use different keys. Their columns are appended to the Complete Report in the order the files were uploaded.

Behavior in the Complete Report¶

When the Complete Report is generated the platform reads every enrichment file once and adds its columns to the end of the per-respondent rows. For each respondent the value of the chosen survey match variable is looked up in the Excel; a hit fills the new cells, a miss leaves them empty. The rest of the report (defaults, question columns, Choice tabs, Step Times) is unchanged.

Deleting a file¶

Click the trash icon on the table row. The Excel file is removed from disk and its columns disappear from future reports. Already-generated reports are not affected.

What is not included¶

Enrichment is currently applied only to the Complete Report. The per-question reports, NPS report, Choice tabs and Quota reports do not include the enrichment columns.
The metadata of an enrichment file (which key column, which match variable) is not editable. To change either field, delete the file and upload it again.
Only .xlsx is supported. CSV uploads are not accepted.

9.12 Careless Indices Report¶

Computes per-respondent careless responding indices with the R package careless (Yentes & Wilhelm; based on Curran, P. G. (2016), Methods for the detection of carelessly invalid responses in survey data, Journal of Experimental Social Psychology, 66, 4-19) and downloads them as an Excel file, one row per completed respondent. These indices quantify low-effort answering patterns from the recorded answers alone — no extra questions, no in-survey tracking — and are a standard convergent-validity criterion in the survey-quality literature.

Requirements and flow. The indices can be generated at any point in the survey lifecycle — during fielding to monitor data quality, or after the survey is closed for the final dataset. Each run is a snapshot computed from scratch over the respondents completed so far, so the values (especially the sample-relative Mahalanobis distance) can shift as more respondents complete; the dashboard's Data Quality coverage header states how many of the current completes a snapshot covers. The Reports list has two rows: Generate Careless Indices (computes the indices; a spinner shows progress and the result reports how many respondents and items entered the matrix) and Careless Indices Report (downloads the Excel; if no indices exist yet, a message asks you to generate first). Re-running Generate replaces the previous values.

Review Rank. The Excel includes a Review Rank column (1 = most suspect) using the same transparent ordering as the dashboard's Respondents to review widget: Mahalanobis 99% outliers first, then lowest IRV, then longest identical run. Sort the sheet by this column to review respondents from least to most careful. It is deliberately an ordinal rank rather than a weighted composite score — the careless literature advises against ad-hoc composites, and each index should still be judged on its own.

Indices and how to read them:

Index	Meaning	Careless direction
Longstring Max / Avg	Longest / average run of identical consecutive answers	Higher = more careless (straightlining)
IRV	Intra-individual response variability (SD of a respondent's answers)	Lower = more careless (invariant responding)
Mahalanobis D² + Flag	Multivariate distance from the average response pattern; the flag marks outliers at 99% confidence	Higher = atypical pattern (potentially careless)
Even-Odd	Inconsistency between the even and odd items of each multi-item block (the package returns the negated within-person even/odd correlation)	Higher = more careless; values near -1 indicate consistent responding
Psych. Synonyms	Within-person correlation over item pairs that correlate ≥ .60 in the sample	Near zero or negative = careless
Psych. Antonyms	Within-person correlation over item pairs that correlate ≤ -.60	Near zero or positive = careless

Which answers feed the indices. Single-answer radio questions (all radio variants), Importance 0-10 questions (except slider and NPS visualizations) and the agree-list rows of matrix questions (the natural Likert battery: one item per row). Questions flagged as bogus items are excluded — they have a designed correct answer that would distort the indices. Choice cards are also excluded (choice attention has its own criteria: the dominated card and per-respondent model fit).

Visual summary. Once generated, the indices also feed the Data Quality tab of the Interactive Dashboard: distribution histograms, a Mahalanobis-outlier cross-filter and a "respondents to review" table, with a coverage header that warns when the snapshot lags the survey's current completes.

Empty cells (NA) and branched flows. An index that cannot be computed is left empty rather than guessed: psychometric synonyms/antonyms need enough highly-correlated item pairs, Even-Odd needs at least two multi-item blocks, and Mahalanobis needs more respondents than items. When the survey branches, each respondent only answers part of the item matrix: unseen questions are NA, every index is computed over what the respondent actually answered, and Mahalanobis restricts itself to the items answered by at least 90% of the sample (the common path). The Items Answered column reports each respondent's coverage — filter by it before trusting an index for a given respondent — and the Run Notes column records why an index fell to NA for the whole run.

Choice Analysis (Multinomial Logit)¶

Choice Analysis (Multinomial Logit) has its own dedicated page: see Choice Analysis (Multinomial Logit) for the full documentation.

Mixed Logit / Random Parameters Logit¶

Mixed Logit / Random Parameters Logit has its own dedicated page: see Mixed Logit / Random Parameters Logit for the full documentation.