Всем привет, меня зовут Никита. Не так давно к моей команде обратился сервис аналитики маркетплейсов — они собирали данные по WB и Ozon и отдавали их селлерам в виде отчетов.

Процесс был устроен по простой схеме: по расписанию обращались к API Wildberries и Ozon, выгружали данные в Google Sheets, дальше внутри таблиц уже считали метрики — продажи, конверсии, воронки, какие-то производные показатели. У каждого клиента свой набор таблиц, свои формулы, свои доработки.

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

Проблемы начались, когда объем клиентов вырос.

У каждого по несколько кабинетов (WB, Ozon), таблицы начали разрастаться, логика расчётов расползлась. Каждое обновление данных требовало ручной проверки и правок, из-за чего команда тратила всё больше времени на поддержку таблиц вместо аналитики. По мере роста клиентов начали накапливаться ошибки, а масштабирование напрямую упёрлось в количество людей, которые могли это обслуживать.

Мы решили пересобрать для них систему, вынести сбор и хранение данных в отдельный слой, централизовать расчёты и убрать всю бизнес-логику из Google Sheets. Таблицы в таком сценарии остаются только интерфейсом, но не местом, где живут данные и считаются метрики.

В качестве инструмента визуализации выбрали Yandex DataLens. Он закрывает базовые задачи по работе с дашбордами и при этом остаётся простым для пользователей без технической подготовки. Также было важно, что сервис доступен в России без ограничений и не требует больших затрат на внедрение и использование.

Процесс работы

1. Сбор данных (Python + API)

Мы реализовали backend-слой, который по расписанию обращается к API Wildberries и Ozon и загружает первичные данные (заказы, продажи, карточки товаров и рекламные показатели). Загрузка организована по источникам с учётом ограничений API — лимитов, пагинации и повторных запросов при ошибках.

На этом этапе данные не агрегируются и не преобразуются. В хранилище сохраняется полный сырой слой.

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

2. Хранилище (BigQuery)

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

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

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

3. Обработка (SQL View)

Ключевая часть системы — это слой обработки, где формируется бизнес-логика расчётов.

На основе исходных таблиц в хранилище строятся SQL-представления (view), в которых выполняется агрегация и нормализация данных из разных источников. На этом уровне объединяются данные по заказам, товарам и рекламным кампаниям, выравнивается структура (например, по ключам товаров, датам, кабинетам) и рассчитываются производные показатели.

Фактически view выступают как слой бизнес-логики. Здесь задаются формулы расчётов, правила агрегации и связи между таблицами. Это позволяет работать с уже подготовленными витринами данных, а не с разрозненными исходными выгрузками.

В этом слое формируются ключевые метрики. Воронка продаж (просмотр → корзина → заказ), конверсии на разных этапах, выручка, показатели по товарам (в разрезе SKU/артикулов), а также эффективность рекламных кампаний с привязкой к продажам и трафику.

4. Визуализация и доступ к данным

Поверх слоя представлений строятся дашборды в DataLens, которые подключаются напрямую к хранилищу.

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

Это позволяет:

• получать актуальные данные без ручного обновления

• исключить ошибки, связанные с формулами и копированием

• обеспечить единое понимание метрик для всех пользователей

5. Контроль (TG-бот)

Также реализовали контроль загрузок через Telegram-бота.

Он интегрирован с backend-процессами и в реальном времени показывает статус выполнения задач (успешность загрузок по источникам, ошибки при обращении к API, а также состояние отдельных джобов и скриптов).

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

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

Примеры дашбордов для селлеров

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

Здесь хочу показать, что у нас в итоге получилось и как выглядит часть итоговых дашбордов для селлеров.

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

Детализация на уровне товаров. Отчёт строится по SKU/артикулам и позволяет смотреть не только продажи, но и поведение пользователей. Переходы в карточку, добавления в корзину, конверсии в заказ. За счёт этого становится понятно, где именно теряется спрос — на уровне трафика, карточки или цены.

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

У нас получилось убраит ручную обработку данных и разрозненные таблицы, заменив их централизованной системой аналитики.

Команда больше не тратит время на проверку формул и обновление отчётов. Данные всегда актуальны и доступны в одном месте. При этом сама система легко масштабируется.

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

Кстати, есть еще демо-дашборд на основе этого кейса. Смотреть демо.

Я в целом часто делюсь своими наблюдениями из практики и веду телеграм-канал От цифр к делу🔎 | Никита Василевский, где разбираю реальные кейсы и то, как компании на самом деле выстраивают аналитику. Буду рад встретиться с вами и там!