Продуктовая аналитика: что мерить и как собрать данные, которым можно верить

Продуктовая аналитика отвечает на вопрос, что люди делают внутри продукта и почему уходят. Это отличает её от соседних дисциплин, с которыми её постоянно смешивают.

Веб-аналитика считает трафик и источники: откуда пришли, сколько страниц посмотрели. Она нужна маркетингу и плохо отвечает на вопросы про поведение внутри продукта.

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

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

Бизнес-аналитика и отчётность живут поверх учётных данных: выручка, себестоимость, остатки. С продуктовой они соединяются в витрине, но источники и требования к точности у них разные.

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

Удержание — самая честная метрика продукта, потому что её нельзя купить рекламой.

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

Важно определиться, что считается возвратом. Для сервиса доставки еды — оформленный заказ, для банковского приложения — вход и просмотр баланса, для B2B-инструмента — рабочая сессия с действием. Открытие приложения без действия — плохая база для решений.

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

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

Общая ошибка — смотреть на итоговую конверсию и оптимизировать последний шаг. Обычно потери сидят раньше: в онбординге, в обязательной регистрации, в форме с восемью полями, в шаге подтверждения по СМС.

Цифры показывают, где теряют, но не объясняют почему. Ответ на «почему» даёт связка с интерфейсными методами: разбор проблемных экранов и правки, о которых говорится в материалах про потери на сайте и в работе над интерфейсами мобильных продуктов. Аналитика находит место, дизайн-исследование — причину.

Документ, с которого начинается работающая аналитика. Без него через полгода в системе будут события `click`, `Click`, `button_click` и `btn_click_new`, и никто не вспомнит, чем они отличаются.

Место, где рождаются расхождения между отчётами. У одного человека есть анонимный идентификатор устройства и идентификатор аккаунта, а устройств может быть три.

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

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

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

Продуктовая аналитика собирает поведение людей, а значит попадает под требования к персональным данным. Три вещи стоит решить до запуска сбора.

Минимизация. В события не кладут телефоны, почты, имена и адреса — вместо них идентификатор. Даже если очень удобно посмотреть «кто это был», в аналитическом контуре этого быть не должно.

Согласия. Аналитика и реклама требуют информирования пользователя и, в части сценариев, явного согласия. Формулировки в политике должны совпадать с тем, что реально собирается.

Хранение и доступ. Где лежат данные, кто имеет доступ к сырым событиям, сколько хранится история. Ответы на эти вопросы понадобятся и юристам, и при выборе между облачным сервисом и собственным хранилищем.

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

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

Длительность фиксируют до старта. Минимум — полный недельный цикл: поведение в понедельник и в субботу разное. Останавливать тест в момент, когда результат стал красивым, нельзя — так значимость получается из шума.

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

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

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

В мобильных продуктах аналитика устроена сложнее веба, и вот почему.

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

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

Магазины считают по-своему. Установки и удаления видны в консолях сторов, а не в вашей аналитике; в России к App Store и Google Play добавился RuStore со своей статистикой. Свести их в одну цифру точно не получится.

Разрешения и трекинг. Часть идентификаторов недоступна без согласия пользователя, поэтому опираться стоит на собственные идентификаторы и события, а не на рекламные.

Дашборд не работает сам по себе — работает регулярная встреча, на которой по нему принимают решения.

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

Ритуал: раз в неделю команда собирается на полчаса, смотрит изменения, формулирует гипотезы и записывает, что проверяет к следующему разу. Без этого шага аналитика превращается в красивую витрину, которую открывают перед советом директоров.

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

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

По нашим работам: мобильное приложение с продуктовой аналитикой — от 1,8 млн ₽, веб-продукт — от 1 млн ₽, витрина данных и дашборды внутри продукта — от 1,5 млн ₽ (корпоративный BI-стек мы не разворачиваем), отдельная интеграция с внешней системой аналитики или рекламным кабинетом — от 150 тыс. до 1,5 млн ₽. Точная цифра зависит от плана событий и глубины отчётов: оценка проекта бесплатная.

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

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

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

Считают средние. Средний чек и среднее время в приложении скрывают всё: смотреть нужно распределения и сегменты.

Верят цифрам, не проверив сбор. Первое, что делают перед разбором «падения» — проверяют, не сломалась ли отправка событий в последнем релизе. В половине случаев причина именно в этом.

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

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

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

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