Функцией пользуются чаще.
Значит, она полезна?

1. Сформулируйте пользу до выбора метрик

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

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

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

2. Разделите доступность, интерес и результат

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

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

3. Запусков стало больше, а результат слабее

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

Число запусков выросло на 75,95%. При этом доля попробовавших с выполненным шагом снизилась с 54,30% до 40,85%. Само число пользователей с результатом тоже стало меньше.

На одного попробовавшего приходится примерно 1,49 запуска в группе А и 2,06 в группе Б. Это повод разобраться: пользователи решают больше задач, исправляют плохие предложения или сталкиваются с ошибками?

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

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

4. Повторное использование тоже нужно определить

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

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

Если функция нужна редко, отсутствие повторного запуска за неделю не означает провал. Она могла успешно решить разовую задачу. Частоту оценивают с учётом того, как часто возникает потребность.

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

5. Пользовавшиеся и не пользовавшиеся изначально могут отличаться

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

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

Как проверить изменение надёжнее

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

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

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

6. Следите за ценой результата

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

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

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

7. Проверьте измерение на реальных последовательностях

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

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

Следующая статья

Разберём, когда результат эксперимента даёт основание запускать изменение.