«События идут» — не значит «данным можно верить»: 4 метрики надёжности ingestion

Типичная картина: дашборд “просел”, продукт спорит с маркетингом, аналитик лезет в SQL и находит “дырку” в событиях. Самое дорогое тут даже не неверное решение. Дороже — потеря доверия: после пары таких историй любые цифры начинают воспринимать как мнение.

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

Минимальный стандарт SLO и мониторингов для event ingestion — это 4 вещи:

  1. Доля потерь (loss rate) Считайте не “сколько приняли”, а “сколько должны были принять”. Нужен контрольный объём: от клиентских счётчиков отправки, от очереди, от edge, от SDK. Без опорной точки “потери” превращаются в гадание.

  2. Задержка доставки (delivery latency) Смотрите распределение, а не среднее: хвосты убивают эксперименты и дневные метрики. В отчётах по качеству это должно жить как freshness: насколько данные “созрели” к моменту расчёта.

  3. Дубликаты (duplicate rate) Дубли делают “рост” там, где его нет, и ломают воронки. Отдельно мониторьте дубли по ключам (event_id, user_id + timestamp + event_name — что у вас считается уникальностью) и по причинам (ретраи, переотправка батча, переигрывание топика).

  4. Ошибки схемы (schema/contract errors) Любая несовместимость версии SDK, изменения типов, отсутствие обязательных полей — это тихая потеря. Мониторинг должен показывать: какие поля чаще всего валятся, на каких платформах/версиях, и куда эти события деваются (в карантин, в “битое”, в никуда).

Как отражать это в data quality отчётах, чтобы не было самообмана:

  • Показывайте статус по каждому event_name отдельно: общий “pipeline green” бесполезен
  • Разрезы обязательны: платформа, версия приложения/SDK, регион, источник (web/app/server)
  • Фиксируйте окно зрелости данных: когда цифры считаются окончательными, а когда предварительными
  • Разводите “нет данных” и “ноль”: это разные бизнес-реальности
  • Храните историю качества рядом с метриками: чтобы любой провал метрики можно было сразу сопоставить с провалом ingestion

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