Описание заказа
1. Цели проекта:
· Мониторинг собственных товаров: Контроль конечной покупательской цены в различных регионах
· Анализ конкурентов: Отслеживание ценовой стратегии конкурентов в каждом регионе
2. Собираемые данные (по каждой карточке товара для каждого ПВЗ):
· Обязательные данные:
1. Артикул товара (Ozon, статичный, основной идентификатор).
2. Название товара.
3. Идентификатор ПВЗ и его адрес (город/регион).
4. Цена по ozon карте (основной показатель).
5. Цена для покупателя.
6. Размер и процент скидки (если есть).
7. Участие в акциях (название/тип акции, например, "Скидка по карте", "Ударная распродажа").
8. Количество начисляемых баллов
9. Срок доставки до выбранного ПВЗ (в днях).
10. Наличие на складе (в наличии/под заказ/отсутствует).
11. Дата и время парсинга.
· Дополнительно:
· Поле для отметки об ошибках (с описанием ошибки, например, "Товар не найден", "Данные по региону недоступны", "Ошибка 403").
3. Входные данные и масштаб:
· Источник товаров: Регулируемый список артикулов Ozon (SKU). Список должен храниться в отдельной таблице и легко редактироваться.
· География: 20 точек выдачи (ПВЗ). Список ПВЗ (их ID или ссылки) должен храниться в отдельной таблице и быть изменяемым.
· Объем парсинга: ~1000 карточек товаров * 20 ПВЗ = ~20 000 запросов в сутки.
4. Технические и функциональные требования:
· Частота обновления: Ежедневно, 1 раз в 24 часа.
· Эмуляция региона: Исполнитель самостоятельно выбирает и реализует наиболее надежный метод. Рекомендуемые варианты:
· Использование сессионных кук, полученных после ручного выбора ПВЗ на сайте.
· Использование API-методов Ozon, отвечающих за смену локации (требует обратного инжиниринга).
· Приоритетный метод: Использование пула качественных резидентских (российских) прокси с привязкой IP-адресов к целевым регионам.
· Обход блокировок: Обязательная реализация механизмов обхода анти-бот систем Ozon. Должны быть включены:
· Ротация User-Agent и других заголовков.
· Использование веб-драйвера (например, Selenium Wire, Playwright) для эмуляции поведения реального пользователя и обработки JavaScript.
· Случайные задержки между запросами (от 5 до 15 секунд) для снижения нагрузки и имитации "человеческого" поведения.
· Обработка капчи (при появлении) через сервис распознавания или остановку процесса с уведомлением.
· Вывод данных: Результаты парсинга должны выгружаться в Google Таблицу.
· Структура таблицы: Единая таблица с колонками, соответствующими пункту "Собираемые данные".
· Форматирование: Данные за каждый день должны быть четко отделены.
· Ошибки: Все ошибки должны быть явно указаны в соответствующем столбце, чтобы их можно было отфильтровать и проанализировать.
5. Нефункциональные требования:
· Надежность: Система должна быть устойчива к временным недоступностям сайта, изменению структуры HTML (за счет модульной архитектуры парсера) и блокировкам.
· Масштабируемость: Архитектура должна позволять легко увеличивать количество товаров и ПВЗ без полного переписывания кода.
· Логирование: Детальное логирование процесса парсинга (старт, завершение, количество обработанных товаров, возникшие ошибки) для диагностики проблем.