Музыкальные стриминговые сервисы давно перестали быть просто каталогами треков. Сегодня значительная часть пользовательского опыта формируется рекомендательными системами: персональными подборками, автоматическими плейлистами, «волнами» и похожими механизмами. Пользователь может сам искать музыку, добавлять треки в библиотеку и слушать знакомых артистов, а может переходить по рекомендациям алгоритма. Возникает естественный исследовательский вопрос: рекомендации действительно расширяют музыкальный кругозор или, наоборот, закрепляют уже существующие предпочтения пользователя?

В рамках курсового проекта по дисциплине «Наука о данных и аналитика больших объемов информации» мы поставили цель исследовать поведение пользователей музыкального стриминга на основе открытого датасета Yambda и сравнить органическое и рекомендательное потребление музыки.

Ключевая особенность набора данных — наличие признака is_organic. Он показывает, каким образом пользователь дошёл до трека:

• is_organic = True — пользователь сам нашёл трек;

• is_organic = False — трек был предложен рекомендательной системой.

Благодаря этому можно не просто анализировать прослушивания в целом, а сравнивать два режима потребления: самостоятельный выбор пользователя и влияние алгоритмических рекомендаций.

Почему выбрали Яндекс.Музыку и Yambda

Для анализа использовался открытый датасет Yambda, опубликованный Яндексом. В проекте рассматривались события взаимодействия пользователей с музыкальным сервисом: прослушивания, лайки, дизлайки и отмены реакций. По структуре данных этот набор хорошо подходит для задач анализа больших данных, так как содержит большой объём событий и позволяет исследовать как статистические показатели, так и скрытые поведенческие закономерности.

В работе использовались следующие основные файлы датасета:

При этом у датасета есть важные ограничения. В нём нет имён артистов, названий треков, альбомов и жанровых меток. Все сущности представлены числовыми идентификаторами. Также временные метки не являются реальными календарными датами, а представляют собой смещение от начала наблюдений. Это сделано для анонимизации данных и защиты пользователей.

Из‑за отсутствия названий артистов и треков в проекте были введены условные обозначения:

• A1, A2, A3,... — артисты, отсортированные по глобальной популярности;

• T1, T2, T3,... — треки, отсортированные по глобальной популярности.

То есть A1 — самый популярный артист в датасете, но его реальное имя неизвестно.

Постановка задач анализа

Курсовой проект предполагает не только обработку данных, но и формулирование набора аналитических задач, построение программной архитектуры, хранение данных, обработку и визуализацию результатов [3]. В нашем случае проект был разделён на семь задач:

1. анализ динамики органического и рекомендательного потребления по месяцам;

2. анализ сессионной активности пользователей;

3. выявление музыкальных сообществ на основе совместных лайков;

4. оценка влияния рекомендаций на разнообразие музыкального кругозора;

5. анализ временных паттернов потребления;

6. построение сообществ артистов по совместному прослушиванию;

7. прогнозирование оттока пользователей на основе поведенческих признаков.

Такой набор задач позволяет посмотреть на рекомендательную систему с разных сторон: через объём потребления, качество прослушивания, разнообразие, графовые связи между артистами и вероятность ухода пользователя.

Архитектура и стек технологий

Проект реализован на Python. Основной акцент был сделан на обработку больших объёмов данных без полной загрузки датасета в оперативную память. Для этого использовались инструменты, подходящие для аналитических нагрузок и пакетной обработки.

Основной стек:

• Polars — быстрая обработка табличных данных и ленивые вычисления;

• DuckDB — аналитические SQL‑запросы, агрегаты и self‑join без полной загрузки данных в RAM;

• NetworkX и python‑louvain — построение графов и поиск сообществ;

• scikit‑learn — модели машинного обучения для прогноза оттока;

• UMAP — снижение размерности аудио‑эмбеддингов;

• Matplotlib / Seaborn — визуализация результатов.

В качестве аналитической базы использовалась DuckDB. В отличие от классических транзакционных СУБД, таких как PostgreSQL или MySQL, DuckDB хорошо подходит для локальной аналитики, тяжёлых агрегаций и колоночной обработки. В рамках проекта это оказалось полезно, потому что данные не помещались в память целиком, а часть задач требовала выполнять группировки, соединения и расчёты по десяткам миллионов событий.

Особенности реализации:

• данные обрабатываются потоково;

• тяжёлые задачи разбиваются на чанки по пользователям;

• для графовых задач применяются предварительные фильтры, чтобы избежать взрывного роста числа рёбер;

• во всех стохастических операциях, где это возможно, фиксируется random_state;

• результаты сохраняются в data/results/ в виде PNG-графиков.

Структура проекта:

src/
  config.py              — параметры пайплайна
  rank_labels.py         — построение справочника A_k / T_k
  tasks/                 — 7 аналитических задач

scripts/
  download_data.py       — скачивание данных
  prepare_db.py          — подготовка локальных parquet
  run_all.py             — запуск всех задач

data/
  raw/                   — исходные данные
  processed/             — промежуточные агрегаты
  results/               — итоговые графики

Задача 1. Динамика органического и рекомендательного потребления

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

Основной результат оказался довольно интересным: за 24 месяца количество событий выросло примерно с 6,4 млн до 9,1 млн, то есть примерно на 41%. При этом рекомендации в финальном месяце формировали около половины всего трафика.

Но ещё важнее другое: рекомендательные прослушивания скипались реже, чем органические. В финальном месяце скип‑рейт у рекомендаций составил около 27,6%, а у органики — около 37,6%. Это контринтуитивный результат: можно было ожидать, что самостоятельно найденные треки будут дослушиваться лучше, но данные показывают обратное.

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

Задача 2. Сессионная активность пользователей

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

Для каждой сессии анализировались:

• длительность;

• количество событий;

• медианный процент дослушивания;

• различия между органическими и рекомендательными сессиями.

Результаты показали, что рекомендательные сессии заметно длиннее. Медианная длительность рекомендательной сессии составила около 2250 секунд, а органической — около 1175 секунд. Также в рекомендательных сессиях выше доля полных прослушиваний: примерно 72% против 62% у органики.

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

Задача 3. Сообщества на основе совместных лайков

Третья задача была исследовательской. Мы построили граф, где узлы — это артисты или треки, а ребро между ними возникает, если одни и те же пользователи лайкали оба объекта.

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

Для поиска сообществ использовался алгоритм Louvain. Дополнительно граф очищался от нестабильных связей: если лайк был отменён, такая связь учитывалась осторожнее. В результате было обнаружено несколько плотных сообществ артистов и треков. Например, для артистов были выделены сообщества размером 51, 50 и 19 узлов, а для треков - 70, 68 и 62 узла.

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

Задача 4. Разнообразие музыкального кругозора

Один из главных вопросов проекта: расширяют ли рекомендации музыкальный кругозор пользователя?

Для этого была рассчитана энтропия Шеннона по распределению прослушиваний пользователя. Чем выше энтропия, тем разнообразнее история прослушиваний. Если пользователь слушает одни и те же треки, энтропия низкая. Если слушает много разных треков и артистов, энтропия выше.

Формально показатель можно описать так:

H(p) = −Σ pᵢ · log₂(pᵢ)

где pᵢ - доля i-го трека или артиста в истории пользователя.

Результат оказался в пользу рекомендаций. В среднем рекомендательные прослушивания повышают энтропию примерно на 1,4 бита. Для треков показатель вырос с 8,04 до 9,43 бит, а для артистов — с 6,44 до 7,75 бит.

Это означает, что рекомендации не просто закрепляют пользователя в привычном наборе артистов, а действительно расширяют его музыкальное потребление.

Интересно и то, что эффект сохраняется на разных уровнях активности. Пользователи с высокой активностью ожидаемо имеют более разнообразную историю, но внутри каждого квартиля активности рекомендательная энтропия всё равно выше органической.

Задача 5. Временные паттерны потребления

Пятая задача была посвящена временным закономерностям. Мы построили тепловые карты по часам и дням, чтобы понять, как меняется активность и качество прослушивания во времени.

Однако здесь важно учитывать ограничение датасета: временные метки в Yambda не являются реальными календарными датами. Поэтому обычные суточные циклы интерпретировать напрямую нельзя. Глобальная тепловая карта получилась почти равномерной, и это скорее особенность анонимизации, чем реальный вывод о поведении пользователей.

Зато полезным оказался анализ жизненного цикла пользователя. В первый день активности пользователь слушает музыку значительно интенсивнее, а затем активность снижается и стабилизируется. Также было видно, что рекомендательные прослушивания в среднем дослушиваются лучше: примерно на 10 процентных пунктов выше по played_ratio.

Задача 6. Сообщества артистов по совместному прослушиванию

Шестая задача похожа на анализ совместных лайков, но вместо лайков использовались прослушивания. Связь между артистами появлялась, если один пользователь слушал их в один день.

Это позволяет выявить не только то, что пользователи явно лайкают, но и то, что они реально слушают рядом друг с другом. Такие связи могут быть даже более показательными, потому что лайк — это отдельное осознанное действие, а прослушивание отражает повседневное поведение.

Для проверки найденных сообществ использовались аудио‑эмбеддинги треков. Сначала эмбеддинги треков усреднялись до уровня артиста, затем снижалась размерность с помощью UMAP. После этого точки раскрашивались по сообществам Louvain.

Результат получился неоднозначным и поэтому интересным. Одно небольшое сообщество оказалось акустически отделённым: точки одного цвета держались компактно. Это похоже на реальный жанровый или стилистический кластер. Но два крупных сообщества перемешались в эмбеддинг-пространстве. Это значит, что они являются скорее поведенческими, а не акустическими: люди слушают этих артистов вместе, хотя по звучанию они могут быть разными.

Задача 7. Прогнозирование оттока пользователей

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

Метка оттока была задана искусственно: пользователь считался ушедшим, если у него не было активности в последние 30 дней датасета. Для модели были сформированы признаки трёх групп:

1. объёмные признаки: число событий, уникальных треков, артистов и альбомов;

2. поведенческие признаки: доля повторов, средний played_ratio, доля органики, средняя длина трека;

3. временные признаки: дни с последнего события, интервалы между событиями, активность за последние 7 и 30 дней.

Сравнивались логистическая регрессия и Random Forest. Лучший результат показал Random Forest: ROC-AUC около 0,86. При этом наиболее важным признаком оказались дни с последнего события. Это ожидаемо: если пользователь давно не проявлял активности, вероятность оттока растёт.

Churn rate составил около 15,6%. Модель показала, что для прогнозирования оттока важнее не только общий объём активности, но и свежесть взаимодействий пользователя с сервисом.

Производительность аналитических задач

Отдельно оценивалось время выполнения задач. Это важно, потому что проект относится к курсу по анализу больших объёмов информации, а значит, важны не только сами выводы, но и то, насколько эффективно система обрабатывает данные.

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

Основные выводы

По результатам проекта можно выделить несколько ключевых наблюдений.

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

Во‑вторых, рекомендательные прослушивания оказались качественными по метрикам дослушивания. Их скипают реже, а сессии с ними длятся дольше.

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

В‑четвёртых, графовый анализ показал наличие устойчивых музыкальных сообществ. Некоторые из них подтверждаются аудио‑эмбеддингами, а некоторые являются скорее поведенческими: пользователи слушают этих артистов вместе, даже если они не обязательно похожи по звучанию.

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

Что можно улучшить в дальнейшем

У проекта есть несколько направлений развития.

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

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

Третье — добавить интерактивную визуализацию. Сейчас результаты сохраняются в виде статичных PNG‑графиков. Для исследовательской работы было бы удобно сделать веб‑интерфейс или дашборд, где можно фильтровать пользователей, сообщества, периоды и типы прослушиваний.

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

Заключение

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

Главный вывод исследования: в рассматриваемом датасете рекомендации не выглядят как механизм, который просто замыкает пользователя в привычном наборе треков. Напротив, они увеличивают разнообразие прослушивания, формируют более длинные сессии и чаще приводят к полному дослушиванию треков.

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