Аналитическая стратегия цифровых продуктов

Это будет пост-инструкция. Вы можете распечатать его и повесить на стенку в аналитическом отделе (если он у вас есть) или дома над кроватью (если весь аналитический отдел – только вы). В любом случае, этот текст может оказаться полезен всем, кто так или иначе сталкивается с аналитикой: и не важно, мобильных, десктопных или веб-приложений.

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

В любом IT-проекте рано или поздно наступает этап формирования аналитической стратегии. Даже если вы так её и не называете.

В какой-то момент принимается ответственное решение: какие данные скармливать прожорливому богу аналитики, а какие пусть остаются несобранными (опытные ребята знают, что переизбыток информации почти так же вреден, как и её отсутствие).

Главная проблема здесь в том, что чаще всего это происходит именно поздно, а не рано.

§ Что такое аналитическая стратегия

Как и большинство терминов в IT, этот тоже сильно размыт. Кто-то под АС будет подразумевать аналитику рынка, кто-то – отслеживание нагрузки на серверные мощности и её балансировку.

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

Немного непонятно, да? Давайте расскажу чуть подробнее.

§ Зачем нужна стратегия

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

Чтобы составлять цели (в той же Яндекс.Метрике, например), исходя из реальных задач бизнеса и пользовательских потребностей. А не просто отслеживать «конверсию в покупку». Без чёткого понимания, что и на каком этапе следует фиксировать, аналитика зачастую превращается в «собираем из того, что есть».

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

§ Шесть стратегических этапов

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

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

§ Этап 1: определяем конечную цель

У каждого проекта есть конкретные задачи. Бизнесу необходимо достигать своих целей, пользователям – решать конкретные потребности. Аналитику достаточно лишь собрать цели бизнеса, разложить их на более мелкие задачи (последовательные и/или параллельные), выяснить промежуточные и финальные задачи клиента/пользователя.

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

§ Этап 2: составляем аналитическую карту

В определённый момент на проекте формируются более или менее окончательные пользовательские сценарии. Сценарии эти, помимо прочего, включают в себя ключевые точки взаимодействия (например, поиск в каталоге, добавление в корзину). Вот эти ключевые точки и станут для нас основными пользовательскими метриками.

Если у вас есть под рукой подробный CJM или UJM вашего продукта, то задача упрощается в разы.

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

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

И да, здесь же прорабатываем сквозную аналитику (например, эффективность каналов привлечения).

§ Этап 3: разделяем внешнюю и внутреннюю аналитики

Однако пользовательская аналитика – это ещё не всё. Есть ещё маркетинг и банальное финансовое прогнозирование. Зачастую нужно понимать, достигаются или нет конкретные бизнес-показатели.

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

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

§ Этап 4: формируем систему триггеров

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

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

§ Этап 5: определяемся с инструментарием

Крайне важный момент, который многие упускают. Аналитика просто так не собирается. Хорошо, если у вас простой интернет-магазин, и вам достаточно одной только Google Analytics. С мобильными приложениями, например, сложнее. Или с финтехом, в котором вообще подключение внешних аналитических систем крайне не рекомендуется (здесь нужно использовать self-hosted системы, которые собирают и хранят все данные непосредственно на ваших серверах).

Помимо вездесущих Google Analytics и Яндекс.Метрики есть ещё огромное количество других инструментов. Например, Amplitude и Branch для сквозной мобильной аналитики, Matomo для self-hosted решений.

§ Этап 6: документируем, администрируем

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

Будут ошибки, несостыковки в сценариях. Данные станут пропадать из-за программных недоработок и невнимательности. Графики начнут врать, бизнес принимать неверные решения. Это реальность, к сожалению. Ни один аналитический проект не рождается сразу идеальным – и чем он сложнее, тем больше поначалу будет подобных ошибок. Аналитику нужно администрировать. Исправлять ошибки, модернизировать отчёты и графики.

§ Вместо итогов

Я старался быть кратким, ибо эта статья впервые публиковалась на Дзене, а формат Дзена не особо поощряет лонгриды. Да и вы, читатели, их тоже не сильно жалуете. Если у вас остались вопросы, если вы хотите примеров, если вдруг с чем-то не согласны – велкам в комменты. Они всё стерпят, а мне важна ваша обратная связь.