Внедряем продуктовую аналитику без вреда для бизнеса. Чек-лист для предпринимателей

Но, если допустить ошибки при настройке аналитики, сборе информации или её интерпретации, легко упустить пользу. Продуктовый аналитик Анна Куликова объяснила, какие важные моменты следует держать в голове при такой работе.

Расскажу, какие шаги помогут обдуманно использовать продуктовую аналитику, чётко понимая, для чего собираются данные и как они помогут развивать продукт и бизнес.

Определить необходимые метрики на старте

Обычно компании отслеживают базовые данные о работе продукта и поведении пользователя: количество пользователей (MAU/WAU/DAU — месячная/недельная/дневная активная аудитория), длительность сессий, популярные разделы, кнопки, сценарии, источники трафика, средний чек и т. д.

Минимальная аналитика помогает держать руку на пульсе, но её недостаточно для более глубокого анализа продукта. Итоговый набор метрик зависит:

• от предметной области, к которой относится продукт (ретейл, контент, финтех и др.),
• от текущих бизнес-целей (увеличить прибыль, привлечь новых клиентов и др).

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

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

Если нужно оценить эффективность части продукта и принять решения о развитии или закрытии направления — определяем, какие метрики нужны, и отслеживаем именно их.

Пример из жизни

После того как в приложении для ретейла внедрили новый раздел с акциями и спецпредложениями, стояла задача — проанализировать эффективность обновления. В документации по аналитике были прописаны десятки метрик — отслеживалось много событий, собирался большой объём данных. Но когда понадобилось проанализировать эффективность нового раздела — оказалось, что данных... не хватает.

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

Смотреть вглубь

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

Пример из жизни

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

Если аудитория приложения резко выросла, необходимо определить, что на это повлияло, и исходя из этого выстраивать план дальнейших действий. Если рост вызван изменениями в приложении — надо продолжать работать в этом направлении. Но это может быть связано совсем с другим. Известен кейс, когда аудитория в приложении резко выросла из-за действий конкурента — запуск масштабной рекламной кампании повысил интерес ко всем приложениям нового формата. Без аналитики и поиска причин мы могли бы подумать, что рост аудитории связан с обновлением приложения или внедрением новой фичи.

Чек-лист. Как внедрить аналитику и не упустить пользу

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

• Выбрать систему для отправки событий о действиях пользователя в мобильном приложении.

Наиболее распространённые сервисы: AppMetrica от Yandex, Firebase от Google, Amplitude и др. Выбор сервиса зависит от бюджета, объёма аудитории и личных предпочтений.

• Определить базовые метрики, которые необходимо отслеживать для продукта.

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

Если говорить про базовые метрики ретейлеров, скорее всего, в этом списке окажутся MAU/WAU/DAU (количество новых установок, новых зарегистрированных пользователей), ARPU/ARPPU (средний доход на пользователя и на платящего пользователя), конверсия в регистрацию и оформление заказа, средний чек, частота совершения покупок и др.

• Спроектировать карту событий.

Принять решение о степени детализации такой карты (насколько подробно будет отслеживаться каждое действие пользователя) необходимо исходя из выбранных метрик.

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

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

Кроме того, сразу стоит учитывать, что, если конверсия окажется ниже, чем мы рассчитывали, нужно будет обязательно выяснить причины. А это значит — необходимо дополнительно отслеживать каждый шаг пользователя на этапе оформления заказа (добавление товара в корзину, выбор способа доставки, оплаты, ввод персональных данных и т. д.), чтобы понять, в какой именно момент он от нас ушёл, — это даст основания для формирования продуктовых гипотез.

• Поставить задачу на разработку: настроить интеграцию с выбранной системой аналитики и реализовать отправку событий из разработанной карты.

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

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

• название экрана, на котором происходит событие (назовём экран оформления заказа order);
• название элемента, с которым взаимодействует пользователь (например, кнопка «Оформить заказ» — placeOrderButton);
• название отслеживаемого действия пользователя (например, нажатие на кнопку — tap).

Тогда событие нажатия на кнопку оформления заказа будет именоваться order_placeOrderButton_tap.

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

• Разработать дашборды по выбранным метрикам.

После того как события реализованы и начали отправляться в выбранный сервис аналитики, можно приступать к разработке дашбордов. Обычно для разработки дашбордов применяются различные BI-системы, для некоторых задач бывает достаточно выгрузок в Excel или отчётов в Google-таблицах.

• При появлении новых фич в продукте повторить действия из пунктов 2–5.

Скорее всего, потребуется пересмотреть набор метрик, доработать карту событий и реализовать события для новой фичи. А впоследствии — адаптировать дашборды.

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

Коллаж: «Секрет фирмы», Pixabay, Pixabay License, Pexels, Pexels License