Кейс / собственная инженерная система
Система сама получает поток доменов, проверяет сайты, применяет сменные fingerprint-профили, сохраняет доказательства и контакты, исключает повторы и продолжает поиск batch за batch без участия оператора.
Проблема
Если потенциального клиента определяет не ОКВЭД или готовый каталог, а конкретный технологический признак сайта, покупка очередной базы почти не помогает. Ручной сбор доменов и загрузка TXT/CSV тоже быстро становится узким местом.
Решение
Источник доменов отделён от scanner: discovery постоянно формирует кандидатов, очередь отвечает за повторы и состояние, а detector registry решает, что именно искать на сайте.
Architecture
Система не привязана к одному CRM-продукту. Меняется detector и правила confidence, а discovery, очередь, HTTP-слой, enrichment и хранение результата остаются теми же.
Получить поток доменов из внешних источников и отфильтровать нужные зоны.
Не ставить в очередь недавно проверенные сайты и не дублировать активные прогоны.
Проверить сайт, пройти допустимые redirect и получить страницу без зависания всего batch.
Применить выбранный fingerprint-профиль и сохранить не только итог, но и подтверждающие evidence.
Достать доступные контакты и контактную страницу, не превращая scanner в отдельный crawler.
Сохранить историю прогонов, confidence, признаки, ошибки и найденные компании для дальнейшей работы.
Detector profiles
Первый рабочий профиль был построен вокруг Bitrix24, но архитектурно это только один detector. Для другой задачи подключается другой набор признаков — без переписывания остального pipeline.
Ищем характерные загрузчики, JS-маркеры, публичные endpoints, cookie и другие признаки клиентских CRM-виджетов.
Профиль может собираться из HTML, путей к статике, generator/meta, характерных API и структуры ресурсов.
Можно искать не только продукт, но и класс бизнеса: интернет-магазин, calltracking, формы захвата или нужную связку сервисов.
Для узкой задачи подключается отдельный detector с набором независимых evidence и собственным порогом уверенности.
Примеры выше показывают классы поисковых профилей. Конкретный detector включается под цель поиска и должен опираться на проверяемые публичные признаки, а не на догадку по одному совпадению.
Current runtime
Текущая версия уже не требует вручную готовить список на каждый прогон: worker набирает следующую порцию доменов и продолжает работу автоматически.
Engineering
Поиск на тысячах сайтов ломается не на одной регулярке. Реальные проблемы — длинные redirect, недоступные сайты, повторные домены, read-only окружение, зависшие worker'ы и необходимость продолжить процесс после ошибки.
Результат
Оператор задаёт цель поиска, после чего система может последовательно обрабатывать bounded-партии сайтов, не возвращаясь к ручной подготовке файлов. Новый профиль поиска добавляется на уровне detector'а, а инфраструктура вокруг него уже остаётся готовой.
В кейсе намеренно нет обещаний по «конверсии базы»: полезность конкретного профиля определяется уже на реальном потоке сайтов и подтверждённых evidence.