Событийная аналитика позволяет владельцу интернет-сервиса (или даже обычного сайта) ответить на вопросы: на каком шаге «отпадывают» пользователи, какой путь проходят пользователи, которые платят больше всего и тд.
В этой статье я расскажу о том, как внедрить в SaaS-сервис событийную аналитику, какие события необходимо отслеживать и какие выводы делать из отчетов.
Что такое событийная аналитика?
В последнее время все больше внимания уделяется аналитике, причем встречаются различные формулировки: событийная аналитика, сессионная аналитика, продуктовая аналитика, сквозная аналитика и тд. Мы не будем разбираться в этом разнообразии, на важно отметить несколько пунктов.
1. Любые данные нужны для принятия управленческих решений
Если Вы собираете данные и не принимаете на их основе решений — то их не нужно собирать. Тут есть одна оговорка — данные лучше собирать с момента создания сервиса, обрабатывать их можно начать позже, зато у Вас уже будет внушительный массив.
2. Событийная аналитика — это данные о событиях пользователей
У любого события есть тип (регистрация, вход, оплата), пользователь (или объект/субъект), другие параметры (изменение баланса, utm-метки и тд).
На основе данных по этим событиям уже строятся графики, так же эти данные Вы можете сегментировать по параметрам.
Зачем нужна событийная аналитика?
1. Тестирование интерфейсов
Я уже писал про тесты интерфейсов и повышение активации пользователей и про то, как повысить эффективность Ваших интерфейсов А/Б тестами.
Если коротко — то на основе событий необходимо построить воронку в активацию, в нашем примере это будет регистрация -> создание рассылки.
Собирая события регистрации и создания рассылки, мы можем понять какой у нас процент активации, поменять интерфейс и посмотреть повысится или понизится процент активации.
2. Расчет юнит-экономики по когортам
Я уже писал про юнит-экономику и анализ каналов трафика. Вкраце, если записывать utm-метки и дату при регистрации пользователя, а затем записывать каждую оплату (сумму и дату) каждого пользователя, то можно построить такую таблицу:
Из этой таблицы можно вывести все показатели юнит-экномики и посмотреть какие каналы трафика окупаются.
Все эти данные можно получить из основных событий, далее поговорим о том, какие вообще события следует записывать и как это сделать.
3. Другие кейсы использования
- Создать триггерное письмо всем, кто месяц не был в админке
- Посчитать выручку за период по каналу, например яндекс.директ
- Просмотреть историю жизни клиента в админке
- Понять по какому каналу приходят пользователи с самым высоким сроком жизни
Как реализовать это в своем продукте?
1. Необходимо определить список событий
Это должны быть значимые события: регистрация, вход, пополнение баланса, изменение профиля, включение API (или даже выполнение API-запроса).
2. Понять какие параметры еще нужны
Чаще всего нам требуются: дата+время, тип события, субъект (автор события), объект (на кого направлено событие), сумма (изменение баланса), utm-метки, другие данные (тут в формате json-массива можно записывать данные по которым НЕ будет делаться выборка из базы).
3. Настроить запись событий в свою базу данный
Если событие происходит на серверной стороне — то это просто, если оно происходит на клиентской стороне — необходимо передать его на сервер и записать в базу.
4. Подключить внешнюю систему событийной аналитики
В своих проектах мы используем amplitude и mixpanel. Они бесплатны до какого-то количества событий ежемесячно.
5. Настроить в своей админке вьюхи для админа и маркетологов
В своей админке необходимо настроить отображение событий:
Также, можно сделать фильтры:
Примеры событий и параметров
Таблица событий может выглядеть так:
При интеграции с внешними сервисами событийной аналитики необходимо учесть дополнительные данные:
- изменение баланса надо подумать как разделять боевые и стартовые/промо/маркетинговые платежи (чтобы расчеты внешеней системы были правильными)
- подумать, чтобы письма и другие уведомления не учитывались в расчете retention
Так может выглядеть таблица типов событий:
Выводы
1. У совершенства нет предела, но перфекционизм нужен не всегда
Если у Вас вообще нет системы событийной аналитики — сделайте хоть какую-нибудь, это гораздо лучше чем ее полное отсутствие. По ходу работы Вы будете ее улучшать.
2. Событийная аналитика — не самоцель
Всегда тестируйте новые гипотезы. Выбирайте метрики, которые Вы можете измерить (ретеншен, процент активации) и непрерывно тестируйте гипотезы, направленные на изменение этих показателей.