Клиент телеметрии
Отправляет версионированные продуктовые события с ограниченным privacy-safe контекстом.
Состояния отправки
Иллюстрация по теме
Визуальный ориентир помогает быстрее считать сценарий страницы и не оставлять компонент абстрактным.
Контракт телеметрия
| Inputs | event schema + context envelope |
|---|---|
| Outputs | validated telemetry event |
| Failure mode | schema drift, PII leakage, retry storm |
| Ownership | UI владеет представлением и recoverable context; финальное бизнес-состояние подтверждает серверный контракт. |
Версионирование на клиенте
Компонент считается самостоятельной границей только если команда может назвать его входы, выходы и невозможные состояния. Если он требует читать provider-specific поля напрямую или хранит финальный статус операции только локально, граница выбрана слишком поздно.
При изменении контракта сначала обновляется state model и совместимость, затем визуальный слой. Это уменьшает риск ситуации, когда новый UI уже ожидает поле или статус, которого старая версия API не гарантирует.
Связанные разборы
Проверки схемы
- Каждое событие содержит schema version и минимальный context envelope.
- PII и чувствительные payload не проходят client-side allowlist.
- Старая версия приложения может отправлять предыдущую схему без поломки ingest.
- Backoff не создаёт retry storm при деградации analytics endpoint.
- События critical journey можно связать с product outcome без записи лишних персональных данных.
- Отдельно измеряются client_received, state_applied и paint там, где важна live freshness.
Почему телеметрия — отдельный контракт
Telemetry проектируется как versioned contract с privacy граница ответственности. Название DOM-кнопки не должно быть долгоживущей схемой аналитики.
При review команда проверяет не название компонента, а его инварианты: какие данные он имеет право считать финальными, что обязан показать при деградации и как возвращается в согласованное состояние после сбоя.
Схема должна переживать релизы
TelemetryClient добавляет общий envelope, version и контекст соединения, но не знает семантику каждой кнопки. Продуктовое событие именуется по действию или результату, чтобы пережить редизайн интерфейса. Старые и новые версии клиента могут отправлять разные schema version одновременно — pipeline обязан видеть это явно.
Чувствительные поля отсекаются до отправки, а не после попадания в warehouse. При ошибке схемы клиент не должен создавать бесконечный retry-loop.
Связанный маршрут: событие клиента → аналитика.
Какие события нельзя отправлять «как получится»
Telemetry становится бесполезной, когда разные версии клиента отправляют похожие, но несовместимые события, а downstream-системы угадывают смысл по названиям. У компонента должен быть свой контракт: версия схемы, правила буферизации и понятное поведение при отказе сети. Эту логику удобно сверять с разбором telemetry contract для frontend и backend.