Moodle Analytics and Reporting in 2026: Turn LMS Data into Student Success

Your Moodle site generates thousands of data points every day -- login times, quiz scores, forum participation, resource views, assignment submissions. Almost all of it goes unread. Meanwhile, students quietly disengage, fall behind, and drop out. The data that could have flagged the problem sat in a database table nobody queried.

This guide shows you how to turn that raw data into actionable insights. You'll learn what Moodle gives you out of the box, which plugins fill the gaps, and how to set up predictive analytics that flag at-risk students before they disappear. Whether you're an educator looking for quick wins or an administrator evaluating enterprise reporting tools, every section includes specific steps you can take today.

What Moodle Gives You for Free

Before installing a single plugin, understand what's already available. Moodle ships with a surprisingly capable analytics toolkit.

1. Activity Completion Tracking

Activity completion is the foundation of everything else. Without it, badges don't work, course completion can't trigger, and predictive models have nothing to analyse.

You can configure three tracking modes per activity:

• None: No tracking. The activity just exists.
• Manual: Students click "Mark as done" when they finish.
• Automatic: Moodle marks it complete when the student views the activity, receives a grade, submits work, or meets custom criteria.

A practical example: for a 10-week course with 30 activities, enable automatic completion with a "require view" condition at minimum. For graded activities, add a minimum grade threshold. Within days you'll have a completion grid showing exactly who's engaging and who isn't -- no plugin required.

To enable: Site Administration -> Advanced Features -> Enable completion tracking -> Yes. Then enable it at course level under Course Settings, and configure each activity's completion criteria in its own settings.

2. Core Reports

Site-level reports (available to admins via Site Administration > Reports):

Report	What It Shows
Logs	Complete audit trail of every action on the site
Live Logs	Real-time activity from the past hour
Statistics	Graphical view of site activity over time
Config Changes	Log of admin setting modifications

Course-level reports (available to teachers via the course Reports menu):

Report	What It Shows
Activity Report	View counts for every activity in the course
Activity Completion	Grid of students vs. activities with completion status
Course Participation	Who viewed or posted to a specific activity this week
Logs	Course-specific audit trail filtered by participant, date, or action

The Activity Completion report is the one you'll use most -- a matrix with students on the left and activities across the top. Download it as CSV for offline analysis.

3. The Gradebook

Moodle's Gradebook has six views worth knowing:

• Grader Report: Complete grade matrix for all students and graded activities
• Grade History: Audit trail of every grade change: who changed it, when, and what it was before
• User Report: Individual student's grade summary
• Overview Report: One student's grades across multiple courses
• Outcomes Report: Competency-based tracking
• Single View: Override grades for one student or one item

The Grade History report is frequently overlooked. If you ever need to prove when a grade was changed and by whom, this is your audit trail.

4. Report Builder: Custom Reports Without SQL

Introduced in Moodle 4.0, Report Builder is a drag-and-drop tool for creating custom reports -- no SQL, no plugins required.

To build a course completion dashboard:

1. Navigate to Site Administration -> Reports -> Report builder -> New report
2. Select "Course participants" as your data source
3. Add columns: Course name, User first/last name, Completion status, Date completed
4. Add a condition and filters so users can narrow by course or date
5. Set the audience (Managers, Teachers) and schedule weekly email delivery

Report Builder supports 10+ data sources, exports in six formats (CSV, XLSX, PDF, JSON, ODS, HTML), and can deliver scheduled reports automatically. It handles most day-to-day reporting needs -- but it can't generate charts, run arbitrary SQL, or export configurations between Moodle sites. When you hit those limits, the tools below fill the gaps.

Custom SQL Reports: Full Database Access

The Ad-hoc Database Queries plugin, maintained by The Open University, lets administrators write SQL SELECT queries directly against the Moodle database. It's free, actively maintained, and used by thousands of institutions.

Here are four queries you can copy and use immediately:

Enrollment count by course:

SELECT c.fullname AS "Course Name",
       COUNT(ue.id) AS "Enrolled Users"
FROM prefix_course AS c
JOIN prefix_enrol AS en ON en.courseid = c.id
JOIN prefix_user_enrolments AS ue ON ue.enrolid = en.id
GROUP BY c.id
ORDER BY c.fullname

You can also run similar queries to track course completion rates, identify active users in the last 30 days, and spot users who have never logged in.

The plugin supports on-demand and scheduled exports, interactive filtering via placeholder parameters, and CSV download. Only administrators can create queries -- and only SELECT statements are permitted. INSERT, UPDATE, and DELETE are blocked.

Predictive Analytics: Flagging At-Risk Students

Moodle's built-in predictive analytics system uses machine learning to identify students at risk of dropping out. It's based on the Community of Inquiry framework, uses real ML backends, and has been validated by published academic research.

How It Works

Moodle ships with three analytics models:

Model	Type	What It Does
Students at risk of dropping out	Predictive (ML)	Flags learners with low engagement who may not complete
Upcoming activities due	Static	Notifies students about approaching deadlines
No teaching	Static	Identifies courses where no teacher has logged in

The dropout prediction model works in three stages:

1. Training: Moodle analyzes completed courses with known outcomes. It measures two things per activity: cognitive depth (how deeply a student engaged -- from viewing to submitting to reviewing) and social breadth (how broadly they interacted with peers).

2. Prediction: Once trained, the model evaluates active courses. At configurable intervals (quarterly is the default), it generates predictions for each student.

3. Intervention: Teachers receive "Insights" notifications. For each at-risk student, a teacher can send a message, view the student's course report, accept the insight, or mark it as not applicable (which helps the model learn).

Two ML Backends

Moodle supports two prediction engines:

Feature	PHP Backend	Python Backend
Algorithm	Logistic regression	Neural network (TensorFlow)
Dependencies	None (pure PHP)	Python 3 + moodlemlbackend package
Accuracy	Lower	Higher
Default	Yes	No
Deployment	Automatic	Flask app, Docker, or AWS Lambda

The Python backend is significantly more accurate and is recommended for production use. You can deploy it as a Docker container:

docker pull moodlehq/moodlemlbackend
docker run -p 5000:5000 moodlehq/moodlemlbackend

Then point Moodle to it via Site Administration > Analytics > Analytics settings > Predictions processor > Python machine learning backend.

Setting Up Predictive Analytics

1. Site Administration -> Analytics -> Analytics settings -- set "Enable analytics" to Yes
2. Enable analysis intervals: "Quarters" and "Quarters accumulative" (accumulative intervals include all historical data, producing more accurate predictions)
3. Select Python as your prediction processor if installed
4. Site Administration -> Analytics -> Analytics models -- click "Evaluate" on "Students at risk of dropping out" to test accuracy against your data
5. Enable the model for production predictions
6. Verify the "Train models" and "Predict models" scheduled tasks are running -- training daily and predictions every 6 hours is recommended

Important: The model requires courses with defined start and end dates. If your courses don't have end dates, the model can't define what "dropping out" means. Set course dates before enabling analytics.

Reporting Plugins: When Built-In Tools Aren't Enough

Your situation	Recommended solution	Cost
Basic reporting, no budget	Report Builder (built-in)	Free
SQL skills, full control	Ad-hoc Database Queries	Free
Visual reports, no SQL	Report Builder + Edwiser Reports	Free + Paid
Multi-site standardised reports	Configurable Reports	Free
Enterprise analytics with ML	IntelliBoard	Custom pricing
On-premise, pre-built reports	LearnerScript (80+ templates)	One-time purchase
Cloud-based BI	Zoola Analytics	Subscription
Cross-platform tracking	xAPI + LRS	Varies

1. IntelliBoard

IntelliBoard is the most comprehensive third-party analytics platform for Moodle -- 50+ pre-built dashboards, ML for at-risk learner identification, automated report scheduling, and multi-LMS support. It holds SOC 2 Type II certification and is a Moodle Certified Integration Partner. The trade-offs: significant cost (enterprise pricing, not public), your data leaves your Moodle instance, and it may exceed what smaller institutions need.

2. Configurable Reports

Configurable Reports plugin offers a middle ground between Report Builder and raw SQL. It supports visual report building, optional SQL for advanced users, charts and plots, and -- critically -- export and import of report configurations between Moodle sites. If you manage multiple installations and want standardised reporting across all of them, this is your tool.

3. Edwiser Reports

Edwiser provides clean, role-specific dashboards for managers, teachers, and students. The free version covers the basics. The Pro version adds scheduled email delivery, custom report building, and additional analytics. It's a strong complement to Report Builder for institutions that want visual dashboards without writing SQL.

4. xAPI

xAPI is worth a brief mention for institutions whose learners use tools outside Moodle -- mobile apps, simulations, virtual labs. The Experience API tracks learning activities across platforms in a standardised format and stores them in a Learning Record Store (LRS), which can then feed into BI tools like Tableau or Power BI. The Logstore xAPI and xAPI Launch Link plugins handle Moodle's side of this. If cross-platform tracking is a requirement, xAPI deserves its own dedicated evaluation -- it's too large a topic to cover fully here.

GDPR and Analytics: Yes, You Can Do Both

Institutions often hesitate to run analytics on student data because of GDPR, FERPA, and similar regulations. The concern is legitimate, but Moodle was designed with privacy in mind, and you can run powerful analytics while staying compliant.

Three essential configurations:

1. Data Privacy plugin (built into Moodle core since 3.5): Handles subject access requests, data export, and erasure requests. Designate a Privacy Officer to manage incoming requests via Site Administration -> Privacy -> Privacy and policies.

2. Data retention policies: Navigate to Site Administration -> Privacy -> Data Registry and define how long each type of data is kept. Configure the "Delete expired contexts" scheduled task to automatically purge old data.

3. Plugin Privacy Registry: Check Site Administration > Privacy > Plugin privacy registry before installing any analytics plugin. Plugins without Privacy API implementation can't have their personal data exported or deleted through Moodle's privacy system.

Two further reassurances worth knowing: Moodle's analytics models use aggregated indicators for predictions, not raw personal data. And Moodle itself does not collect, use, or monetise student data from individual installations -- your data stays on your servers.

What to Prioritise: A Practical Roadmap

If you're starting from scratch, here's a sensible order of operations:

1. Enable activity completion tracking: everything else depends on this data existing
2. Run the Activity Completion and Course Participation reports: understand your baseline before changing anything
3. Build one Report Builder report: a course completion dashboard is the highest-value starting point
4. Install Ad-hoc Database Queries: run the four queries above and save the results
5. Set course start and end dates: required before predictive analytics can run
6. Enable the Python ML backend and dropout prediction model: test on historical data before going live
7. Configure the Data Privacy plugin: do this before enabling any third-party analytics tools

The analytics capability in core Moodle is more powerful than most institutions realise. Most of the value in this guide comes from configuration, not additional software.

Why Your Moodle Host Matters for Analytics

The analytics capabilities covered in this guide -- activity completion tracking, Report Builder, predictive models, the gradebook -- are all built into Moodle core. But how well they actually work in practice depends heavily on the health of the Moodle instance underneath them.

Analytics tasks are resource-intensive. Training predictive models, running scheduled reports, executing SQL queries, and processing completion data all compete with your users for CPU time and database connections. On an under-resourced or poorly maintained server, scheduled tasks fall behind, reports time out, and the data you're depending on becomes unreliable. The tools are there -- they just don't perform.

MooDIY is a managed Moodle hosting platform built to keep your site stable, up to date, and performing consistently -- so that the built-in analytics tools work the way Moodle intended. No server management, no missed updates, no infrastructure headaches getting between you and your data.

If you're ready to put the reporting and analytics capabilities in this guide to work, start with a solid foundation by subscribing to a MooDIY Premium or Enterprise plan.

Related reading: 10 Ways to Optimise Your Moodle Performance in 2026, The Perfect Moodle Server Architecture: 2026 Planning Guide, The Ultimate Moodle Backup Policy for 2026, MooDIY's Curated Plugin Selection