Как проверять, не отправляет ли бот дубли уведомлений
Пример расчёта (условные цифры): если из 200 начатых диалогов 50 заканчиваются подтверждённой заявкой, доля составляет 25%. Сначала проверьте, что все события посчитаны по одному правилу. На БЕСПЛАТНОЙ КОНСУЛЬТАЦИИ можно согласовать события и проверить расчёт на вашем потоке.
Результат, который нужен по теме «дубли уведомлений»
Проблема отчёта начинается там, где повторный запрос интеграции отправляет клиенту два одинаковых сообщения. Сопоставьте определение показателя с исходными разговорами, а не только с графиком.
Событийный журнал нужен для проверки гипотезы, а не только для дашборда. Запишите, какое изменение вы ожидаете увидеть и на каком шаге. Потом проверьте исходные разговоры, подтверждающие число.
У каждого уведомления нужен ключ исходного события и статус доставки. Повтор после тайм-аута сначала проверяет журнал; если содержание изменилось, это уже новая версия сообщения, а не простой дубль.
Для поиска дублей нужен ключ исходного события и адресат. Два одинаковых текста не всегда дубль: второй может сообщать новую дату. А повтор после тайм-аута не должен становиться новым уведомлением, если содержимое и событие прежние.
Сведения берите из источника «Журнал исходящих и ключ события». Сверьте события с карточкой результата и не переносите отсутствующее событие из другого канала по предположению.
Вопрос к вам: сколько повторных событий одного диалога учитывает текущий показатель?
Лайфхак: добавьте к аномалии ссылки на несколько исходных диалогов. Причина станет видна быстрее, чем в ещё одном сводном графике.
Какие данные и решения подготовить
Опишите момент возникновения каждого события и правило его повторения. Отдельно храните начало, полезный ответ, передачу человеку и подтверждённую заявку.
Условие «содержимое изменилось после первой отправки» может изменить трактовку метрики. Оставьте эту группу отдельным разрезом до проверки первичных данных.
Сравните отчёт с карточками результата и несколькими исходными диалогами. Особенно проверьте случаи, где бот назвал вопрос закрытым, а человек вернулся вскоре с той же проблемой.
Выберите строки отчёта с необычным переходом и прочитайте исходные диалоги. Поздняя загрузка, дубль и неверный статус требуют разных исправлений.
Перед тестом назначьте владельца исходных сведений и владельца текста бота. Когда правило меняется, оба проверяют одну и ту же цепочку: что введено, что сохранилось, кто получил задачу и каким сообщением она завершилась. Дата обновления без ответственного не защищает от старого ответа.
Два способа обработать запрос
Вручную. Аналитик способен распознать неверную классификацию в исходном диалоге. Плюс - объяснение причины; риск - субъективный отбор разговоров для проверки.
Автоматический отчёт. Отчёт быстро находит шаги с аномалией и сравнивает периоды. Плюс - охват всего потока; главный риск - неверное определение события.
Используйте отчёт как указатель для редактора сценария. Не переносите вывод по нескольким разговорам на весь поток без подсчёта доли.
Как запустить сценарий по шагам
Шаг 1. Присвоить событию ключ
Укажите точный момент возникновения события и возможность повтора. Два аналитика должны получить одинаковый результат.
Шаг 2. Проверить перед отправкой
Сохраните идентификатор диалога, время и источник трафика. Отметьте, где данных нет.
Шаг 3. Сохранить результат доставки
Разделите поток по типу задачи и версии сценария, затем проверьте строки с необычным переходом.
Шаг 4. Прогнать повтор и сбой
Сравните периоды по одному правилу и укажите размер выборки. Учтите изменение трафика.
Сравните автоматический расчёт с ручным на примерах «содержимое изменилось после первой отправки». Расхождения оформите как задачи владельцу данных, а не как произвольную поправку к отчёту.
Таблица проверки результата для «дубли уведомлений»
Для этой задачи контролируйте показатель «число дублей на тысячу событий». Зафиксируйте его определение, период и источник до запуска. Дополните его временем до результата и числом случаев, которые пришлось исправлять вручную. Иначе отчёт может объявить успехом отправку сообщения, за которой не было нужного действия.
Пример расчёта (условные цифры): если из 100 обращений 20 помечены решёнными, но пять человек быстро вернулись с той же задачей, подтверждённый результат требует отдельной проверки. Это оценка для проверки процесса, а не обещание эффекта внедрения.
Не называйте рост показателя улучшением без проверки состава трафика, версии сценария и качества результата. Сохраните примеры, подтверждающие вывод.
Вопрос к вам: на сколько изменится показатель после исключения дублей за прошлый месяц?
Лайфхак: храните три проверочных случая рядом с описанием сценария. После каждого изменения прогоняйте их заново и добавляйте новый случай, если обнаружили повторяющуюся ошибку.
Что ещё связано
Сценарий опирается на качество исходных данных и понятную передачу исключений. В A3bot можно собрать маршрут вокруг вашей рабочей системы. Стоимость обсуждаем после разбора задачи.
Заметка эксперта
У задачи «дубли уведомлений» есть проверяемое завершение. Бот полезен, когда он приближает к этому завершению и не скрывает задержку или ошибку. Начните с небольшого потока, подтвердите итог в основной системе и только затем расширяйте сценарий.
Напишите, какой процесс хотите автоматизировать: A3bot