Мониторинг цен через прокси и Afina

Мониторинг цен с Afina Browser, прокси и изолированными профилями для скрапинга

Мониторинг цен выглядит простым, пока его не нужно запускать каждый день по сотням товаров и регионов. Скрипт может запросить страницу. Прокси может сменить IP. Но многие ecommerce-страницы зависят от браузерного состояния: куки, local storage, языка, часового пояса, WebRTC и истории сессии.

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

Для команд с прокси-инфраструктурой вроде MangoProxy, Afina Browser закрывает браузерную часть стека: профили, отпечатки, куки, WebRTC-настройки и автоматизацию. Прокси отвечает за маршрут трафика. Afina удерживает браузерное состояние изолированным.

Почему обычных запросов недостаточно

HTTP-скрапинг полезен для статичных страниц и API. Проблемы начинаются, когда сайт меняет контент в зависимости от контекста сессии. Карточка товара может показывать разные цены после принятия куки, смены региона, входа в аккаунт, переключения валюты или просмотра нескольких страниц категории.

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

Типичные слабые места:

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

Поэтому команды переходят от простых request-скриптов к браузерным воркфлоу. Браузерный профиль дает каждому направлению мониторинга собственное состояние, а прокси дает этому направлению сетевой маршрут.

Модель профилей для скрапинга каталогов

Практичный подход — считать каждое направление мониторинга отдельным браузерным профилем. Направление может означать страну, магазин, тип аккаунта, условие цены или товарную категорию. Главное — консистентность.

Например, отдельные профили можно использовать для публичных цен в Германии, B2B-цен после входа, мобильной витрины, категорий конкурентов, checkout и локализованной выдачи.

Afina использует изолированные браузерные профили, поэтому куки, local storage и сетевые параметры не пересекаются между сессиями. Для мониторинга цен это важно: один загрязненный набор куки может изменить результат всего обхода категории. Профиль, который использовался для аккаунта A, не должен незаметно влиять на аккаунт B.

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

Как согласовать прокси, отпечаток и настройки браузера

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

В Afina можно назначить отдельный прокси на каждый профиль. Команда может использовать HTTP, HTTPS или SOCKS5. SOCKS5 с UDP полезен, когда процессу нужны QUIC, HTTP/3 или WebRTC, но только если сам прокси поддерживает UDP. В Afina также можно отключить WebRTC, когда он не нужен.

С отпечатком безопаснее не максимальная рандомизация, а правдоподобная стабильность. Afina позволяет настраивать Canvas, WebGL, Audio, Rects, часовой пояс и язык браузера. Часовой пояс и язык можно согласовать с IP прокси, и это обычно лучше, чем ручные комбинации без логики.

Базовый чеклист профиля:

• регион прокси соответствует целевому рынку
• язык браузера соответствует рынку мониторинга
• часовой пояс следует за IP прокси
• WebRTC отключен, если он не нужен процессу
• Canvas и WebGL стабильны внутри одного профиля
• куки переиспользуются только там, где это нужно бизнес-логике

Куки и состояние сессии

Многие ecommerce-сайты персонализируют цены или варианты страницы после нескольких визитов. Это не значит, что каждая задача мониторинга должна хранить куки постоянно. Это значит, что команде нужна политика.

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

Afina изолирует куки по профилям и поддерживает импорт и экспорт в JSON или TXT. Это полезно, когда рабочему процессу нужно сохранить сессию, перенести ее в выделенный профиль или сделать резервную копию перед рискованным тестом.

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

Автоматизация без одинакового поведения

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

В Afina есть визуальный RPA-конструктор: клики, переходы, ожидания, условия и группы задач. Для технических команд Afina также предоставляет локальный REST API и MCP-сервер.

Хороший дизайн автоматизации разбивает процесс на небольшие шаги:

• подготовить или выбрать профиль
• назначить корректный прокси
• открыть целевую витрину
• проверить язык, валюту и регион доставки
• собрать данные товара или категории
• сохранить скриншоты для выборочной проверки
• экспортировать результаты в пайплайн данных

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

Практический процесс для команды с прокси

Начните с вопроса к данным, а не со скрипта. Какие рынки, аккаунты, магазины, валюты и состояния страницы нужно измерять отдельно?

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

После этого назначьте прокси по направлениям. Если направление представляет конкретный рынок, прокси, часовой пояс и язык должны поддерживать этот же рынок. Для SOCKS5-процессов проверьте, нужен ли UDP и поддерживает ли его выбранный прокси. В Afina есть подробный материал про UDP через SOCKS5 и маршрутизацию QUIC для команд, которым нужен такой уровень сетевого поведения.

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

И наконец, проверяйте результат через скриншоты и ID профилей. Цена без контекста — слабое доказательство. Цена, связанная с профилем, прокси, временем, режимом куки и скриншотом, намного надежнее.

Скачать Afina Browser

Промокоды для новых пользователей:

• SALE20 — 20% скидки на все тарифы, кроме Max
• SALE30 — 30% скидки на тариф Max