Вы включили семплирование 10% для высокочастотного события scroll (в instrumentation оно отправляется не всегда). Как сделать так, чтобы аналитика и data quality не пострадали?
AНичего не делать: семплирование не влияет на выводы, потому что выборка большая.
BЛогировать
sample_rate в properties и использовать веса при расчётах, а критичные для user journey события не семплировать.CУбрать
sample_rate, чтобы не путать аналитиков, и считать как обычные события.DСемплировать только «плохих» пользователей, чтобы быстрее находить проблемы.
Правильный ответ. При семплировании важно фиксировать
sample_rate и не семплировать события, которые являются основой воронок и инвариантов.Разбор
Без знания sample_rate вы не сможете корректно восстанавливать оценки и сравнивать периоды. Для событий поведения вроде scroll семплирование может быть нормальным, но для событий успеха и шагов user journey оно ломает конверсии и invariants. Поэтому обычно разделяют: высокочастотные события можно семплировать, а ключевые — нет. Явная фиксация семплирования делает расчёты воспроизводимыми и защищает data quality.
Проверь себя · 1/3разбор после ответа
Вы описываете
event taxonomy для purchase_succeeded. Как лучше хранить сумму покупки в properties, чтобы избежать проблем data quality при агрегациях?Ещё вопросы по теме «Инструментация и качество данных»
- Вы проектируете `event taxonomy` для регистрации. Какой вариант `instrumentation` лучше всего подходит, чтобы считать конверсию в успешную регистрацию и понимать, через какой способ вошли?
- Вы хотите логировать применение фильтров в каталоге. Какой вариант лучше для `event taxonomy` и последующей аналитики?
- Вы настраиваете мониторинг `data quality` для платёжного флоу. Какой набор `invariants` наиболее практичен и устойчив к сезонности?
- После обновления SDK вы видите, что сумма по `purchase_succeeded` выросла почти в 2 раза, но платежный провайдер этого не подтверждает. Что наиболее вероятно и какое действие по `data quality` самое уместное?
- В мобильном приложении события могут копиться офлайн и отправляться позже. Какие поля времени лучше заложить в `logging`, чтобы корректно строить `user journey` и контролировать задержки?
- Все вопросы по «Инструментация и качество данных» →