Разбор конкурента по открытым источникам: что видно снаружи

Сбор сведён к одной команде

Скрипт 01-recon.sh принимает на вход домен и за один заход проходит WHOIS, DNS, разбор сертификата, историческую выборку из прозрачности сертификатов, HEAD-запрос, публичные сканы, пассивный DNS и веб-архив. Каждый шаг ложится отдельным файлом в рабочую папку — это артефакт, к которому можно вернуться, приложить к выводу и сравнить с повторным прогоном того же домена через месяц. Разбор, существующий только в терминале аналитика, — не разбор.

Запрос к самой странице — отдельный шаг, намеренно

Первый скрипт вообще не обращается к сайту: WHOIS, DNS, сертификаты и архивы отвечают со стороны. Запрос к самой странице — единственный шаг, который оставляет след в чужой аналитике, поэтому он живёт в отдельном файле 02-live-click.sh и запускается осознанно, а не по умолчанию. Снимается с него ровно то, ради чего разбор и затевался:

• оффер и цена на дату разбора — то, с чем реально сравнивается ваше предложение
• формы захвата: сколько полей, что обязательно, что обещают после отправки
• внешние сервисы, которые грузит страница: аналитика, чат, приём платежей, CDN
• Set-Cookie и заголовки ответа — по ним движок опознаётся точнее, чем по содержимому страницы

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

Набор технологий опознаётся по отпечаткам, а не по надписям в подвале

Сайт нигде не сообщает, на чём он собран. Но каждая платформа оставляет отпечаток, и он устойчивее любой надписи на странице. Справочник tracker-signatures.md — это таблица «признак → платформа», которая пополняется на каждом разборе:

• служебный заголовок ответа, уникальный для одной платформы — самый сильный признак, опознание мгновенное
• форма имени cookie и её структура — по ней видно и движок сайта, и подключённую аналитику
• пути к статике и имена файлов сборки — по ним читается фреймворк и то, чем собран фронтенд
• набор внешних доменов, которые грузит страница: CDN, аналитика, чат, приём платежей
• имена в DNS облачного провайдера — по ним видно, где и на чём всё хостится

Собранный фронтенд говорит о продукте больше, чем витрина

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

Правила вывода — отдельный документ, а не абзац в конце

За одним сайтом стоит не один участник, а несколько независимых: хостинг, CDN, конструктор или CMS, подключённые сторонние сервисы. Каждый из них обслуживает десятки не связанных между собой клиентов. Поэтому в attribution-rules.md признаки разделены на два списка: те, что действительно что-то доказывают, и те, что встречаются у всех подряд. Вывод делается по уникальной сигнатуре, а не по общей инфраструктуре.

Ноль платных источников — это ограничение, а не экономия

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

Самый ценный результат — пойманная собственная ошибка

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

Правило, которое из этого выросло

Общие инструменты не доказывают общей команды. Формулировка попала в attribution-rules.md вместе с явным списком признаков, которые ничего не доказывают, хотя выглядят убедительно:

• anycast-адреса популярного CDN — общий пул на всех клиентов тарифа
• самый массовый регистратор и его дефолтный privacy-провайдер — это про популярность, а не про связь
• общий сторонний виджет — чат, форма, аналитика: их ставят десятки не связанных между собой компаний
• типовой шаблон лендинга и стандартный набор cookie популярного фреймворка

Итоговый алгоритм короткий: найти уникальную сигнатуру, опознать по ней платформу, подтвердить вторым независимым признаком — и только тогда что-то утверждать. Совпадение по общей инфраструктуре идёт в вывод как дополнительное свидетельство, никогда как основное.

Что осталось после трёх разборов

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