Сегментация пользователей в продуктовой аналитике

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

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

Сегмент начинается с гипотезы

Перед построением отчёта запишите:

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

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

Пользовательские и аккаунтные свойства

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

В B2B SaaS эти уровни нельзя смешивать. Пользователь с ролью «аналитик» может работать в enterprise-аккаунте; тариф относится к аккаунту, а не к человеку.

Статья аналитика аккаунтов B2B SaaS подробно разбирает единицы анализа.

Событийные свойства

Иногда сегмент относится не к пользователю, а к конкретному действию:

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

Не переносите свойство одного события на всю историю пользователя без правила. Человек мог использовать несколько способов в разные моменты.

Текущее и историческое значение

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

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

В зависимости от вопроса нужны:

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

Подпишите выбранное правило рядом с отчётом.

Полезные группы сегментов

Жизненный цикл

• новый пользователь;
• прошёл активацию;
• платящий аккаунт;
• реактивированный;
• отменивший подписку.

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

Продуктовый контекст

• вариант интерфейса;
• доступность функции;
• версия клиента;
• способ интеграции;
• роль;
• платформа.

Коммерческий контекст

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

Финансовые свойства лучше получать из систем-источников, а не выводить из кликов.

Поведение

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

Поведенческий сегмент должен иметь окно: «использовал функцию когда?»

Знаменатель и доступность

Feature adoption нельзя считать как долю использовавших функцию от всех пользователей, если функция доступна только части тарифов или ролей.

Корректный знаменатель:

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

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

Малые выборки

Сегмент из нескольких пользователей может показать 0% или 100% конверсии без устойчивого сигнала. Всегда показывайте рядом абсолютные числа.

Вместо «конверсия выросла до 50%» пишите: «из четырёх аккаунтов два дошли до шага». Это сразу меняет уверенность вывода.

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

Множественные сравнения

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

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

Пример

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

Она сравнивает:

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

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

Сегменты для регулярного отчёта

В постоянный дашборд стоит включать только группы, у которых:

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

Остальные сегменты можно создавать для разового исследования и удалять после ответа.

Итог

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