Опубликовано: 21.09.2026 | Источник: TechCrunch

Микро-драмы в дипломе: рекомендательная система и аналитика удержания для мобильного видеосервиса

Пока академическое сообщество спорило, умерло ли длинное видео, рынок тихо собрал миллиарды на его противоположности. По данным TechCrunch, «micro dramas» — вертикальные сериалы на 60–90 секунд с клиффхэнгером на последней секунде — превратились в отдельную индустрию: тайные миллиардеры, неодобрительные матери-оборотни, оплата за серию монетами внутри приложения. Для выпускника ИТ это не курьёз из мира контента, а готовый полигон для ВКР: здесь одновременно живут рекомендательные системы, потоковая аналитика событий, биллинг микроплатежей, эксперименты на пользователях и жёсткие SLA по доставке видео. Ниже — как превратить этот сюжет в защищаемую работу, а не в пересказ новости.

Три темы ВКР, которые вырастают из этого кейса

Все три опираются на одну предметную область, но дают разный результат — модель, пайплайн или архитектуру. Выбирайте ту, где у вас есть доступ к данным или возможность сгенерировать синтетику.

Тема 1. Рекомендательная система для коротких вертикальных серий

• Актуальность: в микро-драмах длина сессии критична — пользователь должен провалиться в следующую серию, а не уйти в ленту конкурента. Именно рекомендация определяет, дойдёт ли он до платного эпизода.
• Цель: повысить долю просмотров «следующей серии» (completion-to-next ratio) относительно базовой эвристики «популярное за неделю» не менее чем на 8%.
• Задачи: собрать профиль взаимодействий (досмотр, свайп, пауза, покупка монет), обучить two-tower модель кандидатов, добавить ранжирование с учётом контекста сессии, провести офлайн- и онлайн-оценку.
• Структура: Глава 1 — анализ формата микро-драм и метрик вовлечённости; Глава 2 — проектирование пайплайна рекомендаций (C4 + схема признаков); Глава 3 — эксперимент, сравнение с baseline, расчёт эффекта.

Тема 2. Прогнозирование оттока и LTV в модели микроплатежей

• Актуальность: монетизация микро-драм комбинированная — монеты за эпизод, недельная подписка, реклама за вознаграждение. Отток платящего пользователя на 3-й день обнуляет экономику привлечения.
• Цель: построить модель бинарной классификации оттока на горизонте 7 дней с ROC-AUC ≥ 0,78 и перевести её в правило таргетированной скидки.
• Задачи: определить событийную воронку, сформировать признаки (частота сессий, глубина просмотра, число отказов от покупки), обучить градиентный бустинг, оценить экономический эффект через LTV/CAC.
• Структура: Глава 1 — бизнес-модель и unit-экономика сервиса; Глава 2 — витрина данных и модель; Глава 3 — валидация, калибровка вероятностей, оценка эффекта кампании удержания.

Тема 3. Потоковая аналитика просмотров и A/B-платформа

• Актуальность: клиффхэнгер — это гипотеза, которую нужно проверять. Без честного A/B-контура команда правит сценарий «на глаз», а это прямой путь к выгоранию бюджета.
• Цель: спроектировать потоковый пайплайн событий и сервис разбиения на эксперименты с корректным расчётом значимости.
• Задачи: описать схему событий, развернуть сбор через очередь сообщений, реализовать агрегаты в колоночной СУБД, добавить контроль метрик и guardrail-показателей.
• Структура: Глава 1 — обзор подходов к измерению вовлечённости; Глава 2 — архитектура сбора и хранения (UML-диаграмма последовательности + C4); Глава 3 — нагрузочное тестирование и разбор кейса A/B на длине серии.

Что положить в каждую главу: раскладка по тексту ВКР

Глава 1. Материал статьи как источник требований

Не пересказывайте новость — извлеките из неё измеримые сущности. Из формата «soap opera × TikTok» выводятся четыре класса требований: контентные (вертикаль 9:16, длина 60–90 с, hook в первые 3 секунды), пользовательские (мгновенный старт воспроизведения, автопереход), экономические (оплата за эпизод, подписка, реклама) и эксплуатационные (стоимость доставки трафика). Каждое требование оформляйте как проверяемое: не «быстрая загрузка», а «время до первого кадра ≤ 1,5 с на 4G при p95».

Здесь же уместна таблица сравнения с аналогами — три-четыре сервиса, критерии: модель монетизации, средняя длина эпизода, наличие рекомендаций, поддержка офлайн-просмотра. Источником цифр могут быть открытые обзоры рынка и сами приложения; обязательно фиксируйте дату снятия метрик.

Глава 2. Проектирование: диаграммы, которые спросят на защите

Минимальный набор графики, который закрывает вопросы комиссии:

• C4 (уровни 1–2): контекст системы (клиент, сервис контента, платёжный шлюз, аналитика) и контейнеры (API-шлюз, сервис рекомендаций, хранилище признаков, очередь событий).
• UML Sequence: путь одного просмотра — запрос манифеста → выбор серии → событие просмотра → пересчёт рекомендации → показ следующей серии.
• BPMN или схема воронки: онбординг → первый бесплатный эпизод → paywall → покупка монет → возврат.
• ER-диаграмма: пользователь, серия, сезон, транзакция, событие просмотра, эксперимент.

Пример схемы признаков для рекомендаций в виде псевдоконфигурации хранилища:

user_features:
  - last_3_watched_genres        # top-3 жанра, скользящее окно 14 дней
  - avg_completion_rate          # средняя досматриваемость, 30 дней
  - coin_balance_bucket          # категориальный признак: 0 / 1-50 / 51+
  - hours_since_last_session
item_features:
  - episode_duration_sec
  - cliffhanger_score            # разметка сценариста, 0.0–1.0
  - is_paywalled
  - cohort_release_week
label:
  - watched_next_episode_within_10min  (0/1)

Глава 3. Эксперимент, метрики и статистика

Ключевая метрика в этом домене — не «просмотры», а досматриваемость и переход к следующей серии. Формула расчёта удержания по когортам на колоночной СУБД выглядит так:

-- D7 retention по когортам первого дня
SELECT
    cohort_date,
    uniqExact(user_id)                                        AS cohort_size,
    uniqExactIf(user_id, day_offset = 7)                      AS retained_d7,
    round(retained_d7 / cohort_size, 4)                       AS d7_rate
FROM (
    SELECT
        user_id,
        min(toDate(event_time)) AS cohort_date,
        dateDiff('day', min(toDate(event_time)), toDate(event_time)) AS day_offset
    FROM view_events
    GROUP BY user_id, toDate(event_time)
)
GROUP BY cohort_date
ORDER BY cohort_date;

Для A/B-теста на конверсии в следующую серию считайте z-критерий для долей, а не «на глазок»:

from math import sqrt
from statistics import NormalDist

def ab_significance(c_a, n_a, c_b, n_b, alpha=0.05):
    p_a, p_b = c_a / n_a, c_b / n_b
    p_pool = (c_a + c_b) / (n_a + n_b)
    se = sqrt(p_pool * (1 - p_pool) * (1 / n_a + 1 / n_b))
    z = (p_b - p_a) / se
    p_value = 2 * (1 - NormalDist().cdf(abs(z)))
    return {"lift": round((p_b - p_a) / p_a, 4), "p_value": round(p_value, 5),
            "significant": p_value < alpha}

Не забудьте про guardrail-метрики: число жалоб на контент, доля отказов платежей, нагрузка на CDN. Рост конверсии за счёт агрессивного paywall — классическая ловушка, которую ловят на защите.

Нормоконтроль: где чаще всего снимают баллы

Схемы — по ГОСТ 19.701-90 (или UML с расшифровкой обозначений), текстовый документ — по ГОСТ 2.105-95, стадии и этапы создания системы — по ГОСТ 34.601-90, ТЗ на программу — по ГОСТ 19.201-78. Качество продукта удобно описывать через ISO/IEC 25010: функциональная полнота, производительность, надёжность, удобство использования. Если в работе есть платёжный модуль, добавьте раздел по OWASP API Security — комиссия по ИБ это оценит. Оформление ссылок — ГОСТ Р 7.0.5-2008.

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

• Проектировать событийную схему продукта и отличать метрику-цель от метрики-обманки.
• Строить рекомендательный пайплайн от кандидатов до ранжирования и честно оценивать его офлайн.
• Считать когортное удержание, LTV и статистическую значимость A/B без подгонки результата.
• Описывать архитектуру в нотации C4/UML так, чтобы её понял и технарь, и нормоконтролёр.
• Оценивать стоимость доставки видео и эксплуатации сервиса в деньгах, а не в «условных единицах».

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

Где взять данные, если у меня нет доступа к реальному сервису?

Три рабочих варианта: открытые датасеты по коротким видео и вовлечённости, синтетический генератор событий по заданному распределению (пишется на Python за вечер) и логи собственного прототипа. Синтетика — законный путь, если в главе 3 честно описана модель генерации и её ограничения. Это как раз тот случай, когда лучше показать прозрачную методологию, чем «датасет из компании N» без деталей.

Какой стек выбрать, чтобы не утонуть?

Для рекомендаций: Python, pandas/Polars для подготовки, LightFM или CatBoost для базовой модели, PostgreSQL/ClickHouse для хранения. Для потоковой части: очередь сообщений (Kafka или Redpanda), тот же ClickHouse как витрина, Grafana для дашбордов. Для API — FastAPI. Не тащите Kubernetes, если у вас один сервис: это добавит текста, но не добавит смысла.

Сколько метрик достаточно для защиты?

Одна целевая, две-три вспомогательные и одна guardrail. Для этой темы: цель — конверсия в следующую серию; вспомогательные — D1/D7 retention, средняя длина сессии; guardrail — доля отказов платежей или жалоб. Пять-семь метрик с обоснованием сильнее, чем двадцать без логики.

Нужно ли считать экономический эффект, если тема «чисто техническая»?

Да, и это выгодно отличает работу. Даже грубая оценка «рост конверсии на 0,5 п.п. → +X рублей ARPU на 10 000 пользователей» показывает, что вы понимаете цель внедрения. Если не хватает данных, приводите сценарии «пессимистичный / базовый / оптимистичный».

Источник: How soap opera-TikTok hybrids became a billion-dollar business (опубликовано 2026-03-25)