ТЗ на мониторинг конкурентов: события, источники и проверка сигналов

Определите решение, которому нужен сигнал

ТЗ на мониторинг конкурентов начинается с действия сотрудника. Отчёт о тысяче изменений бесполезен, если никто не знает, что делать с каждым из них. Компания может следить за новым предложением, условиями доставки, ассортиментом или выходом в регион. У этих задач разные источники, интервалы и критерии существенности.

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

Создайте реестр наблюдаемых объектов

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

Определите устойчивую связь объекта с источником. Переименование страницы не всегда означает новый продукт, а прежний URL может начать вести к другому предложению. Храните идентификатор объекта отдельно от адреса и предусмотрите ручное подтверждение спорного сопоставления.

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

Согласуйте получение и ограничения

Для каждого источника зафиксируйте разрешённый способ доступа: официальный API, предоставленная выгрузка, публичная страница или ручное наблюдение. Протокол robots.txt регулирует поведение автоматизированного обхода, но RFC 9309 не рассматривает его как авторизацию доступа. Отсутствие запрета не отменяет условий самого источника.

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

Google Alerts может быть полезен для обнаружения новых упоминаний по запросам. Однако уведомление о найденном материале не заменяет точный снимок состояния всех наблюдаемых предложений. Выбирайте инструмент по задаче и не обещайте полноту, которую источник не подтверждает.

Опишите существенное изменение

Сырые различия HTML не равны бизнес-событию. На странице меняются порядок блоков, время, рекомендации и рекламные элементы. Требование должно объяснять, какое значение извлекается, как нормализуется и какое изменение заслуживает внимания.

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

Учебное правило: сообщать об изменении включённого объёма только после успешного чтения поля и сопоставления версии предложения; повтор того же наблюдения объединять с существующим сигналом. Число подтверждений и интервал команда выбирает по риску пропустить короткое изменение и риску ложной тревоги.

Сохраняйте доказательства и неопределённость

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

Статус получения храните отдельно от бизнес-значения. «Не удалось загрузить» не означает «товара нет»; «поле не найдено» не означает «цена равна нулю». Сохраняйте последнее успешное наблюдение с его датой и показывайте устаревание. Это предотвращает ложные графики резких падений при технических сбоях.

Настройте полезную доставку сигналов

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

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

Постройте контрольную выборку

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

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

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

Передайте мониторинг владельцу процесса

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

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