Гайд: как построить аналитику в EdTech с нуля

Мы разработали для EdTech-стартапа систему аналитики, которая помогла отследить путь клиента от первого клика до конца обучения. Расскажу, как мы это сделали, по этапам.

За годы работы мы научились не просто каждый раз готовить с нуля, а отмечали и фиксировали все удачные и неудачные методы и подходы. В итоге, сейчас, как минимум метафорично, у нас есть книга рецептов (или «Учебник Принца-Полукровки», если эта аналогия вдруг покажется вам более близкой) , в которую попали самые удачные и результативные решения для компаний-клиентов.

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

Мы расскажем вам, как мы помогли наладить деятельность стартапа Refocus, который занимался созданием онлайн-курсов на рынке Юго-Восточной Азии по современным диджитал направлениям: веб-разработка, маркетинг и, конечно же, анализ данных.

Компании нужна была помощь в создании инфраструктуры сбора, хранения и обработки исходных данных (студенты, их учебный прогресс и платежи) , а также визуализации данных в информативных дашбордах для принятия продуктовых решений. Основа проблемы (как это часто бывает) крылась в неоптимальном способе хранения данных — Google Sheets. Сотрудники компании, в основном, придерживались этого подхода и ощущали острую как нож шеф-повара необходимость перехода на автоматизированные ежедневно обновляемые данные.

У компании уже был сервер Hetzner, с которым мы могли работать, исходя из оговоренных требований. Для хранения данных было решено использовать облачный сервис Google Cloud BigQuery.

На сервер мы решили поставить Python и Airflow для сбора данных по API: сперва только для сбора данных из AmoCRM и Google Sheets, а позже и из остальных источников. Чаще всего для выгрузки и обработки сырых данных в наших проектах мы полагаемся именно Python за счет простоты понимания и использования, а также богатства регулярно поддерживаемых библиотек.

Полный список источников данных (которые служат ингредиентами в нашем блюде) выглядел следующим образом:

Все процессы загрузки данных из источников в BigQuery были разбиты по отдельным направлениям и оформлены в соответствующие DAG’и в Apache Airflow:

Пример DAG’а в Airflow

Это DAG выгрузки контактов студентов. E-mail адреса и телефоны выгружаются отдельно в соответствующих тасках (задачах внутри DAG’а). На первом скриншоте представлено дерево и время исполнения скриптов, а на втором — граф порядка исполнения:

Мониторинг

Для основного DAG’а, который часто исполнялся, были настроены алерты в Slack с помощью опции “hooks” в Airflow. Благодаря этому в случае возникновения ошибки при выполнении дага мы получали автоматические оповещения.

Пример кода для отправки алерта:

Таблиц в BigQuery получилось много, вот пример тех, которые содержали в своем названии слово “leads”:

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

Для того, чтобы построить отчеты не только по каждому источнику данных, но и по смежным источникам, мы продумали логику соединения таблиц (чаще всего, в роли связующего звена выступал e-mail адрес или телефонный номер пользователя):

Изначально, большинство преобразований для отчетов, которые реализовались с помощью SQL-запросов, происходило на уровне датасорсов в Tableau. Однако, это решение имело три ограничения:

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

Для этого мы создавали таблицы или представления (они же Views) в BigQuery и с помощью Python и Airflow воссоздавали их в Tableau. В результате, при создании датасорса в Tableau стало достаточно ввести простой select-запрос из нужной таблицы или представления. А для внесения изменений надо было изменить код, а не редактировать датасорс. Это решение сэкономило время на выполнении запросов в Tableau и ускорило работу, потому что нам больше не приходилось обновлять каждый датасорс по отдельности.

Python-скриптами с помощью Airflow по расписанию данные выгружались (через API соответствующего источника) , обрабатывались и помещались в базу данных Google BigQuery. В ней все собранные данные хранились по таблицам.

Благодаря правильной настройке системы организации данных мы могли найти необходимые таблицы и создать датасорсы в Tableau с помощью SQL-запросов, а также ставить на регулярное обновление уже готовые. В итоге, визуализации данных мы строило на основе этих датасорсов.

В чем же конечная цель нашей работы? В том, чтобы помочь бизнесу развиваться и принимать решения на основе данных. То есть видеть, какие каналы продвижения эффективны, а на какие надо перестать тратить бюджет. Или разобраться, на каком этапе и почему студенты оставляют заявки на возврат средств — это поможет понять, как улучшить контент, чтобы поднять вовлеченность.

В случае с Refocus мы автоматизировали процессы по работе с данными, а саму систему выстроили так, чтобы она могла расти вместе с бизнесом. Это и произошло: на старте у нас было всего 2 источника данных, а через два года — уже больше 20.

У нас есть еще несколько кейсов, о которых мы хотели бы рассказать в будущем. А пока узнать о наших услугах, подходе к работе и стеке можно на нашем сайте. Знакомьтесь и записывайтесь на бесплатную консультацию!