Сбор данных с сайтов: проверяемая база компаний для B2B-продаж

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

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

Какую базу компаний действительно нужно собрать

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

Это разделяет четыре разных процесса:

1. Сбор открытых сведений о компаниях создаёт записи с происхождением.
2. Проверка контрагента оценивает юридические и финансовые риски по отдельным правилам и источникам.
3. Квалификация обращения определяет, подходит ли уже обратившийся клиент; этот этап разобран в руководстве по квалификации входящих заявок.
4. Рассылка использует утверждённую базу и собственные правила контакта. Наличие адреса на странице не разрешает автоматически добавлять его в кампанию.

Минимальная рабочая запись может выглядеть так:

Исходные значения не следует перезаписывать нормализованными. Храните их рядом: company_name_raw показывает, что было на странице, а отдельное нормализованное поле помогает сопоставлять записи. Тогда ошибку правила можно исправить, не загружая источник заново.

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

Как выбрать источники и условия доступа

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

Для каждого источника зафиксируйте:

• владельца и назначение источника;
• нужные страницы или методы API;
• условия доступа и дальнейшего использования;
• ограничения частоты и объёма запросов;
• обязательные поля и формат ответа;
• способ повторного получения данных;
• дату проверки условий;
• ответственного за изменения.

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

Компактное сравнение помогает выбрать не «лучший парсер вообще», а подходящий способ для конкретного источника:

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

Как извлечь поля и сохранить происхождение

Единицей хранения должно быть наблюдение, а не только «последнее правильное значение». Для каждого найденного поля сохраняйте исходное значение, URL, дату и способ извлечения. После проверки можно добавить нормализованное значение и статус, но исходное наблюдение остаётся неизменным.

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

Минимальный маршрут извлечения:

1. Получить страницу разрешённым способом.
2. Сохранить URL, время получения и технический результат.
3. Извлечь исходное значение без смыслового дополнения.
4. Сверить его с видимым содержимым страницы.
5. Присвоить статус или отправить противоречие человеку.

Страница может содержать размеченные сведения об организации. Тип Organization в словаре schema.org описывает организацию и связанные с ней свойства. Такая разметка — возможный источник значения, а не гарантия его правильности. Сохраните извлечённое значение вместе с URL и датой, затем сопоставьте его с видимым названием, адресом страницы и контекстом. Если разметка и текст расходятся, не выбирайте победителя автоматически: присвойте записи статус conflicting.

Простой пример: в разметке указано «Гамма Сервис», а заголовок страницы говорит «Гамма Сервис — Север». Первая строка может обозначать головную компанию, вторая — филиал. Пока страница не показывает эту связь явно, система не должна превращать предположение в parent_company_id.

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

Как нормализовать компании и убрать дубли

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

Например, HTTPS://Example.Test/about и example.test/products дадут одинаковый нормализованный хост example.test, но это ещё не доказывает, что страницы описывают одну юридическую сущность. И наоборот, смена домена не означает появления новой компании.

Для решения о связи используйте несколько признаков:

• совпадение или подтверждённая смена домена;
• полное и сокращённое название;
• явная ссылка страницы на головную компанию;
• устойчивый идентификатор разрешённого источника;
• адрес подразделения, если он нужен задаче;
• дата и основание каждого вывода.

Одного похожего слова недостаточно. «Альфа Механика» и «Альфа Логистика» нельзя автоматически объединить из-за слова «Альфа». Если признаков мало, сохраните две записи и статус неподтверждённой связи.

Филиал также не следует превращать в дубликат головной компании. Храните подразделение отдельной записью, добавляйте parent_company_id только при явном основании и сохраняйте это основание. Тогда менеджер видит одну компанию верхнего уровня и её подразделения, а база не теряет адреса и страницы филиалов.

Полезно вести журнал решений о связи:

Так специалист сможет повторить решение и отменить ошибочное объединение без восстановления удалённых строк.

Как проверять и обновлять базу

Разделяйте три содержательных состояния:

• unknown — поле не найдено или данных недостаточно для вывода;
• stale — срок актуальности по правилам набора истёк, поэтому требуется новое наблюдение;
• conflicting — доступные источники дают несовместимые значения.

Техническую ошибку получения храните отдельно как retrieval_error с датой попытки, URL и доступным кодом ошибки. Ошибка HTTP, DNS или загрузки не означает, что компания закрылась. Поле company_closed нельзя заполнять на основании одной недоступной страницы.

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

Проверку удобнее строить слоями:

1. Техническая доставка. Получен ли ответ разрешённым способом.
2. Полнота происхождения. Есть ли у записи URL и дата.
3. Смысловая согласованность. Подтверждает ли страница извлечённое значение.
4. Связи. Достаточно ли оснований для объединения компании, домена и филиала.
5. Актуальность. Не истёк ли согласованный срок повторного наблюдения.

Не заменяйте дату наблюдения датой импорта в CRM: это разные события. Если данные получены 1 сентября, а загружены 5 сентября, для оценки актуальности важна первая дата, а для аудита интеграции — обе.

Учебный пример трёх компаний и смены домена

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

Для «Альфа Механики» остаются два исторических домена и два датированных наблюдения. Связь domain_successor объясняет переход, но не стирает старое происхождение. Ожидаемый результат — одна компания, а не две записи, ошибочно принятые за разные организации.

У «Бета Контура» категория остаётся неизвестной. Слово «Контур» не даёт достаточного основания назначить отрасль. Запись остаётся в базе с category_raw = null и verification_status = unknown.

Две страницы «Гамма Сервис» явно относятся к одному родителю, но описывают разные филиалы. Обе записи получают одинаковый parent_company_id; ни одна не удаляется как дубликат.

Расчёт результата:

• наблюдений в таблице: 2 по «Альфе» + 1 по «Бете» + 2 по филиалам «Гаммы» = 5;
• текущих записей о компаниях и подразделениях: 1 «Альфа» + 1 «Бета» + 2 филиала «Гаммы» = 4;
• компаний верхнего уровня: «Альфа», «Бета» и родитель двух филиалов «Гаммы» = 3;
• подразделений: 2;
• автоматически слитых записей: 0.

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

Как принять сбор и обсудить задачу

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

Для учебного набора выборка охватывает все пять наблюдений из таблицы. Проверяем:

• все 5 сочетаний source_url и observed_at;
• 2 записи филиалов и их связь с одним родителем;
• 1 неизвестную категорию, оставленную null;
• 2 исторических домена «Альфа Механики»;
• отсутствие автоматических слияний без достаточного основания.

Расчёты для этой выборки:

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

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

Switch On AI может помочь описать критерии компаний, перечень разрешённых источников и одну операцию обновления, а затем согласовать прототип ИИ-помощника, бота или обычной интеграции. Выбор зависит от поведения системы: интеграция переносит данные по заданным правилам, бот ведёт диалог, а ИИ-помощник может разбирать неоднозначные сведения в пределах утверждённого сценария. Решения о категории, связи организаций и допустимости источника остаются у ответственного специалиста заказчика.

Если собранные сведения должны поддерживать работу менеджера, посмотрите сценарий ИИ-помощника для продаж. Нужные API, права, условия источников и совместимость проверяются для конкретного проекта; статья не подтверждает готовое подключение к любому сайту или сервису.

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