Фича популярна у самых ценных пользователей. Стоит ли делать её центральной частью продукта?

Команда сервиса аналитических отчётов планирует следующий квартал.

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

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

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

Что известно перед решением

Сервис продаёт месячную подписку компаниям. Один клиент соответствует одному рабочему пространству с несколькими сотрудниками.

Отчёты отправляют вручную из продукта, а с 1 марта администраторам всех платных тарифов стала доступна отправка по расписанию.

В анализ вошли 1000 клиентов, которые:

• имели платную подписку;

• имели хотя бы один созданный отчёт на 1 марта.

Самыми ценными команда назвала верхние 20% по платежу за февраль.

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

На 90-й день после запуска подписка есть:

• у 250 из 300 клиентов, пользовавшихся фичей;

• у 500 из 700 остальных.

Получается удержание:

• 83,3% против 71,4%;

• разница — почти 12 процентных пунктов.

Здесь удержание означает наличие платной подписки на контрольную дату. Ушедших раньше из исходной базы не исключали.

Цель команды состоит в росте удержания и дохода от подписок.

Обсуждаются три действия:

1. заняться надёжностью уже работающих расписаний;

2. помочь другим клиентам освоить автоматизацию;

3. переделать основной сценарий для всей аудитории.

Какое действие вы согласовали бы сейчас?

Что именно в отчёте обосновывает этот выбор и каких данных не хватает для остальных решений?

Что происходит с разницей после сегментации

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

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

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

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

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

Внутри каждого сегмента наблюдаемое удержание одинаковое.

При этом среди пользователей фичи дорогих клиентов около 53%, а среди не использовавших её — около 6%.

Если привести обе группы к составу всей базы, где дорогих клиентов 20%, получим одинаковые 75% удержания.

Расчёт для обеих групп будет один:

0,2 × 95% + 0,8 × 70%.

В нашем примере различие в составе групп создаёт общую разницу. Причина поведения клиентов из таблицы неизвестна.

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

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

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

Период использования тоже фиксируем. Признак «когда‑либо пользовался» позволит будущим событиям менять исходные группы.

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

Популярность фичи обосновывает разные действия по‑разному

В нашем отчёте 80% означает хотя бы одну успешную отправку.

Для вывода об устойчивом использовании нужны:

• повторные отправки;

• данные об отключении расписаний.

Клиент мог попробовать функцию и вернуться к ручной работе.

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

Поддерживать существующий сценарий.

Стоит выяснить:

• какие рассылки продолжают работать;

• как часто они опаздывают;

• сколько ручного вмешательства требуют.

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

Приоритет таких работ зависит от последствий сбоев и других проблем продукта.

Развивать автоматизацию для клиентов с повторяющейся задачей.

Среди 160 дорогих клиентов, попробовавших расписание, проблема может быть в сбоях доставки.

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

Для этих случаев потребуются разные изменения.

Сделать автоматизацию основным направлением продукта.

Для этого нужны:

• размер и доступность целевого сегмента;

• его платёжный потенциал;

• затраты на обслуживание;

• оценка альтернативных направлений.

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

Этих данных в условии нет.

Автоматизация может стать главным сценарием для аудитории с регулярными отчётами. Показывать её первой всем клиентам стоит после отдельной проверки.

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

Проверка должна начинаться с задачи клиента

Следующий шаг состоит в разборе ручных отправок и последних повторяющихся задач клиентов.

Нужно понять:

• какие отчёты они обязаны отправлять;

• кому и к какому сроку;

• почему не используют расписание.

По воронке настройки проверяем:

• нехватку прав;

• ошибки;

• незавершённые попытки.

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

Более заметная настройка расписания должна уменьшить долю пропущенных сроков.

Ниже разберём проверку при этом условии.

В контроле остаётся текущий главный экран. В тесте блок настройки расписания занимает часть места списка отчётов. Доступность и поведение самой функции одинаковы в обоих вариантах.

До распределения по группам фиксируем:

• отчёты;

• получателей;

• сроки на период проверки.

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

Затем сравниваем показатель между группами на уровне рабочих пространств.

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

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

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

Мы выбираем метрику по задаче клиента. Такой переход от целей к измерению описан в работе исследователей Google Measuring the User Experience on a Large Scale. Сам показатель предложен для нашего сценария.

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

Как сохранить смысл эксперимента

Распределять по вариантам нужно рабочие пространства целиком. Иначе администратор из тестовой группы может настроить отправку для коллег из контрольной, а подписка у них общая. Выбор единицы рандомизации при совместной работе пользователей отдельно разобран в рекомендациях Microsoft Research.

Клиент, которому достался новый экран, но который не включил расписание, остаётся в тестовой группе. Это анализ intention‑to‑treat, то есть по исходному назначению воздействия. Если после запуска оставить только включивших расписание, случайное распределение больше не защищает сравнение. Мы снова отберём людей по действию, связанному с их потребностями и мотивацией.

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

До запуска нужно оценить и размер выборки. В исходном примере общее удержание составляет 75%. Чтобы отличить рост до 78% от нулевого эффекта при простом сравнении двух долей, распределении 50/50, двустороннем уровне значимости 5% и мощности 80%, нужно примерно 6300 независимых клиентов. Мощность означает вероятность обнаружить заданный эффект, если он существует. Расчёт приближённый, без специальных способов снижения дисперсии.

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

Для показателя своевременных отправок чувствительность нужно рассчитать отдельно. Он не обязательно даст точный ответ на меньшей базе. Успешный тест подтвердит уменьшение пропущенных сроков в выбранном сегменте. Рост удержания и дохода от подписок останется отдельной гипотезой.

Какое решение разрешают полученные данные

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

Его связывают с ценой пропущенных сроков и стоимостью изменения.

Дополнительно задают допустимые ухудшения по:

• ошибочным получателям;

• дублирующим отправкам;

• обращениям в поддержку;

• работе с обычными отчётами.

Численные границы команда задаёт заранее. Доверительный интервал показывает статистическую неопределённость оценки эффекта.

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

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

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

Проблему принятия решений по промежуточным результатам разбирает инженерная команда Etsy.

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

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

В рабочей задаче зафиксируйте:

• аудиторию;

• изменение в работе клиента;

• решение при каждом результате проверки.

Эти записи помогут понять, каких данных действительно не хватает для следующего шага.

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

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

• 15 октября, 20:00. «Цели и метрики как одно целое». Записаться

• 22 октября, 20:00. «Как AI помогает продакту быстрее проверять гипотезы». Записаться

>> Полный список бесплатных уроков сентября смотрите в дайджесте.