От идеи до результата: как оценить, нужна ли пользователям новая фича (JTBD и TARS)

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

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

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

Ключевые вопросы анализа фичей

Концепция Jobs-To-Be-Done (JTBD) гласит, что пользователи «нанимают» продукт для выполнения определённой работы или достижения результата. В этом контексте фича – это конкретное решение, которое помогает пользователю выполнить свою “работу” с помощью продукта.

JTBD определяет, что именно хочет достичь пользователь (желаемый исход), а фичи представляют собой реализованные в продукте решения для выполнения этих работ. Важно помнить, что одна работа пользователя (job) может требовать нескольких функций для полного удовлетворения потребности, и одновременно одна фича может способствовать выполнению разных работ. Поэтому между пользовательскими задачами и функциями продукта нет строгого соответствия «один к одному» – осознание этого помогает избегать мышления, когда сначала придумывают решение, не поняв задачи (solution-first thinking).

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

Пример 1. Instagram: мгновенный обмен моментами vs. цифровой фотоальбом

Instagram изначально вырос как приложение для быстрого обмена фотографиями с мобильного. Пользовательская «работа» тут – поделиться моментом из жизни красиво и сразу. Для выполнения этой задачи Instagram предоставляет целый набор функций:

Камера с фильтрами – позволяет сделать снимок и улучшить его вид за секунды, что удовлетворяет потребность “сделать фото привлекательным” перед публикацией.
Лента и подписки – даёт аудитории сразу увидеть новый пост, тем самым выполняется работа “донести своим друзьям/подписчикам новость или эмоцию”.
Подписи и теги – контекстуализируют момент, отметка друзей и геолокация расширяют охват и связность, это помогает усилить социальный аспект обмена.
Лайки и комментарии – обеспечивают обратную связь и социальное одобрение, завершая задачу “получить реакцию и почувствовать связь с окружающими”.

Важно, что для одной такой работы (“поделиться моментом”) задействованы сразу несколько функций: от съёмки и фильтрации до социализации в ленте. Без какого-либо из этих элементов потребность удовлетворялась бы не полностью. Например, без фильтров фото может не дать желаемого эстетического удовлетворения, без ленты и лайков – не чувствовалась бы связь с друзьями.

В то же время одна и та же функция Instagram может служить разным JTBD.

Возьмём Stories (Истории) – 15-секундные фото/видео, исчезающие через 24 часа. Для одних пользователей история – это способ “быстро поделиться ежедневным моментом, не загромождая основную ленту” (задача: быть на связи ежедневно, но не слишком официально). Для других та же функция выполняет работу “заглянуть в жизнь знакомых здесь и сейчас и не пропустить ничего важного” – отсюда высокий просмотр сториз для скучающих или любопытных (работа: скоротать время, быть в курсе) – эта задача ранее частично решалась лентой, но сториз делают её более живой и актуальной. Третьи пользователи “нанимают” Stories для продвижения личного бренда или бизнеса через интерактивные опросы, стикеры, ссылки – тут уже работа “удержать внимание аудитории и вовлечь её”. Получается, одна фича охватывает несколько разных работ: от личного общения до маркетинга.

Такой многосторонний дизайн объясняет, почему Instagram удалось вытеснить фотохостинги старой школы. Например, Flickr позиционировался как “онлайн-фотоальбом”, предлагая безлимитное хранение, альбомы (сеты) и сохранение оригинального качества снимков. Это отлично решало задачу архивирования и упорядочения фотографий – “сохранить все снимки в сети как в семейном альбоме”. Instagram же сфокусировался на другой работе – моментальном мобильном шеринге и социализации, которую Flickr сначала недооценил. Flickr-менеджмент концентрировался на улучшении своего решения (альбомов, хранения) для существующих “про”-пользователей, тогда как Instagram предложил новую ценность: мгновенный шеринговый опыт для широкого круга людей, без долгих раздумий о композиции или организации. Появились и новые сопутствующие функции под эту работу – фильтры для красоты кадра, хэштеги для охвата, простой лайк как форма признания. В результате пользователи “наняли” Instagram для работы “поделись легко и получи отклик”, даже если у них уже был Flickr для хранения фотографий.

Пример 2. TikTok: развлечение и самовыражение в одном флаконе

TikTok знаменито тем, что захватило пользовательскую работу “развлеки меня, когда у меня есть свободная минутка” лучше многих прежних платформ. Задача: быстро получить дозу интересного контента, не прилагая усилий к поиску. Как TikTok удовлетворяет этот job?

Лента “For You” с бесконечной прокруткой – центральная фича, которая мгновенно подстраивается под вкусы. Пользователь открывает приложение и сразу получает поток видео, подходящий именно ему. Эта функция напрямую решает задачу “дай мне нечто занимательное прямо сейчас, без поиска”. В отличие от YouTube, где нужно выбирать видео, или Instagram, где контент от тех, на кого подписан, алгоритм TikTok сам “кормит” вас развлечением, избавляя от любых усилий.
Короткий формат видео (~15-60 секунд) – снижает “стоимость” внимания. Пользователь знает, что даже скучное видео скоро сменится следующим. Это идеально для работы “убить скуку в маленькие промежутки времени” – на остановке, в очереди, во время отдыха. Короткие ролики и лёгкость свайпа решают функциональную часть этой работы: контент всегда свежий и быстро сменяется, не успевая наскучить.
Музыка и тренды – TikTok позволяет накладывать популярные треки, участвовать в челленджах. Для зрителя это создаёт чувство общего пространства развлечения – когда куча людей креативно переосмысляют один тренд, смотреть интереснее. Для пользователя-зрителя здесь выполняется эмоциональная работа “быть на волне актуальных приколов и ощущать сопричастность к трендам” – ощущение, что “я тоже в теме”.
Лайки, комментарии, репосты – хоть TikTok потребляется преимущественно пассивно, интерактивные элементы позволяют вовлекаться при желании: поставить лайк (что ещё и обучает алгоритм вашим предпочтениям), почитать комментарии (часто сами по себе развлекательны), скинуть другу смешное видео. Таким образом, развлекательная задача дополняется социальной: “посмеяться вместе с другими” и “поделиться настроением”.

Для создателей контента (активных пользователей) свой JTBD: “получить аудиторию и самовыразиться творчески”. Инструменты TikTok и тут работают комплексно:

Встроенный редактор с эффектами – выполняет работу “позволь мне легко создать что-то классное”. Без монтажа на компьютере, буквально за минуты на телефоне, можно реализовать задумку с фильтрами, переходами, стикерами. Это привлекает пользователей, которые хотят самовыражения, но не хотят осваивать сложные программы.
Библиотека звуков и музыка – даёт идею и контекст для видео. Например, пользователь думает: “Хочу снять что-то смешное под трендовую музыку” – TikTok сам предоставляет популярные звуки, из которых рождаются мемы. Одна и та же функция “добавить звук” позволяет выполнить разные работы: одному создателю – присоединиться к вирусному флешмобу (работа: не отставать от трендов, нарастить охват), другому – подчеркнуть настроение своего уникального ролика музыкой (работа: творчески усилить эффект на аудиторию).
Дуэты и “стичи” (склеивание с чужим видео) – ещё одна мощная фича, что обслуживает сразу несколько задач. Задача 1: коллаборация или реакция. Пользователь может взять чужое видео и добавить свою реакцию или продолжение – фактически поучаствовать в общем творчестве или ответить на контент. Задача 2: повышение видимости. Новичок может сделать дуэт с вирусным видео, чтобы его тоже заметили (он “прикрепляет” себя к уже успешной единице контента) – это работа “быстрее добиться охвата, используя тренд”. Задача 3: социальное взаимодействие. Дуэт с другом просто ради шутки – “повеселиться вместе, несмотря на расстояние”. Одна функция удовлетворяет разные намерения – творческие, социальные, утилитарно-продвиженческие.

ТикТок, таким образом, объединил в одном продукте несколько связанных работ. Для зрителя – развлечение и чувство сопричастности, для автора – простое творчество и шанс прославиться. Раньше для этого пришлось бы использовать разные решения: например, “убить время” можно было в Instagram Explore или YouTube, а “выложить креативное видео” – на YouTube (но там нужно было накопить аудиторию) или в Instagram Stories (но там ограничения по функционалу редактирования и меньше алгоритмической раскрутки). TikTok закрыл оба фронта сразу, поэтому его “нанимают” на работу развлечения и самовыражения комплексно.

Пример №3. Маркетплейсы: закрыть все потребности онлайн-покупателя под одной крышей

Главная работа для пользователя маркетплейса сегодня – “купить нужный товар быстро, удобно и с уверенностью в правильном выборе”. Чтобы целиком закрыть эту задачу, предоставляется множество функций:

Поиск и навигация по категориям. Простейшая часть – “помоги мне найти то, что я ищу”. Маркетплейс реализует её мощной поисковой строкой, фильтрами, каталожной структурой. Это первая функция для работы “найти подходящий вариант среди миллионов товаров”.
Карточка товара с подробностями. Фото, характеристики, описание – решают функциональную потребность узнать все детали о товаре (размер, материал, спецификации). Без этого пользователь бы искал инфо на сторонних сайтах. На маркетплейсах всё под рукой, что закрывает под-задачу “собрать информацию для принятия решения”.
Отзывы покупателей и рейтинг. Один из самых влиятельных элементов, выполняющий работу “убедиться, что товар мне подойдёт и качественный”. Читая реальные отзывы, покупатель снимает свои сомнения (эмоциональная работа – снизить тревогу перед покупкой незнакомой вещи). Интересно, что отзывы как функция служат разным ролям: для продавца – повышают доверие к его товару, выполняя работу “доказать качество через социальное подтверждение”; для пишущего отзыв пользователя – дать обратную связь, поделиться опытом (некоторые “нанимают” функцию отзывов ради самовыражения или помощи другим). Один и тот же механизм удовлетворяет и функциональную потребность покупателя (информация для выбора), и социально-эмоциональную потребность активных пользователей (высказаться, получить признание как полезный комментатор).
Рекомендации и сопутствующие товары (“С этим часто покупают…”). Эта часть интерфейса решает работу “не пропусти ничего важного / купи всё необходимое в комплекте”. Например, пользователю не нужно самому догадываться, что к фотоаппарату нужна карта памяти. Также блок “похожие товары” помогает в задаче сравнения и поиска лучшей альтернативы, иногда расширяя изначальную работу (намеревался купить одно – понял, что лучше выбрать другой вариант).
Быстрая доставка. Для многих скорость и удобство доставки – критичная часть работы “купить с удобством”. Маркетплейсы удовлетворяют важную функциональную потребность “получить товар как можно скорее, без лишних переплат”. Здесь же выполняется эмоциональная составляющая: “я могу положиться на него, он не подведёт со сроками”, что превращает разовую покупку в привычку пользоваться постоянно.
Простота оплаты и возвратов. Купить в один клик, сохранённые карты, легкий возврат – всё это снижает барьеры. Пользователь ощущает: “ничего страшного, если что – верну”, “это займёт секунды – оформить заказ”. Таким образом, под-задача “совершить транзакцию без хлопот и рисков” тоже решена.

Заметим, что все эти функции работают в связке. Пользователь “нанимает” маркетплейс выполнить работу покупки end-to-end, и если бы какого-то модуля не было, пришлось бы “договаривать” другую службу. Например, если бы не было отзывов, покупатель бы искал обзоры в Google (отдельный сервис), если бы не было быстрой доставки – пошёл бы в офлайн-магазин купить срочно. Такие лидеры как Ozon или Wildberries победили во многом потому, что стал “one-stop shop” – закрыл смежные работы в одном месте. В терминах JTBD, они помогают “сделать всю работу покупки целиком, не прибегая к другим решениям”, чем и завоевал лояльность.

Пример №4. Notion: гибкий инструмент, “нанимаемый” под любые задачи организации информации

Notion – пример продукта, который изначально спроектирован как конструктор для разных Jobs-to-Be-Done в сфере организации информации и совместной работы. У разных пользователей Notion “работы” могут сильно отличаться, и успех продукта во многом обусловлен тем, что ключевые функции Notion многоцелевые и настраиваются под потребность.

Рассмотрим сценарий №1: личная организация заметок и дел. Пользователь хочет “иметь единое пространство для всех своих записей, списков задач, идей” – проще говоря, навести порядок в личной информации. Какие функции Notion участвуют в выполнении этой работы?

Страницы и разделы с иерархией – позволяют создавать структуру из папок и страниц. Это фундаментальная возможность под задачу “разложить информацию по полочкам, сделать собственную базу знаний”. Например, у пользователя могут быть страницы “Рабочие проекты”, “Личный дневник”, “Список книг к прочтению” – всё в одном месте, вложено и логично организовано.
Шаблоны и форматирование – Notion предлагает готовые шаблоны (канбан-доска, список задач, планировщик) и гибкие блоки (текст, таблицы, чекбоксы). Это решает под-задачу “быстро начать вести список дел или заметок по лучшим практикам”. Пользователь может “нанять” шаблон To-Do list вместо придумывания с нуля. Эмоционально это даёт уверенность и экономит время – важная часть работы, особенно если цель – начать новую привычку по самоорганизации.
Поиск по содержимому – когда нотсов и задач накопится много, важна задача “найти нужное по ключевому слову”. Встроенный поиск Notion реализует её, избавляя пользователя от хаотичного пролистывания. Это дополняет основную работу – хранить информацию, но и легко получать её обратно при необходимости.
Доступ с разных устройств и синхронизация – Notion работает на компьютере, телефоне, в вебе. Это невидимая функция, но критичная для работы “мои записи всегда со мной”. Пользователь может добавить идею на телефоне по дороге и затем открыть её на ноутбуке – работа “не упустить мысль и иметь доступ везде” выполнена.

Здесь мы видим, что один пользовательский job (личная организация информации) распадается на ряд более мелких, и Notion старается покрыть их все в рамках продукта. Альтернативой без Notion было бы использовать несколько средств: текстовые файлы или Google Docs для заметок, отдельное приложение-список задач для дел, облачное хранилище для доступа везде и т.д. Notion объединяет эти функции, чтобы пользователь “нанял” один инструмент вместо трёх-четырёх.

Сценарий №2: совместная работа и документация в команде. Представим стартап, который ведёт в Notion всё – от roadmap до протоколов созвонов. Работа команды: “иметь единое пространство, где мы вместе редактируем документы, ведём базу знаний и управляем задачами”.

Notion закрывает эту работу такими функциями, как:

Совместное редактирование в реальном времени – выполняет задачу “несколько человек могут одновременно дополнять документ”. Аналогичные JTBD решали Google Docs или Confluence, и Notion этот функционал тоже включает. Социальная часть работы – чувство единообразия информации – достигается: все видят одну самую свежую версию, никто не “работает в старой копии”.
Комментарии и упоминания – позволяет обсуждать прямо на страницах, ставить задачи коллегам через @упоминание. Это решает работу “не выпадать из контекста обсуждения и сразу фиксировать решения”. Раньше пришлось бы писать в почте или мессенджере отдельно, а тут всё происходит там же, где содержится информация.
Базы данных и виды (таблицы, доски) – чрезвычайно мощная универсальная фича Notion, которую разные команды “нанимают” под свои уникальные нужды. По сути, пользователь может сделать из базы данных что угодно: CRM-систему для продаж, список задач в виде канбан-доски, каталог сотрудников, контент-план и пр. Таким образом, одна функциональность (таблица + фильтры + вид представления) закрывает множество разных JTBD в разных компаниях. Для продуктовой команды база в виде доски Kanban – это выполнение работы “вести бэклог и трекать статус задач” (конкурируя с Trello, Jira). Для HR-отдела та же база, но в виде списка, может выполнять работу “учет кандидатов и вакансий” – аналог ATS системы. Одна и та же “фича” гнётся под разные процессы, что и делает Notion столь универсальным.
Права доступа и ссылки на страницы – дают возможность безопасно делиться отдельными разделами с внешними участниками (например, дать ссылку клиенту на проектный отчет). Это решает задачу “поделиться результатом работы с теми, кто вне нашей рабочей группы, сохранив остальное приватным”. Опять же, эту задачу можно было решить через выгрузку PDF или копирование в другой документ, но встроенная функция позволяет не покидать экосистему.

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

Конечно, такая универсальность имеет и обратную сторону – пользователю нужно самому продумать, как организовать информацию. Но сообщество и готовые шаблоны помогают: пользователь может скопировать чужой Space (рабочее пространство) для своего контекста. Это, кстати, ещё одна функция – шаблоны и копирование страниц – которая работает на разные задачи: новичку упрощает старт (работа “быстро получить структуру для моей задачи”), а опытному даёт возможность делиться лучшими практиками (работа “продемонстрировать кейс и помочь другим, получив признание” – многие энтузиасты делают бесплатные шаблоны и таким образом становятся известны в комьюнити).

Итак, только поняв конкретный JTBD, продукт-менеджер может решить, какие функции действительно нужны. Таким образом, ключевые ответы на вопросы “что строить” и “как будет расти продукт” заключаются в четком определении use case (кейса использования), то есть работы, которую вы собираетесь выполнять для пользователя. Например, если Instagram видит задачу “помоги пользователю чувствовать связь с друзьями ежедневно”, то решение родится в виде Stories – функциональности, идеально соответствующей контексту (мобильность, краткость, визуальность). Если бы команда исходила от решения (“давайте добавим исчезающие фото, это прикольно”), но без привязки к задаче, внедрение могло провалиться.

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

Это еще важно и в контексте конкурентного анализа — каждый новый сервис или функция на рынке может быть оценён через призму: какую работу она делает лучше, чем прежние решения? Если ответ чёткий, шансы на успех высоки. Если нет – велик риск, что продукт останется без “работы” и, образно говоря, его уволят за ненадобностью. Вместо вопроса “какую бы функцию еще добавить в Instagram?”, подход JTBD спросит: “какую незакрытую работу по обмену информацией у пользователей всё ещё не выполняет ни Instagram, ни другие соцсети?”. Именно так в Instagram появилось, например, Reels (ответ на работу “делись и смотри вирусные видео под музыку”).

2. Алгоритм разработки новых фичей

Шаг №1. Формирование идеи – на первом этапе важно понять, какую задачу (Job-To-Be-Done) пытается решить пользователь с помощью продукта. Для этого проводится исследование потребностей: интервью с пользователями, анализ отзывов, поведения в приложении и конкурентов. Начинать анализ стоит с правильных вопросов. Перед запуском или оценкой сценария использования (фичи) спросите себя:

Для кого этот сценарий (фича)? Определите целевую аудиторию. Какая доля пользователей продукта должна ей пользоваться (Target Users)? Например, функция может быть рассчитана на всех новых пользователей или только на опытных, или на определенный сегмент (страна, тарифный план и т.д.).
Какую проблему он решает? Понимание JTBD и ценности. Какую боль снимает новая возможность, либо какое удовольствие приносит? Это определит, как оценивать ее успех.
Какие цели и ожидаемые результаты? Четко сформулируйте, чего вы хотите достичь. Это может быть повышение вовлеченности (например, рост DAU/MAU), улучшение удержания (Retention), рост конверсии в оплату, увеличение среднего чека или LTV, привлечение новых пользователей (Growth), улучшение удовлетворенности (Satisfaction) и т.п.
Какие метрики «опишут» успех? Из целей вытекают KPI для сценария (фичи). Например, если цель – повысить вовлеченность, то смотрим на время в приложении, частоту сессий, если удержание – на процент вернувшихся через N дней, если монетизация – на количество покупок или ARPU и т.д.
Что считается хорошим результатом? Задайте базовые значения (baseline) и плановые. Например: «Ожидаем, что новый сценарий (фича) увеличит DAU на +10%» или «Retention на 7 день вырастет с 20% до 25%».
Как будем собирать данные? Продумайте реализацию аналитики: какие события логировать (нажатия, просмотры, завершение действия), нужна ли воронка, когортный разрез, контрольная группа. Важно спланировать это до выпуска фичи, чтобы не упустить нужные данные.

Шаг №2. Формулировка гипотезы и целей – имея идею фичи, её важно сформулировать как проверяемую гипотезу. Гипотеза должна четко связывать целевую аудиторию, их проблему и ожидаемый результат.

Обычно она формулируется в формате: «Если мы добавим функцию [название фичи] для [конкретного сегмента пользователей] с целью [решения определённой проблемы или выполнения JTBD], то [ключевая метрика] улучшится на [ожидаемый процент] за счёт [обоснование механизма улучшения]».

Например, если мы добавим функцию «Рекомендованные товары» для пользователей, совершивших хотя бы одну покупку, чтобы помочь им легче находить товары, которые могут быть им интересны, то конверсия в повторные покупки (CRR – Customer Repeat Rate) увеличится на 15% за счёт сокращения времени поиска товаров и персонализированных предложений

В этой формулировке выделяются независимая переменная (сама новая фича) и зависимая переменная (то, что измеряется). Учитывайте, что могло повлиять на показатели: сезонность, маркетинговые акции, смежные изменения в продукте.

Шаг №3. Проектирование и приоритизация – на этом этапе команда продумывает, как именно реализовать фичу и оценивает её приоритет относительно других задач. Каждой фиче присваивается ценность для продукта – например, ожидаемый прирост Retention на +5%, или прогноз, что новая возможность привлечёт N новых пользователей в месяц.

Далее анализируется стоимость и риск: сколько времени займет разработка, насколько сложна технически, нет ли риска ухудшить опыт других пользователей или сломать существующий функционал. Часто используют специальный фреймворк приоритизации, например RICE (Reach, Impact, Confidence, Effort) – он помогает оценить идею по четырём параметрам: охват (скольких пользователей затронет), влияние (насколько сильно улучшит опыт или метрики), уверенность (насколько надежны наши данные и предположения) и трудозатраты

Шаг №4. Разработка и тестирование – после планирования фича переходит в стадию реализации: дизайнеры и разработчики создают минимальный рабочий продукт (MVP) новой функции. Параллельно продумывается план аналитики: какие события и метрики нужно отслеживать, чтобы потом оценить использование фичи (например, сколько пользователей нажали новую кнопку, сколько завершили новый сценарий, как изменилась сессия использования и т.д.). Перед полноценным запуском почти всегда проводят тестирование. Стандартный подход – A/B-тест: новую функцию включают для небольшой доли пользователей (группа B), а другая доля остается на старой версии (контрольная группа A) для сравнения.

Это позволяет изолированно измерить влияние фичи на метрики: например, повышается ли удержание или ARPU в тестовой группе по сравнению с контролем. Тест может проводиться на ограниченной географии или сегменте аудитории (бета-тестеры, новые пользователи и пр.). Помимо количественных данных, собирается и обратная связь: через опросы, отзывы в сторах, аналитику из саппорта – нравится ли пользователям новое изменение, нет ли непредвиденных проблем. Такая комбинация данных даёт целостную картину.

Шаг №5. Анализ результатов и итерации – после тестового запуска наступает критически важный этап – оценка результатов. Команда продуктовой аналитики изучает, оправдались ли гипотезы: сравниваются целевые метрики до и после, между тестовой и контрольной группами. Если проводился A/B-тест, результаты проверяются на статистическую значимость, чтобы убедиться, что улучшения (или ухудшения) не случайны. Также анализируются вторичные эффекты: не просели ли другие показатели, изменилась ли структура поведения пользователей. Параллельно изучаются качественные данные: что говорят пользователи о новой функции, нет ли всплеска обращений в поддержку, как изменилась оценка продукта. На основе всего этого принимается решение о дальнейших действиях. Возможны варианты: масштабирование и улучшение фичи, доработка/итерация или откат (roll-back). Об этом подробнее ниже.

3. Анализ использования сценария и фичи. Анализ воронки

Многие продуктовые сценарии можно представить в виде воронки шагов или этапов, через которые проходит пользователь от первого контакта с функцией до получения ценности. Анализ такой воронки (Feature Adoption Funnel) позволяет найти, где и почему пользователи “отваливаются”, не дойдя до цели, и как это исправить.

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

Выявив шаг с аномально высоким оттоком, продуктовая команда может сформировать гипотезы: улучшить UX этого шага, убрать лишние поля формы, ускорить загрузку и т.п., и протестировать их. Цель – увеличить конверсию узкого этапа, тем самым “расширив” воронку и убрав ключевое ограничение роста.

Создание стратегии фичи. TARS

TARS – это продуктовый фреймворк, разработанный экспертами Reforge для оценки успешности отдельных функций продукта. Акроним TARS расшифровывается как Target Audience (целевая аудитория), Adopted (принятие функции пользователями), Retention (удержание пользователей) и Satisfaction (удовлетворенность). Фреймворк фокусируется на этих четырех ключевых метриках, позволяя сбалансировать бизнес-цели и потребности пользователей.

По сути это четыре вопроса к каждой новой функции:

Target Users (Целевые пользователи): сколько пользователей могло потенциально воспользоваться фичей? Это тот самый охват – скольким она вообще видна и доступна. Например, если фича только для новых пользователей, то таргет – это все новые регистрации; если доступна всем, то таргет ~ MAU всего продукта в периоде. В процентах Target можно считать как долю от общей базы, кому фича релевантна (100% целевой аудитории по замыслу).
Adopted (Приняли/активировали): сколько из целевых попробовали фичу. Это adoption rate, о котором говорилось выше. Процент пользователей, которые хотя бы раз воспользовались возможностью. Если есть шаг активации (например, включить настройку или создать первый объект) – фиксируем именно его. Например, у функции “темный режим” adoption = процент пользователей, зашедших в настройки и переключивших тему на темную.
Retained (Удержаны): сколько пользователей продолжают пользоваться функцией со временем (через неделю, месяц…). Retention тоже можно выразить в процентах от принявших. Низкий retention означает, что попробовали и забросили – возможно, фича не оправдала ожиданий или была разовой.
Satisfied (Довольны): показатель удовлетворенности тех, кто пользуется. Сложнее количественно измерить – используют косвенные метрики. Можно замерять коэффициент повторного использования (если пользователи возвращаются снова и снова – признак удовлетворенности), смотреть качественную обратную связь, или ставить мини-опрос после использования: например, “Помогла ли вам эта функция решить задачу? Оцените”. Сюда же можно отнести и отсутствие негатива: если фича влияет на общий NPS продукта в позитивную сторону или снижает жалобы.

Сейчас рассмотрим подробнее.

Target Audience (Целевая аудитория) – определяет, какой сегмент пользователей решает проблему, под которую сделана функция, и на кого она нацелена, это оценка размера рынка через то, какую «работу» пытается выполнить пользователь и кто эти пользователи. При использовании JTBD целевая аудитория определяется не просто демографией или ролями, а группой людей + задачей, которую они пытаются выполнить. JTBD уточняет Target Audience через потребности. В рамках JTBD сегментация аудитории происходит по общим задачам и болям, а не по классическим персонам. Например, вместо размытого портрета «молодые специалисты 25-34 лет» фреймворк JTBD группирует всех пользователей, для которых определенная потребность важна и пока неудовлетворена.

Такой подход выявляет истинную целевую аудиторию функции – тех, кто активно ищет решение конкретной задачи: зная “работу, которую надо выполнить”, продуктовая команда лучше определяет, кто эти пользователи и сколько их. Исследование JTBD помогает ответить на вопрос: какой процент наших пользователей действительно сталкиваются с этой задачей? Именно этих пользователей и стоит считать целевой аудиторией функции.

Например, возьмем JTBD-сценарии.

Пример. Экспорт данных для офлайн-анализа

Функция: Добавление кнопки «Экспорт результатов поиска в CSV/Excel» в аналитическом сервисе.

JTBD-сценарий: «Помогите мне легко использовать результаты поиска вне платформы, чтобы выполнить офлайн-задачи (например, подготовить отчет или провести доп. анализ).» Пользователь «нанимает» функцию экспорта, чтобы перенести данные в удобный формат и решить внешнюю задачу.

Целевая аудитория: Пользователи, которым регулярно требуется работать с данными вне продукта – например, аналитики или менеджеры, выгружающие результаты для отчетов. Через исследования выясняется доля таких пользователей. В одном случае из практики оказалось, что ~10% всех пользователей сервиса нуждаются в экспорте результатов поиска для офлайн-задач. Именно эти ~10% и есть целевая аудитория новой функции экспорта. Чётко сформулировав job («подготовить данные для офлайн-использования»), команда поняла, кого нацеливать: продвинутых пользователей с потребностью в гибком использовании данных.

Пример. Оффлайн-доступ к контенту в стриминговом сервисе

Функция: Offline Downloads – возможность скачивать видео/контент в приложении (например, на Netflix) для просмотра без интернета.

JTBD-сценарий: «Помогите мне посмотреть мои любимые сериалы/фильмы, когда у меня нет доступа к интернету (в самолёте, в дороге).» Пользователь «нанимает» функцию офлайн-доступа, чтобы заполнить время в пути или в зоне без связи, продолжая потреблять контент.

Целевая аудитория: Пользователи, которые часто бывают вне сети – путешественники, авиапассажиры и т.д. Именно они остро ощущают задачу «смотреть в дороге без сети». До введения этой функции такие пользователи были неудовлетворены (не могли пользоваться сервисом в полёте). Введя офлайн-скачивание, сервис нацелился на этот сегмент. JTBD-подход показал: если job – “развлечь себя офлайн”, то целевая группа – подписчики, часто находящиеся офлайн.

Если JTBD обеспечивает “внешний фокус” – понимание того, что действительно хотят достичь пользователи (их Jobs), – а TARS даёт “внутренний компас” метрик для оценки, насколько хорошо функция это реализует. Фактически, JTBD помогает правильно выполнить шаг Targeted: определить правильную целевую аудиторию и ценность функции для неё, а TARS затем измеряет Adoption, Retention, Satisfaction именно в контексте этой целевой группы.

Практически продуктовая команда может действовать так: сначала через интервью и наблюдения по JTBD выявить неудовлетворенную задачу пользователей и сформулировать видение функции под эту работу. Этот этап отвечает на вопросы: “Какую проблему/работу пользователя решаем? Кто испытывает эту проблему?” Таким образом формируется чёткое понимание для кого и зачем создаётся функция. Затем, при запуске, команда применяет TARS-метрики: отслеживает, какой процент тех самых пользователей (целевой аудитории) начал использовать функцию (Adopted), возвращается ли к ней повторно (Retained), и удовлетворены ли они результатом (Satisfied). Например, если из рассчитанной целевой аудитории в 10% пользователей функцию попробовали лишь 2% (низкий Adoption), это сигнал о проблеме с донесением ценности или удобством – возможно, пользователи не осознали, как функция решает их job. Команда может вернуться к JTBD-инсайтам: провести дополнительные исследования, чтобы понять, почему функция не «нанята» – соответствуют ли реализованные решения изначальной задаче пользователя, нет ли рассинхрона между задачей и функциональностью.

Таким образом, определив через JTBD, что означает ценность для пользователя, команда устанавливает критерии успеха в терминах TARS (доля охваченной аудитории, частота использования, уровень удовлетворенности). Этот подход предотвращает ситуации, когда функция сделана «в вакууме»: JTBD не даст забыть о реальной жизни пользователя, а TARS не даст забыть про результаты.

Такой цикл итераций – “Job → Фича → Метрики → Инсайты → уточнённый Job” – создает непрерывное улучшение. Как отмечают эксперты, ключ к осмысленной аналитике продукта в том, чтобы понимать, что пытаются сделать пользователи (их Job), а не просто считать клики по функции

4. Как повышать уровень активации сценария (фичи)?

Активный пользователь фичи – это тот, кто хотя бы раз совершил с ней целевое действие. Например, если фича – «еженедельная email-рассылка отчётов», активными пользователями фичи будут те, кто эту рассылку настроил и получает. Для продукта в целом под активными пользователями обычно понимают тех, кто выполняет значимые действия за определенный период (DAU, WAU, MAU – дневная, недельная, месячная аудитория). Причем “значимое действие” должно быть определено под специфику сценария использования: в соцсети это может быть логин и взаимодействие с контентом (лайк, пост или комментарий), в маркетплейсе – размещение или покупка товара, а в SaaS – использование ключевого функционала.

Для количественного определения метрики активных пользователей в JTBD необходимо определить ключевое действие в сценарии, отражающее выполнение работы, и следить за тем, кто и как часто его совершает. Например, команда Calendly определила, что активный пользователь сервиса – это тот, кто получил хотя бы одну бронь встречи через Calendly (т.е. решил задачу планирования встречи без переписки). Такой критерий напрямую связан с ценностью: пользователь действительно использовал продукт по назначению. Другой пример: в банковском приложении, созданном для задачи ежедневных платежей, активным можно считать пользователя, который совершает платежи или переводы с определенной регулярностью (скажем, минимум раз в неделю). В JTBD-логике важно именно значимое использование: не просто открыть приложение, а выполнить целевое действие. Таким образом, активный пользователь – это тот, кто с заданной частотой достигает ценностного взаимодействия (выполняет job) с помощью продукта.

Например, для фитнес-приложения – это завершенная тренировка, достигнутая цель по шагам, просмотренный прогресс. В каждом случае есть ключевой сценарий, ради которого пользователь открыл приложение, – его успешное выполнение и есть ценностное взаимодействие. Этот момент можно определить как событие (event) в аналитике – например, “workout_completed” или “level_complete”. Критерии: достигает ли пользователь результата, и насколько часто.

Критерии варьируются: важно определить разумную частоту исходя из того, как встроен продукт в жизнь пользователя. Также мобильные команды часто сегментируют активных пользователей по уровням вовлеченности: например, “core” активные (ежедневные), “occasional” (раз в неделю) и т.п., чтобы лучше таргетировать улучшения.

Низкий уровень принятия (adoption) новых функций пользователями может быть обусловлен несколькими ключевыми факторами:

Нехватка осведомленности (Lack of Awareness):
- Пользователи не знают о существовании новой функции или не понимают, как она может решить их проблемы.
- Тактики решения:
  - Информационные кампании: Использование push-уведомлений, баннеров внутри приложения и email-рассылок для информирования пользователей о новой функции и ее преимуществах.
  - Обучающие материалы: Создание руководств, видео или FAQ, объясняющих, как использовать функцию и какую ценность она приносит.
  - Интеграция в пользовательский путь: Размещение подсказок или туров по новой функции в процессе использования приложения, чтобы пользователи могли легко ознакомиться с ней.
Проблемы с обнаружением (Discoverability Issues):
- Пользователи не могут найти новую функцию в интерфейсе, даже если знают о её существовании.
- Тактики решения:
  - Оптимизация интерфейса: Размещение новой функции на видном месте, использование ярких иконок или выделение её цветом.
  - Поисковая оптимизация: Обеспечение возможности поиска функции по ключевым словам внутри приложения.
  - Всплывающие подсказки: Использование всплывающих сообщений или туров по приложению, показывающих, где находится новая функция.
Высокие барьеры использования (High Friction):
- Функция требует значительных усилий для начала использования, что отпугивает пользователей.
- Тактики решения:
  - Упрощение процесса: Сокращение количества шагов, необходимых для начала использования функции.
  - Автоматизация: Предзаполнение форм, автоматическое сохранение данных и другие методы, уменьшающие нагрузку на пользователя.
  - Обратная связь: Сбор отзывов пользователей для выявления и устранения точек трения в процессе использования.
Низкое ценностное предложение (Low Value Proposition):
- Пользователи не видят явных преимуществ или пользы от использования новой функции.
- Тактики решения:
  - Четкое позиционирование: Ясное объяснение того, какую проблему решает функция и какие преимущества она предоставляет.
  - Демонстрация ценности: Использование примеров, кейсов и отзывов, показывающих успешное применение функции другими пользователями.
  - Тестирование и итерации: Проведение A/B-тестов и сбор обратной связи для улучшения функции и её соответствия потребностям пользователей.

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

5. Как повышать уровень удержания сценария (фичи)?

Ценностное взаимодействие – это ключевое действие пользователя с продуктом, при котором он получает обещанную ценность. В TARS косвенным показателем таких взаимодействий выступают метрики удержания и удовлетворенности: если пользователи продолжают возвращаться к фиче (Retained) и довольны ею (Satisfied), значит, фича дает им ценность.

Активный удерживаемый пользователь – это пользователь, регулярно задействующий эту функцию (например, несколько раз за период, соответствующий задумке фичи). Критерии идентификации активного пользователя: частота и регулярность ключевых действий. В TARS Retained-показатель по фиче прямо указывает на долю пользователей, ставших активными в длительной перспективе (не разово, а на постоянной основе). Например, если из 1000 целевых пользователей новой функции 200 ее попробовали (Adopted) и 100 продолжают пользоваться еженедельно (Retained), то активных удерживаемых пользователей можно считать этих ~100 человек (10% от целевой аудитории). Дополнительно, удовлетворенные пользователи (Satisfied) – это те активные пользователи, чей опыт был позитивным, что тоже важно при оценке качества активности.

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

Что тут можно сделать? Убедитесь, что каждая функция имеет уникальное ценностное предложение и не дублирует возможности других. Для этого можно провести качественные исследования, чтобы понять, какие задачи пытаются решить пользователи или UX-тесты. Это поможет разработать функции, отвечающие их реальным потребностям.

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

6. Как повышать уровень удовлетворенности?

Customer Effort Score (CES) — это метрика, оценивающая усилия, которые клиент затрачивает при взаимодействии с компанией или использованием ее продуктов и услуг. Измерение CES для конкретной функции продукта помогает понять, насколько легко пользователям использовать эту функцию, и выявить возможные проблемы в пользовательском опыте.

Как рассчитать CES для функции:

Сформулируйте вопрос для опроса: после того как пользователь взаимодействовал с конкретной функцией, задайте ему вопрос, оценивающий усилия, затраченные на использование этой функции. Например: «Насколько легко вам было использовать функцию X?» Ответы могут быть представлены на шкале от 1 до 5, где 1 — «Очень сложно», а 5 — «Очень легко».
Проведите опрос: отправьте опрос непосредственно после использования функции, чтобы получить наиболее точные и свежие впечатления пользователей. Это можно сделать через всплывающие окна в приложении, email-рассылки или другие каналы коммуникации.
Соберите и проанализируйте данные: после сбора ответов вычислите средний балл CES для функции. Чем выше средний балл, тем меньше усилий требуется от пользователей для использования функции, что является положительным показателем.

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

50 пользователей оценили на 5 («Очень легко»)
30 пользователей оценили на 4 («Легко»)
15 пользователей оценили на 3 («Нейтрально»)
5 пользователей оценили на 2 («Сложно»)
0 пользователей оценили на 1 («Очень сложно»)

Для расчета среднего CES используйте формулу:

Средний CES=(5×50)+(4×30)+(3×15)+(2×5)+(1×0)/(50+30+15+5+0)=4.25

Средний CES для функции «Быстрый заказ» составляет 4.25, что указывает на то, что большинство пользователей считают эту функцию легкой в использовании.

Рекомендации по улучшению CES:

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

7. Метрики для анализа фичей

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

Число активных пользователей, имеющих доступ к фиче (baseline). Это своего рода базовая выборка: сколько пользователей в принципе могут воспользоваться функцией. Например, если фича доступна только платным подписчикам или участникам A/B-теста, – это количество активных пользователей из этих групп. Если же функция открыта для всех, число пользователей примерно равно общему MAU продукта. Понимание важно, чтобы знать, от какого максимального пула пользователей мы отталкиваемся при оценке использования фичи.
% MAU – доля от общего числа MAU, имеющих доступ к фиче. Показывает, какой процент всей месячной аудитории продукта охвачен фичей. Если функция доступна всем, этот показатель будет близок к 100%. Если же доступ ограничен (например, только 20% пользователей участвуют в бета-тесте новой функции), % MAU может быть ~20%. Эта метрика отражает покрытие фичи: насколько широко она развернута среди пользователей. При анализе важно учитывать, что низкое значение % MAU само по себе не означает плохую фичу – возможно, она умышленно доступна не для всех (например, премиум-функция).
MAU – уникальные активные пользователи, реально взаимодействовавшие с фичей хотя бы раз за месяц. Это реальный месячный охват фичи – сколько человек воспользовались функцией в течение месяца. В отличие от потенциальных пользователей, MAU – это фактические пользователи фичи. Данная метрика показывает популярность функции на практике.
% MAU (sample) – доля MAU, реально взаимодействующих с фичей хотя бы раз в месяц. Проще говоря, это процент от всей месячной аудитории продукта, которая воспользовалась данной функцией. Рассчитывается как (Sample MAU / общий MAU продукта) * 100%. Если, скажем, у приложения 100 000 MAU, и 5 000 из них воспользовались фичей хотя бы раз, то % Sample MAU = 5%. Этот показатель отражает проникновение фичи в общую аудиторию. Он удобен для быстрого сравнения: например, одна функция охватывает 50% всех пользователей, а другая – только 5%. Кроме того, сравнение % MAU и % Sample MAU дает понять, сколько из тех, у кого есть доступ, реально воспользовались функцией. Если фича доступна 100% пользователей, но лишь 5% ею воспользовались, это сигнал о низком интересе или проблемах с обнаружением ценности функции.
AVG DAU – среднее количество уникальных пользователей в день, взаимодействующих с фичей. Эта метрика отображает среднесуточную аудиторию функции. Рассчитывается обычно за месяц: берется количество уникальных пользователей фичи за каждый день и выводится среднее. Например, если в среднем за день функцию используют 500 пользователей, то AVG DAU = 500. Средний DAU показывает, насколько регулярно функция используется день ото дня. Он полезен для понимания дневной активности: используется ли фича ежедневно большим числом людей или лишь эпизодически.
DAU/MAU – отношение дневной активности к месячной для фичи, т.н. «коэффициент липкости». Рассчитывается как (AVG DAU / Sample MAU) * 100% – доля пользователей фичи, которые используют её в любой средний день. DAU/MAU отражает частоту использования: насколько часто пользователи возвращаются к функции в течение месяца. Например, если у функции Sample MAU = 5 000, а средний DAU = 500, то DAU/MAU = 10%. Это означает, что в среднем в каждый день активны ~10% от месячной аудитории функции (или иначе, среднестатистический пользователь задействует функцию 10% дней месяца, то есть ~3 дня в месяц). Высокий DAU/MAU (ближе к 50–100%) свидетельствует, что фича встроилась в ежедневные привычки (пользуются очень часто, почти каждый день). Низкий (5–10%) говорит, что функцию используют редко, время от времени. Этот коэффициент помогает понять, насколько фича «липкая» – привязываются ли к ней пользователи или используют эпизодически.
Среднее количество дней в месяц с использованием фичи: эта метрика отражает, сколько дней в среднем пользователь активен в рамках данной функции. По сути, это близкий показатель к DAU/MAU, но в понятных единицах: например, «средний пользователь использовал функцию в 5 разных дней месяца». Рассчитывается как (DAU/MAU * 30) или альтернативно через среднее по пользователям (сумма дней использования всеми пользователями / число пользователей). Данный показатель помогает понять, вписывается ли функция в ежедневный ритуал или остается эпизодической. Полезно также смотреть распределение: какая доля пользователей воспользовалась функцией 1 день в месяц, 2-3 дня, 10+ дней и т.д. Среднее может скрывать эти детали, поэтому иногда считают метрику «% пользователей, активных X дней в месяце в данной фиче».
Total usage – общее количество взаимодействий с фичей за месяц. Это метрика суммарной активности: сколько раз в целом функция была использована всеми пользователями. Под «взаимодействием» обычно понимают единицу действия, например, число запусков фичи, кликов или сессий, связанных с ней. Total usage показывает объем нагрузки или интереса к функции в абсолютных числах. Например, 5 000 пользователей могли совершить 20 000 действий с функцией за месяц – эти 20 000 и будут Total usage. В паре с Sample MAU этот показатель дает среднее число действий на пользователя (Average per user). Если Total usage значительно превышает Sample MAU, значит, активные пользователи фичи совершают много действий (высокая интенсивность использования). Если же они близки по величине, то чаще всего каждый пользователь сделал только одно действие за месяц.
Retention (R(Day 1), R(Day 7), R(Day 30)) – удержание пользователей фичи на 1, 7 и 30 день. Retention показывает, сколько процентов пользователей возвращаются к фиче спустя определенное время после предыдущего (или первого) использования. Обычно рассчитывают retention для новых пользователей фичи: например, R(Day 1) – процент тех, кто, попробовав функцию, снова воспользовался ею на следующий день. R(Day 7) – вернулись через неделю (± на 7-й день), R(Day 30) – через 30 дней. Если R1 низкий, это значит, что единицы продолжили пользоваться функцией уже на следующий день (что нормально для нерегулярных сценариев). Более показательно R7 и R30: высокое значение означает, что функция цепляет и люди возвращаются к ней со временем, тогда как низкое говорит о разовом использовании без длительного интереса. Например, R7 = 30% означает, что почти треть пользователей повторно воспользовались функцией примерно через неделю после первого использования – хороший знак вовлеченности. Retention помогает понять, превращается ли первое знакомство с фичей в устойчивое использование.

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

Важно, не все элементы продукта корректно оценивать описанными метриками. Некоторые фичи работают в фоновом режиме или не требуют явных действий от пользователя – например, алгоритмические рекомендации контента, персонализированная лента, автоматические бэкапные сервисы, или просто статичные информационные блоки интерфейса. У таких «фичей» нет явного события использования (пользователь может даже не осознавать их работу), поэтому классические метрики (DAU, MAU для фичи) неприменимы или мало информативны. Включение их в общий анализ может исказить картину.

Рекомендуется фокусироваться на тех функциях, где есть осознанное действие пользователя: клик, просмотр, создание чего-либо. Исключая фоновые возможности из расчета, мы получаем более чистые данные по вовлеченности. Это не значит, что фоновые функции неважны – просто для них нужны другие подходы оценки (например, A/B тест влияния рекомендации на общее удержание или метрики качества алгоритма вместо прямых пользовательских метрик).

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

8. Примеры анализа фичей с помощью метрик

Рассмотрим несколько примеров функций в контексте реального продукта, чтобы проиллюстрировать различия в метриках. В качестве примера возьмем фичи из фитнес-приложения на примере Strava (социальный сервис для спортсменов): в нем есть три сценария использования Saved Routes, Local Legends и Record Activity. Эти три сценария существенно различаются по популярности, частоте использования и целевой аудитории, что отражается в метриках.

Saved Routes («Сохраненные маршруты»)

Saved Routes («Сохраненные маршруты»): этот сценарий и как следствие фича позволяет пользователям сохранять маршруты тренировок для будущего использования. Её аудитория относительно узкая: маршруты сохраняют преимущественно активные велосипедисты или бегуны, которые планируют тренировки.

Основной JTBD: Когда я планирую будущую тренировку (велосипедную или беговую), я хочу заранее сохранять проверенные маршруты, чтобы минимизировать усилия по их поиску и иметь возможность быстро приступить к тренировке.
Дополнительные JTBD:
- Когда я нахожу или создаю маршрут, который мне особенно понравился, я хочу сохранить его, чтобы легко повторить тренировку и улучшать результаты, сравнивая показатели на знакомой трассе.
- Когда я готовлюсь к соревнованиям или важному мероприятию, я хочу сохранять и систематизировать маршруты тренировок, чтобы заранее контролировать нагрузку и уверенно двигаться к цели.
- Когда я регулярно тренируюсь в незнакомой местности (например, в командировках или путешествиях), я хочу заранее сохранять маршруты для быстрого ориентирования и комфортных тренировок без стресса.
Эмоциональный и социальный JTBD:
- Я хочу сохранять свои лучшие маршруты, чтобы делиться ими с сообществом или друзьями, чувствовать гордость за свои достижения и вдохновлять других пользователей.

Target Audience (Целевая аудитория)

Доступность функции: 100% от общего MAU (доступна всем зарегистрированным пользователям).
Фактическое использование: 10–15% от общего MAU (активные пользователи, регулярно планирующие тренировки и сохраняющие маршруты).

Adoption (Принятие и распространение функции)

Общий MAU (по доступу): 100% от активной пользовательской базы.
Sample MAU (фактическое использование): 10–15% от общей активной пользовательской базы.
Причина: Сохранение маршрутов актуально преимущественно для активных велосипедистов и бегунов, которые регулярно планируют тренировки.

Retention (Удержание пользователей)

Day 7 Retention: 15–20% (большинство пользователей используют эпизодически, возвращаясь не каждую неделю)
Day 30 Retention: 30–40% (стабильное ядро пользователей, которые планируют тренировки регулярно, возвращается примерно раз в месяц)

Stickiness (Частота использования, DAU/MAU)

DAU/MAU Ratio: ~10% (низкая липкость) (Функция используется эпизодически, примерно 1–2 раза в месяц перед тренировками или поездками, но не ежедневно.)

Avg per User (Средняя частота использования)

~1–2 сохранённых маршрута в месяц на одного активного пользователя
(Большинство сохраняют 1 маршрут, небольшая часть аудитории — 2 и более для разных типов тренировок.)

Итого, выводы по метрикам:

Функция Saved Routes представляет собой нишевую, но полезную функцию для узкой группы пользователей (велосипедистов и бегунов), активно занимающихся планированием тренировок. Несмотря на широкую доступность, реальное использование эпизодично и преимущественно среди тех, кто регулярно планирует тренировки заранее. Низкий DAU/MAU (низкая частота использования) и умеренное удержание говорят о том, что основная ценность функции — в периодическом использовании для конкретных сценариев (подготовка к мероприятиям, поездкам или повторению любимых маршрутов).

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

Пользователи могут по-разному взаимодействовать с разными элементами функции. Например, фича Saved Routes включает подфункции: создание нового маршрута, сохранение существующего маршрута (например, найденного у друга или в каталоге), следование по маршруту (навигация). Анализ покажет, какая часть пользователей маршрутов создаёт свои маршруты с нуля, а кто просто сохраняет готовые, сколько из них затем действительно используют сохраненный маршрут в тренировке. Возможно, выяснится, что 90% пользуются только сохранением готовых маршрутов и лишь 10% создают сами – это инсайт для команды, куда развивать функцию (например, улучшить рекомендательную систему маршрутов вместо усложнения редактора маршрута).

Local Legends («Local Legends»)

Основной JTBD:

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

Дополнительные функциональные JTBD:

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

Эмоциональные JTBD:

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

Социальные JTBD:

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