Аналитика в приложении: диагностическая система, а не журнал кликов

Аналитика — это не теги на каждой кнопке

Я не считаю продуктовую аналитику камерой внутри приложения. Такая метафора создает иллюзию, что мы видим все. В продуктовой работе нужна более узкая и полезная вещь: диагностическая система. На каком шаге пользователь не получает ожидаемую ценность? Какие причины вероятны? Что менять дальше?

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

Практическая рамка: дерево вопросов -> путь пользователя -> контракт событий -> действие

1. Сначала дерево вопросов, потом имена событий

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

Я разбиваю это на три уровня:

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

Отслеживать стоит только те вопросы, которые могут привести к решению.

2. Нарисовать путь пользователя

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

Базовые события могут включать screen_view, feature_exposure, feature_click, task_success, error_show и payment_result. Свойства важнее количества событий. Обычно я хочу видеть entry, source, screen, module, status, error_code, app_version, os, network, latency_bucket и experiment_id.

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

3. Превратить это в контракт событий

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

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

4. Проверить доверие к данным до релиза

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

Чек-лист для событий

• На какой продуктовый вопрос отвечает событие, и кто действует при изменении метрики?
• Есть ли знаменатель? Клик без показа не объясняет конверсию.
• Покрыты ли отмена, ошибка, таймаут, возврат назад и пустое состояние?
• Можно ли группировать данные по входу, версии, устройству, сети, каналу и эксперименту?
• Событие успеха означает, что пользователь получил ценность, или только нажал кнопку?
• Имя события стабильно и не зависит от текста в интерфейсе?
• Исключены ли лишние персональные данные, например телефон, email и точная геолокация?
• Подтверждаются ли критические результаты сервером?
• Есть ли экран здоровья данных: пропуски, дубли, задержки, аномальные пики?
• Если это событие никто не смотрит три месяца, нужно ли его удалить?

Анализ: идти от результата назад, а не от кликов

Обычно я смотрю на данные в шести разрезах и не меняю порядок без причины.

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

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

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

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

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

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

Пять уровней диагностики продуктовой проблемы

Когда метрика выглядит слабой, я проверяю пять уровней:

1. Доступ: пользователь не увидел функцию. Проверить место входа, долю показов, разрешение на уведомления, правила рекомендаций.
2. Мотивация: пользователь увидел, но не захотел нажать. Проверить текст, выражение ценности и соответствие аудитории.
3. Понимание: пользователь нажал, но быстро ушел. Проверить иерархию интерфейса, термины, управление ожиданиями и подсказки.
4. Возможность: пользователь хотел продолжить, но не смог. Проверить формы, разрешения, сеть, производительность, коды ошибок и оплату.
5. Ценность: пользователь успешно завершил действие, но не вернулся. Проверить качество результата, обратную связь, контент и частоту использования.

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

Пример: функция shadowing в приложении для изучения языков

Это пример, а не описание реального проекта или реальных данных.

Предположим, в приложении для изучения языков есть функция повторения вслух. Я бы отслеживал ключевые события: lesson_enter, shadowing_exposure, shadowing_start, permission_result, record_complete, score_result, retry_click и next_lesson.

Если shadowing_exposure высокий, а shadowing_start низкий, сначала нужно проверить текст входа, обещание ценности и момент показа. Если shadowing_start приемлемый, но record_complete низкий, надо смотреть разрешение микрофона, длину записи, сеть и падения приложения. Если record_complete нормальный, но score_result часто неуспешен, внимание нужно сервису оценки речи, таймаутам и сообщению об ошибке. Если оценка успешна, но пользователь не идет к следующему уроку и не возвращается позже, проблема может быть не в потоке. Возможно, обратная связь не создает достаточной учебной мотивации.

Смысл не в количестве событий. Смысл в том, чтобы каждый разрыв цепочки вел к конкретному действию.

Дашборд должен быть небольшим

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

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

Как я бы это внедрял

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

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

PaxLee