UX телеметрия в корпоративной системе: клики и ошибки без ПДн

Зачем нужна UX-телеметрия и что она решает

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

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

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

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

Важный момент: «без лишних персональных данных» означает, что вы собираете не человека, а событие. Не отправляйте в аналитику ФИО, телефон, email, ИИН, текст комментариев, содержимое полей и файлы. Вместо этого фиксируйте обезличенный контекст: идентификатор сессии, роль или тип пользователя (например, оператор, бухгалтер), экран и действие, код ошибки, длительность шага.

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

Что именно собирать: клики, ошибки, время и контекст

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

Клики и пути: где теряются пользователи

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

Часто хватает событий уровня «что хотели сделать», а не «куда попал курсор». Например: invoice_create_clicked, filter_applied, export_started.

Ошибки форм: что ломает заполнение

Для форм собирайте не то, что ввели, а факт ошибки и ее тип. В событии обычно достаточно хранить имя поля, вид ошибки (пусто, неверный формат, слишком длинно), шаг, на котором она появилась, и сколько раз повторилась до успешной отправки.

Пример: сотрудник заполняет заявку в сервис-деск. Телеметрия показывает, что поле «ИНН/БИН» дает ошибки формата в 40% попыток, а люди по 3-4 раза исправляют ввод. Это сигнал: подсказка неясная, маска ввода отсутствует или правило проверки слишком строгое.

Время операций: ожидание, завершение, таймаут

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

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

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

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

Как не собрать лишнее: принципы приватности и безопасности

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

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

Персональные идентификаторы лучше заменить псевдонимами и агрегатами. Вместо ФИО, логина, табельного номера или e-mail используйте случайный технический идентификатор с коротким сроком жизни, либо собирайте метрики на уровне группы (например, «роль: оператор/руководитель», «подразделение: да/нет», без названий). Это помогает находить проблемные сценарии, но не дает «следить» за пользователем.

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

Практика, которая обычно закрывает большую часть рисков: запрет на любые «свободные строки» (только справочники и коды), маскирование технических параметров, которые могут содержать ПДн (например, URL с query, заголовки, исключения), разделение доступа (инженеры видят сырые события ограниченное время, продукт и UX работают с агрегатами), а также сроки хранения с автоматическим удалением.

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

Проектируем события: простая модель данных для UX

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

Минимальная схема события

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

Обычно хватает такого набора:

• event_name (например, form_submit, field_error, operation_start, operation_end)
• screen_id (идентификатор экрана: request_create, profile_edit)
• action_id (что сделали: click_save, open_modal, select_tab)
• session_id (случайный идентификатор сессии с ограниченным сроком жизни)
• ts и timezone (время события)

Параметры держите в одинаковых единицах: длительности в duration_ms, количества в count, размеры в bytes. Для кликов вместо координат по пикселям лучше фиксировать смысл: target (например, btn_save) и position (например, header, footer). Так данные переживут редизайн.

Время операций: начало, конец и шаги

Чтобы понять, где люди теряют время, важно мерить не только итоговую длительность, но и этапы. Рабочий шаблон: operation_start с operation_id, затем operation_step (например, validation_done, server_response_received), и operation_end со status (success или fail) и duration_ms.

Так видна разница между медленной загрузкой, долгим заполнением и задержкой на стороне сервера.

Ошибки форм: одинаковые категории

Ошибки лучше кодировать категориями, а не текстами. Тексты меняются и часто содержат лишнее.

Подходящие классы:

• required - не заполнено обязательное поле
• format - неверный формат (почта, ИИН, телефон)
• range - значение вне допустимых границ
• server - ошибка ответа сервера или недоступность
• conflict - конфликт данных (например, уже существует)

Для каждой ошибки добавляйте field_id, error_type и attempt (номер попытки отправки). Введенное значение поля не отправляйте.

Версионирование: когда UI меняется

Интерфейсы меняются постоянно, и без версий графики быстро «ломаются». Добавляйте хотя бы два поля: schema_version (версия формата событий) и ui_version (версия фронтенда или номер релиза). Если часть аудитории живет за фичефлагом, фиксируйте experiment или feature_flag.

Правило простое: меняете смысл параметра или его единицы - поднимаете schema_version. Переименовываете элемент интерфейса - сохраняете старый target как алиас на время перехода, чтобы не потерять тренды.

Пошагово: как внедрить телеметрию в существующую систему

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

План внедрения, который реально сделать

1. Выберите 3-5 критичных сценариев. Обычно это вход, поиск, создание заявки, согласование, выгрузка отчета. Один сценарий должен быть сквозным, от первого клика до результата.

2. Опишите события по шагам простыми словами: что пользователь сделал и к чему это привело. Хорошая проверка: по событиям можно восстановить путь без чтения текстов и без знания пользователя.

3. Добавьте сбор ошибок форм и технических сбоев. Для форм фиксируйте тип ошибки (валидация, обязательное поле, неверный формат), имя поля и момент появления. Для сбоев: код ошибки, модуль, время ответа, но без содержимого запроса.

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

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

Чтобы это не превратилось в «собрали и забыли», заранее договоритесь, кто владелец метрик и как часто команда смотрит результаты. Например, продукт-менеджер отвечает за еженедельный разбор, а техлид - за качество событий.

Перед включением в прод

Проверьте еще раз:

• события не содержат ФИО, ИИН, номера документов, комментарии и любые свободные поля
• есть идентификатор сессии или устройства, но он не позволяет прямо узнать человека
• ошибки сгруппированы по типу, а не по тексту, который может включать данные
• есть простой отчет: где пользователи бросают сценарий и сколько времени занимает операция

Пример: в форме «Создать заявку на обслуживание» вы фиксируете шаги (открытие, заполнение, отправка), ошибки по полям и время до успешной отправки. Через неделю видно, что 40% ошибок на одном поле и среднее время выросло после изменения подсказки. Это повод вернуть подсказку и упростить правило валидации.

Как превращать события в понятные отчеты для команды

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

Начните с 2-3 дашбордов, каждый под один вопрос. Например: «Где чаще всего бросают процесс оформления заявки?» или «Какие поля в форме дают больше всего ошибок?». Для каждого вопроса заранее договоритесь, кто читает отчет и какое действие сделает по итогам.

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

Со временем часто ошибаются: среднее «съедают» редкие, но очень длинные сессии. Медиана показывает типичный путь, а 95-й процентиль подсвечивает, где часть людей мучается дольше обычного. Если p95 резко вырос после релиза, это похоже на регресс.

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

Типичные ошибки и ловушки при сборе UX-телеметрии

Телеметрия часто проваливается не из-за инструмента, а из-за мелких решений в начале. Потом они превращаются в шум, риски по приватности и отчеты, которые никто не использует.

Ошибки при сборе данных

Самая частая проблема - «соберем все, а потом разберемся». Без цели и владельца метрик события растут как сорняки: один экран шлет 30 событий на клик, другой - ничего. Через месяц никто не помнит, зачем это было нужно.

Еще опаснее, когда в события попадает содержимое полей. Даже если вы не планировали собирать ПДн, в комментариях и «сообщениях об ошибке» пользователи могут написать ФИО, телефон или ИИН. В результате телеметрия становится хранилищем чувствительных данных.

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

Наконец, таймеры. Команды нередко считают «время операции» от клика до ответа сервера и называют это скоростью работы пользователя. Но это в основном сеть и бэкенд. Для UX полезнее разделять: время ожидания, время ввода, время исправления ошибок.

Короткий список того, что чаще всего портит сбор:

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

Ошибки интерпретации и управления

Даже хорошие данные бесполезны, если они не превращаются в решения. Типичный сценарий: отчет показывает, что на шаге 3 люди часто возвращаются назад, но задачи в бэклог не появляются.

Чаще всего мешает простое:

• отчеты ради отчетов: нет правила, кто и как принимает решения по метрикам
• нет порогов: непонятно, что считать проблемой (например, 5% или 25% ошибок)
• нет проверки после фикса: улучшили форму, но не измерили, стало ли лучше

Пример: в форме заявки растет число ошибок «неверный формат», но в телеметрии нет контекста (какое поле, какой тип ввода, на каком шаге). В итоге команда спорит. Если же событие хранит только ключ поля и код ошибки (без значения), становится ясно, где проблема, и задача формулируется за 10 минут.

Короткий чеклист перед запуском и после релиза

Перед запуском

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

Проверьте перед стартом:

• выбраны 3 ключевых сценария и метрики успеха (доля завершений, время, частота ошибок форм)
• каталог событий описан и согласован: названия, параметры, версия схемы, кто владелец
• в событиях нет ввода пользователя и содержимого документов: ни текста полей, ни комментариев, ни фрагментов файлов
• сессии псевдонимные, а отчеты доступны в разрезе ролей или отделов, без привязки к людям
• заданы сроки хранения, права доступа и журналирование действий с данными

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

После релиза

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

Проверьте в первые 1-2 недели:

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

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

Пример: улучшение формы заявки на основе кликов и ошибок

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

Что видно в событиях, если собирать их аккуратно и без лишних персональных данных:

• шаг формы (например, 1 из 3) и идентификатор экрана
• поле, где возникла ошибка (только ключ поля, без введенного значения)
• тип ошибки (пусто, неверный формат, не прошло проверку)
• время на шаге и время ожидания ответа сервера
• действие перед уходом (клик по «Назад», закрытие, повторная отправка)

На дашборде это обычно выглядит как воронка: открыли форму -> заполнили шаг 1 -> шаг 2 -> отправили. Допустим, видно, что 40% пользователей отпадают на шаге 2, а среди оставшихся 70% получают ошибку в поле ИИН/БИН или «Номер договора». При этом тип ошибки часто один и тот же: format_invalid, а медианное время на шаге растет до 90 секунд из-за повторных попыток.

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

Изменение небольшое, но точечное: добавить подсказку рядом с полем, включить маску ввода (чтобы пробелы и разделители обрабатывались автоматически) и заменить сообщение об ошибке на конкретное («Введите 12 цифр без букв»). Если есть серверная проверка, оставить ее, но сделать клиентскую проверку раньше, чтобы человек не ждал лишние 2-3 секунды на каждую попытку.

Проверка должна быть такой же конкретной, как и проблема: сравнить конверсию воронки до и после (особенно шаг 2 -> отправка), долю ошибок по этому полю и типу ошибки, p95 времени до отправки (не только среднее), а также убедиться, что не выросли повторные отправки и обращения в поддержку.

Если после релиза p95 по времени снизился, а отвал на шаге 2 заметно упал, значит изменение реально помогло. И это можно доказать цифрами, не собирая содержимое полей и не превращая аналитику в сбор ПДн.

Следующие шаги: пилот, цикл улучшений и помощь с внедрением

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

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

Минимальный план пилота на 2-4 недели

Соберите команду из продукта, UX и разработки и договоритесь о базовом наборе шагов:

• описать цель и метрику (например, снизить долю ошибок формы на 20% или сократить время операции на 15%)
• утвердить политику данных: без ФИО, текста полей и содержимого документов, только технические события и контекст
• разметить ключевые события в одном процессе и добавить пару контрольных точек времени (старт, успешное завершение, отмена)
• настроить дашборд или простой отчет и определить владельца, который раз в неделю подводит итоги
• запланировать одно небольшое улучшение интерфейса и критерий, по которому вы поймете, что стало лучше

Дальше работает регулярный цикл: находите аномалии, формулируете гипотезу (что мешает), делаете правку и проверяете ее по тем же метрикам.

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

Инфраструктура и безопасность без сюрпризов

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

Если вы внедряете телеметрию в рамках более широкого обновления ИТ-инфраструктуры (рабочие места, серверы, контуры эксплуатации), системная интеграция может упростить проект. Например, GSE.kz как производитель и системный интегратор в Казахстане помогает спроектировать безопасный контур сбора событий и подобрать инфраструктуру под корпоративную нагрузку с учетом дальнейшей поддержки и сопровождения.