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 позволяет анализировать исторические данные по продажам, отлеживать динамику и тренды, управлять и планировать деятельность компании на МП.
Кроме того, корпоративное хранилище данных в связке с 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, помогающих своевременно реагировать на изменения рынка.
Подробности реализации — в полном кейсе
Кейс 2. Проблема интеграции с маркетплейсами у поставщика косметики
Клиент — крупный поставщик косметики, ведущий продажи на WB, OZON, Яндекс Маркет, Летуаль, Lamoda, а также в собственных розничных магазинах.
Перед компанией стояла задача объединить разрозненные данные по продажам в единый источник правды для обеспечения качественной аналитики — корпоративное хранилище данных.
Для реализации проекта компании необходимо было решить проблемы интеграции хранилища данных с маркетплейсами:
- Разные цифры по заказам и продажам в отчетах «Реализация», «Возвраты», «Отгрузки» и API
Например, выгрузка из API показывала +15% заказов против личного кабинета, или наоборот, появлялись «минусовые продажи» после пересчета возвратов.
- API и личный кабинет обновляются с разным лагом
Маркетплейсы пересчитывали продажи задним числом, корректировали комиссию и начисления по прошедшему периоду. Данные в ряде отчетов отставали от API.
- Ошибки агрегации в сервисах аналитики (MPstats, Market Papa, WBLEADS)
Данные собирались разными методами, а маркетплейсы не давали унифицированных endpoint’ов.
- Проблемы с возвратами и утилизацией
У маркетплейсов разные методы работы с возвратами и отменами. Данные обновлялись задним числом и пересчитывались в зависимости от логики маркетплейса.
- Отсутствие общего идентификатора между системами
Артикулы в отчетах WB, Ozon, Летуаль и внутреннего учета в 1С не совпадали, из-за чего ручная сверка была невозможна.
Важно понимать, что из-за особенностей учета аналитика WB и Ozon никогда не будет совпадать «до копейки», поэтому главной задачей проекта стало не устранение расхождений метрик, а обеспечение воспроизводимости и прозрачности учета заказов, продаж и возвратов.
Настройка грамотной интеграции хранилища данных с МП возможна тремя способами:
- API-интеграция с маркетплейсами
- Выгрузка отчетов в xls/csv из личных кабинетов
- Имитация пользовательского поведения для выгрузки тех данных, которые невозможно извлечь через API
Для решения задач клиента командой Qlever были осуществлены следующие работы:
- Настроена интеграция DWH с Wildberries, OZON, Яндекс Маркет, Летуаль, Lamoda, а также с системой учета 1С — с помощью экстрактора от Денвик
- Разработана и внедрена методология учета данных по МП для обеспечения максимальной достоверности и актуальности отчетов
- Автоматизирована ETL-обработка — загрузка данных, проверка качества, работа с мастер-данными
- На базе полученных данных реализованы три витрины:
- Заказы — Продажи — Возвраты — для отслеживания воронки продаж
- Остатки — по маркетплейсам и по 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, маркетплейсы) сведены в единый мастер-слойОпределен набор обязательных атрибутов. Все источники (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 становится фундаментом, на котором строится устойчивое управление продажами.
Если DWH отвечает за точность и полноту данных, то BI способствует скорости и удобству принятия решений. Наглядные дашборды, сквозная аналитика, автоматизированные отчеты с детализацией до SKU демонстрируют полную картину бизнеса в режиме реального времени.
Qlever Solutions внедряет корпоративные хранилища данных и BI-системы для компаний отраслей ритейла, eCommerce, производства. Дашборды от Qlever Solutions помогают компаниям держать под контролем ключевые процессы: усиливать продажи, управлять запасами, отслеживать эффективность промо, оперативно реагировать на отклонения в логистике.