Пользовательская аналитика ИТ систем: анализ данных - анализ количества активных пользователей корпоративных систем

Пользовательская аналитика в рамках ИТ-департамента CIO представляет собой критически важный элемент управления эксплуатационной эффективностью корпоративной инфраструктуры. Анализ количества активных пользователей по каждому системному портфелю позволяет прогнозировать нагрузку, планировать лицензирование, оценивать качество доступа и выявлять аномалии использования. В этой главе рассматриваются технические аспекты построения и эксплуатации аналитики активности пользователей в BI DWH: архитектура данных, модели и схемы, методы расчета метрик, потоки данных и интеграции, а также практические сценарии внедрения в крупных организациях. Основной акцент сделан на конкретике реализации: какие данные брать, как их связать, какие метрики и какие сценарии автоматизации внедрять.

Глубокий технический подход к аналитике активности пользователей требует единого взгляда на источник данных, модель данных, ETL/ELT-процессы и обеспечение управляемости данных. В CIO-контексте особенно важно обеспечить прозрачность происхождения данных, воспроизводимость расчетов и возможность быстро масштабировать решение при росте числа систем и пользователей. В этой главе детально разобраны архитектурные принципы, схемы и алгоритмы, применимые в современной корпоративной DWH-среде, а также практические примеры реализации.

Краткое содержание главы
Архитектура пользовательской аналитики в BI DWH
Модели данных и схемы активных пользователей
Метрики и расчеты активных пользователей
Интеграции источников данных и потоки данных
Применение и сценарии внедрения
Проблемы качества данных и управление данными

Архитектура пользовательской аналитики в BI DWH

Эффективная архитектура аналитики активности пользователей строится на сочетании надежной идентификации пользователей, агрегации по временным интервалам и устойчивых потоков данных между источниками и хранилищем. В большинстве крупных организаций реализация следует концепции data lakehouse или многослойной DWH-архитектуры: сырой слой (raw), обработанный слой (staging/ops) и аналитический слой (subject area, data marts). Центральным элементом становится факт-таблица активности пользователя (FactActiveUser) и связанные размерности. Ключевые компоненты архитектуры:

Источники данных: регистры идентификации (SSO/IdP: Okta, Azure AD, Google Identity), журналы входов приложений, системные логи, события аудита, данные об доступе и сеансах. Подсистема IAM/SSO обеспечивает консистентность идентификаторов пользователей, даже если пользователь имеет несколько учетных записей в разных системах.
Интеграционные каналы: пакетная загрузка и потоковая передача данных. Потоки должны поддерживать CDC (change data capture) и событийно-ориентированную передачу для минимизации задержки между событием входа и его отражением в BI DWH.
Хранилище данных: схема звезды или снежинки в BI DWH, управляемые метаданными и классами доступа. В реальном времени подходят ленточные(append-only) или микросегментированные потоки для фактов активности.
Модели данных и бизнес-логика: слой расчетов, где определяется активность: по Login/Session событиям, по времени активности и по контексту системы.
Управление качеством данных: контроль уникальности идентификаторов, консистентность по доменам систем, обработка дублей и конфликтов идентификаторов.
Безопасность и соответствие требованиям: защита PII, минимизация рисков утечки идентификаторов, аудит доступа к данным аналитики и журналирования изменений схем.

Важно подчеркнуть: активность пользователей должна отражаться в совместимой и воспроизводимой модели представления данных. Это требует строгой идентичности пользователя, согласованных правил сопоставления (identity mapping) между системами и единой календарной размерности. В рамках технологий выберем устойчивые к изменениям и повторяющиеся подходы: схема звездой, CDC-потоки, ELT-процессы и модульная организация ETL/ELT.

В рамках открытых и коммерческих решений применяется сочетание Apache Kafka или аналогичных систем потоковых данных, инструментов ELT/ETL (например, dbt для моделирования и оркестрации) и хранилищ данных (классические RDBMS или облачные хранилища вроде Snowflake, Google BigQuery, Azure Synapse). Для российского контекста допустимы наиболее используемые локальные и открытые решения с ограничениями по лицензиям и требованиям к локализации данных. В этом разделе не приводятся детализированные техничес спецификации конкретных платформ, однако примеры интеграций показывают общую схему взаимодействия компонентов.

Пример потока данных

Источник: Identity Provider (IdP) и журналы входов приложений -> отправка событий в потоковую шину.
Центральный слой: обработка и нормализация событий, сопоставление идентификаторов, очистка и агрегация.
Аналитический слой: формирование фактов и размерностей, расчеты и сохранение в хранилищеDWH.

Потребители: отчеты и дашборды, API для операционных систем и службы поддержки.

-- Пример упрощенного DDL-скелета для star schema
CREATE TABLE DimUser (
  user_id VARCHAR(64) PRIMARY KEY,
  username VARCHAR(128),
  department VARCHAR(128),
  role VARCHAR(64),
  identity_provider VARCHAR(64),
  locale VARCHAR(10)
);

CREATE TABLE DimSystem (
  system_id VARCHAR(64) PRIMARY KEY,
  system_name VARCHAR(128),
  environment VARCHAR(32),
  vendor VARCHAR(64)
);

CREATE TABLE DimDate (
  date_key DATE PRIMARY KEY,
  date_value DATE,
  year INT,
  month INT,
  quarter INT,
  is_holiday BOOLEAN
);

CREATE TABLE FactActiveUser (
  date_key DATE,
  user_id VARCHAR(64),
  system_id VARCHAR(64),
  login_count INT,
  active_minutes INT,
  first_login TIMESTAMP,
  last_login TIMESTAMP,
  device_type VARCHAR(32),
  auth_method VARCHAR(32),
  PRIMARY KEY (date_key, user_id, system_id)
);

Модели данных и схемы активных пользователей

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

DimUser: идентификатор пользователя, базовые атрибуты (подразделение, роль, источник аутентификации). Важная задача - консолидировать идентичности пользователей из разных систем в единую «персону» в рамках аналитики.
DimSystem: идентификатор системного портфеля, атрибуты типа среды (продукт, служба, внутренняя/облачная), владение и ответственность за систему.
DimDate: полная временная размерность: дата, год, месяц, день недели, признак праздничного дня. Позволяет строить DAU/WAU/MAU, сезонность и аномалии.
FactActiveUser: за временнóй гранью хранится факт активности: количество заходов, суммарное время активности, первый и последний вход, метод аутентификации, тип устройства.

Ниже представлена согласованная таблица, описывающая сущности и их ключевые атрибуты в рамках модели:

Сущность	Назначение	Основные атрибуты	Примечания
DimUser	Пространство пользователей	user_id PK, username, department, role, identity_provider, locale	уникальный идентификатор пользователя внутри DWH; поддерживает mapping через идентичности
DimSystem	Корпоративные системы	system_id PK, system_name, environment, vendor	охватывает SaaS, on-prem, облако; для группирования по портфелям
DimDate	Временная размерность	date_key PK, date_value, year, month, quarter, is_holiday	единая календарная логика отчетности
FactActiveUser	Факт активности	date_key, user_id, system_id, login_count, active_minutes, first_login, last_login, device_type, auth_method	grain: одна запись на пользователь-система-день

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

Пример кодовой операции по согласованию идентичностей

-- Псевдокод миграции идентификаторов пользователей из разных систем в DimUser
INSERT INTO DimUser (user_id, username, department, role, identity_provider, locale)
SELECT COALESCE(u1.user_id, u2.user_id, u3.user_id) AS user_id,
       COALESCE(u1.username, u2.username, u3.username) AS username,
       COALESCE(u1.department, u2.department, u3.department) AS department,
       COALESCE(u1.role, u2.role, u3.role) AS role,
       'IdP' AS identity_provider,
       COALESCE(u1.locale, u2.locale, u3.locale) AS locale
FROM staging_ids u1
LEFT JOIN staging_ids u2 ON ...
LEFT JOIN staging_ids u3 ON ...
WHERE ...

Метрики и расчеты активных пользователей

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

DAU/WAU/MAU по каждому системному портфелю: дневная, недельная, месячная активность по уникальным пользователям.
Активные пользователи на систему: количество уникальных пользователей, вошедших в конкретную систему за период.
Среднее время сеанса на пользователя и на систему: для оценивания качества использования приложений.
Доля неиспользуемых систем: системы с низкой активностью, которые подлежат аудитам и возможной декоммиссии.
Коэффициент перекрестной активности: доля пользователей, использующих несколько систем, что влияет на лицензионную стратегию.

Определение активности: в современных CIO-практиках активность часто определяется по входу в систему или по продолжительному сеансу. В качестве базового определения можно использовать "пользователь считался активным, если за период зафиксирован хотя бы один вход (login) или сессия продолжительностью более N минут". Величина N Минут может зависеть от характера системы (внутренние порталы - 5-10 минут; специализированные сервисы - 15-30 минут).

Примеры SQL-выражений для расчета ключевых метрик:

-- 1) DAU по системе за выбранный день
SELECT f.system_id, d.date_key, COUNT(DISTINCT f.user_id) AS dau
## FROM FactActiveUser f
JOIN DimDate d ON f.date_key = d.date_key
WHERE d.date_key = DATE '2024-12-01'
GROUP BY f.system_id, d.date_key;

-- 2) MAU по системе за месяц
SELECT f.system_id, DATE_TRUNC('month', d.date_value) AS month_key,
       COUNT(DISTINCT f.user_id) AS mau
## FROM FactActiveUser f
JOIN DimDate d ON f.date_key = d.date_key
GROUP BY f.system_id, month_key;

-- 3) Среднее активное время на сеанс по системе
SELECT f.system_id, AVG(f.active_minutes) AS avg_active_minutes
FROM FactActiveUser f
GROUP BY f.system_id;

-- 4) Доля активных пользователей среди зарегистрированных за период
## WITH reg AS (
  SELECT user_id, MIN(reg_time) AS first_reg
  FROM UserRegistration
  GROUP BY user_id
)
SELECT f.system_id, COUNT(DISTINCT f.user_id) AS active_users, COUNT(DISTINCT reg.user_id) AS registered_users,
       (COUNT(DISTINCT f.user_id) * 1.0 / NULLIF(COUNT(DISTINCT reg.user_id),0)) AS activity_rate
## FROM FactActiveUser f
JOIN DimDate d ON f.date_key = d.date_key
LEFT JOIN reg ON reg.user_id = f.user_id
WHERE d.date_value BETWEEN '2024-12-01' AND '2024-12-31'
GROUP BY f.system_id;

Расчеты должны поддерживаться на уровне представлений (views) или моделей dbt, чтобы обеспечить повторяемость и возможность ревизий. В рамках архитектуры моложно реализовать “calculation layer” на уровне ETL/ELT, где факты активностей предрасположены к агрегации и хранению в агрегированных таблицах по нескольким временным уровням, например daily, weekly и monthly.

Ключевые концепции для расчета активных пользователей

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

Интеграции источников данных и потоки данных

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

Интеграционные каналы: потоковая архитектура с использованием очередей событий (Kafka) для минимизации задержек, пакетная загрузка для больших объемов данных и исторических архивов. Эндпоинты идентификации пользователя (IdP/SIDP) должны обеспечивать единый идентификатор и маршрутизировать события в централизованный поток.
Соотношение источников и модель: соответствие между идентификаторами пользователей в разных системах и центральной DimUser-таблицей; сопоставление между системой и временными метками.
Протоколы и стандарты: SAML/OIDC для аутентификации и SCIM для синхронизации учётных записей; стандартные REST API и вебхуки для событий активности. Современная инфраструктура требует поддержки безопасности и аудитирования: шифрование транспорта, контроль доступа к данным аналитики, журналирование изменений.
Управление качеством и lineage: отслеживание источников данных, версий схемы, постоянная проверка согласованности идентификаторов и данных по системе, а также автоматическое тестирование ETL/ELT-процессов.
Этапы обработки: извлечение** - нормализация - агрегация - загрузка в DimDate/DimSystem/DimUser и факт-таблицу; обработка ошибок, повторные попытки и мониторинг загрузок.

Примеры паттернов интеграции

Потоковая передача событий входа в систему через Kafka + Spark Streaming, с последующей загрузкой в FactActiveUser и DimUser.
Пакетная загрузка журналов приложений в S3/ADLS, затем dbt-модели для формирования аналитических представлений и агрегаций.
Интеграция IdP-идентичностей: периодическое сопоставление и нормализация идентификаторов пользователей в DimUser через сопоставляющую таблицу IdentityMapping.

Применение и сценарии внедрения

Для CIO-главы ориентированность на бизнес-цели и практическая применимость. Ниже приведены ключевые сценарии внедрения и ожидаемые бизнес-выгоды:

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

Практические шаги внедрения:

Определение целевых метрик и согласование единиц измерения между бизнес-линиями и ИТ-архитекторами.
Разработка единой модели данных (DimUser, DimSystem, DimDate, FactActiveUser) и документация по соответствиям идентификаторов.
Настройка источников и потоков данных, поддержка CDC и событийной передачи, обеспечение устойчивости к задержкам.
Реализация представлений/моделей в ELT-процессе и создание базовых дашбордов для CIO и руководителей IT-направлений.
Нормализация и контроль качества: процедуры валидации, регламент ревизий и обновлений данных.
Обучение команд оперативной аналитики: как интерпретировать метрики, как строить сквозные сценарии для разных систем.

Пример сценария внедрения в крупной организации

Определение наборов систем в портфеле CIO и идентификация всех точек входа пользователей.
Интеграция IdP, журналов приложений и систем аудита в единый поток событий.
Разработка и внедрение DimUser/DimSystem/DimDate и FactActiveUser.
Построение первых таблиц метрик: DAU/MAU по системам за последние 3 месяца.
Выход на регулярные дашборды для CIO и системных владельцев.

Проблемы качества данных и управление данными

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

Неоднозначность идентичностей: пользователи могут иметь несколько учетных записей в разных системах, что ведет к занижению активности; необходим единый механизм Identity Mapping.
Дублирование и конфликт идентификаторов: в результате миграций или переноса пользователей могут появляться повторяющиеся записи. Требуется процесс дедупликации и складируемые уникальные ключи.
Несоответствие временных рамок: разные источники могут использовать различные временные зоны и форматы времени; необходимо унифицировать хранение дат и времени.
Проблемы качества данных: пропуски в событиях входа, некорректные атрибуты (департамент, роль), что влияет на точность метрик.
Управление изменениями и версионирование схем: эволюции данных, новые источники, изменения в структурах требуют регламента версионирования и тестирования изменений.

Для борьбы с этими проблемами применяются:

Стандартизация сущностей и атрибутов: единые регламент именования, согласованные правила сопоставления идентичностей.
Регламент контроля качества ETL/ELT: pre-checks, post-load validation, reconciliation между источниками и целевыми таблицами.
Метаданные и каталог данных: фиксированные источники, версии схем, описание полей и бизнес-значение каждого атрибута.
Встроенная мониторинг: дашборды по задержкам загрузки, пропускам, дубликатам и снижению точности метрик.
Периодические аудиты и ревизии: регулярные проверки на полноту, корректность и согласование источников.

Key takeaways

Активность пользователей должна опираться на единые идентичности, согласованные правила сопоставления и устойчивую модель данных.
Архитектура должна поддерживать как потоковую, так и пакетную обработку, обеспечивая близкую к реальному времени оперативность и устойчивость.
Модели DimUser, DimSystem, DimDate и FactActiveUser позволяют гибко агрегацию по любым временным уровням и системным контекстам.
Метрики DAU/WAU/MAU и связанные параметры должны быть четко определены и воспроизводимы; используйте ELT-подход и dbt-подходы для управления моделями.
Интеграции источников требуют строгого управления идентичностями, контроля качества и lineage; безопасность и соответствие - важная часть архитектуры.
Внедрение должно быть ориентировано на управляемость и бизнес-ценность: лицензионная оптимизация, безопасность доступа, планирование нагрузок и поддержка CIO.

FAQ

Что считается активным пользователем в контексте ИТ-систем CIO?

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

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

Основной набор включает журналы входов приложений, события из IdP/SSO (SAML/OIDC), данные аудита систем, логи сеансов и атрибуты пользователя (департамент, роль). Дополнительные данные могут включать данные об устройстве, геолокацию и метод аутентификации для более точной сегментации. Важна консолидация идентичностей и согласование временных меток.

Как выбрать подход к моделированию данных: звездная схема или снежинка?**

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

Как определить границы времени для расчета метрик?

Рекомендуется использовать стандартные горизонты: DAU (за текущий день), WAU (за текущую неделю) и MAU (за текущий месяц). При необходимости можно добавлять субпериоды: дневные cut-off, недельные квантили, календарные праздники и периоды отпусков. Важна единая настройка временной размерности и согласование с бизнес-потребностями.

Как обеспечить точность и воспроизводимость расчетов?

Воспроизводимость достигается через централизованные ETL/ELT-процессы, версионирование моделей (dbt/аналогичные инструменты), использование единых тестов качества и регламентов ревизий. Каждой расчётной операции должен соответствовать источник, версия и временная метка. Документация значений и бизнес-правил должна быть доступна заинтересованным сторонам.

Какие методы обработки идентичностей можно применить?

Основной подход - Identity Mapping: сопоставление пользователей из разных систем через единую «персону» в DimUser. В процессе могут применяться сопоставления по email, имени пользователя, идентификаторам IdP или аудиту. В рамках регламентов рекомендуется хранить историю изменений идентичности и обрабатывать конфликты через бизнес-правила.

Какие риски и как их минимизировать?

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

Как построить управляемые дашборды для CIO?

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

Какие подходы к безопасности и соответствию применяются?

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

Какие требования к обучению команд при внедрении?

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

← Предыдущая статья

Управление поставщиками анализ данных - анализ эффективности сотрудничества с поставщиков ИТ услуг

Следующая статья →

Пользовательская аналитика ИТ-систем: анализ частоты использования информационных систем