К содержанию
ActionPulse

← Все статьи

  • feature adoption
  • функции
  • saas
Автор — Редакция ActionPulse

Feature adoption: как измерять использование функций продукта

ActionPulse — анализ использования функций продукта

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

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

Базовая формула

Feature adoption = активные участники, использовавшие функцию ÷ активные участники, которым функция доступна × 100%.

Ключевое слово — «доступна». В знаменатель не должны попадать:

  • тарифы без функции;
  • роли без разрешения;
  • аккаунты вне rollout;
  • платформы, где функция ещё не выпущена;
  • пользователи, не имевшие подходящего объекта или данных.

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

Уровни использования

Exposure

Пользователь увидел точку входа или получил доступ. Это условие возможности, но не использование.

Discovery

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

First success

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

Repeat usage

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

Breadth and depth

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

Не объединяйте уровни в одно событие feature_used. Для решений важно понимать, где именно останавливается путь.

Выберите единицу

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

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

Один активный человек не должен превращать весь аккаунт в «широко использующий функцию» без согласованного правила.

События функции

Пример контракта:

Этап Событие
точка входа показана feature_entry_viewed
сценарий начат feature_started
результат сохранён feature_completed
результат применён feature_result_used
произошла ошибка feature_failed

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

Первое и повторное использование

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

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

Для ежемесячной функции ежедневный repeat rate бессмысленен. Период должен соответствовать задаче.

Связь с результатом

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

Аккуратный подход:

  1. сформулировать ожидаемый механизм;
  2. определить целевую аудиторию;
  3. измерить первый и повторный успех;
  4. сравнить сопоставимые когорты;
  5. при возможности провести контролируемый rollout;
  6. проверить побочные метрики;
  7. дополнить числа интервью.

Статья как измерить эффект изменений разбирает ограничения сравнения «до и после».

Сегменты

Полезно сравнить adoption по:

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

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

Диагностика низкого adoption

Разделите проблему:

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

Для каждого варианта нужен свой отчёт. Увеличение числа показов не исправит ошибку завершения.

Пример

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

Команда считает:

  1. аккаунты, которым отчёт доступен;
  2. аккаунты, где администратор открыл настройку;
  3. аккаунты с успешно сохранённым отчётом;
  4. аккаунты, где результат открыли повторно через неделю;
  5. роли, фактически использовавшие результат.

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

Итог

Feature adoption — не число кликов по новой кнопке. Это доля подходящей аудитории, которая получила первый результат и вернулась к функции в естественном цикле. Укажите доступность, единицу, период и уровень использования — тогда метрика подскажет конкретное улучшение.

Продолжить разбор

Связанные материалы

Все статьи →

Проверьте это на своих данных

Триал Growth на 14 дней: отчёты и SQL-консоль, карта не нужна. До 30 млн событий за 14 дней. Выгрузка событий через API недоступна во время пробного периода; после оплаты доступна с тарифа Growth.

Попробовать 14 дней бесплатно