Поведение пользователей во внутреннем сервисе: как найти провал процесса до переноса в backlog

Воронка просела. Что именно теперь чинить?

Понедельник, 10:15. Внутренний сервис закупок показывает, что сотрудники всё чаще возвращают заявку со стадии «Проверка». На встрече быстро появляется объяснение: форма слишком длинная, значит, нужно сделать её короче. Через час в backlog уже лежит задача «Упростить UX проверки». Она звучит разумно, но в ней пока нет ни наблюдаемого механизма, ни границы результата.

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

Поэтому первая задача аналитики поведения — не найти самый низкий столбец. Она должна ответить на более строгий вопрос: какой наблюдаемый факт связан с каким шагом процесса, какое объяснение этому противостоит и какой результат подтвердит изменение? Это особенно важно для внутренних сервисов. Их пользователь часто действует не ради собственного удовольствия, а чтобы завершить рабочую обязанность. Он может повторить попытку, написать коллеге, обойти систему через письмо или таблицу. Если смотреть только на один экран, процессный провал останется за границей дашборда.

Официальная документация Яндекс Метрики о целевом событии называет событием фиксируемое онлайн- или офлайн-действие и предлагает проверить его работу после настройки. Это полезная инженерная дисциплина: событие — след факта, а не диагноз. В GA4 событие также определено как конкретное взаимодействие или происшествие; таким происшествием может быть и техническая ошибка приложения. Ни один из этих инструментов не превращает регистрацию действия в доказательство намерения пользователя.

В этой статье мы возьмём один путь — от начала внутренней заявки до передачи на следующий шаг — и не будем делать вид, что он представляет всю организацию. Цель скромнее и полезнее: научиться остановиться перед автоматической постановкой задачи, проверить след, назвать альтернативы и выбрать одну следующую проверку. Это не замедляет backlog. Наоборот, уменьшает число красиво сформулированных доработок, которые после релиза не меняют рабочий результат.

Сначала отделите симптом от причины

Симптом — это наблюдаемое отклонение: на одном шаге выросла доля возвратов, сократилось завершение, увеличилось ожидание, стало больше повторных попыток или меньше сотрудников дошли до результата. Он отвечает на вопрос «где стоит посмотреть». Причина — условие или механизм, изменение которого действительно объясняет отклонение и даёт основание менять сервис. Она отвечает на другой вопрос: «что именно должно быть иначе, чтобы результат изменился?»

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

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

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

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

Нельзя требовать от одной метрики, чтобы она различала эти случаи самостоятельно. Её работа — сделать спор предметным: «в этой версии, на этом шаге, в этой роли мы видим вот такой след». Причина начинается там, где команда может назвать механизм, альтернативу и проверку.

Событие — это действие, параметр — его условие

Чтобы читать путь, не нужно собирать всё, что делает пользователь. Нужна небольшая, понятная модель. У шага процесса обычно есть начало, полезное действие, результат и возможный выход в исключение. Для внутренней заявки это могут быть request_opened, check_started, check_completed, check_returned и request_transferred. Названия условны. Важнее, чтобы команда одинаково понимала, какое действие произошло в реальности и что означает каждый факт.

Яндекс Метрика описывает события как действия, которым задают идентификатор; сведения рядом с событием могут передаваться в отчёт как параметры. В отчёте «Параметры событий» прямо сказано, что данные группируются по переданным параметрам. В документации GA4 о параметрах параметр определяется как дополнительный контекст взаимодействия. Это даёт простое правило для модели: событие отвечает на вопрос «что произошло», а параметр — «в каком условии это произошло».

Для первого разбора внутреннего пути обычно достаточно нескольких безопасных контекстов.

Этот список не является обязательной схемой. Он показывает способ мышления: параметр должен отвечать на заранее выбранный вопрос процесса. Если у поля нет вопроса, не нужно добавлять его «на всякий случай». Официальная документация Amplitude о выборе событий формулирует похожее ограничение: слишком мало событий оставляет вопрос без ответа, а слишком много превращает сигнал в шум. В российском контексте есть ещё одна причина не расширять телеметрию автоматически: статья 5 Закона № 152-ФЗ требует определённой цели и достаточности объёма персональных данных. Закон не даёт готовый набор продуктовых параметров, но не позволяет собирать личные сведения без связи с задачей анализа.

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

Хорошая модель переживает устный пересказ. Любой участник команды должен суметь объяснить: «check_returned отправляется только после фактического возврата; return_reason — нормализованный код, а не текст комментария; flow_version отделяет новый маршрут от старого». Если это объяснение невозможно, метрика может быть красиво нарисована, но её нельзя безопасно использовать как основание для изменения.

Проверьте след раньше, чем строить вывод

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

Начните с трёх контрольных вопросов.

1. Точка. В какой момент отправляется событие? После клика, после серверного подтверждения, после смены статуса или после фактической передачи? Для показателя завершения нужен тот момент, который соответствует результату, а не надежде на результат.
2. Единственность. Может ли один экземпляр отправить событие повторно при обновлении страницы, повторе запроса или возврате из исключения? Если да, как команда отличит повтор от нового действия?
3. Связь. По какому техническому ключу начало, возврат и завершение относятся к одному пути? Ключ не обязан быть личностью пользователя; чаще это идентификатор заявки, процесса или сессии работы.

Добавьте ещё два вопроса, если внутренний сервис включает интеграции: «когда данные считаются доставленными?» и «что происходит при повторной обработке?» Событие «передано» на клиенте не равно событию «принято» в системе-получателе. Если график отвечает на процессный вопрос, ему нужен выбранный источник истины. Иначе команда будет сравнивать пользовательский жест с фактическим результатом и называть разницу «плохой конверсией».

Здесь важна честная граница. Отсутствие события не всегда означает отсутствие действия. У сотрудника мог зависнуть браузер, отключиться сеть, сработать блокировка скрипта, не пройти асинхронная очередь или операция могла завершиться в офлайн-ветке. И наоборот, наличие события не всегда означает полезный исход. Документация Яндекс Метрики рекомендует проверить настроенную цель именно потому, что передача следа — отдельная техническая работа. Проверка не устраняет все неизвестные, но позволяет не перепутать поломку измерения с поломкой процесса.

Практический приём НТА — составить мини-таблицу из пяти–десяти экземпляров, не обещая статистической репрезентативности. Укажите момент действия, ожидаемое событие, пришедшее событие, ключ связи и фактический исход. Если строки расходятся, backlog пока получает задачу на наблюдаемость: уточнить модель, добавить контроль, исправить дедупликацию. Если они сходятся, команда получает достаточно оснований перейти к гипотезе поведения.

Это не «ручная работа вместо аналитики». Это калибровка измерения. Пока таблица не существует, показатель не отличает изменение поведения от изменения кода. После калибровки можно обсуждать доли, сегменты и динамику без магического доверия к экрану отчёта.

Сегментируйте условие, а не ищите виновника

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

Представим, что возвраты выросли с 9% до 23%. Разбивка по версии показывает, что рост начался после новой формы. Разбивка по роли показывает, что чаще возвращаются сотрудники, которым доступен сокращённый набор справочников. Это уже не готовый причинный вывод. Но появляется конкретная гипотеза: форма требует значение, которое эта роль не может выбрать. Её можно проверить воспроизведением в тестовом контуре и несколькими наблюдениями за работой. В отличие от гипотезы «пользователи не любят форму», она указывает на механизм и возможное изменение.

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

У сегмента есть и граница приватности. Даже «роль» становится рискованной, если в ней один человек, а сочетание нескольких полей позволяет легко восстановить личность. Закон № 152-ФЗ не превращает любую продуктовую аналитику в запрет, но требует соразмерности цели и объёма. Практически это означает: не включать идентифицирующие поля в общий отчёт, ограничивать доступ к техническим ключам, не показывать малые группы и не хранить свободный текст без ясной необходимости. Аналитика должна помогать исправить процесс, а не незаметно строить профиль сотрудника.

Обратите внимание и на отрицательный результат. Если после сегментации провал равномерно распределён по ролям, версиям и каналам, это не «данных недостаточно» по умолчанию. Возможно, гипотеза о конкретном условии неверна. Тогда команда должна вернуться к альтернативам: изменилась ли политика, внешний справочник, SLA, последовательность действий, доступность сервиса? Равномерный сигнал тоже сужает поле поиска, если не подгонять его под заранее выбранное объяснение.

Гипотеза должна встретиться с реальной работой

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

Сформулируйте гипотезу так, чтобы она могла оказаться ложной: «У сотрудников роли R возврат на шаге S происходит потому, что поле X требует значение из недоступного справочника; после доступа или изменения обязательности доля возвратов по коду Y уменьшится, а завершения сохранятся». Эта формула содержит условие, механизм и ожидаемый результат. У неё есть альтернатива: «Справочник доступен, но правило возврата не объяснено проверяющему» или «событие возврата отправляется до сохранения формы».

Дальше выберите минимальную проверку.

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

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

Документация Amplitude о планировании внедрения советует начинать с нескольких ценных событий и tracking plan, который связан с бизнес-результатом. Для внутреннего сервиса план стоит дополнить полями «процессный шаг», «владелец правила», «альтернативы» и «способ проверки». Тогда аналитика не живёт отдельно от требований. Она становится входом в решение: какая работа пользователя должна стать проще, какое правило должно остаться, какое исключение нельзя замести средней метрикой.

Есть ситуации, когда проверку не нужно растягивать. Если ошибка воспроизводится и нарушает критичный процесс, её можно вести как инцидент: зафиксировать технический факт, ограничить последствия и исправить. Но даже тогда полезно отделить факт от предположений о пользователях. «Сервер отвечает 500 на сохранение» — наблюдаемая причина технического дефекта. «Пользователи бросают форму из-за дизайна» — нет, пока не проверены альтернативы.

Договоритесь, что означает улучшение

Даже подтверждённая гипотеза не отвечает автоматически на вопрос «стало лучше?». Команда может убрать возврат, но одновременно увеличить время обработки или перевести сотрудников в ручной обход. Поэтому ожидаемый результат нужно связать с целевым шагом и хотя бы одним защитным показателем. Целевой показатель отвечает на вопрос, ради которого начинается изменение. Защитный показывает, какую цену нельзя незаметно заплатить.

Для примера со справочником целевой показатель — доля возвратов с кодом missing_reference у роли R в версии V2. Защитными показателями могут быть успешная передача заявки на следующий шаг, число технических ошибок сохранения и время до завершения проверки. Мы не называем заранее точный процент улучшения: его нельзя честно обещать без исходных данных, состава сегмента и проверки того, что сам след устойчив. Но команда может заранее назвать направление и границу: возвратов по этой причине должно стать меньше, а передача не должна ухудшиться.

Это различие особенно помогает в спорах. Один участник может предложить скрыть обязательное поле — и возвратов сразу станет меньше. Другой заметит, что поле нужно для последующего исполнения. Оба смотрят на один симптом, но выбирают разные последствия. Защитный показатель и владелец правила возвращают разговор к процессу: можно ли перенести получение данных раньше, дать доступ к справочнику или сделать условие обязательным только для части маршрутов? Форма остаётся средством, а не самостоятельной целью.

Минимальный план проверки после изменения выглядит так:

1. Зафиксируйте период и сегмент до релиза. Не смешивайте новую форму со старой, новую роль со всеми сотрудниками и праздничный день с обычной неделей.
2. Повторите тот же пользовательский путь и убедитесь, что события по-прежнему означают то же действие. Изменение интерфейса часто меняет и момент отправки события.
3. Сравните целевой и защитный показатели, а также несколько фактических экземпляров. График без строк процесса не показывает новый обход.
4. Спросите владельца правила, остался ли результат процесса допустимым. Метрика не может одна подтвердить, что контроль, качество или ответственность не потеряны.
5. Зафиксируйте вывод с ограничением: что улучшилось в выбранном условии, что не измерялось и когда нужно пересмотреть решение.

У такого порядка есть альтернатива: быстрый A/B-эксперимент. Он полезен, когда можно безопасно разделить пользователей или экземпляры и когда организация заранее знает, какое изменение сравнивает. Но эксперимент не заменяет модель процесса. Если группа B не имеет доступа к нужному справочнику, а группа A имеет, сравнение измеряет не только интерфейс. Сначала нужно понять различие условий, затем выбирать метод проверки.

Внутренний сервис нередко меняется из-за нормативного правила, интеграции или аварии; тогда выборка не будет идеальной. Это не повод отказаться от измерения. Просто вывод становится условным: «после изменения в роли R на версии V2 возвраты по коду Y снизились, при этом мы не отделили влияние нового регламента». Такая честная формулировка ценнее, чем универсальный вывод об удобстве продукта. Она подсказывает следующий шаг — расширить проверку, уточнить сегмент или остановиться, если решение уже достаточно безопасно.

В backlog передаётся проверяемое изменение

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

Такая карточка оставляет пространство для инженерного решения, но не размывает причину. Её можно проверить после релиза тем же маршрутом данных. Если результат не изменился, это не повод переписать историю задним числом. Нужно сравнить: гипотеза была неверна, изменение не дошло до нужного условия, показатель измеряет не тот результат или появился новый фактор. Именно так backlog становится системой обучения, а не списком пожеланий.

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

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

Карта наблюдения для одного проблемного пути

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

Карта сознательно не содержит колонку «пользователь плохой». Её цель — выбрать условие, которое организация может проверить и изменить. Не все ответы будут в событиях. Иногда окажется, что нужно пересмотреть шаблон данных, дать доступ, убрать дублирующую проверку или обучить проверяющего одному правилу. Иногда — что аналитика не покрывает решающий офлайн-шаг. Все эти ответы полезнее, чем ещё одна общая задача на UX.

Тест понедельником

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

Если после этой проверки команда может написать изменение в форме «в условии X меняем Y, владелец Z подтвердит результат W», backlog получил полезную задачу. Если нет, следующая работа — не придумывать улучшение, а восстановить наблюдаемость или продолжить исследование. Это нормальный и часто самый экономный результат аналитики поведения.

Важное уведомление

Материал носит информационный характер и не является индивидуальной консультацией, проектной документацией, инструкцией по внедрению или гарантией результата. Применимость описанных подходов зависит от процессов, систем, данных, требований безопасности и иных условий конкретной организации. Перед внедрением или изменением ИТ‑систем необходимо самостоятельно оценить риски и привлечь профильных специалистов.