Events — как продукт сообщает “что произошло”

4.1 Цель

События — это способ превратить “кажется стало лучше” в измеримые данные: что показали, что нажали, что купили, что сломалось. Механизм принятия решения отвечает на вопрос “что нужно показать” (какие значения флагов применить). Чтобы считать метрики, контролировать качество и списывать стоимость показов, платформа должна принимать от продукта события о том, что реально произошло после решения.

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

4.2 Типы событий

В платформе нет “зашитого навсегда” списка событий.
События — это договор между продуктом и платформой, и этот договор можно расширять через админку.

4.2.1 Каталог событий

В админке поддерживается каталог типов событий:

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

Backend использует каталог для:

• валидации входящих событий (чтобы “левые” типы не ломали аналитику),
• нормализации (одинаковые названия/поля для всех команд),
• маршрутизации в хранение/стрим (чтобы дальше отчёты и уведомления работали предсказуемо).

4.2.2 Стандартные и пользовательские события

Чтобы платформа работала “из коробки”, в каталоге может быть заведён минимальный базовый набор (например, событие «экспозиция» как факт показа — он нужен для корректной атрибуции).
А всё остальное — пользовательские события под конкретную фичу:
«просмотр экрана», «клик по кнопке», «добавление в избранное», «успешная покупка» — любые, которые вам реально нужно мерить.

Как это выглядит в лоре: продакт говорит Лотти “хочу понять, стали ли люди чаще добавлять книгу в избранное”.
Лотти заводит в админке тип события «клик по добавлению в избранное» (и ещё тип события «просмотр карточки книги») — и после этого продукт/бек начинает слать эти события, а платформа принимает их по общим правилам.

4.3 Идентификация и дедупликация

В истории: приложение может ретраить отправку (интернет упал), поэтому платформа должна уметь не считать одно и то же событие дважды.

Сложно построить аналитику, если одно событие будет засчитано несколько раз — нужно предусмотреть механизмы защиты от этого.

4.4 Атрибуция

4.4.1 “Считаем только то, что реально показали”

Боль, которую Лотти уже ловил на прошлых релизах: если считать “конверсии” без факта показа — метрики становятся мусором.

Поэтому в каталоге событий (см. 4.2) для каждого «тип события» задаётся политика атрибуции, например:

• правило «требует факта показа» — событие учитывается только если по тому же «идентификатор решения» есть факт показа (обычно это событие категории «экспозиция»).

Важно: какие именно типы требуют факта показа, не зашито в коде.
Команда настраивает это в админке: для кликов/покупок/ошибок/латентности обычно включает это требование, а для технических/фоновых событий — нет.

4.4.2 События могут приходить не по порядку

Платформа должна корректно работать, если события приходят не по порядку.

Типичный кейс из жизни: событие «клик по добавлению в избранное» прилетело раньше, чем событие «экспозиция» (сеть/батч/ретраи). Считаем, что более старое событие придёт не позднее, чем через 7 дней после более нового.

4.5 Требования к приёму и ответу

В истории: продукту важно быстро понять “приняли событие или нет”, чтобы не держать очередь бесконечно и не забивать сеть. При приёме пачки событий платформа должна:

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