На 4-й день после релиза у нас был дашборд цен конкурентов, который выглядел образцово: сборщик на Python 3.12 работал по расписанию, Celery не шумел, алертов не было. Проблема сидела в данных: после редизайна источник начал отдавать промо-цену вместо базовой, и команда четыре дня принимала решения по искаженной картине. С тех пор я смотрю на scraping как на отдельный продукт, у которого есть экономика, право, поддержка и цена ошибки.
Если вы хотите собирать цены, остатки, объявления или отзывы, вопрос уже не в том, можно ли написать scraper. Для бизнеса важнее другое: окупится ли он, выдержит ли поддержку и не создаст ли проблем через 3 месяца, когда источник поменяет верстку или включит защиту.
Сначала ищут не код, а официальный путь к данным
Парсинг нужен не везде, где данные видны глазами. На практике я почти всегда начинаю с попытки обойтись без него: API, XML-выгрузка, партнерский feed, доступ по расписанию. Это менее эффектно, чем свой сборщик, но для бизнеса почти всегда дешевле.
У нас был e-commerce проект с 12 000 SKU и мониторингом 40 конкурентов. До автоматизации аналитик тратил около 20 часов в неделю на ручную сверку. Мы нашли официальный доступ у части источников, а кастомный scraping оставили только там, где выбора не было. После запуска ручная работа сократилась до 2 часов в неделю.
Частая ошибка - идти по сценарию «соберем все со всех». Рабочий подход другой: сначала проверить, какие источники действительно влияют на деньги. В одном B2B-кейсе 70% пользы дали всего 3 площадки. Остальное хорошо смотрелось в презентации, но почти не влияло на решения.
Юридический риск начинается не в коде, а в том, что вы делаете потом
Сам по себе scraping публичных страниц не делает проект серым. Риск меняется в тот момент, когда бизнес начинает собирать контакты, профили, фото и тянуть это в CRM. Публичная цена товара и массовый сбор телефонов частных лиц - это разные истории, хотя код может быть почти одинаковым.
Перед стартом я обычно проверяю пять вещей:
- доступны ли данные без авторизации и обхода защиты
- что написано в правилах сайта
- есть ли в выгрузке персональные данные
- какая частота запросов нужна на деле
- как именно бизнес будет использовать результат
Самый опасный участок в web scraping - не сбор, а применение данных после него.
Поэтому юриста я подключаю не в финале, а в первую неделю. Обычно это 2-3 часа работы, которые потом экономят месяцы переделок и лишние разговоры с площадками.
Дешевый старт почти всегда прячет дорогой хвост
На пилоте почти все выглядит хорошо. Бесплатный инструмент собрал пару страниц, отчет открылся, всем нравится скорость. Разница начинается через 4-6 недель, когда источник меняет верстку, включает anti-bot или переносит часть данных в JavaScript.
| Подход | Запуск | Стабильность | Поддержка |
|---|---|---|---|
| API / feed | 1-2 недели | высокая | низкая |
| Свой scraper | 3-6 недель | средняя | высокая |
| Облачный парсер | 1-3 недели | средняя/высокая | средняя |
В прошлом году один стартап сравнивал Python + Scrapy 2.11, облачный сервис и гибрид. Через 6 недель оставили схему, где официальный доступ использовали везде, где он был, а кастомный сборщик - только на сложных источниках. По данным команды, поддержка после запуска стала примерно на 60% дешевле, чем у полностью self-hosted варианта.
Если страниц много, есть JavaScript, нужна ротация прокси и обход anti-bot, облако часто выгоднее. Если источников мало и они стратегически важны, мы обычно берем свой стек: Playwright для тяжелых страниц, PostgreSQL 16 для нормализации, raw-слой в S3-совместимом хранилище.
Ломается обычно не парсер, а доверие к цифрам
Сборщик написать несложно. Намного сложнее заметить, что он уже второй день собирает не те поля и при этом выглядит здоровым. Именно в этот момент и начинаются потери.
Блок «до/после» у нас обычно выглядит так:
- до: сбой замечали через 3-4 дня, когда аналитики писали, что цифры «подозрительные»
- после: schema validation, контроль диапазона цен и алерт при completeness ниже 95%
- результат: время обнаружения сократилось до 15-30 минут
Был и неудачный кейс, где я сам недооценил масштаб поддержки. B2B-команда хотела за 2 недели собрать рынок объявлений и для пилота взяла бесплатный парсер. На 2-3 источниках все выглядело убедительно, но на 8 площадках полезли 429, 403, дубли и пропуски. Самым дорогим оказалась не техника, а ручная перепроверка выгрузок: люди перестали верить цифрам. Через месяц проект остановили, и это было разумное решение - в production такие инструменты быстро упираются в лимиты, отсутствие SLA и слабую работу с anti-bot.
Я бы начинал парсинг только после одного простого расчета: сколько стоит неделя ошибки в данных. Я когда-то недооценил этот вопрос и заплатил за это лишними релизами. Если такой цифры нет, сначала стоит посчитать цену неверного решения, а уже потом открывать IDE. По моему опыту, именно этот расчет чаще всего и решает судьбу проекта.
