Восемь дней без алерта: как ручной разбор конверсии превратился в ИИ-агента

В партнёрском отчёте доля выданных займов среди одобренных сползла примерно с 80 до 77 %. Текущая неделя выглядела ещё хуже — меньше 75 %. Мы начали разбирать падение и довольно быстро нашли убедительное объяснение: в органическом трафике такого сдвига не было, а несколько партнёров стали приводить клиентов, которые получали одобрение, но не подписывали оферту.

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

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

Сначала разбор шёл от экрана к экрану

Я бэкенд-разработчик в финтехе. Наша воронка начинается с регистрации и заканчивается переводом денег клиенту. Между этими точками — решение по заявке, документы, карта, оферта и несколько внешних систем. График «одобрено → выдано» показывает итог, но не говорит, на каком шаге клиент остановился.

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

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

Но технический канал мы проверили недостаточно рано. Позже в данных доставки нашлись два периода повышенных ошибок СМС подписания. Один из них длился восемь дней: доля отклонённых сообщений доходила до 13–18 % при обычных 2–4 %. Это объясняло часть июльского падения, включая сдвиг у органических клиентов в те дни. После восстановления СМС устойчивый дефицит партнёрского сегмента остался — у него действительно была другая причина.

Ручной разбор требовал всё время удерживать в голове разные определения и часы: когда событие попало в отчёт, успела ли созреть заявка, какой сегмент изменился, были ли ошибки ^[2] у конкретного типа СМС. Самая опасная остановка — получить правдоподобную версию и перестать искать вторую причину. Специализированного скилла, который вёл бы по этим проверкам, у нас тогда ещё не было.

Из последовательности проверок вырос скилл

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

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

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

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

От алерта до проверенного кейса

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

Следующий шаг — связать алерт с запуском агента. Когда метрика выходит за границу нормы, он получает шаг воронки и время изменения, проверяет свежесть данных и сначала ищет похожие случаи в графе базы знаний. Если в прошлом похожая просадка была связана с доставкой СМС, агент проверит этот канал, но не объявит его причиной без свежих данных. Затем он откроет нужные графики мониторинга, выполнит запросы, сопоставит сегменты и релизы. Если первая версия не выдержит проверки, вернётся к данным.

Результат приходит человеку как расследование с доказательствами: что изменилось, какие версии проверены, на каких графиках и числах держится вывод, что остаётся неизвестным. Человеку не приходится повторять ^[3] всю цепочку от первого запроса. Он сверяет ключевые свидетельства и оценивает точность разбора: какие выводы подтверждены, какие спорны и что агент пропустил. Если агент ошибся, поправка остаётся рядом с исходным кейсом.

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

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

Проверка на новой задаче: выдача падает в двух продуктах

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

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

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

До релиза заметную долю среди получивших СМС составляли аккаунты с повторяющимся изображением документа, пустым кадром или без фото. Некоторые из этих аккаунтов очень часто доходили до выдачи. Новая проверка резко сократила их присутствие в когорте. Доля клиентов с такими документами упала примерно с 22 до 6 %.

Общая доля выдачи в нашем пересчёте снизилась примерно с 66 до 62 %. А у клиентов со своим фото осталась около 65 % и до, и после релиза. Изменение общей метрики объяснялось прежде всего тем, кто перестал попадать в выборку, а не отказом виртуальной карты у оставшихся клиентов.

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

Исходный Tableau показывал более сильное падение, чем наш пересчёт, а точного определения его шага у нас нет. Часть чисел по второму продукту позднее не удалось запросить повторно. Поэтому в отчёте остались и выводы, и вопросы, на которые пока нельзя ответить уверенно.

Что мы построили из одного ручного разбора

Июльский разбор оставил неприятное чувство: нужные данные об ошибках СМС были, но мы добрались до них слишком поздно. Проверки держались в голове, и убедительная версия про партнёров на время остановила поиск. Я перенёс этот опыт ^[4] в скилл: агент проверяет свежесть метрики, разделяет сегменты, ищет технические сбои и требует доказательств для каждой версии.

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

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