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. The Careless Reports entry, previously in the Analysis menu, now lives in this Reports page 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.

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 two 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.

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.

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.

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 - Rating and Justification: The attention score (0-10) and the LLM's reasoning - Flags: Any attention flags detected (e.g., rushing, straightlining) - 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

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.

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, and Montenegrin.

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.

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.