Как превратить данные об использовании продукта в отчет об освоении функций (2026)

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

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

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

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

Что вам понадобится перед началом работы

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

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

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

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

Три решения, которые меняют итоговый показатель

Знаменатель. Все зарегистрированные пользователи, активные пользователи за месяц (MAU) или только те, кому доступна функция. Эти варианты дадут три совершенно разных процента на основе одних и тех же событий. Любой показатель принятия функции — это дробь, поэтому четко определите обе ее части перед началом расчетов.

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

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

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

Временное окно. Принятие — это не мгновенный показатель. Это доля пользователей (из числа тех, кому доступна функция), совершивших действие за определенный период, поэтому сам период является частью определения.

Вот одна задокументированная тонкость, о которой стоит знать, прежде чем копировать методологию какого-либо инструмента. В документации по удержанию Amplitude объясняется принцип расчета. Инструмент «вычисляет данные удержания путем сравнения даты начального события с датой указанного вами возвращаемого события».

Диапазон дат применяется только к первому событию. Amplitude прямо заявляет, что «пользователям не обязательно активировать возвращаемое событие в течение этого периода, чтобы попасть в анализ».

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

Как сделать это вручную

Вариант 1: Подсчитать уникальных пользователей, а затем разделить

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

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

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

Главный минус в том, что на выходе вы получаете одну плоскую цифру. Вы знаете, что уровень принятия составил 18%, но понятия не имеете, кто эти люди.

Вариант 2: Создать таблицу признаков на уровне пользователей

Одна строка на каждого подходящего пользователя, один столбец на каждый вопрос. Запустили ли они событие, сколько раз и в сколько разные дни.

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

Именно на этом этапе показатель принятия функции становится полезным для принятия решений, а не просто цифрой для отчета. Общие 18% могут скрывать тот факт, что среди новых пользователей этот показатель равен 40%, а среди прошлогодних — всего 4%.

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

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

Вариант 3: Вести вкладку с определениями рядом с расчетами

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

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

Минус в том, что само по себе документирование правил не применяет их автоматически. Кому-то все равно придется заново настраивать те же пять фильтров при каждом обновлении.

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

В каких случаях ручной подход начинает тормозить процесс

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

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

Изменения в процессе раскатки ломают знаменатель. Функция становится доступна 100% аккаунтов, и показатель принятия падает просто потому, что целевая аудитория выросла в три раза.

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

Есть и еще одна скрытая проблема, которая всплывает в самый неприемлемый момент. Когда кто-то спрашивает: «А это хороший результат?», один лишь процентный показатель не даст ответа, а построение сравнения превращается в отдельную задачу.

Как построить отчет с помощью Powerdrill Bloom

Шаг 1: Загрузите данные об использовании

Загрузите файл экспорта событий или файлы событий и аккаунтов вместе. Powerdrill Bloom анализирует структуру столбцов при загрузке, поэтому несоответствия в названиях событий и пропущенные ID пользователей обнаружатся еще до начала расчетов.

Шаг 2: Опишите правила простыми словами

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

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

Шаг 3: Экспортируйте график, отчет или презентацию

Выгрузите динамику принятия, таблицу по сегментам или слайд, на котором объединены и цифры, и их определение.

Почему это лучше, чем перестраивать отчет вручную каждый раз

	Ручной подход	Powerdrill Bloom
Дедупликация пользователей по событиям	Вспомогательные столбцы в каждом файле	Запрос уникальных пользователей
Сегментация по когортам или тарифам	Объединение и пересборка таблицы	Запрос разбивки данных
Переименование событий после релиза	Обнаружение постфактум на графике	Выявляется при загрузке
Изменение целевой аудитории	Пересчет знаменателя	Указание нового правила

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

Распространенные ошибки

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

Использование всех зарегистрированных пользователей в качестве знаменателя для функции под флагом. Если только треть аккаунтов видит функцию, остальные две трети не являются «отказавшимися». Им эта функция просто недоступна.

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

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

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

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

Предоставление процента без сопутствующего определения. Цифра бессмысленна без знаменателя и порогового значения. Выносите оба этих параметра на график — точно так же, как на хорошем дашборде KPI подписываются все метрики.

Заключение

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

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

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

Часто задаваемые вопросы

Что такое принятие функции (feature adoption)?

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

Как рассчитать этот показатель на основе экспорта событий?

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

Должен ли знаменатель включать всех пользователей или только активных?

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

Каким должно быть временное окно измерения?

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

Почему мои цифры отличаются от данных в инструменте аналитики?

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