Untitled

:::Definition

What is Learning Analytics

Learning analytics is the measurement, collection, and analysis of data about learners and their contexts, used to understand and improve both the learning experience and the environments in which it occurs. In practice, it means turning the activity logs, completion data, and assessment results inside your LMS into something you can actually act on.

:::

In Depth

Learning analytics sits at the intersection of data science and instructional design. The term covers everything from a simple completion rate report inside Moodle to a full data pipeline that streams xAPI statements through a Learning Record Store into a BigQuery warehouse and surfaces results in a Looker Studio dashboard. What those things share is intent: understanding what learners are doing, where they're struggling, and whether the program is working.

The field formalised around 2011 with the first Learning Analytics and Knowledge conference, but the underlying problems — how do you know if training worked? — are as old as workplace learning itself. What changed is data volume and tooling. A modern LMS generates hundreds of events per learner session. The question is no longer whether you have the data; it's whether you have the architecture to use it.

How learning analytics is used in higher education and corporate L&D

In higher education, learning analytics typically focuses on early-alert systems: identifying students at risk of failure or dropout before it happens, based on login patterns, assignment submission rates, and grade trajectories. Institutions running Moodle or Canvas LMS use these signals to trigger adviser interventions. The outcomes when done well are measurable — institutions we've worked with have reduced dropout rates in the first semester by 15–20% using relatively simple engagement models.

In corporate L&D, the questions are different. The business wants to know whether the training changed behaviour on the job, not just whether the learner clicked through the compliance module. That shifts analytics from completion tracking to performance correlation — harder to instrument, but the data that actually justifies the L&D budget. This is where xAPI and LRS architecture becomes essential, because the data you need lives outside the LMS.

The LMS analytics stack

A production learning analytics stack has four layers. The LMS itself generates raw event data — Moodle logs, SCORM completion data, gradebook entries. A collection layer captures and standardises this data, typically using xAPI statements routed to a Learning Record Store. A warehouse layer — most commonly BigQuery — stores the standardised data alongside other sources like GA4 web analytics, CRM records, and HR systems. A presentation layer — Looker Studio, Power BI, or a custom dashboard — surfaces the metrics to whoever needs them.

Most institutions have layer one and nothing else. The gap between "we have data" and "we have analytics" is almost always an architecture problem.

Common implementation challenges

The first challenge is data quality. Moodle's native logs are verbose and inconsistently structured — pulling useful metrics out requires transformation work before the data is useful for reporting. The second is organisational: analytics requires someone to own it. A BigQuery dataset with no one maintaining the dbt models or refreshing the dashboard is worse than nothing, because it creates false confidence. The third is intent creep — analytics projects that start as "let's understand completion rates" expand into surveillance territory if there's no governance framework defining what data is collected, who can see it, and how long it's retained.

Edvanta's analytics practice is built around one belief: reporting should change what someone does on Monday morning, or it's not worth building. Our standard analytics stack for Moodle clients runs from native Moodle logs through GA4 and GTM instrumentation on the web layer, into BigQuery via Google's native export, and out through Looker Studio dashboards built specifically for L&D decision-makers — not data teams.

We've built this pipeline for institutions running 5,000 to 150,000 active learners, and the architecture scales without rebuilding from scratch. What we've found consistently is that the most valuable data isn't completion rates — it's the drop-off points inside courses that no one was watching, and the correlation between learner support ticket volume and specific content modules that were never properly tested.

If your current analytics answer is "we pull a Moodle report once a month," we can show you what the next level looks like in a 30-minute walkthrough.

:::FAQ

What is the difference between learning analytics and LMS reporting? LMS reporting is what your platform produces natively — completion percentages, quiz scores, login counts. Learning analytics is what happens when you connect that data to other sources, apply analysis, and ask harder questions: does training completion predict job performance? Which courses have the highest drop-off rate, and why? Reporting describes; analytics explains.

What data does learning analytics use? The core data sources are LMS activity logs (logins, time-on-task, completion events), assessment results, xAPI statements from content played outside the LMS, and — where available — performance data from HR or CRM systems. GA4 web analytics adds behavioural context from the learner's experience navigating the platform itself.

Do you need an LRS for learning analytics? Not for basic completion reporting. But if you want to track learning events from SCORM content, mobile apps, simulations, or any tool outside your LMS, you need a Learning Record Store to receive and store xAPI statements. Without one, that activity is invisible.

How do you connect Moodle to BigQuery? The most reliable path is GA4's native BigQuery export combined with a Moodle log extraction via scheduled queries or a middleware tool. Edvanta runs a pipeline that combines Moodle's database exports with GA4 event data and xAPI statements from an LRS, all landing in a single BigQuery dataset partitioned by event date.

:::