Вы включили семплирование 10% для высокочастотного события scroll (в инструментировании событий оно отправляется не всегда). Как сделать так, чтобы аналитика и качество данных не пострадали?

AНичего не делать: семплирование на больших объёмах не влияет на выводы и не требует поправок на стороне расчётов
BЛогировать sample_rate в свойствах события и применять веса в расчётах, а критичные для пути пользователя события не семплировать
CПрименять единую константу семплирования 10% ко всем событиям продукта, чтобы аналитика считала метрики без пересчёта весов
DСемплировать события по user_id хешу с фиксированной долей и не учитывать долю в расчётах: коэффициент примерно сократится в формулах
Правильный ответ. При семплировании важно фиксировать sample_rate и не семплировать события, которые являются основой воронок и инвариантов.

Разбор

При семплировании высокочастотных событий критично сохранить возможность правильно пересчитывать метрики. Поэтому в само событие кладут поле sample_rate (или эквивалент), а в SQL-агрегациях умножают COUNT(*) на обратный коэффициент. Критичные события (покупка, регистрация) не семплируют вовсе — они и так редкие. Делать единый коэффициент на все события — терять на критичных. Игнорировать долю в расчётах работает только для долей и средних, но ломается на абсолютных счётчиках, и в пересечении когорт даёт смещение.

Тренировать продукт в Telegram

Ещё вопросы по теме «Инструментация и качество данных»