Коротко
Парковочный дашборд часто начинается с крупной цифры «занято 78%». Но без контекста она может быть неверной: часть камер offline, места в ремонте попали в знаменатель, данные сняты только в рабочее время, а реконфигурация зоны изменила ёмкость посреди периода.
Хорошая аналитика начинается не с графика, а с паспорта данных.
Перед KPI: четыре вопроса о данных
- Что является событием? Наблюдение камеры, подтверждённый переход, проход через границу или ручная правка.
- Какой scope? Объект, уровень, зона, тип места или группа.
- Какой знаменатель? Физические, доступные или места с доверенным статусом.
- Как учитывается неизвестность? Исключается, показывается отдельно или делает интервал непригодным.
KPI 1. Фактическая занятость — occupancy rate
Базовая формула для момента времени:
occupied trusted spots / trusted available spots × 100%.
Почему не всегда occupied / total: место в ремонте физически существует, но не должно снижать показатель использования доступного фонда. Место без данных требует отдельного решения.
Публикуйте вместе:
- occupancy;
- available capacity;
- unknown share;
- время/интервал.
Ловушка: сравнивать зоны с разной долей unknown.
KPI 2. Пиковая занятость
Максимальная занятость за интервал или устойчивый высокий процентиль. Абсолютный максимум может быть одиночной ошибкой, поэтому полезнее показывать p95 и длительность превышения порога.
Вопрос: сколько минут/интервалов объект находился выше 90%, а не только «достигал ли 100%».
KPI 3. Оборачиваемость места — turnover
число завершённых парковочных сессий / число доступных мест / период.
Для per-space событий сессия требует корректного определения начала и конца. Дребезг free↔occupied не должен создавать дополнительные визиты.
Ловушка: считать каждое изменение камеры отдельным автомобилем.
KPI 4. Длительность стоянки
Медиана, p75/p95 и распределение лучше среднего. Один автомобиль, оставленный на неделю, искажает mean.
Сегментируйте по:
- зоне и типу места;
- времени въезда;
- сотрудник/гость, если есть законный и корректный атрибут;
- завершённым и цензурированным активным сессиям.
Ловушка: включить незавершённые сессии как нулевые.
KPI 5. Поток между зонами
Количество наблюдений/уникальных перемещений по зонам за интервал. Нужны обзорные камеры или контролируемые рёбра графа.
CShark принимает device.camera.zone_observation, доверенно связывает camera→zone и публикует domain.vehicle.zone_observed. PGS flow endpoint формирует аналитический срез.
Ловушка: считать повторное наблюдение одного автомобиля новым потоком без дедупликации.
KPI 7. Uptime и влияние оборудования
Обычный uptime камеры не показывает бизнес-эффект. Добавьте:
- количество затронутых мест;
- время недостоверности;
- критичность зоны;
- повторные отказы;
- MTTD и MTTR.
KPI 8. Инциденты: MTTA, MTTR, SLA
- MTTA — от создания до взятия в работу;
- MTTR — до решения;
- SLA breach rate — доля просроченных;
- reopen/repeat rate — повтор по тому же месту/источнику;
- доказательные материалы completeness — доля с кадром/видео и причиной.
Ловушка: улучшить MTTR массовым ignore без анализа причин. Статусы решения нужно показывать отдельно.
KPI 9. Ручные вмешательства
Количество ручных открытий, смен статуса и отмен по reason code и роли. Это показатель не «плохих операторов», а мест, где автоматический процесс недостаточен.
Нужен серверный аудит, а не только фронтовая аналитика. CShark пишет действия в AuditLog.
KPI 10. Результативность клиентского поиска
Для сервиса find-car:
- число безопасно scoped запросов;
- доля найденных результатов;
- время до результата;
- CAPTCHA/rate-limit failures;
- обращения в поддержку до/после;
- false match.
Не храните поисковую строку без необходимости. В CShark предусмотрены fingerprint/audit и ограниченная выдача.
Что нельзя вычислить без дополнительного контура
Доход, средний чек, потери выручки и конверсия оплаты требуют платёжных/фискальных данных. Текущий CShark имеет тарифные расчёты, но не завершённый payment/ОФД-контур. Поэтому маркетинговый дашборд «выручка выросла» допустим только из согласованных клиентских систем и с описанной сверкой.
Как строить сравнение до/после
1. Зафиксировать гипотезу
Например: «новая навигация уменьшит медианное время от въезда до занятия места в зоне B».
2. Определить событие начала/конца
Въезд зафиксирован контрольной линией; занятие места — подтверждённым переходом, а не отправкой команды.
3. Выбрать сопоставимые периоды
Одинаковые дни недели, сезон, события, число доступных мест и режим работы.
4. Зафиксировать контрольные факторы
Ремонт, изменение тарифов, арендаторы, новая разметка, погода, поломки камер.
5. Показать распределение
Медиана, p95, выборка и confidence interval после расчёта, а не одна средняя.
6. Сохранить методику
SQL/endpoint, timezone, фильтры, исключения и version продукта. Иначе результат нельзя повторить.
Паспорт KPI — шаблон
| Поле | Пример |
|---|---|
| Название | Доля доверенно свободных мест |
| Владелец | директор по эксплуатации |
| Цель | качество навигации |
| Формула | trusted free / trusted available |
| Источник | spot events + topology |
| Scope | site 1, zones A–D |
| Интервал | 5 минут |
| Timezone | Europe/Moscow |
| Unknown policy | показывать отдельно; >5% делает интервал invalid |
| Исключения | planned maintenance |
| Версия | версия релиза |
| Проверка | ручная выборка N=согласованный размер выборки |
FAQ
Occupancy и utilization — одно и то же?
Термины используют по-разному. Зафиксируйте формулу. Occupancy чаще описывает долю занятых мест в момент/интервал, utilization может учитывать время использования ресурса.
Как считать turnover без въездной системы?
По подтверждённым циклам free→occupied→free с защитой от дребезга. Но связать цикл с конкретным визитом и типом клиента без сессии сложнее.
Что делать с неполными данными?
Показывать unknown/coverage, устанавливать порог пригодности интервала и не восстанавливать пропуски без документированной модели.
Какой период до/после нужен?
Зависит от трафика и сезонности. Обычно нужны несколько сопоставимых недель, но окончательный размер выборки рассчитывается под метрику и вариативность.
Можно ли измерить рост выручки в CShark?
Только если подключены достоверные данные платежей/сессий и согласована сверка. Текущий продуктовый scope не включает полный платёжный контур.
Граница применимости к CShark
Материал описывает проверяемый инженерный подход. Конкретный состав CShark зависит от версии, подключённых источников данных, прав, конфигурации и приёмки оборудования на объекте.
Посмотрите, какие возможности CShark доступны водителю и оператору и как они применяются на парковке, на странице возможностей системы.