Всем привет, меня зовут Никита. Не так давно к моей команде обратился сервис аналитики маркетплейсов — они собирали данные по 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/артикулам и позволяет смотреть не только продажи, но и поведение пользователей. Переходы в карточку, добавления в корзину, конверсии в заказ. За счёт этого становится понятно, где именно теряется спрос — на уровне трафика, карточки или цены.

Сводный дашборд, который собирает всю картину магазина целиком. Продажи, воронку, рекламные показатели и оборачиваемость товаров. Он используется, чтобы отслеживать динамику, сравнивать план и факт и быстро находить отклонения.
У нас получилось убраит ручную обработку данных и разрозненные таблицы, заменив их централизованной системой аналитики.
Команда больше не тратит время на проверку формул и обновление отчётов. Данные всегда актуальны и доступны в одном месте. При этом сама система легко масштабируется.
Клиент остался доволен результатом. Мы продолжаем работать вместе. Постепенно дорабатываем систему, добавляем новые метрики, расширяем отчёты и адаптируем аналитику под меняющиеся задачи бизнеса.
Кстати, есть еще демо-дашборд на основе этого кейса. Смотреть демо.
Я в целом часто делюсь своими наблюдениями из практики и веду телеграм-канал От цифр к делу🔎 | Никита Василевский, где разбираю реальные кейсы и то, как компании на самом деле выстраивают аналитику. Буду рад встретиться с вами и там!
