- «Нам нужен парсер сайтов. Хотим каждый день смотреть цены конкурентов».
- «Сколько людей сейчас делают это руками?»
- «Двое. И почти день в неделю уходит только на таблицы».
Я не раз видел, как бизнес приходил за «парсером», а уходил с другой схемой: где-то хватало API, где-то - выгрузки раз в неделю, где-то - своего сервиса. Смысл читать дальше простой: парсинг - это не про сбор всего подряд, а про конкретное решение, которое вы примете завтра по цифрам.
Парсинг начинается с решения, а не с сайта
Что такое парсинг в бизнесовом смысле? Это способ регулярно забирать данные со страниц, если сайт не дает нормальный API или экспорт. Но почти никогда не нужны все данные страницы. Обычно хватает 3-7 полей: цена, наличие, дата публикации, рейтинг, регион, контакт, иногда SKU.
Главная ошибка - сначала собрать максимум, а потом пытаться придумать, что с этим делать. На практике половина полей лежит мертвым грузом, а поддержка сбора уже требует времени и денег.
У нас был проект для интернет-магазина мебели на Laravel 11 + PostgreSQL 16. Менеджер вручную отслеживал 40 конкурентов и тратил 12-15 часов в неделю на таблицы. Мы оставили только SKU, цену, наличие и дату обновления, а данные вывели в Metabase. Ручная работа сократилась до 30-40 минут в неделю, и этого уже хватало, чтобы видеть просадки по марже.
Пользу дает не сбор сам по себе, а момент, когда очищенные данные попали в ценообразование, отчет или CRM.
Какой вопрос я задаю на старте?
Какое решение вы примете, если завтра увидите эти цифры. Если ответа нет, проект почти всегда откладываем. Иначе автоматизируется сбор, а не управление.
Деньги появляются в трех сценариях
Самый частый сценарий - мониторинг конкурентов. Если вы видите изменение цены или наличие раньше, чем это заметит менеджер вручную, вы быстрее меняете свою цену, закупку или акцию. Для ритейла этого часто достаточно, чтобы окупить разработку.
Второй сценарий - лиды и поиск объектов: тендеры, карточки компаний, поставщики, объявления, вакансии. Когда источников много, а данные устаревают за день-два, ручной процесс начинает проигрывать уже не только по времени, но и по качеству.
Третий сценарий - когда парсинг становится частью продукта. У proptech-сервиса под NDA мы собирали объявления с нескольких площадок и считали медианную цену по районам. Запрос звучал как «нужен парсер Авито», но бизнесу нужен был не инструмент, а ответы: где рынок сдвинулся, сколько новых объектов вышло за сутки, в каких районах растет предложение.
До / после по этому проекту
- До: 2 аналитика, обновление раз в 3-4 дня, пропуски по районам
- После: сбор каждые 24 часа, единая сводка, контроль дублей
- Эффект: свежие объекты находили раньше, ручной труд упал почти на 70%
Бесплатный парсер хорош для проверки, облачный парсер - до первого усложнения
Я нормально отношусь к no-code инструментам. Бесплатный парсер полезен, когда надо быстро проверить гипотезу: один источник, простая верстка, разовый сбор. За вечер можно понять, есть ли сигнал в данных или это пустая трата времени.
Облачный парсер удобен, когда нужен быстрый старт: расписание, выгрузка через API, иногда прокси уже в тарифе. Но потолок приходит быстро - JavaScript, смена HTML, блокировки, неполные карточки, странные дубли.
Мы это проходили на e-commerce проекте. На пилоте подключили 8 сайтов через no-code сервис, и первые недели все выглядело нормально. Через 6 недель три источника начали отдавать неполные данные, еще два стали резать запросы. Перешли на свою логику: Playwright для тяжелых страниц, requests + BeautifulSoup для простых, Redis для очередей и проверку обязательных полей. Качество выросло с ~68% до 95%+.
Был и обратный случай, где мы сами ошиблись. Для одного B2B-каталога начали с безголового браузера (headless) «с запасом», хотя сайт спокойно отдавал нужные данные из внутреннего JSON. Потратили лишние 2 недели и почти 180 000 ₽ на то, что можно было сделать проще. С тех пор сначала ищем самый короткий путь к данным, а потом уже строим тяжелую схему.
Под капотом это уже маленькая система
На простом сайте все выглядит невинно: открыть страницу, вытащить поле, сохранить результат. В работе все сложнее. Данные часто приезжают через JavaScript, часть уходит во внутренние запросы, а сайт следит за частотой, отпечатком браузера и шаблоном поведения.
Поэтому рабочий парсер - это очередь задач, прокси, повторы запросов, логирование, дедупликация и мониторинг изменений верстки. Вопрос не в том, сломается ли сбор, а в том, кто и как быстро это заметит.
| Инструмент | Когда берем | Что ограничивает |
|---|---|---|
| requests + BeautifulSoup | Простые страницы без JS | ломается при динамической загрузке |
| Playwright | Сложные JS-сайты | дороже по ресурсам |
| Selenium | Легаси-сценарии | медленнее и тяжелее в поддержке |
page = load(url)
price = extract(page, "div.price")
save({"url": url, "price": price})
Если страница серверная, можно проходить тысячи страниц в час. Если нужен браузерный рендеринг, скорость падает в разы, и стоимость поддержки растет вместе с ней.
Самый выгодный старт - узкий MVP
Мы предпочитаем начинать с 1-2 источников и 5-10 полей. Этого хватает, чтобы проверить окупаемость, понять реальную грязь в данных и увидеть, кто в компании вообще будет на них смотреть. Старт с 20 источников и 50 полей почти всегда выглядит амбициозно только на первой встрече.
Когда парсер правда нужен?
Когда данные меняются регулярно, их много, и сотрудник тратит на одинаковый сбор хотя бы 10+ часов в месяц. Если задача возникает раз в квартал и там 200 строк, ручной процесс часто дешевле и надежнее.
Часть задач по парсингу действительно лучше не брать в работу. Перед стартом попросите команду показать не демо сбора, а первый отчет, по которому вы реально поменяете действие в бизнесе. Если такого отчета нет, код вам пока не нужен.
