Если ваш сервис событий “зелёный”, но вы не меряете эти 4 метрики — “данные есть” не значит “данным можно верить”.

Типичная картина: дашборды обновляются, таблицы растут, аналитики строят воронки. А потом внезапно “просели конверсии”, “сломалась атрибуция”, “А/Б не сходится”. И выясняется, что проблема не в продукте, а в доставке событий. Цена ошибки всегда одна: решения принимают на шуме, а спорят так, будто это реальность.

Почему это происходит: ingestion почти никогда не ломается красиво. Он деградирует. Чуть больше ретраев, чуть больше очереди, чуть больше таймаутов, чуть больше версий клиента в проде. В итоге у вас одновременно появляются потери, задержки, дубликаты и “кривые” события. Если это не подсвечено как качество данных, бизнес видит “эффект”, а не “сбой измерений”.

Минимальный стандарт надёжности event ingestion, который должен жить в SLO и мониторингах:

  1. Доля потерь (loss rate). Считайте не “сколько приехало”, а “сколько не доехало”: по каждому источнику и типу события. Лучший сигнал — сверка счётчиков отправлено/принято по одному и тому же ключу (app version, platform, event_name).

  2. Задержка доставки (delivery latency). Не средняя, а перцентили и хвост. Отдельно по очереди и по пайплайну до витрины. И отдельно по времени события (event_time) и времени приёма (ingest_time), иначе вы “лечите” не то.

  3. Дубликаты (duplicate rate). Дубликаты часто выглядят как рост метрик и “улучшение” эксперимента. Нормальная практика — стабильный id события, идемпотентная запись и мониторинг доли совпадений по этому id (или по детерминированному набору полей).

  4. Ошибки схемы (schema error rate). Любая несовместимость версии, неожиданный enum, пропавшее обязательное поле должна уходить в отдельный поток (quarantine/dead letter), считаться и разрезаться по версии клиента и SDK. Иначе вы просто теряете события молча.

Как это отражать в data quality отчётах: не “всё ок/не ок”, а статус по каждому продукту и событию с разбивкой по платформе и версии, плюс тренд и алерты на деградацию. В правильной практике аналитик видит: метрика изменилась, и рядом видно, что выросла задержка или поползли дубликаты.

Граница применимости простая: если у вас нет бизнес-решений на этих данных, можно жить без SLO. Как только появляются эксперименты, бюджет, KPI и бонусы — эти 4 метрики перестают быть “инфрой” и становятся частью аналитики. Обычно спорят про “порог допустимо/недопустимо”, но без самих измерений спорить не о чем.