How do you track learner completion rates across a WordPress multisite LMS?

You can track learner completion rates across a WordPress multisite LMS by combining a plugin that natively supports network-wide reporting with a centralized dashboard that pulls progress data from each subsite. The most reliable setups use either a multisite-aware LMS plugin or a custom reporting layer that queries each subsite’s database tables. This article walks through every major question you’ll face when building that system.

Which WordPress LMS plugins support multisite completion tracking?

The WordPress LMS plugins that best support multisite completion tracking are LearnDash, LifterLMS, and TutorLMS, each of which can be network-activated and stores progress data in a way that makes cross-site reporting feasible. LearnDash is the most widely used option for complex multisite setups because it integrates with third-party reporting tools and exposes progress data through a well-documented database structure.

That said, “multisite support” means different things to different plugins. Some plugins let you activate them network-wide but still silo all reporting within each subsite. Others offer a true network admin panel where you can see enrollment and completion data across all subsites from one screen. Before you commit to any plugin, it’s worth testing the network admin experience directly.

Here’s a quick breakdown of the main options:

• LearnDash: Strong developer ecosystem, good database transparency, compatible with reporting plugins like GamiPress and Uncanny Automator
• LifterLMS: Built-in reporting per site, but requires additional tooling for aggregated network views
• TutorLMS: Clean interface, improving multisite support, but network-level analytics are still maturing in 2026
• Sensei LMS: Tight WooCommerce integration, useful if you’re selling courses, but network reporting is limited out of the box

If your priority is aggregated eLearning analytics across many subsites, LearnDash with a custom reporting plugin or a dedicated integration layer is usually the safest starting point.

How does WordPress multisite store learner progress data?

In a WordPress multisite LMS, learner progress data is stored in each subsite’s own set of database tables, not in a shared network-wide table. Each subsite gets its own prefixed tables (for example, wp_2_, wp_3_), and the LMS plugin writes completion records, quiz scores, and enrollment statuses into those tables individually. There is no built-in mechanism in WordPress core to merge this data automatically.

This architecture is important to understand because it directly shapes how you approach course completion tracking. When a learner finishes a course on subsite 3, that completion record lives in wp_3_postmeta or a custom table specific to your LMS plugin. Subsite 1 has no awareness of it unless you build a bridge.

LMS plugins typically use one of two storage patterns:

• Post meta storage: Progress is saved as user meta or post meta entries, which are easy to query but can become slow at scale
• Custom tables: Some plugins like LearnDash (with its custom tables add-on) write to dedicated tables, which perform better and are easier to aggregate across subsites

Understanding which pattern your plugin uses is the first step before you design any cross-site reporting solution. Custom tables are generally easier to query efficiently across a multisite network.

What reporting tools can aggregate data across multiple subsites?

The most practical reporting tools for aggregating completion data across a WordPress multisite LMS network are Uncanny Owl’s Tin Canny Reporting, LearnDash Reporting by Wisdm Labs, and custom-built dashboards using direct database queries. Each of these approaches the aggregation problem differently, so the right choice depends on your technical resources and reporting needs.

Tin Canny Reporting is purpose-built for LearnDash and supports xAPI and SCORM tracking, which makes it a strong fit if your courses use those standards. Wisdm’s reporting plugin adds group-level and site-level analytics that are especially useful for corporate training environments with multiple departments or client subsites.

For teams who need more flexibility, a custom reporting layer that queries each subsite’s database directly gives you complete control. You can build this as a network-admin-only WordPress page that runs aggregated SQL queries across all subsite tables and displays the results in a simple table or chart. This approach requires developer time upfront but scales well and doesn’t depend on a third-party plugin’s update cycle.

External tools like Google Looker Studio or Metabase can also connect to your WordPress database and visualize cross-site completion data, though you’ll need to handle authentication and data access carefully to avoid exposing sensitive learner information.

How do you set up a centralized completion rate dashboard?

To set up a centralized completion rate dashboard for a WordPress multisite LMS, you need to identify where each subsite stores completion data, write queries that pull that data into a unified view, and then surface that view in a location accessible to network administrators. The simplest version of this is a custom network admin page in WordPress; the most robust version connects your database to a dedicated BI tool.

Step 1: Map your data sources

Start by listing every subsite on your network and confirming which LMS tables hold completion records for each one. Run a quick query against the wp_blogs table to get all blog IDs, then check each subsite’s tables for the relevant LMS data. Document the table names and column structures before writing any aggregation logic.

Step 2: Build the aggregation layer

Write a PHP function or a set of SQL queries that loops through each subsite, switches to its database context using switch_to_blog(), and collects completion records. Store the results in a transient or a dedicated network-level table so the dashboard doesn’t run heavy queries on every page load. Schedule a cron job to refresh this data at a sensible interval, such as every hour or every night.

Once your data pipeline is working, the front end of the dashboard can be as simple as a WordPress admin table or as visual as a Chart.js graph embedded in a custom admin page. The key is making it easy for whoever manages the network to see completion rates per subsite, per course, and per learner group at a glance.

Why do completion rates differ between subsites on the same network?

Completion rates differ between subsites on the same WordPress multisite LMS network because each subsite typically serves a different audience, uses different course structures, or applies different completion criteria. Differences in learner motivation, course length, content quality, and even the definition of “completed” at the plugin settings level all contribute to variation across subsites.

Some of the most common reasons for the gap include:

• Audience differences: A subsite serving mandatory compliance training will show higher completion rates than one offering optional professional development
• Course design: Shorter, well-structured courses consistently outperform long, text-heavy ones regardless of audience
• Completion requirements: One subsite might require only video views, while another requires a passing quiz score, making direct comparisons misleading
• Notification and reminder settings: Subsites with automated reminder emails tend to see better follow-through from enrolled learners
• Enrollment source: Learners who self-enroll often complete at lower rates than those enrolled by an admin or manager

Before drawing conclusions from cross-subsite comparisons, make sure you’re comparing like for like. Normalizing your completion criteria across the network (covered in the next section) is the most impactful step you can take to make those comparisons meaningful.

What counts as a ‘completed’ course in a WordPress LMS?

In a WordPress LMS, a course is typically marked as “completed” when a learner has finished all required lessons, passed any required quizzes, and met any other conditions set by the course administrator, such as a minimum time on page or a final assignment submission. The exact definition varies by plugin and by how each course is configured, which is why completion rates can be misleading if you don’t standardize the criteria across your network.

LearnDash, for example, lets you set course completion to trigger automatically when all steps are done, or manually when an admin marks a learner complete. LifterLMS adds membership and prerequisite conditions on top of that. If different subsites use different settings, your network-wide completion rate data will be comparing apples to oranges.

A practical approach is to define a network-wide completion policy and document it clearly for anyone managing individual subsites. That policy might specify:

• All lessons must be marked complete (not just visited)
• Any quizzes must achieve a minimum passing score
• Completion is recorded automatically, not manually
• Certificates are issued only on full course completion, not partial progress

Consistent definitions make your LMS reporting audit far more reliable and give you data you can actually act on.

Should you use custom code or a plugin for multisite LMS reporting?

For most WordPress multisite LMS setups, starting with a plugin is the right move, then adding custom code where the plugin falls short. Plugins like Tin Canny or Wisdm Reporting handle the heavy lifting for standard reporting scenarios and save significant development time. Custom code becomes necessary when your reporting requirements are unique, your data volume is large, or you need to integrate with external systems like an HR platform or a CRM.

The honest answer is that most multisite LMS networks eventually need some custom code. Plugins are built for common use cases, and the moment your network has unusual subsite structures, non-standard completion logic, or a need to push data into another system, you’ll hit the limits of off-the-shelf tools.

Here’s a simple way to think about the decision:

• Use a plugin if: Your reporting needs are standard, your team has limited development resources, and you need something working quickly
• Use custom code if: You need real-time aggregation, your subsite count is large, you’re integrating with external tools, or you need full control over data privacy and access
• Use both if: A plugin covers 80% of your needs and targeted custom development fills the gaps without rebuilding everything from scratch

For teams that want a WordPress development partner to handle this rather than managing it in-house, working with developers who specialize in LMS and multisite builds can save a lot of trial and error.

How White Label Coders helps with WordPress multisite LMS reporting

Building a reliable completion tracking system across a WordPress multisite LMS is genuinely complex work. It touches database architecture, plugin configuration, custom development, and ongoing maintenance. White Label Coders works with agencies and product teams to design and build exactly these kinds of systems, from scratch or on top of an existing setup.

Here’s what that looks like in practice:

• Auditing your current multisite LMS setup to identify where completion data lives and where reporting gaps exist
• Configuring or extending LearnDash, LifterLMS, or TutorLMS to support consistent completion criteria across all subsites
• Building custom network admin dashboards that aggregate eLearning analytics from every subsite in real time
• Integrating your LMS data with external tools like CRMs, HR platforms, or BI tools
• Writing clean, maintainable code that your team can manage long-term without vendor lock-in

Whether you’re starting a new multisite LMS build or trying to fix reporting on an existing one, the team at White Label Coders can step in as a white-label development partner. Get in touch to talk through your setup and find out what a practical solution looks like for your network.