Заказы с Wildberries и Ozon не доходят до amoCRM: как собрать продажи в одну воронку

У продавца на маркетплейсах обычно три разрозненных места с данными. Рекламный бюджет лежит в рекламных кабинетах, заказы, статусы и выплаты — в личных кабинетах Wildberries и Ozon, выручка — в Excel, куда кто-то раз в неделю выгружает отчёты. В amoCRM этих заказов нет. Собственник считает окупаемость рекламы по неполным данным, и связки по конкретному товару между тремя источниками нет.

Ниже разбираем, как мы собираем заказы маркетплейсов в одну воронку amoCRM, какие данные в неё заводить и какие метрики окупаемости после этого начинают считаться без ручной сверки.

Где распадается картина: заказы в кабинетах, выручка в Excel

Первая проблема — обслуживание покупателей. Обращения и заказы размазаны по кабинетам Wildberries, Ozon и Яндекс Маркета. Менеджер переключает вкладки и копирует данные о клиенте и заказе из одной системы в другую. Каждая такая операция — потерянное время и риск ошибки при переносе: неверный артикул, перепутанный телефон, заказ, о котором забыли.

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

Механика интеграции: заказы разных площадок в единой модели данных

Заказы Ozon, Wildberries и Яндекс Маркета мы заводим в одну воронку amoCRM. Первый шаг — привести статусы площадок к единому виду: «новый», «сборка», «отгрузка», «доставка», «выплата». Каждая площадка ведёт свою терминологию, и без общего словаря статусов заказы разных маркетплейсов несопоставимы между собой.

Интеграция передаёт из Wildberries новые заказы по схемам FBS и DBS, обновления статусов доставки, данные покупателя (ФИО, телефон, адрес) и детали товаров — артикулы, штрихкоды, цены. В amoCRM автоматически создаётся сделка на нужном этапе воронки, с ответственным и привязанными товарами из каталога. Обращения покупателей попадают в CRM как чаты с проставленным источником — WB, Ozon или Яндекс Маркет. Менеджер работает из одного окна, вкладки кабинетов ему больше не нужны.

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

Финансы сделки внутри CRM: комиссии, логистика, выплаты, возвраты

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

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

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

Атрибуция: как реклама связывается с выкупом и прибылью

Атрибуция строится через отдельные метки в ссылках на карточку товара. Метка сопоставляет заказ с конкретным источником и креативом и восстанавливает цепочку: внешний клик → карточка → заказ → выкуп → прибыль.

Рекламные системы показывают клики и обращения, закрытую выручку они не видят. Коммерческий смысл атрибуция получает в момент, когда данные о продажах возвращаются в CRM. Тогда становится видно, что кампания с меньшим числом переходов приносит больше денег, чем кампания с большим числом кликов. Сведение Wildberries и Ozon в одну воронку даёт основание перераспределять бюджет по прибыли товара, число переходов здесь вторично. Как из выручки и расходов собирается отчёт по каналам, мы показали в разборе того, как Roistat считает ROMI.

Метрики окупаемости в одной системе

Когда реклама и фактические заказы сведены вместе, начинают работать метрики маркетплейсов:

• ДРР — доля рекламных расходов: расходы на рекламу / выручка с рекламы × 100 %. Чем ниже, тем выгоднее. На условных числах: 12 000 расходов на 50 000 выручки дают ДРР 24 %.
• ROMI — окупаемость маркетинговых вложений: (выручка − себестоимость − расходы на рекламу) / расходы на рекламу × 100 %. Ниже нуля — убыток, ноль — безубыточность, выше — прибыль. Для корректного значения нужны выручка и себестоимость по конкретным заказам.
• CPO — стоимость заказа: она должна быть меньше маржи товара, иначе продвижение работает в минус. Низкий CTR карточки — сигнал остановить рекламу и переработать карточку.

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

С чего начинаем

Сначала разбираем, какие площадки и схемы работы у вас есть (FBS, DBS, FBO), как устроен каталог и где сейчас ведётся учёт выплат. По итогам проектируем модель данных и делаем интеграцию маркетплейсов с amoCRM на коде через API площадок. Пилот проверяет перенос статусов, финансов и атрибуции до цифр прибыли по товарам — результат «данные подтянулись» пилот не закрывает. Когда данные в CRM, подключаем сквозную аналитику и сводим маркетплейсы с продажами сайта. Как устроена CRM для торговли в целом, мы описали на странице CRM для интернет-магазина.

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