Learning Progress Tracking System for LMS Development

Our company is engaged in the development, support and maintenance of sites of any complexity. From simple one-page sites to large-scale cluster systems built on micro services. Experience of developers is confirmed by certificates from vendors.

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Showing 1 of 1All 2062 services
Learning Progress Tracking System for LMS Development
Medium
~3-5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1362
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    958
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    949

Students drop courses if they don't see their own progress. A simple counter like "5 of 20 lessons" neither motivates nor informs the instructor about who is falling behind. We develop learning progress systems that collect data at the second level: how much video was watched, which assignments were completed, how often the student logs in. This data forms the basis for analytics and alerts. Over years of work, we have implemented such systems for ten educational platforms—from small schools to corporate universities. Our experience guarantees the system will work under load and not lose a single event. Instructor time savings of up to 30% through automatic notifications.

What Problems Does Progress Tracking Solve

Inactive students. Without automatic notifications, the instructor learns about churn post-factum. Our progress system sends alerts to instructors if a student has not logged in for 7 days with an unfinished course. This allows timely intervention.

Low student engagement. Streak (consecutive days) is a powerful motivator. We calculate it automatically and display it in the personal account. If the streak is broken, the student sees they need to return.

Lack of learning analytics. Activity events show which lessons are toughest and where students rewatch videos. For example, if 70% of students rewind a specific segment, the content needs revision.

Why Is Streak Important for Retention?

Streak motivates 30% more effectively than a simple counter. If a student misses a day, the streak resets to 1 (not 0), psychologically giving a chance to rebuild the habit. We have seen streak implementation increase return rate by 40% in a short period on one platform.

How Do We Track Video Progress?

We use the stack: React on the frontend, Laravel on the backend, PostgreSQL for storage, Redis for activity caching. Example video tracker:

// Frontend: sending video progress
class VideoProgressTracker {
  constructor(videoElement, lessonId) {
    this.video = videoElement;
    this.lessonId = lessonId;
    this.maxReached = 0;
    this.setupListeners();
  }

  setupListeners() {
    // Send progress on pause, not on every timeupdate
    this.video.addEventListener('pause', () => this.reportProgress());
    this.video.addEventListener('ended', () => this.markCompleted());

    // Track maximum watched point (do not count rewinding)
    this.video.addEventListener('timeupdate', () => {
      const pct = (this.video.currentTime / this.video.duration) * 100;
      if (pct > this.maxReached) this.maxReached = pct;
    });
  }

  async reportProgress() {
    await api.post(`/lessons/${this.lessonId}/progress`, {
      videoProgress: this.maxReached,
      lastPosition: Math.floor(this.video.currentTime),
      timeSpentSec: Math.floor(this.video.currentTime),
    });
  }

  async markCompleted() {
    if (this.maxReached >= 85) {  // Consider lesson watched at 85%
      await api.post(`/lessons/${this.lessonId}/complete`);
    }
  }
}

This code sends progress only on pause—not on every timeupdate—to avoid overloading the server. A lesson is considered complete at 85% watch time.

Technical Implementation

Data Model

-- Lesson progress
CREATE TABLE lesson_progress (
  id              UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  student_id      UUID REFERENCES users(id),
  lesson_id       UUID REFERENCES lessons(id),
  course_id       UUID REFERENCES courses(id),
  status          VARCHAR(30) DEFAULT 'not_started', -- not_started, in_progress, completed
  started_at      TIMESTAMPTZ,
  completed_at    TIMESTAMPTZ,
  time_spent_sec  INT DEFAULT 0,
  video_progress  NUMERIC(5,2),  -- % video watched
  last_position   INT,           -- last video second
  UNIQUE(student_id, lesson_id)
);

-- Course progress (aggregate)
CREATE TABLE course_progress (
  student_id          UUID REFERENCES users(id),
  course_id           UUID REFERENCES courses(id),
  lessons_completed   INT DEFAULT 0,
  lessons_total       INT NOT NULL,
  percentage          NUMERIC(5,2) DEFAULT 0,
  last_activity_at    TIMESTAMPTZ,
  started_at          TIMESTAMPTZ,
  completed_at        TIMESTAMPTZ,
  streak_days         INT DEFAULT 0,
  PRIMARY KEY(student_id, course_id)
);

-- Detailed activity log for analytics
CREATE TABLE activity_events (
  id          UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  student_id  UUID REFERENCES users(id),
  event_type  VARCHAR(100) NOT NULL, -- 'video_played', 'video_paused', 'lesson_completed'
  entity_type VARCHAR(50),
  entity_id   UUID,
  metadata    JSONB DEFAULT '{}',   -- position, duration, device, etc.
  created_at  TIMESTAMPTZ DEFAULT NOW()
);
CREATE INDEX ON activity_events (student_id, created_at DESC);
CREATE INDEX ON activity_events (entity_id, event_type);

How the Streak Is Calculated

Streak is the number of consecutive days a student performed at least one action. Algorithm:

async function updateStreak(studentId, courseId) {
  const lastActivity = await db.courseProgress.findOne({ studentId, courseId }, 'last_activity_at');
  const today = new Date().toDateString();
  const yesterday = new Date(Date.now() - 86400000).toDateString();
  const lastDate = new Date(lastActivity.lastActivityAt).toDateString();

  let streakDelta = 0;
  if (lastDate === today) {
    streakDelta = 0; // Already updated today
  } else if (lastDate === yesterday) {
    streakDelta = 1; // Streak continues
  } else {
    // Streak broken — start over from 1
    await db.courseProgress.update({ studentId, courseId }, { streakDays: 1 });
    return;
  }

  if (streakDelta > 0) {
    await db.courseProgress.increment({ studentId, courseId }, 'streak_days', 1);
  }
}

Identifying At-Risk Students

Automatic alerts for instructors:

  • Student hasn't logged in for 7+ days with an unfinished course.
  • Progress < 20% two weeks after enrollment.
  • Sharp slowdown: last week 5 lessons, this week 0.
-- Students inactive for 7+ days
SELECT cp.student_id, u.name, u.email,
       cp.percentage, cp.last_activity_at
FROM course_progress cp
JOIN users u ON u.id = cp.student_id
WHERE cp.course_id = $1
  AND cp.completed_at IS NULL
  AND cp.last_activity_at < NOW() - INTERVAL '7 days';

Tracking Levels: Comparison

Level What We Track Technical Complexity Approx. Implementation Time
Basic Number of completed lessons Low 2–3 days
Medium Video progress, streak, session time Medium 4–5 days
Advanced Activity events, cohorts, alerts High 7–10 days

We implement the level that fits your needs. Most often, Medium level is sufficient—it delivers 80% of the value with 50% of the effort.

Typical Mistakes in Tracking Implementation

Mistake Consequence How to Avoid
Sending progress on every timeupdate High server load, data loss on pauses Send only on pause/completion
Resetting streak on inactivity Demotivates students Start streak at 1 after a skip, not 0
Storing all events without archiving Table growth to terabytes Use partitioning and TTL indexes

We eliminate these mistakes at the design stage. Our engineers with years of LMS experience anticipate bottlenecks in advance.

Implementation Process

  1. Analytics. We study your LMS, course list, reporting requirements.
  2. Design. We design the data model, API endpoints, event schema.
  3. Implementation. We write backend on Laravel, frontend on React, integrate with video player.
  4. Testing. We verify data collection correctness, perform load testing.
  5. Deployment. We deploy on your server or cloud. Provide documentation.

What's Included in the Work

  • Data model (migrations, indexes)
  • API for recording and reading progress
  • Frontend components (indicators, progress bar)
  • Teacher alerts (email/telegram)
  • LMS analytics dashboards (active students, completion rate)
  • Operation manual
  • 6-month code warranty

Timeline and Cost

Basic tracking (lessons + course) — 3–4 days. Adding video tracking and streak — another 2–3 days. Analytics and alerts — 3–4 days. Final cost is calculated individually after auditing your LMS. Contact us—we'll evaluate the project within one business day. Get a consultation on the optimal tracking level.

Why Choose Us

Years of experience in educational platform development. We have completed 10+ projects, support over 5000 students. We know how to work with PostgreSQL on millions of records without performance degradation. We use proven patterns—Repository, BFF—to keep code maintainable. Our clients reduce training costs by 25% and increase student LTV by 30%. Get in touch for a detailed discussion of your project.

Setup Web Analytics: GA4, GTM, Yandex.Metrica, and Amplitude

We often see: conversion rate 1.2%, traffic grows, but conversion stays flat. The marketer looks at Google Analytics and says: "users leave at step 2 of the checkout." The developer opens the same step — no errors, Sentry is silent. So it's not a JS bug, but a UX issue or skewed data from analytics. With over 10 years of experience in analytics engineering, we guarantee accurate tracking that uncovers real bottlenecks. Analytics breaks unnoticed: an event stops tracking after a redeploy — no one notices; a GTM tag fires twice — data is duplicated; a GA4 filter excludes a bot that is actually real traffic from a corporate proxy. An audit of your current tags will find the cause within a week.

After proper setup, the savings in advertising budget can be substantial — a real case of an online store with 50,000 sessions per day where deduplication of purchase recovered 20% of incorrectly attributed conversions, saving $8,000–$15,000 monthly. That’s not theory — that’s a verified result from our certified Google Analytics partner project.

Why do GA4 events duplicate and how to fix it?

Universal Analytics is gone, replaced by GA4's event-based model. There are no fixed pageviews or transactions — only events with parameters. This is more flexible but requires proper event design. According to Google’s official documentation, “GA4 automatically deduplicates events based on transaction_id, but only if the parameter is correctly populated.” Many implementations miss this.

Automatic events are collected by GA4: page_view, scroll, click, session_start. Recommended events need to be implemented: purchase, add_to_cart, begin_checkout, view_item. Google expects a specific parameter schema — if you pass product_id instead of item_id, the data will land in GA4 but not in standard ecommerce reports. Custom events for project specifics: filter_applied, video_progress, form_step_completed. Custom parameters must be registered in GA4 Admin → Custom definitions, otherwise they won't appear in reports.

A common mistake is the purchase event being duplicated. Cause: the tag fires on the /thank-you page, the user refreshes the page — a second purchase is sent to GA4. Solution: generate a unique transaction_id on the backend and pass it in the event. In our experience, 80% of e-commerce stores have this issue. GA4 deduplicates based on it (in theory — verify with DebugView). Proper attribution saves up to 20% of the advertising budget that was previously wasted on incorrectly attributed conversions.

How to set up the data layer to avoid data loss?

GTM is a tool for managing tags without code deployment. But "no code" doesn't mean "no architecture." The data layer is the foundation. We pass data from the application to GTM via dataLayer.push(). Structure: event + contextual data. For e-commerce: before opening a product page — push with product data. GTM tag reads from the data layer, not from the DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Product name',
      price: 1990.00,
      currency: 'USD'
    }]
  }
});

Bad practice: GTM tag parses the DOM — looks for the price in span.price, the name in h1. This breaks with any layout change. Good practice: always use the data layer. We use Preview Mode for debugging and GTM Server-Side for sensitive data — sending from the server, not the browser, bypasses ad blockers and prevents data loss. A properly implemented data layer reduces tracking errors by 95%.

How does Yandex.Metrica complement web analytics?

For a Russian audience, Metrica is a must — especially Webvisor. Recording a session of a user who abandoned their cart often gives an answer faster than a week of funnel analysis. Goals in Metrica: event-based (via ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) or automatic (button click, page visit). Integration with CRM via Metrica Plus — passing offline conversions. Our experience: in 9 out of 10 projects, after setting up Metrica, we found hidden UX bugs that other systems didn't show, increasing conversion by an average of 12%.

What does product analytics give in Amplitude?

Amplitude is a product tool, unlike marketing-oriented GA4 and Metrica. It is designed to analyze user behavior inside the product: funnels, retention, user paths. Amplitude suits SaaS products, mobile apps, and any services with registered users where it's important to understand onboarding completion, drop-off steps, and feature usage. Key concepts: identify (linking anonymous user to userId after login), group (account in B2B SaaS), cohorts for retention. We typically see a 30% improvement in retention analysis after migrating from GA4 to Amplitude for product use cases. Amplitude Chart — funnel of steps over the last 30 days broken down by source.

Monitoring Data Quality

Analytics without monitoring is a black box. We set up:

  • GA4 Realtime — check after every deploy that key events are coming in
  • Alerting in GA4 — anomaly in the number of purchase events (sharp drop = something broke)
  • GTM Preview in staging before production
  • Manual funnel tests once a week — simply go through the buyer journey and verify everything is tracked
What we check after each deploy
  • All recommended events present in DebugView
  • No duplicates (count purchase per 100 sessions)
  • Data layer structure unchanged after frontend update

What the work includes

Component Description
Audit of existing tags Check current GTM tags, data layer, duplicates, and errors
Event schema design Documentation: event list, parameters, triggers
GA4 + GTM setup Create configuration, tags, custom definitions
Yandex.Metrica Install counter, create goals, set up Webvisor
Amplitude (optional) Set up client and server SDK, cohorts
QA and monitoring Testing in Preview Mode, alerting
Training and handover Access, instructions for adding new events, console

Process and timeline

  1. Audit of existing tags and data (2 days)
  2. Event schema design (2 days)
  3. Data layer development and tag setup (3–5 days)
  4. QA in Preview Mode and staging (2 days)
  5. Deploy and dashboard setup (1 day)
Scenario Timeline
Basic GA4 + GTM setup 1 week
Full e-commerce tracking + Metrica 2–3 weeks
Server-side GTM + Amplitude 3–5 weeks

Cost is calculated individually. Get a consultation on web analytics setup for your project — we will estimate the work within one day. Contact us to get started with a free audit of your current tracking.