Главное Авторские колонки Вакансии Вопросы
Выбор редакции:
99 0 В избр. Сохранено
Авторизуйтесь
Вход с паролем

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

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

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

На старте продаж в МП аналитика строится в 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) и визуализация данных позволят построить наглядные отчеты для разных задач бизнеса:

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

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

В отличие от фиксированных отчетов из онлайн-сервисов аналитики маркетплейсов, которые демонстрируют картину «здесь и сейчас», BI позволяет анализировать исторические данные по продажам, отлеживать динамику и тренды, управлять и планировать деятельность компании на МП.


Кроме того, корпоративное хранилище данных в связке с BI дает следующие преимущества:


Внедрение корпоративного хранилища данных и BI необходимо, если:

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

Рассмотрим эффект от внедрения 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 никогда не будет совпадать «до копейки», поэтому главной задачей проекта стало не устранение расхождений метрик, а обеспечение воспроизводимости и прозрачности учета заказов, продаж и возвратов.

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

  1. API-интеграция с маркетплейсами
  2. Выгрузка отчетов в xls/csv из личных кабинетов
  3. Имитация пользовательского поведения для выгрузки тех данных, которые невозможно извлечь через 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. Ключ наследуется из мастер-системы, например, 1С
  2. Введены product_key, warehouse_key, region_key как единственные «истинные» идентификаторы
  3. Все внешние ID маркетплейсов живут только в таблицах соответствий (mapping), а не используются напрямую в витринах и отчетах

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

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

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

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

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

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

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

  1. Для каждого домена проверяется уникальность ключа, отсутствие дублей, заполненность критичных атрибутов, целостность ссылок
  2. Разработан дашборд качества мастер-данных, настроены алерты при появлении «неизвестных» id с маркетплейсов


По каждому отдельному направлению были реализованы следующие шаги:

Номенклатура

Создана «Золотая карточка» товара (Product Master)

  • Все источники (ERP/1С, PIM, XLS, маркетплейсы) сведены в единый мастер-слойОпределен набор обязательных атрибутов. Все источники (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)

  1. Товары — category management / маркетинг / коммерция
  2. Склады — логистика/операции
  3. Регионы — логистика / финансы

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

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

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

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

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


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

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

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

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

Настроим интеграцию с WB, OZON, Lamoda и другими маркетплейсами. Реализуем интерактивные дашборды для оценки прибыли в разрезе SKU

0
В избр. Сохранено
Авторизуйтесь
Вход с паролем
Комментарии
Выбрать файл
Блог проекта
Расскажите историю о создании или развитии проекта, поиске команды, проблемах и решениях
Написать
Личный блог
Продвигайте свои услуги или личный бренд через интересные кейсы и статьи
Написать

Spark использует cookie-файлы. С их помощью мы улучшаем работу нашего сайта и ваше взаимодействие с ним.