У меня был проект с дистрибьютором, где менеджер каждое утро открывал Авито, проходил 5 категорий в 3 городах и руками сводил цены в таблицу. На это уходило 2-3 часа в день, то есть 40-60 часов в месяц. При внутренней ставке 1 500-2 000 ₽/час компания сжигала 60 000-120 000 ₽ еще до первой строчки кода.
Я видел это десятки раз: все боятся «дорогой автоматизации», хотя уже давно платят за нее временем команды, ошибками в Excel и запоздалыми решениями. Если мониторинг повторяется, вопрос уже не в парсере. Вопрос в том, почему вы до сих пор делаете это вручную.
Ручной сбор ломается не на тысячах карточек, а сильно раньше
Если вам надо один раз посмотреть 30-50 объявлений, я бы не стал ничего автоматизировать. Мы так и советовали компании из сервисного бизнеса: задача была разовая, выборка маленькая, руками закрыли быстрее и дешевле.
Когда проверка идет хотя бы 3 раза в неделю, а данные влияют на цену, закупку или выбор региона, ручной режим начинает искажать картину. Сотрудник может честно сидеть 2 часа в день и все равно не увидеть снятые карточки, новые объявления и изменения цены внутри дня.
Вот простой тест, после которого я уже смотрю в сторону MVP:
- в одном цикле больше 200 карточек
- обновления нужны регулярно, а не раз в квартал
- ручная проверка съедает больше 40 часов в месяц
- по этим данным вы реально меняете цены или ассортимент
Если совпали хотя бы три пункта, автоматизацию уже надо считать на 1-2 недели. Героизм менеджера здесь обычно выходит дороже.
Главная ошибка - тащить все поля подряд
Тут я сам ошибался. Несколько лет назад мы собирали почти все: заголовки, описания, фото, даты, продавцов, служебные признаки. Выгрузка выглядела солидно, а пользы в ней было мало. Бизнесу не нужен архив сайта, бизнесу нужны ответы.
Смотрите: перед стартом надо фиксировать не поля, а решение. Что вы поменяете через неделю на основе этих данных - цену, регион, закупку, список конкурентов? После этого набор данных обычно резко худеет.
Для одной команды по вторичному рынку техники хватило всего 4 метрик:
- медианная цена
- число новых объявлений за неделю
- доля объявлений с доставкой
- распределение по регионам
Мы урезали сбор примерно на 70%, и отчет из мертвой витрины превратился в рабочий инструмент.
До / после
| Было | Стало |
|---|---|
| Собирали десятки полей | Оставили 4 метрики |
| Хранили фото и описания | Считали только то, что влияет на решения |
| Таблицу почти не открывали | Отчет начали смотреть каждую неделю |
| Аналитика жила сама по себе | Цены пересобрали за 6 недель |
Если данные нельзя перепроверить и воспроизвести через неделю, это уже не аналитика, а разовая выгрузка.
Рабочий парсер - это не скрипт на вечер, а цепочка с контролем
Первая версия почти всегда выглядит бодро. Сегодня скрипт собрал 500 объявлений, все довольны. Через неделю верстка изменилась, часть карточек пропала, и у вас уже минус 25-30% выборки без явной ошибки на экране.
Поэтому я не люблю разговоры в стиле «давайте быстро напишем парсер». Для регулярной аналитики нужна цепочка: сбор, ретраи, дедупликация по ID и URL, очистка, загрузка в PostgreSQL 16, проверка полноты и алерты. Если нужен браузер, мы обычно берем Python 3.12 + Playwright 1.50. Если хватает HTML, Scrapy 2.11 почти всегда дешевле в поддержке.
| Инструмент | Когда беру | Где ограничение |
|---|---|---|
| Scrapy | массовый обход HTML, быстрый старт | плохо там, где критичный контент грузится через JavaScript |
| Playwright | сложная отрисовка, действия как в браузере | тяжелее по ресурсам, медленнее в 3-5 раз |
| Гибрид | листинги на Scrapy, сложные карточки на Playwright | дольше запускать, но ниже стоимость поддержки |
Нормальная система показывает, сколько карточек пришло, сколько потерялось и где началась проблема. Все остальное - лотерея с красивой выгрузкой.
Дешевый старт иногда выходит дороже нормальной разработки
У нас был неудачный кейс с облачным парсером. Компания хотела быстро мониторить конкурентов, взяла готовый сервис, получила аккуратные CSV и решила, что задача закрыта. Через несколько недель выяснилось, что сервис не держит нужную частоту обновлений, часть карточек выпадала, а истории изменения цены не было вообще.
Команда смотрела на среднюю цену по рынку, где половина объявлений уже была снята. Потом мы почти 3 недели потратили не на разработку, а на разбор того, в какой момент данные начали врать. Я бы как раз это и называл дорогим эффектом дешевого входа.
Когда хватит готового сервиса?
Когда вы проверяете гипотезу на 1-2 недели и вам не нужна история изменений.
Когда лучше делать свое?
Когда объем уже идет к 10 000+ объявлений, есть разные расписания обновления и данные потом уходят в BI, алерты или ценовые решения.
Начинать надо с витрины, а не с парсинга
Я бы не запускал сбор, пока не понимаю, кто и как будет смотреть результат. Самый частый провал здесь простой: данные собираются исправно, а витрины нет. В итоге команда живет в CSV, разработка продолжается, пользы почти ноль.
Для старта обычно хватает простого контура: сборщик, очередь задач, PostgreSQL 16, проверка качества и витрина в Metabase. Этого достаточно, чтобы увидеть пользу за 2-3 недели и не тащить в проект лишнюю инфраструктуру.
Если завтра вам дадут идеальный слепок Авито, какой один управленческий шаг вы сделаете в тот же день - измените цену, отключите регион или пересмотрите закупку? Если ответа нет, проблема вообще не в парсере.
