Аудит-лог в вебе не заменяет продуктовую аналитику: на таком логе метрики “красивые”, но неверные.

Типичная картина: разработчики честно пишут “user updated profile”, “order created”, “button clicked”, и дальше BI строит воронки. Через неделю выясняется, что конверсия пляшет, события дублируются, а A/B “ничего не показывает”. Цена ошибки простая: команда спорит не о продукте, а о том, чьим данным верить, и откатывает решения из-за недоверия к цифрам.

Почему так ломается: у audit-лога другая цель. Он фиксирует факт “что-то произошло” для разборов и безопасности. Аналитике же нужна повторяемая семантика события, стабильные идентификаторы, понятные границы “что считается попыткой/успехом”, и контроль задержек. Плюс веб по природе шумный: ретраи, офлайн, обновления вкладок, блокировщики, двойные отправки, события “вылетели” из очереди и догнались позже.

Минимальный стандарт, чтобы event/audit-логи стали пригодны для метрик и экспериментов:

  1. Схема событий и контракт версий. Название + обязательные поля + что считается “успехом”. Любое изменение поля или смысла — новая версия, а не тихий “мы чуть переименовали”.

  2. Идентификаторы, которые переживают реальность. user_id (если есть), анонимный id до логина, session_id, request_id/trace_id, и главное — event_id для дедупликации. Без event_id вы не отличите повторную доставку от реального повторного действия.

  3. Дедуп и “ровно один раз” как продуктовое требование. Явно решите, где режете дубли: на клиенте, на приёме, в стриме, в витрине. И одинаково для всех потребителей, иначе разные команды увидят разные метрики.

  4. Источник истины для ключевых фактов. Заказы, оплаты, подписки, статусы — обычно должны подтверждаться сервером/БД, а не кликом в интерфейсе. UI-события полезны, но как поведение, не как “свершившийся факт”.

  5. Задержки и доступы. Храните event_time и ingest_time, чтобы видеть лаги и пересчёты. Ограничьте доступ к сырым данным и PII, но обеспечьте воспроизводимость метрик: кто и как считал должен быть проверяемо.

Правильная практика выглядит так: audit-лог живёт для расследований, а продуктовые события — отдельный контракт, который можно тестировать, версионировать и валидировать на качество данных. Спор обычно возникает про “зачем усложнять”, но усложнение не ради красоты: оно покупает одно — доверие к метрикам и честные эксперименты. Для комплаенса достаточно audit; для решений о продукте — нет.