Dashboard & analytics

The admin area answers "what did learners do?" from your academy's own records, live: nothing is refreshed overnight, and every number says how it is counted and opens the rows behind it.

The dashboard

Admin → Dashboard is the admin home. It reads the last 30 days:

• Five numbers: active learners, new learners, lessons completed, lab exercises passed, and certificates issued. Each says how it changed against the 30 days before ("5 more than the previous 30 days"), in whole counts rather than percentages, because "+300%" on a small academy is noise. Each tile is a door: click it for the exact learners or events it counted.
• Learning per day: lessons completed and lab exercises passed, one point per day. The two event tiles are the sums of these lines, so the chart and the numbers can't disagree. Hover a day for its counts, or open Show as a table.
• Most active courses: the five courses with the most active learners, each linking to its funnel and lab analytics.
• Reach: visitor page views and lab runs in the last 30 days, and searches that found nothing, with Open reach (see Reach).
• Content freshness: whether any video currently contradicts your docs (see Content freshness).
• Impact: one line per metric (the first three): how many courses are clearly better, show no clear difference, are clearly worse, or are still waiting, and the best clear course, calculated the same way as the Impact page, below. It loads on its own, a moment after the rest of the dashboard.
• Quizzes (when any question needs attention): the questions worth a look, linking to Needs attention.
• Course ratings (once a learner has rated a published course): the courses that got low ratings — 2 stars or fewer — in the last 30 days, each opening exactly those ratings on its course page (see Ratings). It's a window, not an inbox: there's nothing to mark as read, and the line goes quiet once 30 days pass without a new low rating.
• Recent activity: the newest learning events, with View all activity for the full log.

How every number is counted

The last 30 days means today and the 29 days before it, in UTC.

Your team is left out: people with a seat on the academy's admin team, and learners in accounts marked Internal, so your own company's testing and learning never shows up as your customers' learning. Their rows still exist everywhere else: the Learners list tags them Staff or Internal, and the Activity log can include them. (Mark your own company's account Internal on its account page — see Describing accounts.)

• Active learners — Learners who opened or completed a published lesson in the last 30 days. The Accounts table's "Active (30d)" applies the same test to each account's learners (staff included there, since that table lists people).
• New learners — Learners who signed in to the academy for the first time in the last 30 days.
• Lessons completed — Published lessons completed in the last 30 days, with the Complete button or by passing every exercise of the lesson's labs. A lesson marked incomplete again stops counting.
• Lab exercises passed — Lab exercises passed for the first time with the learner's own code in the last 30 days. An applied solution doesn't count, and passing the same exercise again doesn't count twice.
• Certificates issued — Course and learning-path certificates issued in the last 30 days.
• Most active courses — Learners who opened or completed one of the course's published lessons in the last 30 days. One learner can count in several courses.

Lessons count while they are published: a lesson you unpublish or delete takes its completions out of these numbers, the same way it leaves every learner's progress bar. Certificates never revoke, so they always count.

The rows behind each number

• Active learners and New learners open Admin → Learners filtered to the same window with your team left out (the Show and Your team filters above the table). The page repeats the definition above the list; switch Your team to Included and it says the list can now be longer than the dashboard's number.
• Lessons completed, Lab exercises passed, and Certificates issued open Admin → Activity filtered to that event type.

Activity

Admin → Activity is every learning event in the academy, newest first: a first sign-in, a course started (its first lesson opened), a lesson completed, a lab exercise passed for the first time, and a certificate issued. Filter by type, switch between the last 30 days and all time, and include or leave out staff. Each row names the learner (click through to their record) and says when, with the exact time on hover.

Events are read from the records the academy already keeps, not from a separate tracking log, so there is nothing to switch on and nothing that can fall out of step with learners' own progress. (What the academy records about visitors who haven't signed in is on Reach, below.)

Reach

Admin → Reach is the academy's top of funnel: the people the dashboard can't see because they haven't signed in. Courses are free to read, so most readers arrive here first. It reads the last 30 days, live, in the funnel's order: page views and lab runs by visitors, then new learners, then searches.

• Pages: the 25 most viewed pages, with views and lab runs by visitors and by signed-in learners.
• Where sign-ups came from: the new learners of the last 30 days by how they first arrived. Each row opens Admin → Learners filtered to exactly those learners, and a learner's own page says how they arrived.
• Searches: what people searched for and found nothing (content gaps, in your readers' own words), and the most searched, each with how many opened a result.
• Certificates: how often shared certificates were opened, added to LinkedIn, and turned into a new learner, with the most viewed ones. The Certificates page shows each certificate's views since counting began.

Views are counted, not people, so Reach draws no percentage between a view and a sign-up. Until a whole previous 30 days have been counted, a tile says when counting began instead of comparing with days nobody counted.

What the academy records about visitors

Visitors are counted, never identified: no cookies, no visitor ids, and nothing stored in their browser. Opening a page adds one to that page's count for the day. Browsers that announce themselves as crawlers are left out, and so is your admin team.

A sign-up's source is kept the same way. When someone opens the academy, the page notes where they came from (the other site's name, and any utm_source, utm_medium and utm_campaign tags on the link) and the first page they opened, in the browser tab's memory only. If they sign in, those facts travel with the sign-in form and are kept once their learner record exists. If they don't, they're gone when the tab closes. A search is kept by its final words, lowercased, with any email address in it replaced.

Signed-in learners are different: like their lab attempts, each press of Run and each hint they open is recorded as theirs, so exercise analytics can tell effort from guessing. The course analytics show those counts on every exercise.

How Reach counts

• Page views by visitors — Academy pages opened by people who weren't signed in, in the last 30 days: the home page, the All courses page, and the course, lesson, learning path and catalog pages. Certificate pages are counted on their own. The academy keeps no visitor identifier, so this counts views, not people.
• Lab runs by visitors — Presses of Run in a lab by people who weren't signed in, in the last 30 days, on lesson pages and on course pages.
• New learners — the dashboard's number (above).
• Searches — Searches in the academy's search box in the last 30 days, by visitors and learners, each counted once by its final words when the search was closed or a result opened. A search found nothing when no course, learning path or catalog matched.
• Certificate views — Certificate pages opened in the last 30 days by anyone but the certificate's holder.
• Views by learners — The same pages opened by signed-in learners in the last 30 days.
• Lab runs by learners — Presses of Run by signed-in learners in the last 30 days.
• Add to LinkedIn — Presses of the certificate page's Add to LinkedIn button in the last 30 days. It opens LinkedIn's form; whether the holder saved it there, LinkedIn doesn't say.
• Start this course — Presses of the certificate page's Start button by visitors who don't hold the certificate, in the last 30 days.
• Sign-ups from a certificate — New learners of the last 30 days whose first page was a certificate.
• Where sign-ups came from — The new learners of the last 30 days by how they first arrived. A campaign tag (utm_source) on the link wins, then a certificate page as the first page, then the site they came from. "No referrer" means the link was typed, bookmarked, or opened from an email or app that hides it; "Not recorded" means the learner signed in before sources were recorded, or without the academy's sign-in form.
• Runs and hints (on a course's lab difficulty) — Presses of Run by signed-in learners, and the learners who opened at least one of the exercise's hints, all time, staff left out.

Export all of it from the bottom of the page: reach.csv (every daily count), searches.csv, and lab-events.csv (each learner's runs and hint reveals). learners.csv carries each learner's source.

Course analytics

Admin → Course analytics opens on one table of your published courses, so you can see which course to open without opening each one. Click a column to sort by it — the table opens on the courses with the most learners — or search by course title. A second tab, Learning paths, holds each path's funnel.

Two filters apply to every number on the page, ride along when you open a course, and are named in the line above the table:

• Learners from — one account's learners, or Individuals (learners with no company account).
• Period — All time, or Last 30 days. With Last 30 days selected, every number counts what began in the period: learners who started the course or the path in it, learners who opened the lesson in it, lab attempts made in it, learners who first answered a quiz question in it, and ratings given or changed in it. Recent learners have had less time to finish, so a 30-day finish rate reads lower than the all-time one.

The table's columns:

• Started — Learners who opened at least one published lesson of the course.
• Finished — Learners who completed every published lesson of the course.
• Finish rate — Finished as a share of started, shown once 30 learners have started the course. One learner finishing isn't a 100% course: below 30, read the two counts beside it.
• Biggest drop-off — The lesson the most learners opened and haven't completed. It's a count, shown with its whole numbers ("20 of 135 haven't completed it"), so a busy early lesson outranks a small late one that loses a larger share.
• Hardest exercise — The lab exercise with the lowest share of learners who passed it, counted once 30 learners have tried it. Below that the cell stays empty: a pass rate on a handful of learners moves too much to name a culprit.

Open a course for its page — the course's name, how many started and finished it, and four sections, each with its export button:

• Lesson funnel: per lesson, in reading order, how many learners opened it and how many completed it — where people stop. Each bar is drawn on one scale, the most-opened lesson: the solid part completed the lesson, the lighter part opened it and hasn't. The biggest drop-off is marked in amber once 30 learners have opened that lesson.
• Lab difficulty: one row per exercise, in the order learners meet them — the learners who tried it, attempts, how many of those learners passed and their share (applying the solution counts as passing), how many times the solution was applied, presses of Run, how many opened a hint, and the checks that fail most, named by the fail message learners actually saw. Hover a column for how it's counted. Checking work isn't a Run press, so attempts without runs are normal; and runs and hints show a dash, not a zero, for attempts made before they were recorded.
• Quizzes: per quiz in the course, the same table as the Quizzes page — open a quiz for its question cards (below).
• Ratings: how useful learners said the course was, and every rating with its comment (Ratings, below).

Your team is left out of the funnel, the lab difficulty, the quiz questions, the ratings and the path funnels, like every other number here.

Quiz questions

Each question of a published quiz gets a card on its quiz's page (Admin → Quizzes, then open the quiz). Every number is counted from answers to the question's current answer key: when you change which answer is right, the count starts over, and the card says since when (Changing a published quiz).

• Learners — signed-in learners who answered at least once.
• Right first try — the share of learners whose first answer was right. Later answers don't change it: retries are practice.
• Pick rate — for each option, the share of first answers that chose it (on select-all questions, the share that ticked it). The most-picked wrong option is named with the why learners read after picking it.
• Rarely picked — a wrong option chosen by fewer than 5% of first answers, judged from 30 learners up. It isn't doing its job as a distractor: rewrite it from a real misconception, or drop it.
• Most common wrong answers — for typed questions, what learners typed most often on their first try.
• Showed the answer — learners who pressed Show the answer.
• Flagged it as wrong — learners who pressed "This question seems wrong", each with a reason (hover the count to see them). Read the question again: a flag with a low right-first-try share often means an ambiguous wording or a wrong key.
• Separates strong and weak learners — from 30 learners: do the learners who get the course's other questions right also get this one right? It's the correlation (point-biserial) between a learner's first try on this question and their first-try score on the course's other questions (learners who answered at least two others). Around 0.3 and up, the question separates well; near 0 or below, it's measuring luck or a flaw. Labelled provisional under 100 learners — with fewer, the number moves a lot from one learner to the next.

Answers from narrows every card to one account's learners, or to Individuals (learners with no company account) — the rest of the definitions stay the same.

A question that needs attention says why at the top of its card, with Mark as reviewed; those reasons are always judged on every learner.

Every answer, reveal and flag exports as quiz-answers.csv.

Ratings

Learners rate a course by answering one question, "How useful was this course?", on five stars, each with its own words: Not useful, Slightly useful, Somewhat useful, Very useful, Extremely useful. A rating of 3 stars or fewer can also say what got in the way — Outdated, Too basic, Too advanced, Something didn't work, Hard to follow — and any rating can carry a comment ("What should we improve?").

Ratings are private feedback to your team. Learners never see each other's ratings, nothing appears on the catalog or the course page, and the form tells the learner that only your team sees their rating, with their name and email. Rating is never required: it doesn't hold back a lesson, a completion or a certificate.

When learners are asked:

• Once, when they finish the course. The "Course complete" card asks the question. No thanks means the course never asks again.
• Whenever they like, once a lesson is done. The course page's header carries Rate this course, so learners who stop partway can still say why — that's where a course learns the most.

A learner rates a course once and can change it any time (Change beside their rating); the latest rating counts, and the list says Changed under its date.

On the course's page in Course analytics, Ratings shows:

• Ratings — Learners who rated the course, counted once each with their latest rating.
• Average — The mean of those ratings, shown once 10 learners have rated the course. Below that, read the counts per star beside it.
• Per star — how many learners gave each rating, 5 down to 1. Click a row to list exactly those ratings. A low rating is 2 stars or fewer.
• What got in the way — how many low ratings named each reason; pick one to list those ratings.
• Every rating, newest first: when it was given, the learner and their account, the stars and reasons, the comment, and Progress when rated — How many of the course's published lessons the learner had completed when they rated it.
• Earlier version beside a rating — Rated before the course's latest publish: the learner saw an earlier version. The summary says how many ratings predate the latest publish.

Ratings bunch at the top on every learning platform — most courses average above 4 — so the average separates courses less than the low ratings and the comments do. Read those first. A rating also says how much a learner liked a course, not how much they learned or whether they use your product more: that's what Impact measures.

Learners from and Period narrow the ratings like every other section. Each account's page lists its learners' newest ratings, and Course ratings on the dashboard names the courses with recent low ones. Every rating exports as course-ratings.csv, and the course.rated webhook sends each one as it's given.

Learning paths

The Learning paths tab of Course analytics lists each path's funnel: who started the path, who finished every course, and — course by course, as a share of the path's starters — who started and who finished each step. The step that loses the most learners between courses is marked in amber, with its count, once 30 learners have finished it: Learners who finished this course and haven't started the next one. (Learners who stop inside a course are in that course's lesson funnel.)

Impact

Admin → Impact answers one question: do people who finish a course start using your product more than coworkers who didn't? It answers it for every published course on everything your product records (activating, creating a pipeline, filing a ticket), so you can see which courses move adoption. Your product sends those events in, naming the person by email or by your own user id — how is in Integrations & exports.

How it works

With one person:

1. Ana, at Acme, finishes a course.
2. Impact compares her with coworkers at Acme who started the same course but hadn't finished it.
3. It looks at what your product recorded in the 30 days before and after she finished: did Ana gain ground on them? Across everyone who finished, that's the answer.

Until one of your metrics is set up (below), the page shows an example ranking with made-up numbers, so you can see what you'll get.

The metrics overview

The page opens on Your metrics: one row per metric, with which way is good, how many courses have results ("4 of 13"), the results by kind (clearly better, no clear difference, clearly worse, still waiting) and the best clearly-better course. It's sorted so the metrics where courses clearly move something come first (Most clear results), or by Name, and search finds a metric by its words or any of its names. Click a metric to open its ranking, or its Best course to open that course's evidence directly. All metrics goes back, and the box at the top right jumps straight to another metric.

A compact status shows how many events have arrived and flags missing dates or unmatched learners. Manage data (it reads Connect your product until your first event arrives) opens the API, CSV import, and event diagnostics on their own page.

Metrics under Needs setup are grouped below the table, each with Set up metric. Hidden metrics sit behind Hidden from Impact.

Accounts at the top narrows every result on the page to one kind of account: Customers, Partners, Prospects, Unsorted (accounts with no type yet) or Individuals (personal email addresses). People who finished and their coworkers are narrowed alike, so a customers-only answer compares customers with customers. The filter stays on as you move between the overview and each metric, and the page says who counts while it's on. Your own team never counts, filtered or not: staff, and accounts marked Internal (see Describing accounts). The dashboard's Impact card always shows every account.

Setting up a metric

Every event name your product sends is a metric: the first event with a new name creates it. There's nothing to create by hand. Before any course is compared on one, answer two questions about it, once:

• Is more of it good? Creating a pipeline: yes. Support tickets: no, less is better.
• What do you want to measure? Percentage of people who did it counts each person once, even if they did it repeatedly. Average total per person counts every event's value (1 by default). For pipeline creation, choose the percentage to measure adoption or the average total to measure usage volume.

Follow Set up metric on the overview, or in What your product has sent on the Manage data page. From then on every published course is compared on it, live, as soon as it has enough people. Nothing is saved per course, and new courses join on their own.

The settings show under the metric's heading with the day they were set. Edit settings opens the form; Save settings recalculates every course's results.

Names and visibility

Your product decides which metrics exist, so a few will be the same thing under two names, and some won't be outcomes at all. Each metric's page ends with Names and visibility:

• Merge it into another metric when they're the same thing (created-pipeline and created_pipeline). Every event sent under the name, before and after the merge, counts as the metric you pick, and the name is listed there with Separate, which undoes it. The events keep the name they were sent with: exports show it, next to counts_as. A metric that has no settings yet takes the merged name's.
• Hide from Impact a metric that isn't an outcome, like a login or a page view. It leaves the overview, the rankings and the dashboard; its events keep arriving and still export. Show in Impact brings it back.

Names are lower-cased as they arrive, so Activated and activated are always one metric. The overview's row menu offers both, too.

Reading the ranking

Each metric has its own view, titled with its question: "Which courses move "created pipeline"?". It lists the courses in two groups.

Courses with Results are ranked best first, whichever way is good for the metric. Each row shows the answer's tag (Clearly better, No clear difference or Clearly worse), the difference as a dot with its likely range as a bar, all courses on one shared axis with a zero line, the difference in points (or per person) with its range, and how many people who finished and coworkers were counted. A key names the dot, likely range, and zero line; values are in percentage points for percentages, or average total per person. On narrow screens, each row keeps its own labeled scale.

Waiting for enough people lists the rest, soonest expected first, each with how far along it is (people who finished, coworkers, accounts) and when it's expected. Under the ranking, one line counts them and names the closest.

Search finds courses by title in either group; each shows 25 at a time.

Opening a course

Click a row to open it in place. An answered course opens to its own chart: two lines, the people who finished and their coworkers, over the 30 days before finishing and the 30 days after; the legend gives how many of each were counted. A dashed line shows where the people who finished would have landed had they changed exactly like their coworkers, and the bracket between that line and where they actually landed is the answer, labelled with its size and likely range. Beside the chart's title, "More is better" or "Less is better" says which way is good.

Show as a table gives the same numbers in rows, with the difference and its range; screen readers get the answer in words. Who's counted gives who the answer is based on (people who finished, coworkers and accounts), how many each account contributed, what was left out (people still inside their 30 days after, and when the next one counts; people with no coworker who had started but not yet finished; undated events), the metric's settings and when they were set, why the range is wider when several courses are compared, and the reminder that this is a comparison, not an experiment.

A waiting course opens to how far along it is and, when it can, the day enough people who finished can be counted. It goes by how many finished the course recently: over the last 90 days, or since the course was first published if that's shorter (at least 7 days). People who already finished and have a coworker to compare with count on the day their 30 days after pass; new finishes are assumed at the same pace, 30 days later, and scaled by the share of past finishers who had a coworker. Only people who finished can be estimated this way; coworkers and accounts depend on who starts the course, so when those are short too the page says the answer may come later, and gives no date when they're all that's left.

Comparing with coworkers, and with the same people before, is what makes the number worth showing: the people who finish are often your keenest users to begin with, and a product that's growing lifts everyone. Neither counts as the course's doing here. There are no ratios ("2× the rate"), which make tiny numbers look huge.

Many courses at once

Compare 60 courses on one metric and, by luck alone, about three would look clearly better or worse if each were judged on its own. So when several courses have an answer on the same metric, each likely range is stretched around its answer until all of them hold together as often as one range alone would (1.7 times as wide for 60 courses). A course's range can grow, and its answer turn from clear to no clear difference, when another course gets its answer. What each range means is spelled out under Many courses at once in the method, below.

Getting your first result

Until a course has its answer, the page shows three steps and where you stand on each:

1. Connect your product: how many events have arrived, from how many people, and how many of those people are learners here: those with a dated event whose email, or your user id paired with an email, is one of their addresses in this academy. Only they can be counted, and staff never are. If no event has a date, or no one matches, the step says which and what to send.
2. Set up a metric: how many metrics are set up. It becomes the next step once your data can be counted.
3. Get your first result: the soonest course, and when it's expected.

A person who finished counts once their 30 days after have passed, whether or not your product's data covers them. So the page warns, in amber, when it doesn't — "some data may be missing" or "no dated events yet" on the course's row, and in full when you open it. Three cases:

• Before your data begins — people who finished before your data for the metric covers their 30 days before (for example, you started sending events last month). Send your older events with their dates.
• After your latest event — people whose 30 days after run more than a week past your latest event for the metric, as if your product stopped sending it. Send the newer events.
• No dated event at all — nobody can be measured. Send each event with occurred_at.

"May be missing": a rare event's first or latest occurrence can fall inside the time your product was recording it, so the warning can't be sure.

The full method

• People who finished — Learners who completed every published lesson of the course. The day they finished is recorded when it happens: publishing a new lesson later doesn't take it back.
• Coworkers — Learners at the same account who had started the course but hadn't finished it by the day that person finished. Learners with a personal email address are pooled as one account, Individuals.
• Who counts — Your team never counts: people with a seat on the academy's admin team, and learners in accounts marked Internal. The Accounts filter narrows everyone counted, people who finished and coworkers alike, to one kind of account: customers, partners, prospects, accounts with no type yet, or Individuals.
• Before and after — Everyone is measured over the 30 days before the day someone finished and the 30 days after it, their coworkers on that same day. A person who finished counts once their 30 days after have passed. Events without a date are left out.
• The answer — How much more the people who finished changed than their coworkers: each person's change minus the average change of their own coworkers (a fixed random 50 of them when there are more), averaged over everyone who finished. Comparing inside each account cancels out company size, plan and season.
• Likely range — The middle 95% of the answers from resampling whole accounts 2,000 times. When the range includes zero, the answer is no clear difference.
• Many courses at once — Every published course is answered on each metric. When N courses have an answer on the same metric, each likely range is stretched around its answer so that all N hold together 95% of the time, as a bell curve's would: 1.3 times as wide for 5 courses, 1.7 times for 60. Without it, about one course in twenty would look clearly better or worse by luck.
• Enough people — No answer is shown until a course can count 20 people who finished, 20 coworkers and 5 accounts. Until then the page shows how far along it is, and who can't be counted yet.
• The metric — Each metric says whether more or less is better, and whether to measure the percentage of people who did it at least once or the average total per person (each event adds its value, 1 by default). Changing a metric's settings recalculates every course's results, and the page shows the day they were last set.

A learner counts with the account they belong to today (move someone and their history moves with them), and a coworker who finishes during that person's 30 days after still counts as a coworker there, which can only shrink a difference, never inflate one. Every answer carries a short caveat; the full one reads: This is a comparison, not an experiment. People who finish a course can differ in ways this data can't see. Comparing coworkers at the same account in the same weeks removes company-level differences; comparing before with after removes people who were already heavy users.

Connecting your product

Admin → Impact → Manage data takes events by API or as a CSV paste (the door reads Connect your product until the first event arrives). Include occurred_at, when it happened in your product: an event without it is stored undated, kept and exported, but never compared, because a before and after needs to know when. The API and the CSV format are in Integrations & exports.

Metric names read as words on the page: created_pipeline shows as "created pipeline" (the API and the exports keep the name as sent). What your product has sent lists every metric received (merged names under their metric, hidden ones tagged): events, people, how many of them are learners here, how many events are undated, the dated range, and each metric's settings, which link to the metric's view.