От траектории к решению: данные и метрики

Самая частая судьба проекта по отслеживанию перемещений выглядит так. Оборудование смонтировано, система работает, подрядчик сдал объект, в админке появился раздел с графиками. Управляющий открыл его дважды: на демонстрации и через неделю. Через полгода при обсуждении бюджета кто-то спрашивает, зачем мы это покупали, и внятного ответа нет.

Техника при этом исправна. Данные собираются. Проблема не в датчиках.

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

Модель данных: пять сущностей, из которых всё собирается

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

Сущность	Что это	Откуда	Зачем
Событие	Факт с временем и местом: отметка браслета, вход в зону, покупка, тревога	Считыватель, замок, касса, датчик	Основа для денег и учёта: неоспоримый факт
Сессия в зоне	Интервал нахождения в зоне с началом и концом	Пара событий или непрерывный канал	Время в зоне, загрузка
Переход	Пара «зона A → зона B» с временем	Последовательность сессий	Маршруты, воронка, заторы
Визит	Всё, что произошло между выдачей браслета и его возвратом	Склейка событий по идентификатору	Единица анализа и расчётов
Траектория	Последовательность координат с метками достоверности	Непрерывный канал	Тепловые карты, детальная аналитика

Четыре правила, которые стоит заложить сразу.

Сырые события хранить обязательно. Агрегаты можно пересчитать из событий; события из агрегатов — нельзя. Любая система, отдающая только готовые отчёты, через год лишит вас возможности задать новый вопрос. Требование к поставщику: выгрузка сырых событий по API или в базу, и это пункт договора.

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

Единое время. Банальность, которая ломает проекты: считыватель, касса, видеосервер и датчики должны быть синхронизированы по единому источнику времени. Расхождение в полторы минуты между кассой и турникетом превращает анализ «что гость купил после входа в зону» в угадывание.

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

Метрики: что считать и что с этим делать

Главное правило: всё — отношение, и в знаменателе поток

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

Отсюда практический приоритет: сначала корректный счёт на входах, потом всё остальное. Это же объясняет, почему счётчик в проёме важнее, чем кажется, и почему нестабильный источник вроде Wi-Fi опасен — он портит не одну метрику, а все.

Рабочий набор метрик

Метрика	Как считается	Источник	Что с ней делают
Поток по часам и дням	Число входов за интервал	Счётчик, турникет	Графики смен, тарифы по времени, часы работы
Пропускная способность входа	Человек в минуту на пике, время оформления	Касса и турникет	Число рабочих мест на ресепшн, терминалы самообслуживания
Время в очереди	Разница между приходом в зону ресепшн и выдачей браслета	Счётчик зоны плюс касса	Решение о доукомплектовании или самообслуживании
Доля дошедших до основной услуги	Прошедшие турникет мокрой зоны к вошедшим	События	Диагностика: гость заходит и не доходит — проблема в раздевалке или навигации
Загрузка зоны	Число людей в зоне по времени	Датчик зоны или события	Расстановка персонала, вместимость, уборка
Время в зоне	Длительность сессии	Сессия	Понимание ценности зоны
Конверсия зоны в покупку	Покупки у точки к посещениям зоны	Сессия плюс касса	Перестановка точек продаж, ассортимент, цена
Время до первой покупки	От входа до первого чека	События и касса	Оценка барьеров: далеко, непонятно, нет повода
Оборачиваемость шкафчиков	Занятость во времени, доля занятых при неполной загрузке	Замки	Число шкафчиков, политика «один гость — один шкафчик»
Маршрутные цепочки	Частые последовательности зон	Переходы	Понимание типовых сценариев визита
Переработка визита	Доля визитов свыше тарифа, сумма доплат	События и терминал	Тарифная сетка, политика доплат
Загрузка горячих зон	Одновременность и очередь у парной	Датчики плюс события	График парений, число банщиков

Коридор и место назначения

Простое правило чтения зональных данных, которое спасает от типичной ошибки: смотреть посещения вместе со временем. Зона с большим числом посещений и очень малым временем — это коридор, а не место назначения. Пытаться «повысить ценность» коридора бессмысленно: по нему просто ходят.

Чего измерять не надо

Метрики, которые красиво выглядят и не ведут ни к одному решению: «средний маршрут», «общее число перемещений», «средняя скорость гостя», «процент покрытия территории». Если на вопрос «что мы сделаем, если эта цифра изменится на двадцать процентов» нет ответа — метрику не нужно считать и выводить.

Тепловая карта: красивая и обычно бесполезная

Тепловая карта — главный экспонат любой презентации и самый частый источник неверных выводов.

Проблема. Карта показывает абсолютную интенсивность: где люди были чаще. Но интенсивность у входа, в проходах и у лестницы будет высокой всегда, потому что через эти места проходят все. Карта в итоге рисует вашу планировку, а не поведение гостей.

Что делать — нормировать. Варианта три, и лучше использовать все:

1. На входной поток. Интенсивность делится на число гостей за тот же период. Так карты разных дней становятся сопоставимыми, и видно изменение поведения, а не изменение посещаемости.
2. На площадь. Плотность человек на квадратный метр, а не сумма попаданий в ячейку. Иначе большие зоны всегда «горячие».
3. По времени. Отдельные карты для характерных периодов: утро буднего дня, вечер пятницы, субботний пик. Усреднённая по месяцу карта не описывает ни один реальный режим работы.

Как читать правильно. Карта отвечает не на вопрос «где людно», а на вопрос «где людно больше, чем должно быть при такой планировке и таком потоке». Именно отклонение от ожидаемого — полезная информация: затор в неожиданном месте, пустая зона при высокой общей загрузке, скопление у одной из нескольких одинаковых точек.

И честная оговорка про источник. Если тепловая карта строится по видеоаналитике, её разрешающая способность ограничена реальной точностью трекинга; если по зональным датчикам — это не карта, а гистограмма по зонам, и называть её картой не стоит, чтобы не создавать ложных ожиданий.

Что с данными делают: решения по средам

Метрика без решения — украшение. Конкретные связки, которые работают.

Термальный комплекс и баня.

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

Аквапарк.

• распределение спасателей по загрузке зон во времени;
• пропускная способность горок и управление очередями;
• контроль вместимости чаши по нормам площади на человека;
• время и причины заторов на входной группе в пиковые дни.

Фитнес-клуб.

• расписание занятий по фактической посещаемости залов, а не по записи;
• решение о дополнительном оборудовании по загрузке зон в часы пик;
• оценка эффекта акций по приросту визитов, а не по проданным абонементам.

Торговый центр и HoReCa.

• арендные решения по проходимости и конверсии зон;
• расстановка персонала на фудкорте по пикам;
• оценка эффекта мероприятий по приросту потока с нормировкой на погоду и день недели.

Производство и склад.

• время на участках и сравнение смен;
• узкие места по маршрутам техники;
• охрана труда: пребывание в опасных зонах.

Как измерить эффект без выдуманных цифр

Самый частый вопрос на старте: «а сколько это принесёт». Самый частый ответ рынка — цифра из чужого кейса. Так делать нельзя, и вот как делать можно.

Шаг 1. Базовый замер до изменений. Минимум две-четыре недели сбора данных, в которые ничего специально не меняется. Это ваша точка отсчёта. Пропустив этот шаг, вы лишаетесь возможности что-либо доказать — и именно поэтому его пропускают чаще всего.

Шаг 2. Одно изменение за раз. Переставили бар, добавили банщика, сменили тариф. Два изменения одновременно — и результат не атрибутируется.

Шаг 3. Контроль. Три способа, по возрастанию надёжности:

• сопоставимый период: та же неделя месяц назад, с поправкой на сезон, погоду, праздники. Слабый, но доступный контроль;
• контрольная зона: меняем одну из двух похожих зон, вторая остаётся как есть. Хороший контроль;
• контроль по сменам: чередуем режим работы по сменам или дням недели. Лучший доступный контроль в сервисном бизнесе.

Шаг 4. Считать в деньгах или в операциях. Не «время в зоне выросло на 12 %», а «выручка бара на одного гостя выросла с X до Y» или «время оформления на входе сократилось с A до B, очередь на пике исчезла».

Шаг 5. Проверить, не объясняется ли результат иначе. Выросла посещаемость — может, просто похолодало. Это основная причина, по которой нужен контроль.

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

Хранение и обезличивание как инженерная задача

Правовая сторона разобрана в следующей статье; здесь — инженерная.

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

Данные	В каком виде	Разумный срок	Примечание
Сырые события с идентификатором браслета	Как есть	Короткий: недели — месяцы	Нужны для разбора претензий и перерасчётов
Связка «браслет — гость»	Отдельно, с ограниченным доступом	По учётной необходимости	Рвётся по истечении срока
Визиты обезличенные	Агрегат на уровне визита	Годы	Основа аналитики за длительный период
Агрегаты по часам и зонам	Числа без идентификаторов	Бессрочно	Ничего личного не содержат
Видеоархив	Запись	По регламенту объекта	Самый тяжёлый и самый чувствительный массив
Записи инцидентов	Выделенное хранение	Дольше обычного архива	Доказательная база

Два технических требования, которые нужно заложить в систему сразу, иначе их придётся встраивать потом:

Процедура обезличивания. Автоматическое удаление связки по расписанию, а не вручную. Если это делается руками, это не делается.

Исполнение запроса субъекта. Гость вправе обратиться за сведениями и удалением. Система должна уметь найти всё по одному человеку и удалить, не разрушив при этом агрегаты. Поэтому агрегаты должны быть обезличены по построению, а не рассчитываться каждый раз из персональных событий.

Интеграции: где всё ломается

Самая недооценённая часть проекта. Ниже — реальные места отказов.

Учётная система (1С и 1С:Фитнес). Из неё приходят тариф, права доступа, абонемент, клиент; туда уходят визиты, доплаты, продажи. Типовые проблемы: разные справочники услуг и зон, расхождение по времени, отсутствие идемпотентности (повторная отправка создаёт второй визит), асинхронность — браслет выдан, а права ещё не доехали.

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

Замки шкафчиков. Самый дешёвый источник данных о том, чем занят гость, и чаще всего неподключённый. Проблемы: автономные замки без сети не отдают события; схема «мастер-ключ открыл всё» ломает статистику.

Система доступа и турникеты. Источник главного знаменателя. Проблема: аварийное открытие и ручные пропуска не фиксируются как проходы, и в данных появляется разрыв — это надо хотя бы логировать как особое событие.

CRM и мессенджеры. Сценарии «гость не доходил до зоны — предложить попробовать», «гость не был три месяца — напомнить». Здесь начинается область, где требуется согласие на маркетинг, и правила рассылки по сетям электросвязи строже, чем кажется.

Отчётность и BI. Нужен один слой, в котором метрики определены однозначно. Если посещаемость считают три разные системы, спор о «правильной цифре» неизбежен; снимается это назначением главного источника для каждой метрики и фиксацией определений в документе.

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

Эксплуатация: чтобы через год это ещё работало

Ответственный с именем. У системы должен быть владелец — человек, который смотрит отчёты и отвечает за их достоверность. Без этого данные деградируют молча.

Мониторинг датчиков. Система обязана сообщать о молчащем датчике. Признак хорошего проекта: есть экран состояния оборудования, и на него кто-то смотрит.

Контроль достоверности. Раз в месяц — сверка двух независимых источников (турникет и счётчик, события браслетов и касса). Расхождение больше порога — повод разобраться, а не подогнать.

Повторный замер точности. Через три-шесть месяцев после приёмки, по тому же протоколу (см. методическую статью). Обстановка меняется, точность дрейфует.

Регламент изменений. Переставили оборудование, открыли новую зону, изменили границы — надо обновить справочник зон и предупредить тех, кто пользуется отчётами. Иначе в данных появляется необъяснимый разрыв, и доверие теряется.

Дашборд: один экран вместо сорока графиков

Практическое наблюдение: чем больше графиков, тем реже их смотрят.

Рабочая схема для управляющего — один экран, который открывается утром за минуту:

• загрузка сейчас и прогноз на вечер по дню недели;
• сравнение сегодняшнего потока с сопоставимым днём;
• три-четыре зоны с наибольшим отклонением от обычного;
• открытые проблемы: незакрытые визиты, молчащие датчики, тревоги за сутки;
• одно действие, которое система предлагает: «на 19:00 ожидается пик, второй администратор на входе».

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

Чек-лист требований к системе

1. Выгрузка сырых событий по API, не только готовые отчёты.
2. Единый идентификатор визита, связывающий события, кассу и замки.
3. Синхронизация времени всех подсистем от единого источника.
4. Один справочник зон на все подсистемы, с версионностью.
5. Разделение контура учёта и контура аналитики.
6. Автоматическое обезличивание по расписанию.
7. Возможность найти и удалить все данные по одному субъекту.
8. Идемпотентный обмен с учётной системой.
9. Экран состояния оборудования и оповещение о молчащих датчиках.
10. Документ с определениями метрик и указанием главного источника для каждой.
11. Понятный владелец системы на стороне объекта.
12. План базового замера и первого эксперимента — до монтажа, а не после.

Источники

Источники

• Конверсионная аналитика в ритейле — определения метрик как отношений с подсчётом в знаменателе
• Тепловые карты и зональная аналитика — практика построения и чтения карт (материал вендора)
• Разбор зональной аналитики: посещения против времени — признак коридора против места назначения
• Обзор видеоаналитики для ритейла, 2026 — состав метрик и ограничения
• Сравнение методов подсчёта и занятости, 2026 — накопление ошибки в метриках занятости