Аудит-лог в веб-приложении не равен продуктовой аналитике: по нему нельзя честно мерить метрики и A/B
Типичная картина: разработчики “уже логируют всё важное”, а аналитик пытается собрать воронку, ретеншн, влияние фичи и быстро упирается в кашу. События есть, но пользователей “двое”, конверсии скачут, эксперимент “победил” из‑за повторной отправки, а часть действий пропала из-за задержек. Цена ошибки простая: команда принимает решения по шуму и потом долго спорит, “почему данные опять не сошлись”.
Почему так происходит: аудит-лог фиксирует факт изменения (кто и что поменял), а аналитика требует воспроизводимого поведения пользователя во времени. Для метрик важны границы сессий, идентичность человека и устройства, единая семантика событий, стабильные источники истины и предсказуемая доставка. Если этого нет, вы не измеряете продукт — вы пересказываете инфраструктурные артефакты.
Минимальный стандарт, без которого event/audit-логи не пригодны для метрик и экспериментов:
- Схема событий: названия, обязательные поля, версия, контракт “что считается событием”, и запрет на “события по настроению”. Изменили смысл — подняли версию, а не перезаписали прошлое.
- Идентификаторы: user_id (стабильный), anonymous_id (до логина), device/session, и чёткие правила склейки. Если склейка “как получится”, все метрики про пользователей становятся художественными.
- Дедупликация: event_id, идемпотентность, явное различие “показали” vs “подтвердили” vs “доставили”. Ретраи и двойные клики должны превращаться в один факт поведения, а не в “рост”.
- Источники истины: что берём из клиента, что из бэка, что из базы. Клиент хорош для UI, но плох как единственная правда для денег, прав и статусов. Должна быть понятная иерархия.
- Задержки и права доступа: SLA на появление данных, правила late events, и доступ к сырым логам без утечки персональных данных. Если аналитик видит только “агрегаты”, вы теряете проверяемость и отладку.
В правильной практике audit-лог остаётся для комплаенса и расследований, а продуктовые события проектируются как интерфейс измерения: их можно переиграть, объяснить, сравнить между релизами и использовать в A/B без сюрпризов. Исключение одно: если вам нужна только техническая трассировка инцидентов, не притворяйтесь, что это аналитика продукта. Обычно спорят именно про это: “нам же достаточно логов” — пока не приходит время принимать решения.
