Как мы следим за изменениями WB и Ozon, чтобы ваши отчёты не устаревали

Вторник, маркетплейс обновляет тариф на логистику по одной из категорий. Новость висит в портале для продавцов, кто-то её даже репостит в чат. А аналитический сервис, в котором вы каждое утро смотрите маржу по SKU, об этом изменении не знает: в его расчётах по-прежнему старая ставка. Карточка та же, заказы идут, график оборота ровный, цифра прибыли в отчёте — зелёная. Только она неправильная. И таблица «топ по прибыли» три недели спокойно держит товар, который с понедельника торгуется в минус.

Это и есть тихий износ стороннего отчёта. Он не падает с ошибкой и не пишет «данные устарели». Он просто продолжает считать по вчерашним правилам, пока среда уже живёт по сегодняшним. Хуже всего, что обнаруживается это постфактум — в момент, когда деньги уже потеряны, а вернуть их нельзя.

Почему сторонний отчёт устаревает молча

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

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

То же самое происходит на стороне данных. Маркетплейс обновляет метод API — меняет формат поля, переименовывает статус заказа, вводит новый лимит на запросы. Если коннектор сервиса не обновлён под это изменение, в лучшем случае данные перестают подтягиваться и видно пустоту. В худшем — подтягиваются частично и тихо искажают расчёт, а пользователь продолжает принимать решения по картинке, которая уже не сходится с кабинетом.

Что мы держим в поле зрения

Хороший мониторинг начинается не с алгоритма, а со списка мест, куда смотреть, и дисциплины смотреть туда регулярно. Среда меняется по нескольким каналам сразу, и пропуск любого из них оставляет слепое пятно. Поэтому процесс, который мы закладываем в Data Seller, опирается на официальные источники обоих маркетплейсов — без пересказов из чатов, где половина «новостей» оказывается слухом.

Каналы делятся на два типа, и относиться к ним нужно по-разному. Тарифы, комиссии и правила бьют по экономике — они меняют расходную часть, а значит маржу по каждому товару. Изменения API бьют по данным — от них зависит, дойдут ли цифры до расчёта вообще и в каком виде. Первое отслеживается через новостные и тарифные разделы, второе — через документацию и release notes. Сервису аналитики обязательно держать оба контура, потому что слепота в любом из них одинаково тихо ломает отчёт.

Как изменение оценивается на влияние

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

• Влияет ли на маржу? Сдвиг комиссии или логистики меняет расходную часть по конкретным категориям и SKU.
• Влияет ли на логистику и хранение? Это сильнее всего бьёт по габаритным и медленно оборачиваемым товарам.
• Влияет ли на рекламу и ДРР? Меняется порог, при котором продвижение ещё окупается маржой.
• Влияет ли на данные? Изменение метода или формата API может исказить или оборвать поток цифр.
• Нужно ли менять правила расчёта? Иногда меняется не одна ставка, а сама логика, по которой считается прибыль.

Важно, что влияние редко бывает равномерным. «Снизили тариф» не значит «всем стало выгоднее», а «обновили API» не значит «всё сломалось». Один и тот же сдвиг для разных товаров и разных схем означает совершенно разные деньги, поэтому оценка идёт не по заголовку новости, а по тому, каких именно расчётов она касается.

Как изменение превращается в обновление продукта

Само по себе знание об изменении прибыли не возвращает. Возвращает её только обновлённый расчёт. Поэтому в процессе, который мы закладываем, у каждой значимой новости есть продолжение в самом продукте: новую ставку нужно внести в расчёт маржи, под обновлённый метод API — поправить коннектор, под изменённое правило акций — пересмотреть логику расчёта порогов. Изменение среды не должно оставаться записью в новостной ленте — оно должно дойти до формулы, по которой считается ваша прибыль.

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

Как должны выглядеть алерты для клиента

Идеальный итог всей этой работы со стороны продавца выглядит просто: не нужно самому читать новости, держать в голове release notes и гадать, не устарела ли цифра в отчёте. Об изменении сообщает сам сервис — и сообщает не общей сводкой, а адресно, по вашим товарам. Это та цель, ради которой сервис такого класса вообще строится, и именно так мы проектируем клиентские уведомления в Data Seller.

В правильном виде это короткая привязанная к делу подсказка, а не сухой технический лог. «Изменился тариф по категории — пересчитали риск по вашим SKU, проверьте позиции с тонкой маржой». «Маркетплейс обновил метод API — интеграция проверена, данные сходятся». «Комиссия по категории сдвинулась — под риском товары с маржой ниже порога». Такие уведомления — это цель, к которой мы ведём продукт, а не функция, которую можно включить сегодня: Data Seller в разработке, и сам контур слежения сейчас выстраивается. Но проектируем мы его именно так, потому что в этом и есть смысл сервиса — не заставлять продавца самому ловить изменение, а доносить его раньше, чем оно превратится в потерю.

Между адресной подсказкой и сводным отчётом — принципиальная разница. Сводка отвечает на вопрос «что уже случилось», подсказка — «что проверить сегодня, пока ещё можно вмешаться». Сервис, который умеет только первое, всегда говорит с продавцом из прошлого.

Зачем всё это

Красивые графики и аккуратные дашборды легко принять за суть аналитического сервиса. Но суть не в них. Суть в том, чтобы между изменением на маркетплейсе и вашим знанием о нём не было трёх недель тишины, за которые накапливается убыток, который уже не отыграть. Именно этот зазор мы и стараемся убрать — закладываем в Data Seller процесс, при котором среда меняется, а ваши цифры остаются честными, потому что продукт узнал об изменении раньше вас и успел всё пересчитать.