Want your course to tell you which answers learners chose, not just that they finished? This guide covers the handful of things our tracker needs from your build. It doesn't re-teach Storyline — where Articulate already documents how to build something, we link straight to their article.

In this article:

• How Reporting Reads Your Course
• Quick Reference: What Reports and What Doesn't
• Built-In Questions and Surveys
• Question Banks
• Drag-and-Drop Questions
• Result Slides
• Data-Entry Fields
• Course Completion and Exit
• Custom Interactions
• How Reporting Decides the Correct Answer
• More Warnings You Might See
• Naming Rules That Affect Reporting
• Course-Level Variables to Declare Now
• What Never Reports
• Check Your Course Before You Publish

Who this is for: anyone building Storyline courses whose learner responses should reach reporting. This covers how to build; using the tracker's web app and reading reports are documented separately.

How Reporting Reads Your Course

Two things decide whether an answer reaches reporting.

Built-in questions report themselves. Build a question with Storyline's own question tools — graded and survey questions, freeform drag-and-drop, question banks, result slides — and Storyline records the answer choices and the key inside your project file. Reporting reads them. You wire nothing.

Everything else reports only what's in a variable. For interactions you build by hand — games, custom puzzles, click-to-select widgets — reporting can read your project variables and nothing else. It cannot see:

• States. A tile that switches to its Selected state when a learner picks it looks identical to an untouched tile.
• Trigger conditions. Logic like "if these four shapes are Selected, show the success layer" runs inside Storyline and leaves nothing behind. Only its results — a variable you adjust, a layer you show — can be seen.

The one rule: an answer reaches reporting only if it's in a variable at the moment the learner submits.

Note: This is why a custom interaction can look perfect to a learner and report nothing at all. The interaction works; the answer was simply never written down anywhere reporting can read.

Quick Reference: What Reports and What Doesn't

* Warning: A known gap currently stops some built-in questions reporting at all. See Built-In Questions and Surveys.

Built-In Questions and Surveys

Use Storyline's question types wherever they fit — they give the most reliable reporting in the product, with no wiring from you.

How to build them: Adding Form-Based Questions · Adding Survey Questions · Adding Freeform Questions · Converting an Existing Slide to a Freeform Interaction

What we need from you:

• Real answer text in each choice. The text you type in Form View is exactly what appears in reporting.
• Keep the Submit button. It's how reporting knows the learner committed to an answer.
• Graded questions: mark exactly one choice correct.
• Surveys: mark no choice correct.

Now reporting: graded choice questions (Multiple Choice, True/False, Word Bank) and survey choice questions (Pick One, Pick Many, True/False, Which Word) report the learner's answer automatically — including which choice was picked on surveys, with no right/wrong recorded. Numeric entry questions also report the typed number. Still not reporting: Hotspot, freeform text-entry graded questions (the typed value still reports through its variable; the pass/fail does not), and Ranking surveys. A "select all that apply" question reports every choice the learner picked, whether the selection matched the answer exactly, and a score showing how much of the answer they found. If anything you built won't be reported, you'll see a warning when you upload — it names the variables that won't appear in your data.

Warning — Likert scale slides don't report. Storyline's built-in Likert survey puts several statements on one slide sharing one scale, and reporting cannot tell which statement a click belongs to — you'll see a warning at upload and no answers. To collect scale ratings that report today, build the scale yourself: one row of numbered buttons per statement, each button setting that statement's own variable (row one's buttons set Q1 to 1–5, row two's set Q2, and so on). Every row then reports separately.

Note: A stray correct mark on a survey choice no longer turns the survey into a graded question — reporting records the selection and ignores the mark. Still clear the key when you convert a graded question to a survey: the stray mark is flagged on upload, and the feedback layers are what actually separate graded from survey behaviour.

Note: Placeholder answer text like "This is a correct choice." reaches reporting exactly as typed — and shows learners which answer is right. Replace it before you publish.

Don't rename choice shapes to describe the answer. Names like Correct or Best Choice aren't used as answer text, and they reveal the key to anyone who opens the file.

Before you write an Essay or Short Answer question, remember reporting stores whatever learners type, exactly as they typed it.

Ask yourself what a learner could reasonably put in that box. "What did you find difficult about this module?" is safe. "Describe a time you handled a customer complaint" will collect names, and "Any other comments?" collects whatever they feel like saying.

You have three options, in order of preference:

1. Rewrite the question so it cannot invite personal information. Ask about the content, not about people.
2. Replace it with a built-in question type. A pick-one or rating scale gives you comparable answers and cannot collect anything you did not offer.
3. Keep the free-text question and mask the variable — tick it under Privacy Settings → Data Masking before you generate. Masked values are hashed before storage, so you will know the question was answered but not what was said.

If you are unsure, mask it. A masked variable you did not need costs you nothing; unmasked personal data you did not expect is a problem for you as the data controller.

Question Banks

Banks report each question as normal, plus which bank it came from, whether the draw was random, and how many questions were included — so reporting can tell "never saw the question" apart from "saw it and skipped it".

How to build them: Creating and Managing Question Banks · Drawing Slides from a Question Bank

What we need from you:

• Insert a draw. A bank nothing draws from reports nothing — one of our test courses has exactly that.
• Set randomisation and question count on the draw, which is where Storyline keeps them.
• If your bank slides use your own variables, name them question, answer, correct, and category. Reporting recognises these four and puts them first, keeping columns readable. Other names still report — they're just ordered after these.

Drag-and-Drop Questions

A freeform drag-and-drop reports every drag item, the drop target it landed on, and whether that was right — one row per attempt — plus a slide score.

How to build one: Drag-and-Drop Questions

What we need from you:

• Build it freeform, so the drag-item/drop-target pairings become the answer key reporting reads.
• Turn on correct/incorrect feedback, which gives each drag item its Drop Correct and Drop Incorrect states. Without them the slide reports drops but not right/wrong.

Don't build drag-and-drop with your own triggers. "When the learner drops [object]" triggers don't fire reliably in published output, and the answer key ends up in your trigger conditions where reporting can't read it. One of our test courses built all seven of its drag slides this way — the slides are recognised as drag-and-drop, but right and wrong can't be recovered at all.

Note: Deleting and re-adding items can leave stale pairings pointing at shapes that no longer exist. If a drag-and-drop has been heavily edited, rebuild the interaction rather than patching it.

Result Slides

A result slide reports the learner's score on arrival — score and pass points and percentages, whichever the slide shows.

How to build one: Adding Result Slides

What we need from you:

• Show the score on the slide. Reporting captures the values your slide displays, via the %Results.ScorePercent%-style references in your text.

Warning: Using score values only in trigger conditions — for example "jump to the next scene if Results.ScorePercent is greater than or equal to 80" — reports nothing. One of our test courses is a graded, must-pass course whose final score is invisible for exactly this reason. Put the value on the slide.

Note: A congratulations slide with no score on it reports no score. That's deliberate — empty score columns are worse than none.

Don't create your own variable with a dot in its name, such as Results.Score. Dotted names collide with Storyline's built-in variables and break reporting.

Data-Entry Fields

A data-entry field reports what the learner typed. Storyline creates and maintains the variable; reporting reads it when the learner clicks away, presses Enter, or leaves the slide.

How to build one: Working with Data-Entry Fields

What we need from you:

• Rename the variable. Use learner_name, not TextEntry3.

Note: Default names report perfectly well, but arrive as TextEntry1 through TextEntry4 — one of our test courses ships exactly that, and nobody can tell which field is which months later.

Don't build your own on-screen keyboard from letter shapes that each add a character to a variable. Two of our test courses do this, and the learner's name never reports cleanly. If you need a styled input, restyle a real data-entry field.

Course Completion and Exit

What we need from you:

• A trigger using the Complete Course action at each real ending.
• A trigger using the Exit Course action on your exit button.

Reporting records one completion and one exit per slide, so an exit button repeated across layers counts once. Wire them normally.

Note: A course that just stops reports no completion. One of our live courses exits without a Complete Course trigger, so no completion is ever recorded for it.

Don't rely on a "jump to URL" trigger as an exit. It opens a new window and the course keeps running, so it isn't treated as an exit.

Custom Interactions

Everything below applies when you build an interaction by hand instead of using a question type. A custom interaction has no answer key, so the variables you write are the only answers reporting will ever see.

Background reading, if you need it: Working with Variables · Working with Triggers · The Order in Which Triggers Are Executed · Working with Slide Layers

Why This Matters

A live course of ours — a connect-the-tiles game — tracked which tiles a learner picked entirely in Selected states, with one Number variable counting how many were chosen. Its submit button held two dozen triggers, each checking a specific combination of tile states.

Reporting could show that four tiles were picked and a life was lost, but never which tiles — so we could never learn which two options learners confused. Everything needed to answer that was on screen; none of it was written down.

Custom Pick-One

Set a Text variable to the choice's label on each choice's click.

Set answer to value Gemini Live when the learner clicks Gemini Live

The last click wins, which is exactly right for pick-one — clicking B after A leaves answer as B.

Note: Put the Set trigger above any trigger that jumps to another slide or shows a layer. Triggers on an object run top to bottom, so a value written after the course has moved on is never read.

Custom Pick-Many

Use one True/False variable per choice, and Toggle it on that choice's click.

Toggling handles deselection for free — each variable always matches its tile. At submit time, the variables are the answer.

Also give each choice a Selected state, and put a Submit button on the slide. That is the structure reporting reads most reliably. Reporting records every option the learner picked, not just the last one; on a question with a correct answer it is marked right only when the selection matches the answer exactly, and you also get a score showing how much of the answer they found, so "two of the three" is visible rather than just "wrong". For reporting to know it is a pick-many question, make the Submit trigger require all the correct options Selected together; otherwise you will be asked to choose the answer type in the app (see If you see "This question doesn't say whether learners pick one answer or several").

The True/False variables above are still worth setting — they are the clearest record of the learner's choices, and support reads them — but build the Selected-state and Submit structure as well, and verify after upload that a pick-many question shows all the options you ticked.

Don't build the answer as one Text variable that adds labels as they're clicked. Storyline can join text but can't remove it, so the first time a learner deselects something the variable is wrong for the rest of the course.

Don't rely on a count. A Number variable counting selections is fine for game logic — "three of four picked, enable Submit" — but a count is not an answer.

The Submit Moment

Give the interaction its own submit or confirm button. Reporting attaches to that click, so every answer variable must already be correct when the learner can click it — which they are, because they're written on the choice clicks.

To report right and wrong without working it out later, set a verdict variable on the submit click using the conditions you already use for branching — for example Set correct to value 1 when the right combination is chosen — placed above any trigger that navigates away.

Use a plain button, not one of the choice objects. Make the submit control its own object — a button that does nothing else. If you instead reuse one of the selectable objects the learner picks from, reporting can attach to the wrong click. Those objects usually only respond while they are in a particular state — Selected, say — so the trigger reporting attaches to never runs on the click that actually submits the answer, and nothing is recorded. The course behaves perfectly and the column stays empty.

The same applies to any object whose triggers are all conditional on its own state. If every trigger on your submit object starts with "when this object is Selected", it isn't a reliable submit moment. A learner should be able to click it once, in whatever state the slide is in, and move on.

If your upload warns that a tracker may not record anything, this is what it found: check which object your tracker is set to record, and point it at the plain submit button instead.

Give Every Interaction Slide a Way Forward

Reporting sends a learner's answers when they leave the slide — on the Next button, a submit button, or whatever trigger takes them onward. A slide the learner never navigates forward out of has no such moment, so anything they did there is never sent.

This bites on the last slide of a scene or course, where authors often place a summary interaction — a dial to set, a slider to position, a final choice — and then let the course simply end. The learner sets it, the course closes, and the value never reaches your reports.

Put the interaction on a slide the learner moves forward from. If the data matters on your closing slide, add a slide after it — a result, summary, or thank-you slide — and give the interaction slide a trigger that jumps to it. The learner's move onto that final slide is the moment their answer is sent.

A Back button doesn't count. Reporting follows the learner forward; a trigger that returns them to an earlier slide is not an ending, so don't rely on one to send an answer.

The same applies to any slide the learner cannot move forward from — not just the last one. A slide that only has things to click on it, with no trigger that jumps onward, has no moment to send from. If the learner is meant to do something there and you want the data, give the slide a way forward: a Next button, a Continue button, or a choice that jumps to another slide. A click that goes to another slide is what sends the data.

A button that does something is not the same as a button that goes somewhere

The button has to take the learner to another slide. A button that acts on the current slide and leaves them there does not send anything, however final it feels:

• Print — opens the browser's print dialog and stays put
• Submit that only shows a layer or a lightbox
• A button that runs JavaScript, plays media, or reveals a confirmation
• Exit or Close — the course ends, so there is no next slide to move to

This is easy to miss on a closing slide, because a Print or Submit button reads as the natural end of the activity. It is the end for the learner; it is not a moment that sends data.

A worked example — the reflection journal. A course ends on "Document and Print": three free-text boxes for what the learner will stop, start and keep doing, and a Print button. Every box is filled in and Print is clicked, and the report shows three empty answers. Nothing is broken — the slide has no trigger that goes anywhere, so there was never a moment to send from, and the text boxes had not yet handed their contents to their variables (typing alone does not do that — see Text Entry below).

Fix it by adding a step that navigates. Put a Submit or Continue button on the reflection slide that jumps to a short confirmation or summary slide, and put Print on that slide instead. The learner's move onto the confirmation slide is the moment their three answers are sent, and they can still print from there. One extra slide, and the reflections reach your reports.

Custom Question with Feedback Layers

If your choices open feedback layers, reporting can recognise the question and work out the right answer, provided:

• Choices lead to exactly two layers — one correct, one incorrect. All the wrong choices can share the incorrect layer.
• Those layers are named Correct and Incorrect (or Right, Wrong, Try Again). The layer name is what's read, not the text inside it.
• Your choices still set answer variables, if you want to know which choice was picked.

Don't give every choice its own feedback layer. Three or more destinations look exactly like a navigation menu and are treated as one.

Layer-Hosted Question

For questions built on layers — choices on one layer, feedback on others — reporting needs three things:

1. A verdict variable with correct in its name, such as question2Correct, set to a different value on the correct and incorrect layers.
2. Those layers named Correct and Incorrect.
3. At least one answer variable alongside it — either one per choice (question2AnswerA through question2AnswerD) or a single question2Answer set per choice.

Note: The word correct in the variable name must be English. A verdict variable named in another language isn't recognised.

Rating Scale

Have each choice set a different value on one shared Number variable. Identical values collapse the choices together; consecutive numbers (1 to 5) are recognised as a rating scale.

Warning: put each rating's variable on a slide the learner leaves with a button click — a Next or Continue of your own. A rating slide that relies on its timeline ending reports unreliably: learners who answer quickly leave before the report fires, and learners who linger get reported before their answer registers. In our test questionnaire the per-question ratings reported zeros or nothing, while the total — captured on a button click — was exactly right. If you keep a running total, capture it on the click that leaves the final rating slide.

360° Images and Explorable Slides

Exploration reports on its own: when the learner leaves the slide, one record shows how many markers they visited out of the total — however they leave, including through a menu. Two layout choices make the data much better:

• One 360° image per slide. Give each scene or area its own slide and navigate between them with jump-to-slide triggers rather than layers on one slide. Each slide then reports its own visited-of-total record, so you can see exactly which areas learners explored and which they skipped.
• End on a closing slide. Finish the course with a summary or thank-you slide. A learner who closes the course while still inside a 360° slide takes that slide's exploration record with them — arriving anywhere, including a closing slide, saves it.

Note: If a learner leaves an exploration slide and comes back, each visit reports its own record. Reports read the latest one, so revisits always show the most complete exploration.

Branch Menu or Scored Scenario

Menus — one click, one jump, no conditions — aren't reported as questions. The destination slide's own arrival already records the path.

If your scenario scores the choices, the score variable reports only where something captures it. In one of our test courses, each of seven decision slides records the choice the learner clicked, while the running score is invisible because nothing captures that variable. If the score matters, show it on a result slide or capture it explicitly on the final slide.

Note: Keep menu choices to a single trigger that only navigates. A choice that also changes states, plays media, or runs JavaScript stops looking like a menu choice.

Game or Select-Then-Submit Puzzle

For tiles or toggles feeding a submit button, reporting records one row per submission rather than one per click, which keeps data volume sane. That bounds the rows; it doesn't create answers. To know what learners picked, use the pick-many recipe above — those variables then ride along on every submission.

How Reporting Decides the Correct Answer

If a question has a right answer, reporting has to work out which option that was. There are three ways it can know, and they are not equally trustworthy.

A declared key — the only one you should rely on. Build the question with Storyline's own question tools and you mark the correct choice yourself. Storyline writes that key into the project file, reporting reads it, and the answer is recorded exactly as you set it.

The feedback layer an option opens — a guess, and reporting says so. On a hand-built question, reporting can sometimes infer correctness from the layer each option shows: the option that opens Correct is taken to be right. That works only while the layers are named properly and every option opens one.

Nothing at all. The question is recorded as an answer with no verdict.

If you see "This course doesn't clearly identify the correct answer"

Reporting is telling you it fell back to the second method — it guessed from your feedback layers rather than reading a declared key. The answer text is still recorded correctly. What is uncertain is whether it was marked right.

The quickest fix is in the app. Open the slide, look under Detected Pattern and choose the correct option (or Not graded under Answer type if the question is really a poll, a preference or a navigation choice). "Confirm" accepts the detected answer as it is. The warning then clears for that slide. The answer breakdown in reports follows your choice straight away; % correct uses it for responses from the next build you generate and republish. A re-upload of the .story file starts from the new parse, so a choice made here is discarded then.

To fix it in the course itself, in order of preference:

1. Rebuild it as a built-in graded question. The question tools declare a key and the warning goes away. This is the real fix.
2. If it must stay hand-built, name the layers exactly Correct and Incorrect and make sure every option opens one of them. See Custom Question with Feedback Layers.

Until you do one of those, check the recorded answer before you trust a correctness figure for that question. Everything else about it — which option each learner chose, how many chose it — is unaffected.

One trap worth naming. A question whose options all open the same layer, or whose layers are named Layer 1 and Layer 2, gives reporting nothing to go on. It will record the choices and no verdict at all, which is better than a wrong verdict but still not what you wanted.

If you see "This question doesn't say whether learners pick one answer or several"

Reporting decides whether a question is single answer or multiple answers from how the course is built — never from its wording, so "Select all that apply" in the question text changes nothing. It reads these signals:

When none of these applies — typically plain shapes a learner can tick several of, with a Submit that checks just one option — the course doesn't say, and you get this warning. Until you decide, the question is graded as a single answer with the detected correct answer, exactly as before.

Fix it in the app. Open the slide and, under Detected Pattern, choose the Answer type:

• Single answer — a response is correct only when the learner selected the correct answer and nothing else.
• Multiple answers — a response is correct only when the learner selected all the correct answers and nothing else; you also get a score showing how much of the answer they found.
• Not graded — for a poll, a preference or a navigation choice.

Then tick the correct answer(s). Your choice applies to % correct for responses from the next build you generate and republish; responses already recorded keep their verdict. A re-upload starts from the new parse, so the choice is discarded then.

Or fix it in the course, so every re-upload knows: group single-answer options as a button set, or make the Submit trigger require all the correct options Selected together for a multiple-answer question.

If you see "Tied answer scores leave the selected answer unclear"

A two-option question where neither destination tells reporting which answer was right.

What caused it: each option sends the learner somewhere — a layer, usually — but neither of those layers has a name reporting can classify. Layers called Layer 1 and Layer 2, or Path A and Path B, or Slide 3 and Slide 4 all produce this. Reporting has two destinations and no way to tell which one means "right".

What is recorded: the answer the learner chose. No correct answer is recorded, so the question has no score.

The fix — rename the two layers. Call them Correct and Incorrect. Right/Wrong, True/False and Try Again also work. The name is what reporting reads, not the words inside the layer, so renaming changes nothing a learner sees.

If the two destinations genuinely are not right-and-wrong — a branching choice where both are valid — then there is nothing to fix. The question is a survey, and the answer is recorded correctly without a verdict.

More Warnings You Might See

If you see "Repeated question text makes separate questions hard to distinguish"

The same question text has been recorded on three or more slides.

What caused it: almost always that reporting picked up the wrong text. One stem cannot genuinely be three different questions, so what it found is usually slide furniture that repeats on every question — an instruction like "Select the best answer", a heading like "Question", or a title that appears on every slide in the scene.

What is recorded: the answers are fine. The problem is that several different questions will appear in reports under one identical name, and nobody reading the report will be able to tell them apart.

The fix — set the real question text on each of those slides. Open each one in the tracker, and pick the text block that actually asks the question rather than the repeated instruction.

To stop it happening again, put the question itself in its own text box on the slide rather than relying on a layout where the instruction is the most prominent text.

If you see "An answer label may not match the learner's choice"

An option's recorded label is probably the name of one of its states, not its answer text.

What caused it: the option's shape has no text in its Normal state — all its visible text lives in a state instead. A tile whose Normal state is an empty box, with the words added in a Selected or Locked state, produces this. Reporting looks for the base text, finds nothing, and is left with text matching a state name — so it keeps it rather than record an empty label.

What is recorded: the choice is recorded, but under a label like LOCKED or Selected rather than the answer. Your report will show which option was picked and name it unhelpfully.

The fix — put the answer text on the shape's Normal state. Select the shape, make sure Normal is the active state, and type the answer text there. Keep whatever styling the other states add; reporting only needs the base text to exist.

If you see "Matching drop-down question is only partly captured"

This one cannot be fixed by changing settings — it is a limitation of how Storyline stores this interaction.

What is captured: the question, its rows, and the correct answers. What is not: which answer the learner actually selected. Storyline keeps each row's selection in an internal object property that a published course cannot read, so there is nothing for reporting to collect.

If you need learners' answers, rebuild the question as Multiple Choice, Matching Drag-and-Drop, or Pick One. All three record the selection.

If you only need to know the question was reached, leave it — what is captured is still useful, and nothing is broken.

If you see "The course's slide count doesn't match the slides found"

This one is ours, not yours. Your course file says it contains more slides than reporting was able to read.

What it means: some slides use a format reporting does not yet recognise, so they are missing from the course entirely — and slides after them may be assigned to the wrong scene.

There is nothing to fix in Storyline. Don't rebuild anything on the strength of this warning.

In the meantime the rest of the course captures normally — check the tracking points to see which slides made it through.

Naming Rules That Affect Reporting

Storyline's own naming rules still apply (Working with Variables). These are the extra ones that change what reports.

Variables

Layers

Name feedback layers Correct and Incorrect (or Right, Wrong, False, Try Again). This is the one place a name changes what's reported — it's how a true/false question's right answer is identified. The name is what's read, not the words inside the layer.

Slide Names Must Be Unique

Give every slide a unique name within the course. Report labels are built from slide names, so two slides called Question 1 produce two rows called Question 1, and nothing in the report tells them apart.

If you see "Some slides share a name"

Reporting found slides sharing a name and is telling you what it did about it: it qualified them by scene or file so the data is still correct — you will see Keyboard shortcuts (slide16) or GameOrder Final (Switching) rather than two identical rows.

Nothing is lost, but the labels get uglier. A reader of your report sees a file name where they expected a slide name.

The fix is to rename the slides in Storyline and re-upload. Give each one a name that says what it is — Question 1 — Shortcuts, Question 1 — Menus — and the qualifier disappears.

This is worth doing for any slide whose name will appear in front of a client. It is safe to ignore on slides nobody will read about, and it never affects whether an answer is captured — only how it is labelled.

Where duplicates come from, usually: copying a slide to build a variant, or a template that ships with generic names. Both are easy to miss, because Storyline lets you have as many Untitled Slides as you like.

Trigger Order

On any one object, put variable triggers above navigation triggers. Triggers run top to bottom, so a value set below a jump is set after the course has already moved on.

Course-Level Variables to Declare Now

A planned feature will let a course report custom fields on every event — the standing example being a language variable you set per published output, so your French export reports itself as French with no other changes.

Declare these now and your builds are ready the day it ships:

Use the same names across every build in a course family, and set the value as the variable's default rather than with a trigger, so each published output can be changed in one place.

Note: These report today. Define them in the tracker's General Tracking settings, then override the value per published output (for example language = fr-fr on the French build) so each export reports itself distinctly. Use the same names across every build in a course family.

What Never Reports

No amount of authoring rescues these. Build differently if the data matters.

• Scroll position in scrolling panels.
• Shortcut Key questions. The key a learner presses isn't recorded anywhere. Use an ordinary question type.
• Fill-in-the-gaps built from object states. If the right answer lives only in which state a shape is in, there is nothing for reporting to read — no variable ever holds the learner's answer. Use the Word Bank question type, or a real text-entry field, instead.

Not reported yet — but coming

These carry real learner data that reporting doesn't pick up today. Build them if they suit your course; just don't rely on the data appearing yet.

• Which markers inside a 360° image a learner opened. How much of a panorama they explored is reported — the visited and total counts — but not which individual markers they clicked.
• Lightbox opens. When a learner opens a slide in a lightbox, the visit is not recorded — the report shows no trace they saw it. If seeing that content matters to your data, jump to the slide instead of lightboxing it.
• Variables whose NAME is built by JavaScript. A value written with a plain name in quotes — player.SetVar("Score", 10) — is recorded. A name the script assembles as it runs — player.SetVar("Q" + n, 10) — is not, because the variable being written cannot be known before the course runs. If any script in your course builds a name that way, no JavaScript-written variable in that course is recorded. Use plain quoted names, or also set the variable with an Adjust variable trigger.

Check Your Course Before You Publish

Built-in questions

• Questions use Storyline's question types wherever they fit, with real answer text and the Submit button intact.
• The upload showed no warnings. A warning at upload lists anything that won't appear in your reports — fix what it points at (or accept it, if those variables are only internal to the course) before sharing.
• Surveys have no choice marked correct.
• Question banks have a draw, with randomisation set on it.
• Drag-and-drops are freeform, with feedback states enabled.
• Result slides display the score.
• A Complete Course trigger fires at every ending.
• Text entry uses real data-entry fields, with renamed variables.

Custom interactions

• Every choice sets a variable on click — Text for pick-one, True/False toggles for pick-many.
• No answer exists only in a state or a trigger condition.
• Counts aren't being used as answers.
• There's a submit click where every answer variable is already correct.
• The submit control is a plain button — not one of the selectable choice objects, and not an object whose triggers all depend on its own state.
• Right/wrong lands in a variable, or can be worked out from lives or completion.
• Feedback layers are named Correct and Incorrect, with exactly two destinations.
• Variable triggers sit above navigation triggers.
• Every slide with an interaction you want reported has a click that goes to another slide — a Next, Continue, or a choice that jumps onward. A slide the learner cannot move forward from never sends its answers, and the final slide of a course or scene needs a slide after it.

Course-wide

• Slide names are unique within the course.
• No variable name has a dot, starts with dataTrackers_, or is LMS_ID.
• Course-level variables (language, build_name) are declared consistently.
• Upload warnings have been reviewed — each points at something on this list.

Guide updated: 6 September 2026 · Applies to Storyline 360 · Storyline how-to links go to Articulate's own documentation.