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

4-6 минут на прочтение
Аналитическая стратегия

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Павел Шерер
Павел Шерер

Продюсер, аналитик, продуктовый дизайнер IT-решений, Telegram-канал

Поделиться:

Предыдущая статья Информационная архитектура: пример и типизация Следующая статья Разгоняем аналитику через систему триггеров

Комментарии (2)

Артём Шрейдер
Стоит ли бизнес-аналитику, нанятому для аналитики и проектирования, например, CRM-системы или автоматизирующему какие-то бизнес-процессы, настаивать на необходимости проработки аналитической стратегии, если со стороны бизнеса нет продуктового аналитика? Сейчас мы на своих проектах спрашиваем, какие метрики хочет отслеживать бизнес, почти всегда спрашиваем зачем. Но редко можно охарактеризовать этот процесс, как осознанную работу над СА...
Ответить
Павел Шерер
Безусловно, стоит. Внутренняя аналитика ещё более важна, чем аналитика внешняя — она позволяет, как минимум, выявлять слабые места интерфейсов и улучшать их, повышая эффективность сотрудников. На базовом уровне с этим справится любой аналитик, не обязательно продуктовый.
Ответить

Добавить комментарий

Нет соединения с сервером.Сервер получил неверные данные, попробуйте еще раз.
Войдите, чтобы комментировать статью: