Задача
Разработать хранилище данных болельщиков клуба для их дальнейшей обработки и анализа.
Мы разработали приложение, провели маркетинговое исследование и начали разработку системы управления работой с болельщиками (FRM) со сбора данных из различных источников и создания надежной системы их хранения.
Несмотря на то, что данных о болельщиках и их активности у клуба очень много, они до сих пор никуда не собирались, нигде не хранились и не анализировались. Сотрудники клуба использовали разрозненную, созданную вручную, статистику только для отчетности перед «Лигой ВТБ» и собственным руководством.
Было решено, что клубу необходимо централизованное хранилище всей возможной информации о болельщиках, на основе которой сотрудники клуба смогут:
- получать бизнес-аналитику и итоговую статистику по коммерческой деятельности клуба, связанной с продажами болельщикам;
- получать аналитическую информацию для планирования и прогнозирования потенциальных продаж, создания новых услуг;
- сегментировать пользователей и получать различные выборки по заданным критериям;
- вести историю взаимоотношений и управления жизненным циклом посетителя матча (удлинять его, повышать ценность болельщика, увеличивать его положительный опыт);
- планировать, проводить и анализировать эффективность целевых маркетинговых мероприятий по продвижению услуг клуба;
- повышать эффективность своей работы за счет ее автоматизации;
- автоматизировать создание стандартных обязательных отчетов для заинтересованных лиц.
Решение
Работу начали с поиска и изучения подобных систем у других спортивных клубов. Выяснили, что большинство из них также пока не собирают никакие данные, часть клубов использует системы, созданные специально для них, а часть работает с готовыми решениями. Нашли две подходящие FRM-системы и тщательно изучили их возможности и функциональность, чтобы в целом представлять, как все может быть организовано.
Затем мы долго общались с представителями клуба, чтобы выяснить, какие данные о болельщиках к ним поступают и из каких источников, обсуждали, что это за данные и как их необходимо понимать и интерпретировать. Не всегда и не на все вопросы мы сразу получали ответ, иногда нашими заказчикам приходилось самим вспоминать различные уже забытые тонкости или обращаться за помощью к тем системам, откуда были получены данные за подробными разъяснениями. Как всегда бывает в таких случаях, нашли множество моментов, которые можно улучшить.
В результате общения были выявлены следующие источники данных:
- файлы статистики о продажах билетов и абонементов,
- данные о посещении матчей владельцами абонементов,
- логи турникетов с информацией о статусе прохода по штрих-кодам на билетах и абонементах,
- группы в социальных сетях,
- информация о болельщиках, которые пришли на матч по бесплатным ваучерам,
- данные закрытого клуба болельщиков,
- данные регистрации пользователей на официальном сайте и в приложении, заказы в фан-шопе.
Мы описали каждый процесс,который был связан с этими данными и их получением, каждую возможную ситуацию их появления, все ограничения, особенности и проблемы. Получился очень объемный документ, во время написания которого мы постоянно общались с заказчиком, задавали ему все новые и новые вопросы, тщательно разбирались в каждом нюансе.
Затем мы изучили каждый набор данных на предмет их полноты и чистоты. Для каждого поля описали возможные значения, ограничения и все особенности. Например, особенностью системы продажи билетов является использование общих контактных данных (телефон и email) для всех билетов в заказе, при этом фамилия, имя и отчество посетителя матча по каждому билету может быть разным (люди пришли семьей или компанией друзей). Таким образом, оказалось, что посетитель матча и покупатель очень часто неотделимы друг от друга и не идентифицируемы в группе.
Все свои «открытия» мы описывали и обсуждали с нашим клиентом. Иногда для лучшего понимая приходилось рисовать схемы и картинки, например, вот такие:
Все данные из всех источников были сведены в общую таблицу, для каждого элемента которой мы использовали разные цвета для обозначения возможности получения: точно есть в источнике, иногда есть, добавим вручную при загрузке в базу, получим агрегацией и т.п.
В такой таблице стало хорошо видно, какие данные пересекаются в различных источниках. Предстояло подумать, что с этим делать, и как с ними работать.
В таблицу попали также все агрегаты, т.е. данные, которых изначально не было ни в одном источнике, но мы могли получить их при обработке. Например, мы могли посчитать общее количество купленных пользователем билетов, деньги, которые он на них потратил в сезоне и за всю историю увлечения, количество посещенных матчей по абонементу и многое другое. Мы собирались даже вычислять, сколько раз наш болельщик вышел из дворца спорта во время матча, чтобы покурить!
Объем данных и их обработки оказался слишком большим для первой версии хранилища, поэтому были выделены приоритетные источники и данные для MVP варианта.
Вот такой была структура таблицы данных, в которой описывались только выбранные наборы.
На основе данных и планов на получение аналитических срезов была создана структура хранилища. В качестве модели использовалась классическая «звезда» с несколькими таблицами фактов и измерений. Например, таблицами фактов стали билеты, абонементы и заказы в фан-шопе. Предусмотрели справочники, которые администратор базы должен заполнять через веб-интерфейс.
Структура базы была представлена и в виде таблицы.
Следующим шагом было описание процесса ETL, с помощью которого данные должны были попадать в хранилище, очищаться и обрабатываться. Сделали это с помощью обычной таблицы и дополнили схемами-примерами обработки реальных данных из файлов.
Спроектировали и разработали веб-интерфейс для администратора, где он смог бы работать по справочниками, загружать файлы с данными, делать различные выборки с помощью фильтров (например, выбрать всех пользователей-мужчин или всех женщин старше 35 лет из Перми) и скачивать получившиеся наборы в виде файлов.
Создали базу по утвержденной структуре, загрузили в нее исторические данные, наполнили справочники и осуществили необходимые интеграции для автоматического получения данных:
- из социальной сети VK: данные участников официальной группы,
- из приложения клуба: данные профилей пользователей.
Разработали несколько готовых отчетов для заказчика. В частности, их интересовала сводка посещений матчей владельцами абонементов, посещаемость по билетам, выданным отдельным компаниям и специальным группам посетителей.
Надеемся на продолжение интересного сотрудничества и на то, что система станет действительно полезной и нужной нашему заказчику.
Клиент
Баскетбольный клуб «Парма» основан 2 августа 2012 года и является единственным профессиональным баскетбольным клубом Пермского края. С 2017 года клуб входит в одну из сильнейших лиг Европы — Единую Лигу ВТБ. Игры команды в Перми проходят на домашней арене универсального дворца спорта «Молот».