Интеграция CRM и Озон

Интеграция CRM с Озоном — это обмен данными через Ozon Seller API: заказы попадают в систему, остатки и цены уходят обратно на площадку, статусы и удержания подтягиваются автоматически. Штатного канала Ozon нет ни у amoCRM, ни у Битрикс24 — их подключают приложением или собственным коннектором, а у RetailCRM есть готовый модуль Ozon Seller с синхронизацией заказов раз в пять минут. Выбор CRM здесь важнее выбора коннектора: amoCRM не про товарный учет, и подмена одной задачи другой — самая дорогая ошибка на старте.

Ниже разберем, что реально синхронизируется, чем отличаются схемы FBO, FBS и realFBS с точки зрения данных, почему переписка с покупателем оказывается платной опцией и какая из трех систем подходит именно вашему сценарию.

Что дает интеграция CRM с Ozon

Четыре потока данных, и путать их не стоит.

Вниз, из Ozon в CRM, идут заказы: состав, суммы, номер отправления, срок отгрузки, адрес и способ доставки. Вверх, из CRM на площадку, уходят остатки и цены. В обе стороны бегают статусы: собрали у себя — Ozon узнал, площадка доставила — вы узнали. И отдельно, с задержкой, приходят деньги: комиссия, обработка и доставка, возвраты, эквайринг, продвижение.

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

Операционный эффект проще: менеджер не сидит в кабинете Ozon и не переносит заказы руками, а склад видит единый остаток по всем каналам.

Маркетплейс — это не воронка продаж, и это надо принять до старта

Ozon не отдает вам клиента. Персональных данных покупателя в заказе нет, а на схеме FBO их нет вообще: готовый модуль в таком случае просто создает карточку вида «Покупатель OZON» с идентификатором заказа вместо имени.

Отсюда следствие, о котором на первых встречах приходится говорить почти всегда. Классические задачи CRM — повторные продажи, реактивация, прогрев базы, сегментация по истории покупок — на данных Ozon не строятся. Собрать базу клиентов маркетплейса и потом обзвонить ее не получится, и это не ограничение интеграции, а позиция площадки.

Что тогда дает CRM селлеру? Операционный контур: заказы, склад, статусы, документы, деньги и общая картина по всем каналам продаж сразу. Это много, но это другая история, чем «увеличим повторные продажи». Компании, которые заходили в проект с неправильным ожиданием, потом разочаровывались не в интеграции, а в самой идее.

Как устроен обмен по Ozon Seller API

Доступ выдается парой значений: Client Id и API key. Оба берутся в личном кабинете продавца, в настройках, раздел с API-ключами. Ключ создается с ролью Admin или Admin read only, если нужен только чтение, и показывается ровно один раз — не сохранили, создавайте новый.

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

Второй момент — Seller API и Performance API это разные вещи. Первый отвечает за товары, заказы, остатки, цены и финансы, второй — за детальную рекламную статистику. Если задача звучит как «хочу видеть в CRM расходы на продвижение по артикулам», понадобится второй ключ.

Третье, техническое: у API есть лимиты по частоте запросов, и при агрессивном опросе он отвечает отказом. Нормальный коннектор это учитывает — ставит запросы в очередь, повторяет с задержкой и не пытается тянуть весь каталог каждые тридцать секунд.

От схемы работы зависит, какие данные вообще существуют.

Заказы, остатки и цены: что синхронизируется на самом деле

Все держится на одном поле — артикуле. В Ozon артикул продавца обозначается как offer_id, и по нему модуль сопоставляет товар со своим каталогом. Вместо артикула можно связывать по штрихкоду или внешнему идентификатору, но принцип не меняется.

Отсюда правило, которое мы проверяем до начала работ: артикулы должны быть уникальны. Если в каталоге два товара с одинаковым артикулом, поедет все сразу — и остатки, и цены, и состав заказа. Разбирать такое потом дороже, чем один раз навести порядок в номенклатуре.

Дальше конкретика на примере готового модуля Ozon Seller в RetailCRM, потому что там механика описана детальнее всего. Новые заказы и обновления по существующим ставятся в очередь раз в пять минут. Остатки со склада FBO подтягиваются раз в тридцать минут. Цены выгружаются не по всему каталогу, а только по товарам, у которых зафиксировано изменение, — если цена в системе не менялась, на площадку ничего не уйдет.

С остатками есть отдельная тонкость, на которой спотыкаются: если в кабинете заведено больше одного склада и все они работают по realFBS, Ozon откажется принимать общие остатки без указания конкретного склада. Значит, соответствие складов надо настраивать явно, а не надеяться на автоматику.

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

Переписка с покупателем: почему единое окно оказывается платным

Отвечать покупателям Ozon из CRM можно, но не бесплатно и не всегда. С 1 июля 2025 года методы Seller API для переписки работают только при подключенной подписке Premium Plus. Без нее чаты остаются в кабинете и в приложении продавца.

Правила общения тоже зависят от схемы. На FBS и realFBS продавец может написать первым после оплаты заказа и в течение примерно трех суток после доставки. На FBO инициировать диалог нельзя вообще — только отвечать, и тоже в ограниченном окне после сообщения покупателя. Логика площадки понятна: она защищает клиента от увода в сторонние каналы и от рассылок.

Практический вывод простой. Если в техзадании написано «менеджер отвечает на вопросы покупателей Ozon из CRM», первым делом проверяется подписка, а не наличие коннектора. Иначе половина проекта окажется невыполнимой по причинам, к разработке отношения не имеющим. Условия площадка периодически пересматривает, поэтому мы сверяемся с документацией на момент проекта, а не с прошлогодними статьями, включая эту.

amoCRM, Битрикс24 или RetailCRM: что выбрать под Ozon

Короткий ответ: если маркетплейсы — основной канал, берите RetailCRM. Если Ozon один из нескольких каналов рядом с сайтом и оптовыми продажами, обычно выигрывает Битрикс24. amoCRM подходит, когда площадка для вас побочный ручеек выручки, а основные деньги приносят услуги или B2B.

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

Битрикс24 берут, когда Ozon надо свести с сайтом, розницей, оптом и задачами внутри компании. Готовые приложения из Маркета закрывают базовый обмен, но у них бывают заметные ограничения — например, невозможность разделить заказ на отправления или необходимость идти в кабинет за спорами и возвратами. Здесь мы обычно докручиваем логику своим коннектором на REST, а товарный учет выносим в <a href=»https://itrevolution.ru/vnedrenie-moysklad/»>МойСклад</a> или 1С.

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

Порядок работ: как мы настраиваем интеграцию с Ozon

1. Считаем, где живет истина по остаткам. Одна система должна быть источником, остальные — потребителями. Если остаток редактируют и в CRM, и в кабинете, расхождения появятся в первую же неделю.
2. Проверяем номенклатуру. Уникальность артикулов, соответствие каталога в системе и на площадке, чем связываем товары. Скучный шаг, который экономит недели разбирательств.
3. Определяем схемы и склады. FBO, FBS, realFBS, сколько складов, как они соотносятся со складами в системе. От этого зависит, что вообще можно синхронизировать.
4. Получаем и защищаем доступы. Ключ с нужной ролью, ограничение по IP, отдельный ключ под Performance API, если нужна рекламная аналитика.
5. Настраиваем обмен заказами и статусами. Маппинг статусов в обе стороны, тип и статус оплаты, сроки отгрузки, трек-номера, печатные формы.
6. Подключаем цены, остатки и расходы. Типы цен, соответствие складов, статьи расходов для юнит-экономики.
7. Тестируем на живых сценариях. Обычный заказ, частичная отмена, возврат, заказ по другой схеме, товар, которого нет на складе. Возврат забывают чаще всего, а он ломает и остатки, и деньги.
8. Включаем мониторинг. Уведомления об ошибках обмена и о заказах, зависших без движения. Интеграция с маркетплейсом ломается тихо, а штрафы за просрочку сборки приходят громко.

Ошибки, которые мы разбираем чаще всего

Дубли артикулов в каталоге. Самая частая и самая обидная. Товары путаются местами, остатки уезжают не туда, в заказ попадает не та позиция. Лечится только уборкой в номенклатуре.

Ozon воспринимают как источник клиентской базы. Проект стартует с целью «собрать клиентов и продавать им напрямую», а данных покупателя площадка не дает. Ожидания надо править на берегу.

Остатки редактируют в двух местах. Кладовщик поправил в системе, менеджер — в кабинете, синхронизация перезаписала. Дальше продажа товара, которого нет, отмена и удар по рейтингу.

Расходы не подтягивают. Считают выручку по заказам и радуются, пока в конце месяца не приходит отчет с удержаниями. Комиссия, логистика и возвраты должны лежать в том же заказе, что и продажа.

Никто не следит за обменом. Ключ отозвали, лимиты уперлись, коннектор встал. Узнают из просроченных отгрузок, то есть уже вместе со штрафами.

Сроки и стоимость

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

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

Частые вопросы

Придут ли в CRM контакты покупателей с Ozon?

Нет. Площадка не передает персональные данные, а на схеме FBO в заказе нет даже имени — вместо покупателя создается техническая карточка с идентификатором заказа. Строить на этих данных повторные продажи не получится.

Можно ли отвечать на вопросы и чаты покупателей из CRM?

Только при подключенной подписке Premium Plus: с 1 июля 2025 года методы Seller API для переписки доступны в ее рамках. Дополнительно действуют ограничения по схемам — на FBO продавец не может написать первым.

Как часто обновляются заказы и остатки?

В готовом модуле RetailCRM заказы и их обновления ставятся в очередь раз в пять минут, остатки по складу FBO — раз в тридцать минут. В собственных коннекторах частоту задаем мы, но упираемся в лимиты API площадки.

Почему цена в CRM изменилась, а на Ozon нет?

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

Можно ли подключить несколько кабинетов Ozon к одной CRM?

Да, и это типовая задача для продавцов с несколькими юрлицами или брендами. Сложность не в подключении, а в разделении складов, цен и отчетности между кабинетами — это проектируется заранее.

Нужна ли отдельная учетная система, если есть CRM?

Зависит от системы. RetailCRM закрывает товарный контур сама, для Битрикс24 и особенно amoCRM склад и себестоимость разумнее держать в 1С или МойСклад, а в CRM видеть заказы и процессы.

Коротко о главном

Интеграция CRM и Ozon решает операционные задачи: заказы в одном окне, актуальные остатки и цены, статусы без ручного переноса и понятная юнит-экономика с учетом комиссий. Чего она не решает — не превращает маркетплейс в источник клиентской базы, потому что данных покупателя площадка не отдает.

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

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