📊 Статистика и теория вероятностей

Короткий ответ Методология должна включать стандартизированный шаблон гипотезы и метрик, централизованный расчёт размера выборки и мощности, автоматическую проверку на SRM и качество рандомизации, единые правила остановки теста, и механизм пост-анализа с контролем множественных сравнений при одновременных экспериментах — единого "правильного" процесса для всех компаний не существует. Как это работает подробнее стандартизация снижает риск типичных ошибок (peeking, отсутствие power-анализа, конфликтующие одновременные тесты на одной аудитории) и делает результаты экспериментов сравнимыми между командами, так как все используют одни и те же определения метрик и правила принятия решений. Sanity check: провести ретроспективный аудит последних N тестов на предмет SRM и соблюдения заявленной длительности — доля нарушений процесса — хороший индикатор зрелости методологии. Пример кода Что использовать на практике Зрелая экспериментальная платформа включает: централизованный каталог метрик с едиными формулами (чтобы ра

Читать полностьюab-testing

Короткий ответ Нужно явно отделить статистический вывод ("эффект, скорее всего, не ноль") от управленческого решения ("стоит ли внедрение") и сопоставить размер эффекта с заранее согласованным порогом практической значимости, учитывая стоимость разработки, поддержки и возможные риски — единственного правильного решения здесь нет, оно зависит от стратегии и приоритетов. Как это работает подробнее статистическая значимость при больших выборках легко достигается даже для экономически незначимых эффектов, потому что p-value чувствителен и к размеру эффекта, и к размеру выборки одновременно — малый, но стабильно воспроизводимый эффект технически "реален", но может не оправдывать затраты. Sanity check: пересчитать абсолютный эффект в деньгах/заказах в месяц на реальном масштабе аудитории — если цифра значима в абсолютном выражении, несмотря на малый процент, это весомый аргумент даже при скромном относительном эффекте. Пример кода Что использовать на практике Решение должно учитывать совокупную стоимость владения и

Читать полностьюeffect-size

Короткий ответ Резкий скачок или провал метрики, который начинается точно в день релиза/изменения в системе трекинга (а не постепенно) и не сопровождается аналогичным изменением в смежных, независимо собираемых метриках — явный признак технического разрыва, а не реального поведенческого изменения. Как это работает подробнее изменение способа сбора данных (новая версия SDK, смена атрибуции событий, фильтр ботов, изменение логики дедупликации) может резко сдвинуть абсолютные значения метрики, при этом реальное поведение пользователей не изменилось. Пример кода Что использовать на практике На практике. первый шаг диагностики — сопоставить дату скачка с журналом релизов и деплоев (не только продуктовых, но и инфраструктурных/аналитических). Второй шаг — проверить, согласуется ли изменение с независимым источником (например, если выручка по данным платёжного шлюза не изменилась, а «выручка» по внутренней аналитике скакнула — проблема в трекинге). Третий шаг — посмотреть, меняется ли структура данных (появились нов

Читать полностьюchange-point

Короткий ответ Нужно последовательно сравнить определения метрики (та ли формула, тот же ли фильтр по статусам/датам), часовые пояса и границы периодов, этапы ETL-пайплайна (дедупликация, фильтры, джойны) и момент снятия снимка данных (дашборд мог закэшироваться раньше, чем обновился источник). Как это работает подробнее расхождение почти никогда не возникает "само по себе" — оно всегда объясняется конкретным отличием в способе расчёта или моменте среза данных; задача диагностики — методично исключать гипотезы от простых (другой часовой пояс) к сложным (ошибка в логике трансформации). Sanity check: пересчитать метрику дашборда вручную по тем же фильтрам и часовому поясу, что в первоисточнике — если числа сходятся, причина расхождения найдена и её нужно задокументировать для обеих сторон. Пример кода Что использовать на практике Эффективный порядок проверки: (1) сравнить SQL-определение метрики на дашборде с определением в первоисточнике — часто разница в фильтре статусов заказа (включены ли отменённые/возврат

Читать полностьюdashboard

Короткий ответ Коэффициент Пирсона r принимает значения от −1 до 1 и измеряет силу и направление линейной связи между двумя количественными переменными: r близко к 1 — сильная положительная связь, к −1 — сильная отрицательная, около 0 — линейной связи почти нет. Как это работает подробнее r считается через ковариацию переменных, нормированную на произведение их стандартных отклонений; формула чувствительна именно к линейной зависимости. Диапазон коэффициента универсален для любых количественных данных, что делает его удобным для быстрого сравнения разных пар переменных. Пример кода Что использовать на практике На практике: перед использованием r стоит визуализировать данные на scatter plot — коэффициент может быть близок к нулю даже при сильной нелинейной связи (например, параболической), и наоборот, один-два выброса могут создать иллюзию сильной корреляции при её отсутствии в основной массе данных. Значение r ничего не говорит о причинности и о наклоне линии (это разные величины). На практике также полезно c

Читать полностьюcorrelation

Короткий ответ Оконные функции позволяют считать агрегаты (среднее, сумму, процентиль) по «окну» строк, связанному с текущей строкой, не сворачивая результат в одну строку на группу, как это делает GROUP BY; для скользящего среднего используют AVG(...) OVER (ORDER BY ... ROWS BETWEEN ... AND CURRENT ROW). Как это работает подробнее конструкция OVER (PARTITION BY ... ORDER BY ... ROWS/RANGE BETWEEN ...) определяет для каждой строки своё окно соседних строк, по которому и считается функция; ROWS считает окно по числу строк, RANGE — по значениям (например, по дате). Пример кода Что использовать на практике На практике. скользящее среднее полезно для сглаживания шумных временных рядов перед визуализацией трендов (например, 7-дневное скользящее среднее для устранения недельной сезонности). Для расчёта процентилей внутри группы на лету используют PERCENTILE_CONT(...) OVER (PARTITION BY ...) (поддержка синтаксиса отличается между PostgreSQL, BigQuery, ClickHouse — стоит проверять документацию конкретной СУБД). Важно

Читать полностьюmoving-average

Короткий ответ На масштабе компании с десятками одновременных тестов и множеством проверяемых метрик в каждом стоит применять централизованную поправку на множественные сравнения (например, Benjamini-Hochberg) на уровне всего портфеля значимых находок за период, а не оставлять каждую команду контролировать свой альфа независимо — единого стандарта здесь нет, выбор зависит от того, что организация готова считать "семьёй" гипотез для контроля. Как это работает подробнее если каждая из множества команд независимо тестирует на уровне альфа=0.05, ожидаемое число ложных "успешных" экспериментов в масштабе компании растёт линейно с числом тестов — при 200 тестах в квартал без реального эффекта в среднем около 10 из них покажут случайную значимость. Поправка на FDR на уровне компании (а не отдельной команды) контролирует долю таких ложных находок среди всех объявленных "успешными" экспериментов. Sanity check: сравнить число экспериментов, признанных "успешными" до и после поправки — заметное сокращение числа значимых

Читать полностьюbenjamini-hochberg

Короткий ответ Нужно систематически проверять, на каком этапе жизненного цикла данных (сбор события, фильтрация, агрегация, выбор знаменателя метрики) может закладываться систематическое искажение в пользу определённых сегментов пользователей, и явно сверять ключевые метрики с независимыми источниками правды — единого чек-листа для всех продуктов нет, набор рисков зависит от архитектуры трекинга и бизнес-модели. Как это работает подробнее системные смещения редко видны в самой формуле метрики — они чаще скрыты в том, что метрика структурно не замечает (например, retention, считающийся только по пользователям, завершившим онбординг, автоматически исключает самых проблемных пользователей, которые отвалились раньше), или в том, как работает сам продукт и трекинг (платящие пользователи с более быстрым интернетом логируются надёжнее, чем пользователи на медленном соединении, которые чаще "теряются" из выборки). Sanity check: сравнить долю пользователей с сбоями среди ответивших на опрос и среди всех пользователей

Читать полностьюbias

Короткий ответ Дубликаты обычно ищут через GROUP BY по ключевым полям с HAVING COUNT(*) > 1, либо через оконную функцию ROW_NUMBER() для более гибкого определения «что считать дублем». Как это работает подробнее GROUP BY + HAVING COUNT(*) > 1 группирует строки по выбранным колонкам и оставляет только те группы, где больше одной строки — это и есть дубликаты по этим колонкам. ROW_NUMBER() OVER (PARTITION BY ... ORDER BY ...) присваивает номер строкам внутри группы, что удобно для выбора «оставить только первую запись». Пример кода Что использовать на практике На практике: перед поиском дублей нужно явно решить, что считается дублем: полное совпадение всех полей, или совпадение по бизнес-ключу (например, email) при разных ID. Часто дубли возникают из-за повторной отправки формы, сбоя интеграции или отсутствия уникального ограничения в таблице — стоит не только почистить данные, но и найти источник проблемы. Полезно также проверять, не возникают ли дубли систематически в определённый период (например, после сбоя

Читать полностьюdata-quality