Контракт телеметрии: события, версии и граница приватности

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

green_button_click переживёт ровно один редизайн. Имя события описывает действие или результат домена: market_selection_opened, betslip_quote_requested. Визуальный элемент уходит в properties, если он действительно нужен для анализа.

Контейнер и версия

Каждое событие несёт schema version, event name, happened_at, anonymous/session identifiers в допустимом объёме и общий product context. Gateway валидирует структуру до отправки в downstream. Некорректное событие не «чинится» молча.

Строгая схема замедляет импровизацию, но экономит расследования

Свободный JSON удобен в первый день и дорог через полгода: одно поле оказывается string, number и null в трёх приложениях. Небольшой schema registry и совместимые изменения дают дисциплину без тяжёлой платформы данных.

Граница приватности до хранилища

Клиенту вообще не выдаются лишние идентификаторы ради аналитики. Gateway имеет allowlist полей и отбрасывает запрещённые свойства. Для чувствительных продуктовых действий полезно хранить агрегируемый технический контекст, а не свободный текст.

Лавина телеметрии после ошибки интерфейса

Ошибка рендера может отправлять событие на каждом re-render. SDK ограничивает размер batch и частоту однотипных событий, а gateway имеет rate guard. Иначе аналитический канал сам становится эксплуатационной проблемой.

Как сохранить аналитику полезной после редизайна

Событие, названное по кнопке или конкретному экрану, быстро устаревает. Лучше описывать действие пользователя и контекст: market_opened, selection_added, stream_resync_started. Тогда интерфейс можно переработать, не ломая историческую сопоставимость отчётов.

Общий envelope помогает связывать frontend и backend наблюдения: версия схемы, session/request id, product surface и технический context. При этом privacy граница ответственности нужно определить до отправки: персональные и чувствительные значения не должны «временно» попадать в telemetry в надежде очистить их позже.

• Версионировать schema и валидировать события на приёме.
• Не включать свободный пользовательский текст без явной необходимости.
• Следить за долей rejected events и неизвестных версий схемы.

Событие должно пережить редизайн кнопки

Если analytics event называется green_button_clicked, следующий redesign ломает смысл данных. Лучше назвать событие по продуктовой семантике — например, bet_quote_requested — и отдельно передать screen/context. Тогда frontend может менять визуальную композицию, а временной ряд остаётся сопоставимым.

TelemetryClient отвечает за общий envelope, version и локальную фильтрацию, но не должен тихо добавлять персональные поля «на всякий случай». Privacy граница ответственности фиксируется до отправки: что разрешено собирать, что агрегируется, а что не покидает устройство.

После rollout полезно смотреть schema reject rate по app/web version. Резкий рост означает, что клиент и pipeline разошлись в контракте; это инженерная ошибка, а не повод отключить валидацию ради зелёного dashboard.

Сначала качество схемы, потом панели мониторинга

Полезно видеть validation reject rate по version, долю неизвестных событий и лаг ingest. Если эти сигналы плохие, красивый продуктовый график поверх данных лишь скрывает проблему качества.