Перейти к содержимому
PD
Автоматизация

Повышение рейтинга ПВЗ Wildberries

Бот-комбайн на BAS для владельцев пунктов выдачи: автовыкупы дешёвых товаров на нужные ПВЗ, сбор кодов и статусов заказов и автоматическое выставление оценок с отзывом - с журналом в базе данных.

Проблема

Рейтинг ПВЗ падает от случайного негатива, а ниже 4 пункт перестаёт показываться на карте - это штрафы и падение оборачиваемости, и владелец не может быстро выправить оценку.

Результат

Комбайн, который сам выкупает дешёвые товары с доставкой на проблемные пункты, собирает коды и статусы заказов и автоматически ставит оценки с отзывом - весь цикл ведётся в базе данных с экспортом в Excel.

Технологии

Browser Automation Studio (BAS)Антидетект-профилиExcelБаза данных BASПул проксиTelegram

Обзор

У пункта выдачи Wildberries есть рейтинг, и он бьёт по владельцу дважды: чем он хуже, тем выше штрафы, а ниже 4 пункт просто перестаёт показываться на карте - это падение оборачиваемости вплоть до убытка. При этом снизить рейтинг может любая мелочь: не убрано, шумно, громкая музыка. Владелец пункта во многом заложник чужого настроения.

Для владельцев проблемных пунктов я собрал на Browser Automation Studio бот-комбайн, который выкупает дешёвые товары с доставкой на нужный ПВЗ, собирает коды и статусы заказов и автоматически ставит оценки с отзывом - чтобы пункт держался в зоне видимости на карте даже при случайном негативе.

Проблема

Механика Wildberries устроена так, что оценку пункту можно поставить только после получения там заказа. Значит, чтобы поднять рейтинг проблемного ПВЗ, нужно провести через него реальные заказы: выкупить дешёвый товар с доставкой именно на этот пункт, дождаться статуса «готов к получению», получить и поставить оценку.

Руками это цепочка из нескольких этапов на каждый заказ - подготовить профиль, купить, отследить статус, забрать, оценить - и всё это нужно вести и не терять: какой заказ на каком пункте, с каким кодом, на какой стадии. Без учёта система разваливается на второй день.

Решение

Бот собран как комбайн с режимами под каждый этап цикла: преобразование кук в профиль, выкупы товаров, сбор кодов и статусов ПВЗ, сбор ожидающих оценки, оставление отзывов и оценок пункту и тестовый выбор ПВЗ.

Входные данные готовятся в Excel - таблица профилей и товаров с задержками, - и загружаются в бота. Дальше всё идёт через базу данных, и это ключевое решение: каждая покупка пишется в отчёт (профиль, артикул, ПВЗ, статус, время и цена), отдельно собираются коды выдачи и статусы заказов, отдельно - рейтинги пунктов, чтобы находить проблемные. Финальный шаг - оценка с отзывом, и результат ложится в ту же базу с экспортом в Excel.

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

Возможности

  • Режимы под весь цикл: выкупы, сбор кодов и статусов ПВЗ, сбор ожидающих оценки, оставление оценок с отзывом
  • Преобразование кук в антидетект-профили
  • Подготовка входных данных в Excel с настраиваемыми задержками
  • Автовыкуп дешёвых товаров с доставкой на конкретный ПВЗ
  • Сбор кодов выдачи и статусов заказов для отчётности владельцу пункта
  • Сбор рейтингов ПВЗ и выявление проблемных пунктов
  • Автоматическое выставление оценки 5 звёзд с отзывом после получения
  • Полный журнал в базе данных с экспортом в Excel
  • Пул прокси и антидетект-профили

Процесс разработки

Логику продиктовала механика площадки: оценку можно оставить только после реального получения заказа. Поэтому бот - не «поставить оценку», а полная цепочка «выкуп → доставка на нужный пункт → отслеживание статуса → получение → оценка», и большая часть работы ушла на связывание этих этапов, а не на финальное действие.

Отсюда же - центральная роль базы данных. Когда через несколько пунктов параллельно идут десятки заказов на разных стадиях, без журнала невозможно понять, что где находится и что уже оценено. Поэтому каждый этап пишет в базу: отчёт покупок, коды и статусы, ожидающие оценки, выставленные оценки. Это и учёт для себя, и отчётность для владельца пункта, и защита от повторной обработки одного заказа.

Разбиение на режимы позволяет прогонять цикл по частям: сегодня выкупы, через день - сбор статусов, ещё позже - оценки, когда заказы дошли. Это тот же паттерн повторной проверки по расписанию, что и в других задачах с отложенным статусом.

Результаты

  • Весь цикл повышения рейтинга - от выкупа до оценки - идёт в авто-режиме
  • Заказы проходят через нужные пункты, и оценка ставится только после реального получения
  • Журнал в базе данных держит десятки параллельных заказов под контролем по стадиям
  • Владельцу пункта отдаётся отчётность по кодам и статусам
  • Пункт удерживается в зоне видимости на карте даже при случайном негативе

Выводы

Технически это кейс про то, что учёт важнее целевого действия. Поставить оценку - один шаг; удержать под контролем десятки заказов на разных стадиях через несколько пунктов - вот где настоящая работа, и решается она базой данных, а не логикой клика. Журнал здесь одновременно память системы, защита от дублей и отчётность наружу.

Второй вывод - про механику площадки как источник архитектуры. Ограничение «оценка только после получения» превратило простую на словах задачу в многостадийный цикл с отложенными статусами, и именно это ограничение определило, каким должен быть бот. Та же логика отложенной проверки по расписанию встречается и в iHerb + PochtaGlobal.

Услуги в этом проекте

Похожие кейсы

Нужна похожая система?

Расскажите о своей задаче - я предложу архитектуру и кратчайший путь к рабочему продукту.