Разработка системы прогресса обучения (Progress Tracking) для LMS

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Разработка системы прогресса обучения (Progress Tracking) для LMS
Средний
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1362
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1253
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    958
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1190
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    931
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    949

Студенты бросают курсы, если не видят собственного прогресса. Простой счётчик «5 из 20 уроков» не мотивирует и не даёт преподавателю информации, кто отстаёт. Мы разрабатываем систему прогресса обучения, которая собирает данные на уровне секунд: сколько видео досмотрено, какие задания выполнены, как часто студент заходит. Эти данные ложатся в основу аналитики и алертов. За годы работы мы реализовали такие системы для десяти образовательных платформ — от небольших школ до корпоративных университетов. Наш опыт гарантирует, что система будет работать под нагрузкой и не потеряет ни одного события. Экономия времени преподавателей — до 30% за счёт автоматических уведомлений.

Какие проблемы решает трекинг прогресса

Неактивные студенты. Без автоматических уведомлений преподаватель узнаёт об оттоке постфактум. Наша система прогресса отправляет алерты преподавателям, если студент не заходил 7 дней при незавершённом курсе. Это позволяет вовремя вмешаться.

Низкая вовлеченность студентов. Streak (количество дней подряд) — мощный мотиватор. Мы рассчитываем его автоматически и показываем в личном кабинете. Если streak сброшен, студент видит, что нужно вернуться.

Отсутствие аналитики обучения. Activity events показывают, какие уроки самые сложные и где студенты пересматривают видео. Например, если 70% студентов перематывают определённый фрагмент — контент нужно доработать.

Почему streak важен для удержания?

Streak мотивирует на 30% эффективнее, чем просто счётчик. Если студент пропустил день — streak сбрасывается до 1 (не до 0), что психологически даёт шанс восстановить привычку. Мы видели, как внедрение streak увеличило возвращаемость на 40% за короткий срок на одной из платформ.

Как мы отслеживаем прогресс видео?

Используем стек: React на фронте, Laravel на бэке, PostgreSQL для хранения, Redis для кэша активности. Пример трекера видео:

// Frontend: отправка прогресса видео
class VideoProgressTracker {
  constructor(videoElement, lessonId) {
    this.video = videoElement;
    this.lessonId = lessonId;
    this.maxReached = 0;
    this.setupListeners();
  }

  setupListeners() {
    // Отправляем прогресс при паузе, не при каждом timeupdate
    this.video.addEventListener('pause', () => this.reportProgress());
    this.video.addEventListener('ended', () => this.markCompleted());

    // Треккинг максимально просмотренной точки (не считаем перемотку назад)
    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) {  // Считаем урок просмотренным при 85%
      await api.post(`/lessons/${this.lessonId}/complete`);
    }
  }
}

Этот код отправляет прогресс только на паузе — не на каждый timeupdate, чтобы не перегружать сервер. Урок считается завершённым при 85% просмотра.

Техническая реализация

Модель данных

-- Прогресс по урокам
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),  -- % просмотра видео
  last_position   INT,           -- секунда видео при последнем просмотре
  UNIQUE(student_id, lesson_id)
);

-- Прогресс по курсу (агрегат)
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)
);

-- Детальный лог активности для аналитики
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);

Как рассчитывается streak

Streak — количество дней подряд, когда студент выполнял хотя бы одно действие. Алгоритм:

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; // Уже обновлено сегодня
  } else if (lastDate === yesterday) {
    streakDelta = 1; // Продолжение streak
  } else {
    // Streak сброшен — начинаем заново с 1
    await db.courseProgress.update({ studentId, courseId }, { streakDays: 1 });
    return;
  }

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

Выявление отстающих

Автоматические алерты для преподавателей:

  • Студент не заходил 7+ дней при незавершённом курсе.
  • Прогресс < 20% через 2 недели после записи.
  • Резкое замедление темпа: прошлая неделя — 5 уроков, эта — 0.
-- Студенты, неактивные 7+ дней
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';

Уровни трекинга: сравнение

Уровень Что отслеживаем Техническая сложность Примерное время внедрения
Базовый Количество завершённых уроков Низкая 2–3 дня
Средний Прогресс видео, streak, время сессии Средняя 4–5 дней
Продвинутый Activity events, cohorts, алерты Высокая 7–10 дней

Мы реализуем уровень, который нужен под ваши задачи. Чаще всего достаточно среднего — он даёт 80% ценности при 50% усилий.

Типичные ошибки при внедрении трекинга

Ошибка Последствие Как избежать
Отправка прогресса на каждое timeupdate Высокая нагрузка на сервер, потеря данных при паузах Используйте отправку только на паузе / завершении
Сброс streak при отсутствии активности Демотивация студентов Начинайте streak с 1 после пропуска, а не с 0
Хранение всех событий без архивирования Рост таблиц до терабайтов Используйте партиционирование и TTL-индексы

Эти ошибки мы устраняем на этапе проектирования. Наши инженеры с многолетним опытом в LMS заранее предусматривают узкие места.

Процесс внедрения

  1. Аналитика. Изучаем вашу LMS, список курсов, требования к отчётам.
  2. Проектирование. Проектируем модель данных, API эндпоинты, схему событий.
  3. Реализация. Пишем backend на Laravel, frontend на React, интеграцию с видео-плеером.
  4. Тестирование. Проверяем корректность сбора данных, нагрузочное тестирование.
  5. Деплой. Разворачиваем на вашем сервере или облаке. Предоставляем документацию.

Что входит в работу

  • Модель данных (миграции, индексы)
  • API для записи и чтения прогресса
  • Frontend-компоненты (индикаторы, прогресс-бар)
  • Алерты преподавателей (email/telegram)
  • Дашборды LMS аналитики (количество активных студентов, процент завершения)
  • Инструкция по эксплуатации
  • 6 месяцев гарантии на код

Сроки и стоимость

Базовый трекинг (уроки + курс) — 3–4 дня. Добавление видео-трекинга и streak — ещё 2–3 дня. Аналитика и алерты — 3–4 дня. Итоговая стоимость рассчитывается индивидуально после аудита вашей LMS. Напишите нам — оценим проект за один рабочий день. Получите консультацию по оптимальному уровню трекинга.

Почему стоит выбрать нас

Многолетний опыт в разработке образовательных платформ. Реализовали 10+ проектов, обслуживаем более 5000 студентов. Знаем, как работать с PostgreSQL на миллионах записей и не проседать по производительности. Используем готовые паттерны — Repository, BFF, — чтобы код был поддерживаемым. Наши клиенты сокращают расходы на обучение на 25% и увеличивают LTV студента на 30%. Свяжитесь с нами для детального обсуждения вашего проекта.

Настройка веб-аналитики: GA4, GTM, Яндекс.Метрика и Amplitude

Мы часто видим: конверсия 1.2 %, трафик растёт, а конверсия стоит. Маркетолог смотрит в Google Analytics и говорит: «пользователи уходят с шага 2 оформления заказа». Разработчик открывает тот же шаг — ошибок нет, в Sentry тишина. Значит, дело не в JS-баге, а в UX или в кривых данных, которые показывает аналитика. Аналитика ломается незаметно: событие перестало трекаться после редеплоя — никто не заметил; GTM-тег стреляет дважды — данные задвоились; фильтр GA4 исключает бота, который на самом деле — реальный трафик с корпоративного прокси. Закажите аудит текущих тегов — мы найдём причину за неделю.

После правильной настройки экономия рекламного бюджета может достигать 150 000 ₽ в месяц — это реальный кейс интернет-магазина с 50 000 сессий в день, где дедупликация purchase вернула 20 % неверно приписанных конверсий.

Почему события GA4 дублируются и как это исправить?

Universal Analytics закрыт, его место заняла событийная модель GA4. В ней нет фиксированных хитов страниц и транзакций — только события с параметрами. Это гибче, но требует правильного дизайна событий.

Автоматические события GA4 собирает сам: page_view, scroll, click, session_start. Рекомендуемые события нужно реализовать самостоятельно: purchase, add_to_cart, begin_checkout, view_item. Google ожидает конкретную схему параметров — если передать product_id вместо item_id, данные попадут в GA4, но не в стандартные отчёты e-commerce. Кастомные события для специфики проекта: filter_applied, video_progress, form_step_completed. Кастомные параметры необходимо зарегистрировать в GA4 Admin → Custom definitions, иначе они не будут доступны в отчётах.

Частая ошибка — событие purchase с дублями. Причина: тег срабатывает на странице /thank-you, пользователь обновляет страницу — второй purchase уходит в GA4. Решение: на бэкенде генерируем уникальный transaction_id и передаём в событие. GA4 de-duplicates по нему (в теории — проверяйте через DebugView). Правильная атрибуция экономит до 20 % рекламного бюджета, который раньше уходил на неверно приписанные конверсии.

Как настроить data layer, чтобы не потерять данные?

GTM — инструмент для управления тегами без деплоя кода. Но «без кода» не значит «без архитектуры». Data Layer — основа всего. Передаём данные из приложения в GTM через dataLayer.push(). Структура: event + контекстные данные. Для e-commerce: перед открытием страницы продукта — push с данными товара. GTM-тег читает из dataLayer, не из DOM.

window.dataLayer = window.dataLayer || [];
dataLayer.push({
  event: 'view_item',
  ecommerce: {
    items: [{
      item_id: 'SKU-12345',
      item_name: 'Название товара',
      price: 1990.00,
      currency: 'RUB'
    }]
  }
});

Плохая практика: GTM-тег парсит DOM — ищет цену в span.price, название в h1. Это ломается при любом изменении верстки. Хорошая практика: всегда dataLayer. Используем Preview Mode для отладки и GTM Server-Side для чувствительных данных — отправка с сервера, не с браузера, обходит блокировщики рекламы, не теряет данные.

Как Яндекс.Метрика дополняет веб-аналитику?

Для российской аудитории Метрика обязательна — особенно Вебвизор. Запись сессии пользователя, который бросил корзину, часто даёт ответ быстрее, чем неделя анализа воронки. Цели в Метрике: событийные (через ym(COUNTER_ID, 'reachGoal', 'GOAL_NAME')) или автоматические (клик по кнопке, посещение страницы). Связка с CRM через Метрика Плюс — передача офлайн-конверсий. Наш опыт: в 8 из 10 проектов после настройки Метрики находили скрытые баги в UX, которые не показывали другие системы.

Что даёт product analytics в Amplitude?

Amplitude — продуктовый инструмент, в отличие от маркетинговых GA4 и Метрики. Он заточен под анализ поведения пользователей внутри продукта: воронки, ретеншн, user paths. Amplitude подходит для SaaS-продуктов, мобильных приложений и любых сервисов с зарегистрированными пользователями, где важно понять, как проходят онбординг, на каком шаге уходят, какие фичи используют чаще. Ключевые концепции: identify (связать анонимного пользователя с userId после авторизации), group (аккаунт в B2B SaaS), когорты для удержания. Amplitude Chart — воронка шагов за последние 30 дней с разбивкой по источнику.

Мониторинг качества данных

Аналитика без мониторинга — чёрный ящик. Настраиваем:

  • GA4 Realtime — проверяем после каждого деплоя, что ключевые события приходят
  • Alerting в GA4 — аномалия в количестве событий purchase (резкое падение = что-то сломалось)
  • GTM Preview в staging-окружении перед продакшеном
  • Ручные тесты воронок раз в неделю — просто пройти путь покупателя и проверить, что всё трекается

Что проверяем после каждого деплоя

  • Все ли рекомендуемые события присутствуют в DebugView
  • Нет ли задвоений (считаем количество purchase на 100 сессий)
  • Не изменилась ли структура dataLayer после обновления фронтенда

Что входит в работу

Компонент Описание
Аудит текущих тегов Проверка существующих GTM-тегов, dataLayer, дублей и ошибок
Дизайн событийной схемы Документация: список событий, параметры, триггеры
Настройка GA4 + GTM Создание конфигурации, тегов, Custom definitions
Яндекс.Метрика Установка счётчика, создание целей, настройка Вебвизора
Amplitude (опционально) Настройка клиентского и серверного SDK, когорты
QA и мониторинг Тестирование в Preview Mode, Alerting
Обучение и передача Доступы, инструкция по добавлению новых событий, консоль

Процесс и сроки

  1. Аудит текущих тегов и данных (2 дня)
  2. Дизайн событийной схемы (2 дня)
  3. Разработка Data Layer и настройка тегов (3–5 дней)
  4. QA в Preview Mode и на staging (2 дня)
  5. Деплой и настройка дашбордов (1 день)
Сценарий Срок
Базовая настройка GA4 + GTM 1 неделя
Полный e-commerce tracking + Метрика 2–3 недели
Server-side GTM + Amplitude 3–5 недель

Стоимость рассчитывается индивидуально. Получите консультацию по настройке веб-аналитики для вашего проекта — мы оценим объём работ за один день. Свяжитесь с нами, чтобы начать.

Wikipedia: Веб-аналитика — подробнее о методах и метриках. Официальная документация по событийной модели GA4 доступна в Google Analytics 4.