Data scientist — удалённая работа в Москве

небольшой дэш показывающий данные в динамике. Техническое задание (ТЗ) на разработку Мульти-магазинного Дашборда для мониторинга Wildberries 1. Цель проекта Создать централизованную автоматизированную систему мониторинга и анализа ключевых показателей эффективности (KPI) для одного или нескольких магазинов Wildberries. Система должна предоставлять данные в иерархическом виде (от общего к частному) с возможностью детализации по дням/неделям, а также включает ручное управление себестоимостью и закреплением товаров за менеджерами. 2. Ключевые пользователи и их потребности Владелец/Руководитель (нескольких магазинов): Оценка общей и сравнительной эффективности всех магазинов. Выявление лучших и отстающих магазинов/категорий. Консолидированная отчетность по всем точкам продаж. Отслеживание динамики продаж и прибыльности в разрезе каждого магазина. Маркетолог: Анализ показателей видимости (показы, переходы, CTR) и конверсии по всем магазинам или выборочно. Менеджер по продажам: Мониторинг показателей по своим закрепленным товарам в рамках одного или нескольких магазинов. Финансист: Контроль чистой прибыли, маржинальности и ДРР по всем магазинам. 3. Функциональные требования 3.1. Источник данных и автоматизация Источник: Данные должны автоматически загружаться через API личного кабинета продавца Wildberries. Периодичность обновления: Ежедневное автоматическое обновление данных за предыдущий день для всех подключенных магазинов. Платформа: Предпочтительно Google Sheets (для простоты совместного доступа и гибкости) или Google Looker Studio (для более продвинутой визуализации). Альтернатива — Power BI / Tableau. 3.2. Иерархия данных и структура отчета Отчет должен иметь четыре основных уровня детализации: Уровень “Все магазины“ (консолидированный): Сводные KPI по всем подключенным магазинам. Уровень “Магазин“ (индивидуальный): Детальные KPI по выбранному магазину. Уровень “Предмет“ (категория): Детализация по товарным категориям внутри выбранного магазина. Уровень “Артикул“ (НМ): Детальная аналитика по каждому товару внутри выбранного магазина и категории. На каждом уровне должны отображаться следующие метрики (согласно структуре файла): Заказы (и динамика DOD/WOW) ДРР Финансы: Чистая прибыль валовая, на единицу, маржинальность. Маркетинг: Показы, Переходы, CTR, Корзина, Конверсия в корзину, Заказ, Конверсия в заказ, Выкупы, % Выкупов. Только для уровня “Артикул“: Цена со скидкой до СПП, СПП, Цена на полке, Остаток. 3.3. Управление несколькими магазинами Подключение новых магазинов: В интерфейсе дашборда должна быть реализована простая возможность добавить новый магазин Wildberries (ввод API-ключа и наименования магазина) без необходимости создания новой таблицы или отчета. Централизованный справочник магазинов: Создать отдельный модуль (лист “Настройки“ или “Магазины“) для управления подключенными магазинами (добавление, редактирование, отключение). Единые справочники: Справочники себестоимости и закрепления менеджеров должны быть общими для всех магазинов, но с возможностью фильтрации и отображения в разрезе каждого магазина. Переключение между магазинами: В интерфейсе дашборда должен быть основной фильтр/переключатель для выбора магазина для детального анализа (“Показать все“, “Магазин 1“, “Магазин 2“ и т.д.). 3.4. Срез по менеджерам (второй уровень детализации) Должна быть возможность фильтровать и просматривать данные по уровням (“Магазин“, “Предмет“ и “Артикул“) через призму закрепленного менеджера. Для этого необходима отдельная таблица-справочник для закрепления артикулов за менеджерами. 3.5. Гибкость временных периодов Детальный вид: Отображение данных по дням (как в исходном файле). Свернутый вид: Возможность “свернуть“ дни для просмотра агрегированных данных по неделям (столбец “W36“ в исходном файле). Должна быть колонка “VS LW“ (сравнение с предыдущей неделей) для ключевых метрик. 3.6. Вспомогательные модули (ручной ввод) Модуль себестоимости: Простая табличная форма для ручного ввода/обновления себестоимости по каждому артикулу. Это необходимо для корректного расчета чистой прибыли и маржинальности. Данные должны быть привязаны к артикулу и быть едиными для всех магазинов. Модуль закрепления менеджеров: Простая таблица для сопоставления артикулов и ответственных менеджеров. Данные должны быть привязаны к артикулу и быть едиными для всех магазинов. 4. Нефункциональные требования Удобство интерфейса: Интуитивно понятная навигация, возможность быстрой фильтрации (по магазинам, менеджерам, периоду) и сортировки. Производительность: Время загрузки и обработки данных не должно превышать 5-10 минут после их получения с API. Система должна оставаться отзывчивой при работе с данными нескольких магазинов. Надежность: Система должна корректно обрабатывать ошибки API (например, отсутствие данных за день, проблемы с подключением, неверный API-ключ) и уведомлять пользователя. Безопасность: Доступ к дашборду и данным должен быть разграничен (если необходимо). API-ключи должны храниться безопасно. 5. Этапы разработки Проектирование: Согласование финальной структуры дашборда и логики расчета всех показателей. Проектирование базы данных/структуры таблиц для поддержки нескольких магазинов. Настройка интеграции с API WB: Написание скриптов (Google Apps Script, Python и т.д.) для автоматического сбора данных с поддержкой множественных API-ключей. Разработка ядра дашборда: Создание листов/страниц в выбранном инструменте (Google Sheets/Looker Studio) с консолидированным видом и видом по одному магазину. Реализация модулей: Создание модулей для управления магазинами, ввода себестоимости и закрепления менеджеров. Настройка визуализации и фильтров: Реализация переключения между просмотром по дням и неделям. Настройка главного фильтра по магазинам и второстепенных фильтров. Тестирование: Проверка корректности данных, работы фильтров, автоматизации и нагрузки при работе с несколькими магазинами. Запуск и документация: Развертывание системы и написание краткой инструкции для пользователей по управлению магазинами и работе с отчетом. 6. Технические примечания для аналитика Динамика DOD (Day-over-Day): (Значение сегодня / Значение вчера) - 1 Динамика WOW (Week-over-Week): (Значение за текущую неделю / Значение за прошлую неделю) - 1 CTR (Click-Through Rate): Переходы / Показы Конверсия в заказ: Заказы / Переходы Маржинальность: (Чистая прибыль на единицу / Цена реализации) * 100% Расчет финансовых показателей: Требует предварительного занесения себестоимости вручную. Чистая прибыль = Выручка - Логистика - Хранение - etc. (по данным WB) - Себестоимость. Идентификация данных: Все данные, получаемые через API, должны быть четко привязаны к конкретному магазину (API-ключу) во внутренней структуре хранения.