Артикул, SKU и Ozon Product ID: какой номер куда подставлять в отчётах и API

У одного товара на Ozon живут минимум четыре разных номера, и почти каждый отчёт показывает не тот, который нужен прямо сейчас. В отчёте о реализации — SKU, в шаблоне поставки — артикул, в рекламной выгрузке опять SKU, а в ответе API приезжает product_id, который в кабинете вы, скорее всего, ни разу не встречали. Пока позиций десяток, всё склеивается глазами. На сотне ручная склейка начинает тихо врать: две цифры сошлись, третья поехала, и месячный P&L не бьётся с выгрузкой по рекламе. Разбираем, что означает каждый номер, где он встречается и какой подставлять в конкретное поле.

Четыре номера у одного товара

Артикул, он же offer_id. Ваш внутренний код. Придумываете сами при создании карточки, уникален в пределах вашего магазина. Это единственный из четырёх, который вы контролируете полностью, — и единственный, который совпадает с вашей учётной системой, если вы её ведёте.

Ozon Product ID, он же product_id. Номер карточки внутри вашего кабинета. Присваивает площадка в момент создания товара. Живёт в API и в выгрузках товаров, в интерфейсе попадается реже — поэтому его чаще всего и не узнают при первой встрече.

SKU. Номер товара на витрине — то, чем Ozon называет позицию наружу: в ссылке на карточку, в отчётах, в рекламных кабинетах, в аналитике. Один и тот же SKU видят все, кто продаёт этот товар через одну карточку. Раньше у товара было два таких номера — FBO SKU и FBS SKU, по схемам; площадка их объединила, но в старых выгрузках и чужих инструкциях пара колонок до сих пор встречается.

Штрихкод, он же barcode. То, что читает сканер на складе: либо EAN-13 с упаковки производителя, либо код, который Ozon сгенерирует по запросу. Он отвечает не за учёт и не за отчёты, а за физическую единицу — её надо опознать на приёмке и при сборке заказа. К одной карточке можно привязать несколько штрихкодов, а у двух продавцов одного и того же товара код запросто совпадёт, и это нормально.

Распределение из таблицы стоит держать в голове: артикул — про вас и ваши процессы, SKU — про площадку и деньги, product_id — про технику, штрихкод — про физическую единицу товара на складе. Половина вопросов «какой номер сюда вставлять» отпадает сама.

Где какой номер видно глазами

Основная пара, с которой работают руками, — артикул и SKU: оба стоят рядом с названием в разделе «Товары и цены» → «Список товаров». Ozon Product ID приходится доставать выгрузкой товаров или запросом к API — в интерфейсе он попадается точечно, а состав и порядок колонок площадка время от времени двигает, так что актуальный вид проверьте в базе знаний Ozon Seller.

Самый быстрый способ узнать SKU, не заходя в кабинет вообще, — ссылка на карточку. В адресе вида ozon.ru/product/nazvanie-tovara-123456789/ последнее длинное число и есть SKU. Работает и для чужих карточек: когда вы разбираетесь с конкурентом или с прилипшим к вашей карточке товаром, номер берётся прямо из адресной строки.

Штрихкод лежит в самой карточке, рядом с габаритами и весом, и дублируется на этикетке. Если вы печатаете этикетки сами, то видите его чаще, чем хотелось бы.

Поставки и склад: тут правят артикул и штрихкод

В заявке на поставку FBO товар опознаётся вашим артикулом с количеством. Не SKU, не product_id — именно тем кодом, который вы придумали сами. Отсюда самая массовая ошибка новичков: в кабинете артикул KRS-450-BL, в файле из бухгалтерии KRS450BL, и при загрузке площадка честно отвечает, что товар не найден. Сравнение идёт посимвольно: пропавший дефис ломает строку так же надёжно, как чужой номер. Саму форму заявки Ozon за последние пару лет перекраивал не раз — перед первой поставкой скачайте свежий шаблон в кабинете, а не тот, что лежит с прошлого квартала.

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

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

Отчёты и деньги: почему две выгрузки не сходятся

Финансовые документы Ozon оперируют SKU: в отчёте о реализации, в начислениях и в списке транзакций товар опознаётся номером площадки и названием. Ваша себестоимость, закупочные партии и план поставок лежат под артикулом. Моста между этими двумя мирами площадка не строит — это ваша работа.

Без моста соблазн понятный: склеить два файла по названию товара. Ломается это на первой же позиции, заведённой двумя карточками. Типичный случай — новую партию с другой закупочной ценой завели отдельной карточкой, а название скопировали из старой: в выгрузке две строки «Кресло офисное, чёрное», SKU разные, себестоимость отличается на пару сотен рублей. Склейка по названию складывает их в одну строку молча, без единой ошибки в логе, и маржа по обеим позициям превращается в среднюю температуру.

Реклама и аналитика: только SKU

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

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

API: какой ключ в каком методе

Seller API — единственное место, где встречаются все четыре номера сразу, и обычно именно там впервые узнают о существовании product_id. Общая логика такая: методы про карточки принимают offer_id и product_id, методы про продажи и аналитику отдают sku, а штрихкод фигурирует в методах логистики и в генерации кодов.

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

Ещё одна деталь, на которой спотыкаются при первой интеграции: в ответе метода информации о товаре чисел приезжает сразу несколько, и записать в свою базу не то — обычное дело. Различать их на глаз бесполезно: длина у product_id и sku похожая, обе колонки числовые. Опирайтесь на имя поля, а после первой загрузки проверьте результат вручную на одном товаре — подставьте записанный номер в адрес ozon.ru/product/<номер>/. Открылась ваша карточка — в базе SKU. Страница не нашлась — вы сохранили product_id и всю сверку построите на нём.

Разбор: как мы потеряли два дня на сверке из-за одного номера

История из нашей практики, осень прошлого года. Магазин на 1 200 активных позиций, конец месяца, считаем прибыль по товарам. Отчёт о реализации отдаёт выручку по SKU, себестоимость лежит в нашей таблице по артикулам. Скрипт склеивает их через справочник, который собирался руками ещё на четырёхстах позициях.

Сошлось плохо: 214 позиций из отчёта не нашли пары в справочнике, это около 1,9 млн рублей выручки в подвешенном состоянии. Первая версия была «Ozon сломал отчёт», и полдня ушло впустую. Разложилось всё на три причины, и ни одна не на стороне площадки. Первая и самая массовая — 138 карточек, которые мы завели за последние месяцы и в справочник просто не внесли: ассортимент рос с четырёхсот позиций до 1 200, справочник дополняли руками и урывками, между делом. Вторая — 59 товаров, которым мы сами переименовали артикулы при переходе на новую систему кодов, оставив в справочнике старые offer_id. Третья, самая обидная — 17 строк, собранных копированием из адресной строки браузера, где вместо SKU оказался product_id. Числа похожие, обе колонки числовые, глаз не зацепился.

Чинили так: выгрузили через API все товары разом, чтобы offer_id, product_id и sku стояли в одной строке, переписали справочник с нуля и добавили проверку — если в отчёте встретился SKU, которого в справочнике нет, скрипт останавливается и пишет, сколько строк выпало и какие. Теперь сбой всплывает в день появления, а не двадцать восьмого числа. Два дня разбора и целый месяц решений по 214 позициям, маржа которых считалась мимо, — нормальная плата за вывод, что справочник номеров нельзя вести руками.

Таблица соответствий: как собрать её один раз

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

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

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

FAQ

Чем отличается SKU от артикула на Ozon?

Артикул (offer_id) вы придумываете сами, он уникален в пределах вашего магазина и используется в поставках, шаблонах цен и остатков. SKU присваивает Ozon, он одинаков для всех продавцов одной карточки и встречается в отчётах, рекламе, аналитике и ссылке на товар.

Где посмотреть SKU товара на Ozon?

Быстрее всего — в адресе карточки: последнее длинное число в ссылке и есть SKU. Он же показывается в списке товаров кабинета рядом с артикулом и приходит в финансовых отчётах и рекламных выгрузках.

Можно ли изменить артикул после создания карточки?

Да, offer_id меняется отдельным действием в кабинете или через API. Но в момент смены рвутся все внешние связки — интеграция с учётной системой, сохранённые шаблоны, справочники соответствий. Планируйте смену заранее и обновляйте маппинг сразу.

Что такое Ozon Product ID и чем он отличается от SKU?

Product ID — номер карточки внутри вашего кабинета, его присваивает площадка и использует в методах API по товарам. SKU — номер товара на витрине, общий для всех продавцов этой карточки. Это разные числа, и подставлять одно вместо другого нельзя.

Почему в отчётах Ozon для одного товара разные номера?

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