05.12.2025 ПУБЛИКАЦИИ

DWH и аналитика маркетплейсов​. Как объединить данные WB, OZON, Яндекс Маркет, MPStats и 1C в единую систему принятия решений

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

На старте продаж в МП аналитика строится в Excel и онлайн-сервисах мониторинга вроде MpStats, Moneyplace, Маяк, и этого хватает: простые статичные отчеты помогают быстро увидеть результаты продаж, отследить рейтинг товаров, посмотреть остатки на складах.

Но как только SKU становится 100+​, у компании появляется несколько каналов продаж (WB, Ozon, Яндекс.Маркет, онлайн-магазин, оффлайн торговая точка), а показатели продаж становятся нужны для оценки работы нескольких отделов, аналитика в Excel перестает справляться с масштабами бизнеса.

25 ноября на открытой онлайн-встрече «DWH и аналитика маркетплейсов» эксперты Qlever Solutions обсудили трудности, которые возникают при работе с данными из маркетплейсов.
Технический директор Qlever Андрей Харлак и директор по маркетингу Ксения Медова рассказали про способы решения этих проблем с помощью DWH и BI, а также продемонстрировал реальные кейсы внедрения инструментов аналитики в ритейле, производстве электроники и косметической отрасли.

В статье подводим итоги прошедшей онлайн-встречи.

Боли и ловушки крупных продавцов на Wildberries, OZON, Яндекс Маркет

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

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

Любая неточность данных в условиях роста стоит денег: промо уходит в минус, остатки зависают, логистика съедает маржу, а аналитика перестает успевать за бизнесом.

Ниже - ключевые ловушки в области анализа данных, в которые попадают даже самые крупные селлеры МП:

  • Разрозненность данных 
WB, Ozon, Яндекс.Маркет, 1С, CRM и сторонние сервисы (MpStats) демонстрируют разные показатели, из-за чего ни один отчет нельзя назвать источником правды 
  • Отсутствие юнит-экономики 
Онлайн сервисы аналитики МП не позволяют рассчитать реальную прибыльность каждого конкретного юнита: SKU, заказа, кампании или товарной связки

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

  • Отсутствие сквозной аналитики​ 
Данные по рекламе, продажам, логистике и остаткам​ не связаны, невозможно увидеть настоящий путь товара от закупки до заказа

  • Нет контроля по складам и логистике 
Операции на складах маркетплейсов работают с задержками: товары теряются, приход отражается не вовремя, списания появляются постфактум

  • Разные версии отчетов WB​ 
Суточные, еженедельные и операционные отчеты от WB дают разные показатели — пропадает доверие к данным

  • Сложность API-интеграций​ 
Тянуть данные напрямую через API сложно: не хватает ИТ-компетенций, обновления API ломают процессы, а качество данных остается нестабильным 

Где теряются деньги и достоверность данных​

Предпроектные обследования, проводимые командой Qlever на старте проектов, показали, что до 10–15% оборота может уходить в туман ​из-за некачественных данных и ручной аналитики.

При ошибках ценообразования бизнес теряет от 5 до 20% маржи, неэффективная реклама может съесть до 30% заложенного бюджета, а отсутствие прозрачных данных по прибыли вызывает управленческую слепоту.

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

Как решать текущие проблемы с аналитикой МП

Решить трудности с разрозненностью данных, ошибками в отчетах и недостатком информации поможет комплексное ИТ-внедрение: разработка корпоративного хранилища данных DWH в сочетании с BI-платформой для визуализации данных.

Корпоративное хранилище данных (Data Warehouse, DWH, КХД) – единый репозиторий структурированных данных для построения бизнес-аналитики и аналитических отчетов.

DWH позволяет объединить, структурировать и подготовить к последующей аналитике данные из различных источников: от личных кабинетов Wildberries, OZON, Lamoda до данных их ERP и CRM, чтобы построить на их основе полноценные отчеты продаж по разным каналам.
Внедрение бизнес-аналитики (BI) и визуализация данных позволят построить наглядные отчеты для разных задач бизнеса:

  • GM/GM% на уровне SKU×канал×регион с учетом всех комиссий/логистики/уценок​
  • План-факт: продажи, закупки, отгрузки, рекламные бюджеты на одном экране
  • ROMI/атрибуция: связываем клики/затраты из Ads с фактом продаж и маржинальностью​
  • Согласованные отчеты для финдиректора: P&L/CF/баланс с отбором по МП/категориям/брендам​
  • Сегментация ассортимента: ABC/XYZ с товарной и финансовой логикой, авто-рекомендации по запасам/цене​
  • …и другие

Онлайн-сервисы vs DWH + BI

В отличие от фиксированных отчетов из онлайн-сервисов аналитики маркетплейсов, которые демонстрируют картину «здесь и сейчас», BI позволяет анализировать исторические данные по продажам, отлеживать динамику и тренды, управлять и планировать деятельность компании на МП.
ОНЛАЙН - СЕРВИСЫ

  • Быстрый старт, фиксированные отчеты, ограниченная история
  • Фокус - видеть, что происходит сейчас
DWH + BI-АНАЛИТИКА

  • Текущие и исторические данные WB/Ozon/ЯМаркет/СММ + 1С/ERP/CRM/логистика/реклама объединяются в DWH → витрины данных → BI-дашборды по ролям
  • Фокус - управлять, планировать, считать маржинальность и деньги
Кроме того, корпоративное хранилище данных в связке с BI дает следующие преимущества:
Внедрение корпоративного хранилища данных и BI необходимо, если:

  • Ассортимент составляет ≥ 300- 1 000 SKU, компания торгует на ≥ 2–3 маркетплейсах и помимо онлайн-каналов продает D2C/офлайн  
  • В компании для учета продаж используют 1С/ERP/CRM/WMS  
  • Для оценки эффективности бизнеса важно оценивать маржинальность, план-факт, ROMI 
  • Разными отчетами пользуются финансы/закупки/маркетинг/логистика (20+ пользователей) 
  • Нужно хранить и анализировать исторические данные для отслеживания динамики 

Рассмотрим эффект от внедрения DWH и BI-аналитики на примере кейсов клиентов Qlever. 

Кейс 1. DWH и BI-аналитика для бренда детской одежды Orby

Orby – производитель детской одежды полного цикла от идеи до полки, селлер собственной продукции на маркетплейсах.

Специалисты компании регулярно отслеживали результаты торговли на маркетплейсах Wildberries и Ozon через личные кабинеты МП и с помощью сервиса MPStats. Более детальная информация о продажах хранилась на платформе 1С: Управление торговлей.

Из-за отсутствия единой системы аналитики продаж компания сталкивалась со следующими проблемами:

  • Разрозненные данные низкого качества по продажам и маркетплейсам
Для отчетов использовались выгрузки из ЛК WB/Ozon, MPStats, отчеты Excel, 1C:Управление торговлей, 1С:ERP. Каждый источник предлагал свой формат данных и методологию отчетности.

  • Ошибки в выгрузках из MPStats
Значения показателей для одних и тех же дат в MPStats отличались в зависимости от того, как выгружались данные: по дням или за всю неделю.

  • Нет прозрачной аналитики по SKU
Из-за ручного заполнения карточек в МП идентичные позиции в 1C, OZON и Wildberries не совпадали. Не было понимания, что действительно приносит прибыль, а что создает оборот, но работает в минус.

  • Не было единой методологии расчетов и источника правды
Маркетинг считал выручку по одной логике, операционный отдел - по другой, в личных кабинетах маркетплейсов были третьи значения.

  • Задержки и ошибки в ручной отчетности
Сведение данных и подсчеты в Excel занимали у аналитиков до 3 часов в день.

Для решения этих проблем Orby стартовали проект цифровизации продаж. 
Первым этапом стало создание корпоративного хранилища данных и аналитических приложений на базе PIX BI, помогающих своевременно реагировать на изменения рынка. 

Подробности реализации - в полном кейсе

Узнайте, как специалисты Qlever Solutions разработали для бренда детской одежды Orby корпоративное хранилище данных и приложения на PIX BI, позволяющие получить единый доступ к данным и анализировать деятельность компании на OZON и Wildberries.
Внедрение дашборда бизнес-аналитики

Кейс 2. Проблема интеграции с маркетплейсами у поставщика косметики

Клиент - крупный поставщик косметики, ведущий продажи на WB, OZON, Яндекс Маркет, Летуаль, Lamoda, а также в собственных розничных магазинах.

Перед компанией стояла задача объединить разрозненные данные по продажам в единый источник правды для обеспечения качественной аналитики - корпоративное хранилище данных.

Для реализации проекта компании необходимо было решить проблемы интеграции хранилища данных с маркетплейсами:

  • Разные цифры по заказам и продажам в отчетах «Реализация», «Возвраты», «Отгрузки» и API
Например, выгрузка из API показывала +15% заказов против личного кабинета, или наоборот, появлялись «минусовые продажи» после пересчета возвратов.

  • API и личный кабинет обновляются с разным лагом 
Маркетплейсы пересчитывали продажи задним числом, корректировали комиссию и начисления по прошедшему периоду. Данные в ряде отчетов отставали от API.

  • Ошибки агрегации в сервисах аналитики (MPstats, Market Papa, WBLEADS)
Данные собирались разными методами, а маркетплейсы не давали унифицированных endpoint’ов.

  • Проблемы с возвратами и утилизацией 
У маркетплейсов разные методы работы с возвратами и отменами. Данные обновлялись задним числом и пересчитывались в зависимости от логики маркетплейса.

  • Отсутствие общего идентификатора между системами
Артикулы в отчетах WB, Ozon, Летуаль и внутреннего учета в 1С не совпадали, из-за чего ручная сверка была невозможна.


Важно понимать, что из-за особенностей учета аналитика WB и Ozon никогда не будет совпадать «до копейки», поэтому главной задачей проекта стало не устранение расхождений метрик, а обеспечение воспроизводимости и прозрачности учета заказов, продаж и возвратов.

Настройка грамотной интеграции хранилища данных с МП возможна тремя способами:

  • API-интеграция с маркетплейсами
  • Выгрузка отчетов в xls/csv из личных кабинетов
  • Имитация пользовательского поведения для выгрузки тех данных, которые невозможно извлечь через API
Для решения задач клиента командой Qlever были осуществлены следующие работы:

  1. Настроена интеграция DWH с Wildberries, OZON, Яндекс Маркет, Летуаль, Lamoda, а также с системой учета 1С – с помощью экстрактора от Денвик
  2. Разработана и внедрена методология учета данных по МП для обеспечения максимальной достоверности и актуальности отчетов 
  3. Автоматизирована ETL-обработка – загрузка данных, проверка качества, работа с мастер-данными 
  4. На базе полученных данных реализованы три витрины: 
  • Заказы - Продажи – Возвраты – для отслеживания воронки продаж 
  • Остатки – по маркетплейсам и по 1С 
  • Продажи в магазинах (чеки)
В результате реализации клиент получил единое хранилище данных по продажам на маркетплейсах и в собственных магазинах, которое обеспечило компанию надежным источником правды для дальнейшей аналитики.

Кейс 3. Проблема качества данных при работе с маркетплейсами

Клиент - производитель электроники с 500+ SKU, торгующий на OZON и Wildberries.

Задачей клиента стало внедрение DWH и системы бизнес-аналитики для автоматизации отчетности и ускорения принятия решений по совершенствованию процессов продаж и производства.

Основной сложностью проекта стал краеугольный камень всех крупных селлеров: некорректное ведение справочников SKU, складов, регионов и как следствие низкое качество данных при их большом объеме и разнообразии.
  • Номенклатура
    • Один и тот же SKU имел разные коды в 1С:ERP и у разных маркетплейсов, маппинг кодов хранился в Excel или в головах сотрудников 
    • Дубли и разные версии одного и того же товара давали раздутое количество SKU, а значит искажение ABC/XYZ-аналитики и маржинальности 
    • Атрибуты товаров в карточках МП (категории, цвета, размеры) были некорректно заданы, товары выпадали из выдачи
  • Склады
    • Между 1С:ERP и маркетплейсами не были согласованы коды складов 
    • Разные схемы исполнения (FBO, FBS, DBS) использовали разные сущности склада, один и тот же склад в логике бизнеса мог быть разным объектом в API 
    • Отсутствовали уникальные идентификаторы в отдельных API-методах – названия складов могли изменяться, дублироваться, содержать регион/город в разных форматах 
    • Дублирование складов в API
  • Регионы
    • У каждого маркетплейса свои справочники регионов, а внутри компании свой
    • Нестабильность и изменение региональных ID
    • Несоответствие регионов административному делению РФ
    • Регион покупателя ≠ регион доставки ≠ регион склада
    • Несогласованность между методами API
    • Отсутствие признаков региона в некоторых API
Для того, чтобы спроектировать качественное хранилище данных и построить в компании общую отчетность, где заказы, продажи, возвраты товаров с каждого маркетплейса корректно отображаются и относятся именно к той номенклатуре, которой они являются, необходимо было синхронизировать справочники между собой.

Для решения задачи эксперты команды Qlever следовали общим принципам работы со справочниками:

Использовали внутренние суррогатные ключи в DWH

  • Ключ наследуется из мастер-системы, например, 1С
  • Введены product_key, warehouse_key, region_key как единственные «истинные» идентификаторы
  • Все внешние ID маркетплейсов живут только в таблицах соответствий (mapping), а не используются напрямую в витринах и отчетах

Разработали явные mapping-таблицы по каждому домену

  • Таблицы mp_product_map, mp_warehouse_map, mp_region_map
  • Поля: внутренний ключ, ID маркетплейса, тип маркетплейса, даты начала/окончания действия соответствия, признак актуальности

Ввели версионирование и датирование

  • Любое соответствие «внутренний объект ↔ внешний ID» ведется с valid_from, valid_to
  • Аналитика во времени корректно учитывает исторические изменения складов/регионов/товаров

Настроили справочники как отдельный слой хранилища (MD/DIM)

  • Мастер-данные и справочники (товары, склады, регионы, бренды, единицы измерения, категории) - это отдельный контур с собственными процессами обновления и контроля качества
  • Интеграции и витрины только читают их, но не меняют

Разработали правила качества и автоматизировали мониторинг

  • Для каждого домена проверяется уникальность ключа, отсутствие дублей, заполненность критичных атрибутов, целостность ссылок
  • Разработан дашборд качества мастер-данных, настроены алерты при появлении «неизвестных» id с маркетплейсов
По каждому отдельному направлению были реализованы следующие шаги:
  • Номенклатура
  • Создана «Золотая карточка» товара (Product Master)
    • Все источники (ERP/1С, PIM, XLS, маркетплейсы) сведены в единый мастер-слой
    • Определен набор обязательных атрибутов
  • Произведена нормализация атрибутов
    • Единицы измерения (м/см, кг/г и т.п.) приведены к внутреннему стандарту
    • Введены дополнительные справочники по брендам, цветам, материалам, параметрам
    • Проведена чистка наименований, унификация шаблонов
  • Произведена нормализация атрибутов
    • Единицы измерения (м/см, кг/г и т.п.) приведены к внутреннему стандарту
    • Введены дополнительные справочники по брендам, цветам, материалам, параметрам
    • Проведена чистка наименований, унификация шаблонов
  • Обработаны дубли
    В мастере оставлен один product_key, маркетплейсные SKU просто маппятся на него
  • Категорийные иерархии и mapping c маркетплейсами
    • Внутренняя товарная иерархия (группы, подгруппы, категории) стала основной 
    • Настроена таблица соответствия: внутренняя категория - категория/дерево каждой площадки
  • Склады
  • Создан единый справочник складов и логистических ролей
    • Внутренний warehouse_key + атрибуты: тип (РЦ, кросс-док, ПВЗ, сортировочный центр), принадлежность (наш/маркетплейс), регион, часовой пояс, SLA
    • Явно зафиксированы: склад приемки, склад хранения, склад отгрузки - как разные роли, которые можно сводить на один физический объект
  • Настроен мэппинг ID маркетплейсов по схемам FBO/FBS/DBS
    • Настроена таблица соответствий: склад маркетплейса - склад из внутреннего справочника
    • Определен признак типа соответствия: inbound, storage, shipment, returns
  • Реализована агрегация распределенных складов
    • Если у маркетплейса один физический комплекс разбит на несколько ID (зоны, ворота), даем им общий warehouse_key и дополнительный уровень детализации при необходимости
    • В отчетах по логистике настроена гибкая агрегация (по зоне, по комплексу, по региону)
  • Настроено автоматическое обновление справочника складов
    • Регулярные job’ы, которые опрашивают API «справочников складов» маркетплейса
    • Новые ID попадают в «буфер согласования» (staging), где требуют маппинга на внутренний склад и проверки атрибутов
  • Обеспечен контроль качества по складам
    • Регулярные job’ы, которые опрашивают API «справочников складов» маркетплейса
    • Новые ID попадают в «буфер согласования» (staging), где требуют маппинга на внутренний склад и проверки атрибутов
  • Регионы
  • Создан внутренний справочник регионов и зон
    Внутренний region_key + иерархия: страна → макрорегион → субъект РФ → город → зона доставки/логистическая зона (как принято внутри компании)
  • Мэппинг регионов маркетплейсов
    • Таблица: region_key ↔ region_id/логистическая зона/кластер у каждого маркетплейса
    • Признак типа сущности (адм.регион, логистическая зона, ПВЗ-кластер)
    • Версионирование при изменении карты регионов на стороне маркетплейса
  • Нормализованы строковые названия и геокодирование
    Если API дает только строку («МО», «Moscow region», «Московская обл.») - отдельный слой нормализации через справочник с синонимами
  • Настроены единые правила по типам регионов
    • Отдельные признаки: регион покупателя, регион доставки, регион склада, регион логистического тарифа
    • Все они привязаны к одному справочнику, но с разными ролями
  • Обеспечен контроль целостности и изменений
    • Мониторим появление новых региональных ID в потоках заказов
    • При изменении справочников маркетплейса перезагружаем mapping и проверяем, что старые ID либо закрыты корректно, либо сопоставлены
В работе с качеством данных важным остается факт того, что DWH обеспечивает единую платформу и автоматизацию обработки данных, но не корректирует данные и не способен исправить ошибки человеческого фактора.

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

Для этого на процессно-организационном уровне в компании были:

Назначены владельцы мастер-областей (data owners)

  • Товары - category management / маркетинг / коммерция 
  • Склады - логистика/операции 
  • Регионы - логистика / финансы 

Разработаны регламенты изменения мастер-данных

  • Как заводится новый товар/склад/регион 
  • Как согласуются и закрываются дубли 
  • Как онбордится новый маркетплейс и его справочники 

Введен мониторинг качества 

  • Разработан отдельный дашборд по качеству мастер-данных: % дублей, % «непромапленных» id, покрытия по регионам и складам, ошибки в атрибутах 
  • При достижении пороговых значений ответственные за данные получают уведомления 

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

Узнайте больше об эффективной аналитике МП

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

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

Qlever Solutions внедряет корпоративные хранилища данных и BI-системы для компаний отраслей ритейла, eCommerce, производства. Дашборды от Qlever Solutions помогают компаниям держать под контролем ключевые процессы: усиливать продажи, управлять запасами, отслеживать эффективность промо, оперативно реагировать на отклонения в логистике.

Внедрим наглядную аналитику по МП

Свяжитесь с нами. Настроим интеграцию с WB, OZON, Lamoda и другими маркетплейсами. Реализуем интерактивные дашборды для оценки прибыли в разрезе SKU
ОБСУДИТЬ ЗАДАЧИ