Это будет пост-инструкция. Вы можете распечатать его и повесить на стенку в аналитическом отделе (если он у вас есть) или дома над кроватью (если весь аналитический отдел – только вы). В любом случае, этот текст может оказаться полезен всем, кто так или иначе сталкивается с аналитикой: и не важно, мобильных, десктопных или веб-приложений.
Дело в том, что моё недавнее мини-исследование показало, что на самом деле аналитикой на начальном уровне развития проекта заморачивается относительно небольшой процент компаний. Даже крупные игроки зачастую сперва релизят сервис, и только потом начинают думать о том, какую же информацию им нужно собирать. Думаю, не стоит объяснять, чем чреват недостаток реальных данных на старте продукта: от снижения динамики развития до полного провала пользовательских сценариев.
В любом IT-проекте рано или поздно наступает этап формирования аналитической стратегии. Даже если вы так её и не называете.
В какой-то момент принимается ответственное решение: какие данные скармливать прожорливому богу аналитики, а какие пусть остаются несобранными (опытные ребята знают, что переизбыток информации почти так же вреден, как и её отсутствие).
Главная проблема здесь в том, что чаще всего это происходит именно поздно, а не рано.
Что такое аналитическая стратегия
Как и большинство терминов в IT, этот тоже сильно размыт. Кто-то под АС будет подразумевать аналитику рынка, кто-то – отслеживание нагрузки на серверные мощности и её балансировку.
То, о чём я хочу рассказать в этой статье, ещё называют аналитическим планом, деревом метрик и тп. Суть одна: аналитическая стратегия – это набор переходов, событий и метрик, автоматически фиксируемых в вашем продукте. Набор, составленный с учётом технологических возможностей, бизнес-целей и задач пользователей; разделённый на внешнюю и внутреннюю части; задокументированный, администрируемый и развиваемый.
Немного непонятно, да? Давайте расскажу чуть подробнее.
Зачем нужна стратегия
Причина здесь, на самом деле, простая: затем же, зачем вообще нужны стратегии. Чтобы развивать продукт. Чтобы иметь возможность принимать взвешенные решения, основываясь на реальных данных, а не на гипотезах.
Чтобы составлять цели (в той же Яндекс.Метрике, например), исходя из реальных задач бизнеса и пользовательских потребностей. А не просто отслеживать «конверсию в покупку». Без чёткого понимания, что и на каком этапе следует фиксировать, аналитика зачастую превращается в «собираем из того, что есть».
Порой оказывается, что вносить изменения в список фиксируемых событий сложно и дорого. Что для проверки простой гипотезы проще сделать поверхностные выводы из одних только переходов между страницами. Это грустно и мне не нравится такой подход. Я надеюсь, что этот текст поможет хоть кому-то избежать популярных аналитических ошибок.
Шесть стратегических этапов
Для построения грамотной стратегии чаще всего достаточно выполнить лишь шесть базовых действий, о которых я и расскажу ниже. Иногда шести недостаточно – все проекты разные, и где-то необходимо, например, ещё собирать аналитику с партнёров. Но вы люди неглупые, сами разберётесь.
Модернизируйте схему, руководствуясь здравым смыслом и логикой.
Определяем конечную цель
У каждого проекта есть конкретные задачи. Бизнесу необходимо достигать своих целей, пользователям – решать конкретные потребности. Аналитику достаточно лишь собрать цели бизнеса, разложить их на более мелкие задачи (последовательные и/или параллельные), выяснить промежуточные и финальные задачи клиента/пользователя.
Чаще всего, эти данные можно взять готовыми – у бизнес-аналитиков, юиксеров и иже с ними. По факту, это и есть ключевые метрики вашего продукта. На них мы и будем концентрироваться в дальнейшей работе.
Составляем аналитическую карту
В определённый момент на проекте формируются более или менее окончательные пользовательские сценарии. Сценарии эти, помимо прочего, включают в себя ключевые точки взаимодействия (например, поиск в каталоге, добавление в корзину). Вот эти ключевые точки и станут для нас основными пользовательскими метриками.
Если у вас есть под рукой подробный CJM или UJM вашего продукта, то задача упрощается в разы.
Теперь нам достаточно провести между всеми такими метриками взаимосвязи и иерархию. Определить, какие метрики являются родительскими, а какие дочерними; какие могут быть вызваны в любом месте интерфейса, а для каких необходим ряд дополнительных действий.
Важно приоритизировать события, и собирать только те, которые действительно будут нужны на старте. Остальные не выбрасывайте, они нам ещё пригодятся.
И да, здесь же прорабатываем сквозную аналитику (например, эффективность каналов привлечения).
Разделяем внешнюю и внутреннюю аналитики
Однако пользовательская аналитика – это ещё не всё. Есть ещё маркетинг и банальное финансовое прогнозирование. Зачастую нужно понимать, достигаются или нет конкретные бизнес-показатели.
Например, процент пользователей, подключивших рекуррентные (регулярно повторяющиеся) платежи может быть выше среди тех, кто посмотрел обучающее видео в личном кабинете – и бизнесу однозначно следует это знать. Однако слать во внешнюю аналитику финансовую информацию точно не стоит, такие данные должны храниться внутри системы. Вообще, все чувствительные или не-обезличенные данные нужно хранить внутри своей системы – это, думаю, очевидно.
Таким образом, на этом шаге мы не только разделяем внешнюю и внутреннюю аналитики, но и придумываем, как их подружить. Это может стать нетривиальной задачей, на самом деле.
Формируем систему триггеров
Продукты развиваются, аналитика развивается вместе с ними. Вчера нас не интересовали действия пользователя в настройках профиля, а завтра нам нужно улучшить конверсию в рассылку – и критически важно становится собирать клики на чекбоксы.
Я уже писал о системе триггеров, не стану подробно её расписывать снова, ссылка будет в конце статьи. Если сильно упростить, то здесь мы совершаем набор действий, направленный на ускорение последующего внесения изменений в список собираемых данных. Присваиваем идентификаторы, отмечаем важные, ставим задачу разработчикам, не забываем про внешние факторы и внутренние системы.
Определяемся с инструментарием
Крайне важный момент, который многие упускают. Аналитика просто так не собирается. Хорошо, если у вас простой интернет-магазин, и вам достаточно одной только Google Analytics. С мобильными приложениями, например, сложнее. Или с финтехом, в котором вообще подключение внешних аналитических систем крайне не рекомендуется (здесь нужно использовать self-hosted системы, которые собирают и хранят все данные непосредственно на ваших серверах).
Помимо вездесущих Google Analytics и Яндекс.Метрики есть ещё огромное количество других инструментов. Например, Amplitude и Branch для сквозной мобильной аналитики, Matomo для self-hosted решений.
Документируем, администрируем
Без грамотной и полной документации уже через месяц после запуска вы сами не вспомните, что и куда слали. А учитывая высокую динамику развития большинства продуктов, ваши таблицы могут устареть ещё быстрее. Документация по аналитической карте, системе триггеров и способах управления этим должна быть всегда актуальной – это должно стать одним из признаков качества работы проектного аналитика.
Будут ошибки, несостыковки в сценариях. Данные станут пропадать из-за программных недоработок и невнимательности. Графики начнут врать, бизнес принимать неверные решения. Это реальность, к сожалению. Ни один аналитический проект не рождается сразу идеальным – и чем он сложнее, тем больше поначалу будет подобных ошибок. Аналитику нужно администрировать. Исправлять ошибки, модернизировать отчёты и графики.
Вместо итогов
Я старался быть кратким, ибо эта статья впервые публиковалась на Дзене, а формат Дзена не особо поощряет лонгриды. Да и вы, читатели, их тоже не сильно жалуете. Если у вас остались вопросы, если вы хотите примеров, если вдруг с чем-то не согласны – велкам в комменты. Они всё стерпят, а мне важна ваша обратная связь.
