Аналитика аккаунтов B2B SaaS: пользователи, роли и команды

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

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

Три уровня данных

Пользователь

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

Аккаунт

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

Объект

Проект, магазин, интеграция, отчёт или другая сущность внутри аккаунта. Иногда именно объект является единицей воронки.

Каждое событие должно содержать только те идентификаторы, которые действительно известны в момент действия.

Модель связи

Минимальная модель включает:

• user_id;
• account_id;
• role;
• membership_id или историю участия;
• object_id для предметной сущности;
• event_time;
• источник события;
• версию схемы.

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

Активация аккаунта

Аккаунт может считаться активированным после набора условий:

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

Не все условия обязательны для каждого продукта. Определение должно отражать реальную ценность.

Формула:

Account activation = активированные новые аккаунты ÷ подходящие новые аккаунты × 100%.

Путь и окно подробно разобраны в статье воронка активации SaaS.

Роли

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

Пример:

Роль	Значимое действие
Администратор	настройка доступа и интеграции
Оператор	выполнение регулярной операции
Аналитик	создание или изучение отчёта
Руководитель	просмотр результата и принятие решения

Если новая функция рассчитана на администратора, её adoption не нужно делить на всех участников аккаунта.

Активность аккаунта

Простой признак «хотя бы один вход» часто слишком слаб. Более содержательные варианты:

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

Соберите несколько прозрачных сигналов до создания сложного health score.

Feature adoption на уровне аккаунта

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

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

Общая методика приведена в статье feature adoption.

Retention и churn

Пользовательский churn не равен клиентскому. Сотрудник может уйти, а аккаунт продолжит платить и использовать продукт.

Для account retention выберите:

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

Для logo churn используйте статус платящих аккаунтов из биллинга. Продуктовые события показывают изменение использования до отмены, но не заменяют финансовый факт. Подробнее — retention и churn в SaaS.

Изменение состава команды

События членства помогают исследовать:

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

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

Сегменты аккаунтов

Полезные признаки:

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

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

Пример расследования

Общая пользовательская активность снизилась, но logo churn не изменился.

Команда выясняет:

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

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

Качество идентификации

Проверяйте:

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

Контроль всего потока описан в статье о качестве данных.

Итог

Аналитика B2B SaaS должна сохранять связь человека, роли, аккаунта и предметного объекта. Тогда команда видит не только клики отдельных пользователей, но и получение ценности всей организацией, изменение состава, adoption и удержание клиента.