Every school management platform sells analytics, and in most schools the analytics page is visited twice: once during the demo, and once in the week somebody asks for figures for a board meeting. That is not because school leaders dislike data. It is because the reports on offer answer questions nobody asked — how many logins last month, how many courses created — while the questions that keep a head of school awake are harder to put on a chart.
The useful test for any report is blunt: what would I do differently depending on the answer? A number that produces the same action whatever it says is decoration. "Attendance is 94%" on its own is decoration. "Attendance is 94% and was 97% in the equivalent period last term, and three classes account for most of the fall" is a morning's work with a clear beginning.
Almost no figure in a school means anything by itself. Is an average score of 68 good? It depends entirely on what it was, for whom, and on what. Is 40 submissions a week healthy? For a centre with 30 students it is busy; for one with 300 it is close to silent. The single most valuable structural decision in school reporting is to make every number carry its own comparison so nobody has to remember last term's figure to interpret this one.
SprintUp does this by construction rather than by convention: a school asks for a date range, and every figure in the response is returned alongside the same figure for the period of equal length immediately before it. A thirty-day window is automatically set against the thirty days before it; a term is set against the term-length window that preceded it. There is nothing to configure and no way to accidentally compare a fortnight against a year. One request covers a little over a year in total, both periods included, which is the ceiling on how much a single read will do.
The second consequence is that you can stop maintaining a spreadsheet of historical figures to have something to compare against, which in most small schools is the actual reporting system regardless of what the platform provides.
There are two ways to build school analytics. One is to instrument everything — page views, time on screen, mouse movement, session duration — and infer engagement from the exhaust. The other is to count the records the school was already creating in the course of teaching: a submitted answer, an attendance mark, a graded question, a completed unit. The first produces far more data and much less meaning, and it has a cost in trust that small schools in particular cannot afford to pay.
SprintUp takes the second route. Scores come from submitted answers, reduced by exactly the same routine that produces a teacher's own class averages — so a figure on the school page and the same figure on the teacher's page cannot disagree, which sounds obvious and is one of the most common ways reporting loses credibility. Attendance comes from presence records reached through the school's timetabled sessions, in-class sessions and live calls, so every record belongs to a class rather than floating free. Progress means a unit fully submitted and graded, stamped at the moment it was finalised. Feedback means a question a teacher actually graded, stamped when they graded it, which is what makes a median grading turnaround possible to calculate at all.
An honest limitation belongs here, because it shapes what you can ask for. A user record keeps only the most recent sign-in, not a history of sign-ins. That is enough to say who has not been seen for a fortnight, and enough to count how many teachers signed in during the period. It is not enough to draw a trend of logins over time, and a platform that drew one from this data would be inventing it. So SprintUp does not: sign-in data feeds a "last seen" and a current count, never a line on a chart.
The report that gets used in small schools is not the dashboard. It is the list of students who need someone to look at them this week, because that list turns analysis into an afternoon of phone calls. SprintUp builds it from five flags: attendance below 90% once there are at least three records to judge on, an average below 50, a drop of 15 points or more against the previous period, a fortnight without activity, and an account that has never been signed into at all.
Two details in how that list is built are worth copying whatever platform you use. First, the thresholds are sent with the data, so the page explaining what "chronically absent" means is reading the same definition the calculation used, and the two cannot drift apart. Second, the list is capped but the total is always reported — a hundred rows come back, and if four hundred students are flagged the response says four hundred. A truncated list that quietly looks short is worse than no list, because it tells a school everything is fine on the week it is not.
The fortnight rule doubles as a grace period, which is the kind of small decision that determines whether a feature survives contact with a real school: a student enrolled on Monday is not "inactive" on Tuesday, so nobody has to learn to ignore the list in the first fortnight of term.
A school's analytics in SprintUp covers the enrolment side of the commercial question properly: how many students the school has, how many are placed in a class and how many are not, how many joined in this period against the one before, how many seats exist across classes and what proportion of them are filled, and how many join requests are sitting unanswered. Capacity and placement are where most small-school growth problems actually live, and they are visible.
The limitation, stated plainly, because you will otherwise discover it in the demo: a school's analytics page carries no revenue figure. Money taken from families goes to the school's own connected payment account — that is the whole point of taking 0% on student payments — and it is read there, in the payment provider's own reporting and in the school's order records, not in an analytics chart. Revenue reporting inside SprintUp exists at the platform level, for the operator, not for the school. If a single screen showing enrolment and euros side by side is a requirement for you, ask every vendor you evaluate to show you that exact screen with real data in it, and watch carefully for the ones who answer by describing a roadmap. The second article covers how to read the enrolment half well, and how to join it to the money half without a project.
The difference between learning analytics and surveillance is not the amount of data. It is what is collected, who it is about, and what happens to a person because of it. A flag that tells a form tutor to check on a student who has missed four sessions is squarely on the right side of that line. A leaderboard of children ranked by average, visible to their classmates, is not — and neither is a measure of how long a child sat looking at a screen.
One design decision does most of the work here, and it is worth asking any vendor about directly: the analytics never load an answer payload or any question content. The school page can tell you that a class averages 71 and that eleven questions are waiting to be graded; it cannot show you what a child wrote. Aggregation is a privacy control, not just a performance one. The third article is about drawing this line deliberately — including the reports you should decline to build even when the data would allow them, and how to write down what you measure so families can read it.
Start with the five numbers worth watching and the reports to stop producing. Then read the enrolment data properly and find out where the money half really lives. Then decide, before anyone asks you to build it, which reports your school will not keep.