Опубликовано: 24.09.2026 | Источник: CNews (новости)

Аналитика воронки продаж в ВКР: проектирование платформы для маркетплейса

В марте 2026 года Lamoda переработала отчёт «Воронка продаж» в кабинете продавца. Теперь селлер получает не просто сводку продаж, а пошаговую картину: сколько показов получил товар, сколько карточек открыли, сколько добавили в корзину и где именно теряется покупатель. Казалось бы, новость из разряда продуктовых релизов маркетплейса — но для выпускника ИТ-направления она даёт готовый, живой и измеримый сюжет для ВКР. Аналитические платформы для электронной коммерции — редкая тема, где можно соединить backend, хранилище данных, веб-интерфейс и экономику внедрения в один связный проект, защитить его схемами и цифрами, а не общими словами про «цифровизацию торговли».

Семантический разбор темы перед началом работы

Прежде чем садиться за текст диплома, полезно разложить тему на составляющие. Ниже — каркас, который подойдёт для поиска литературы и формулировки научного аппарата.

Этот набор терминов дальше используется как рубрикатор: он попадёт в подзаголовки, в оглавление и в вопросы на защите.

Три темы ВКР, которые можно собрать из одного релиза Lamoda

Тема 1. Проектирование сервиса продуктовой аналитики для продавцов маркетплейса

• Актуальность: Lamoda показала, что рынок ждёт от маркетплейса не сводных отчётов, а воронки по каждому шагу. Значит, аналитический сервис становится отдельным продуктом, а не «побочным отчётом» CRM.
• Цель: разработать сервис, который собирает события просмотра, добавления в корзину и покупки и отдаёт селлеру метрики конверсии по каждому товару.
• Задачи: анализ существующих BI-решений; выбор модели хранения событий; проектирование REST API для агрегатов; расчёт метрик drop-off.
• Структура: Гл. 1 — обзор подходов к web-аналитике; Гл. 2 — архитектура сервиса и схема данных; Гл. 3 — нагрузочное тестирование и оценка экономии времени селлера.

Тема 2. Сравнительный анализ хранилищ для событийных воронок

• Актуальность: Lamoda явно работает с потоковыми событиями кликов. Для студента это повод сравнить ClickHouse, PostgreSQL и колоночные СУБД на одном наборе данных.
• Цель: обосновать выбор СУБД для хранения событий воронки по критериям ISO/IEC 25010.
• Задачи: сгенерировать синтетический датасет событий; прогнать одинаковые запросы агрегации; сравнить latency, объём индексов, стоимость инфраструктуры.
• Структура: Гл. 1 — теория OLAP и колоночных хранилищ; Гл. 2 — методика эксперимента и стенд; Гл. 3 — таблицы замеров, выводы по TCO.

Тема 3. Мониторинг качества аналитического пайплайна на базе OpenTelemetry

• Актуальность: релиз Lamoda невозможен без доверия к данным. Студенту логично доказывать не только «сделал», но и «измерил надёжность».
• Цель: спроектировать систему наблюдаемости для ETL-пайплайна воронки продаж.
• Задачи: описать SLI/SLO для пайплайна; развернуть трейсинг через OpenTelemetry; собрать дашборд в Grafana; провести chaos-тест с падением одного из потребителей Kafka.
• Структура: Гл. 1 — SRE-подходы к аналитике; Гл. 2 — схема пайплайна и точки инструментирования; Гл. 3 — эксперименты, RTO/RPO, вывод о готовности к эксплуатации.

Аналитическая глава: как обосновать стек, а не перечислить модные слова

Первую главу часто проваливают именно на этапе сравнения. Студент пишет «Kafka — надёжная, PostgreSQL — известная», и комиссия теряет интерес. Работает другой приём: зафиксировать критерий из статьи-источника — рост числа событий на каждую карточку товара — и уже под него подбирать инструменты.

Обоснование выбора — половина защиты. Вторую половину даёт расчёт: зачем именно столько узлов и какова цена ошибки. Здесь уместны ссылки на ГОСТ 34.602-89 — состав требований к системе.

Проектная часть: от схемы API до диаграммы развёртывания

Схема данных воронки

Минимальный набор сущностей для повторения логики Lamoda: event (тип: view, cart, purchase), product, seller, session. Событие — узкая таблица с временной меткой и идентификаторами, агрегаты считаются по расписанию в отдельную витрину. Приложите ER-диаграмму по нотации Чена или IDEF1X — этого ждёт нормоконтроль.

Алгоритм расчёта потерь

drop_off(p) = (views - next_step) / views * 100
conversion(p) = purchases / views * 100

Формулы простые, но именно их студенты забывают вынести в отдельный раздел — а комиссия любит спрашивать «как вы считали конверсию».

Интеграция с системой продавца

Опишите, как отчёт появляется в личном кабинете: брокер → потоковый обработчик → витрина → REST API → веб-компонент. На схеме развёртывания покажите два контура — сбор данных и выдачу отчётов. Это ровно то, что реализует Lamoda, только у вас будет упрощённый учебный вариант.

Проверка работоспособности: метрики, нагрузка, устойчивость

Раздел тестирования — единственный, где диплом превращается в инженерную работу. Опишите стенд, сценарии и результаты.

• Нагрузочное тестирование: k6 или JMeter, профиль — 1000 событий в секунду на один узел, замер p95 и p99 latency отчёта.
• Наблюдаемость: OpenTelemetry-трейсинг пайплайна, метрики Prometheus, дашборд Grafana со сквозным временем от события до витрины.
• Отказоустойчивость: остановка consumer-группы, замер RTO — время, за которое витрина догоняет поток; RPO определяется политикой Kafka retention.
• Качество данных: доля дублей, доля потерянных событий, сверка витрины с источником. Показатели хорошо ложатся в ISO/IEC 25010.

Чему вы научитесь на такой теме

• Проектировать событийную архитектуру и объяснять выбор брокера не «по-модному», а по нагрузке.
• Считать продуктовые метрики — конверсию, drop-off, retention — и защищать их формулами.
• Оформлять ТЗ по ГОСТ 34.602-89 и схемы по ГОСТ 19.701-90 без паники перед нормоконтролем.
• Строить CI/CD-пайплайн для аналитического сервиса: сборка образа, миграции, деплой на тестовый контур.
• Готовить раздел экономики не «на глаз», а от сэкономленного времени селлера и стоимости инфраструктуры.

Частые вопросы выпускников

Источник: Lamoda усилила аналитику для продавцов (опубликовано 2026-03-25)