Руководителю не нужен ещё один экран с цифрами Ozon. Полезный результат — быстро понять, что требует внимания, почему это произошло, какое действие имеет смысл и можно ли выполнить его безопасно.
Мы проверили это на реальном кабинете Ozon Seller. ИИ получил доступ к фактическим данным кабинета, собрал управленческую картину, выполнил разрешённые write-back операции и после каждой записи независимо проверил конечное состояние на стороне Ozon.
Что руководитель реально получает из Ozon
В live-контуре подтверждено чтение данных продавца, каталога и статусов товаров, цен, остатков, FBO/FBS-заказов, аналитики, рейтинга продавца и складов. Поэтому вопрос руководителя может звучать не «покажи ещё один отчёт», а «что сегодня требует моего внимания на Ozon?».
Система сопоставляет факты: товар активен или архивирован, прошёл ли validation/moderation, какая установлена цена, есть ли физический остаток и резерв, были ли заказы и выручка, настроен ли склад. Из этого получается не набор метрик, а причина и следующий шаг.
Реальный SKU: что показали данные
Контрольный товар — Котёл газовый BAXI ECO NOVA 24F.
product_id = 1739745476offer_id = econova24f- текущая цена — 57 990 ₽
old_price— 85 880 ₽marketing_seller_price— 57 990 ₽- текущих marketing actions — нет
- price index —
WITHOUT_INDEX moderate_status = approvedvalidation_status = success- статус — «Готов к продаже»
- описание — «Нет на складе»
present = 0,reserved = 0
За последние 30 дней API показал 0 FBO-заказов и 0 FBS-заказов. Аналитика за тот же период: revenue = 0, ordered_units = 0, строк с продажами нет. Настроенных складов продавца — 0.
Seller rating читается, но при отсутствии торговой активности большинство доступных значений в этом кабинете равны нулю или имеют состояние UNKNOWN. UNKNOWN мы не заменяем нулём.
Главный управленческий вывод
Технически ИИ уже умеет менять цену этого товара. Но при нулевом остатке, отсутствии склада и заказов ценовой эксперимент ничего не измерит. Поэтому результат анализа — NO-GO для реального ценового пилота: сначала нужен настоящий склад и подтверждённый физический остаток, потом baseline продаж и только затем контролируемый эксперимент с ценой.
Это важная граница автоматизации: система должна уметь не только выполнить действие, но и остановить бессмысленное действие.
Как мы доказали write-back
Сначала на существующем реальном товаре сделали обратимую проверку цены:
57 990 ₽ → 65 000 ₽ → READ-BACK 65 000 ₽ → ROLLBACK 57 990 ₽ → READ-BACK 57 990 ₽
Финальное состояние реального товара восстановлено: текущая и marketing seller price снова 57 990 ₽.
Затем создали безопасный синтетический ассортимент с маркером AI-DEMO-OZON-20260907. Остатки у всех карточек оставили нулевыми, чтобы тест не мог привести к реальным продажам.
10 тестовых SKU и результаты записи
AI-DEMO-OZON-20260907-01→6255954190: 45 990 → 48 990 ₽...-02→6255954051: 47 990 → 50 990 ₽...-03→6255954041: 49 990 → 46 990 ₽...-04→6255954042: 51 990 → 48 990 ₽...-05→6255954103: 53 990 → 49 990 ₽...-06→6255954078: 55 990 ₽, контроль...-07→6255954059: 57 990 ₽, контроль...-08→6255954048: 59 990 ₽, контроль...-09→6255954034: 62 990 ₽, архив...-10→6255954100: 65 990 ₽, архив
Импорт прошёл 10/10 без ошибок. Все десять получили moderate_status = approved и validation_status = success.
Изменение цен прошло 5/5: каждый ответ содержал updated=true, затем новые цены были прочитаны отдельным запросом. Две позиции архивировали и подтвердили как is_archived=true. После фиксации evidence архивировали оставшиеся восемь. Финальный read-back: 10/10 тестовых карточек в архиве.
По всем синтетическим товарам остатки оставались present = 0 и reserved = 0.
Что именно подтверждено API
В live-тесте использовались операции получения информации о продавце, списка и статусов товаров, цен, остатков, FBO/FBS, аналитики, seller rating и складов; а также создание товара, изменение цены и архивирование. Для write-back действовало правило: ответ операции не считается результатом, пока новое состояние не прочитано независимо.
API fact → управленческий вывод → разрешённое действие → write-back → независимый read-back
Официальная документация: Ozon Seller API.
Чего эксперимент не доказывает
Мы не создавали искусственные заказы покупателей, поэтому в кейсе нет выдуманной выручки, конверсии или эффекта от изменения цены.
old_price — старая цена продажи, а не себестоимость. Для ответа «сколько мы действительно заработали?» нужна авторитетная себестоимость из 1С, МоегоСклада или другой учётной системы.
Если нужны только несколько фиксированных показателей и заранее заданные правила, ИИ может быть избыточен: API + SQL/BI или обычный отчёт решат задачу проще. ИИ полезен там, где нужно сопоставлять несколько сигналов, разбирать альтернативные причины, формировать следующий шаг и контролировать его исполнение.
Следующий шаг
Следующий этап — связать Ozon с учётной системой, получить фактическую себестоимость и остатки, сопоставить их по SKU и после этого рассчитывать маржу, минимально допустимую цену и безопасные границы автоматических действий.
Если нужен такой же управленческий контур для вашего Ozon, возможности интеграции ИИ-ассистента с Ozon описаны на продуктовой странице.