Загрузка данных

Слайд 1. Пользовательская история
Представьте менеджера по экспансии Ozon: на следующий квартал у него бюджет на два–три тестовых пункта выдачи и 125 районов Москвы на выбор. Ручной разбор отчётов занимает дни, а ответ нужен за минуты. Наш дашборд — «линза», которая сужает 125 районов до короткого списка кандидатов: где спрос плотный, а конкурентов мало. Пользователь смотрит карту, выставляет фильтры, получает топ-районы и уходит адресную проработку с конкретным списком станций.
Слайд 2. Гипотеза и главный инсайт
Гипотеза: заказы концентрируются в радиусе 500–800 метров от метро спальных районов, но именно там разворачивается конкуренция. Проверяем гипотезу индексом привлекательности — плотностью заказов, делённой на единицу плюс плотность конкурентов. Инсайт, который должен быть виден за десять секунд: спрос полицентричный, и лучшие зоны — Войковский, Южнопортовый и Алексеевский: 2,5–4,2 заказа на квадратный километр при одном–четырёх конкурентах. Центр при этом перенасыщен выдачей, и его индекс ниже.
Слайд 3. Данные и метрики
В основе три синтетических датасета: 620 заказов с координатами и временем, 211 пунктов конкурентов пяти сетей и 108 станций метро. Семь метрик — от плотности заказов и числа конкурентов до среднего чека и итогового индекса. Данные сгенерированы по правдоподобной модели: кластеры вокруг метро, двухвершинное распределение по часам, логнормальные чеки по категориям. Подчеркну: это учебный датасет; требование задания о 300–500 строках с координатами выполнено с запасом, все поля задокументированы в паспорте кейса.
Слайд 4. Макет дашборда
Компоновка классическая для геодашборда: слева четыре связанных фильтра, сверху четыре KPI-блока, в центре — тепловая карта Москвы с двумя дополнительными слоями, справа — рейтинг районов и карточка инсайта. Тепловая карта построена методом KDE с радиусом 800 метров и ячейкой сто метров; агрегат — количество заказов. Легенда показывает, где «холодно» и «горячо», с порогами в пять и шестьдесят процентов от пика. Подсказка при наведении выдаёт по району заказы, плотность, конкурентов, удалённость до метро и чек — как в настоящем BI-инструменте.
Слайд 5. Обоснование визуализаций
Почему тепловая карта, а не столбцы или хороплет? Наш вопрос — где находятся непрерывные зоны спроса и какова их форма. Столбцы потребовали бы перебирать 125 районов, а хороплет разрезал бы город по административным границам и попал бы в ловушку изменяемой территориальной единицы. Плотностная карта сглаживает шум малой выборки и показывает форму пятна. Радиус 800 метров — это десять минут пешком: при 400 метрах пятна рассыпались бы в шум, при 1500 — слились бы в сплошное зарево. Второй слой точек возвращает конкретику, которую сглаживает KDE.
Слайд 6. Ограничения и риски
Чего нельзя утверждать по этим данным? Во-первых, причинности: плотность у метро не доказывает, что метро «создаёт» спрос. Во-вторых, доходности: у нас нет арендных ставок и трафика, поэтому дашборд не принимает решение об открытии — он сужает список кандидатов. В-третьих, полноты: выборка смещена к зонам работающей доставки, и «белые пятна» сервиса выглядят как отсутствие спроса. И главное — данные синтетические: они воспроизводят структуру спроса, а не реальные продажи.
Слайд 7. Рефлексия
Мы научились деконструировать чужие панели: схема «аудитория — метрики — слои — цвет — фильтры» превращает интуицию в чек-лист. В следующей итерации добавили бы временную анимацию плотности по неделям и слой арендных ставок, чтобы считать не только спрос, но и юнит-экономику. В полноценном инструменте дашборд получил бы живые данные, роли и реальную карту с витринами. Бонусное сравнение: Kepler.gl быстрее даёт результат, QGIS глубже контролирует параметры KDE — для нашего кейса идеален гибрид: прототип в Kepler.gl, финальная настройка ядра в QGIS.