Статистика и R в науке и аналитике

Поведенческая секция: «Расскажите о случае, когда вы не согласились с продактом»

Продолжаем тему собеседований!

В РФ подобные вопросы чаще всего встречаются на финалах с командами, обычно вместо/вместе с задачами на кейсы (кейсы разбирали в прошлый раз). В Европе behavioral секция чаще всего отдельный созвон на час-полтора.

Кажется простой секцией, но у меня самой были проблемы со структурированием ответа и вообще пониманием того, какой ответ ожидается. Поэтому сегодня разберем, что хотят услышать на этой секции, как структурировать поток мысли и что отвечать не надо.

На behavioral интервью основная задача узнать:
- умеете ли вы отстаивать выводы из данных и при этом не ломать отношения с командой
- берёте ли ответственность на себя или ищете виноватых
- понимаете ли бизнес-контекст, а не только p-value
- можете ли рассказать историю так, чтобы за ней было легко следить

Один из рекомендованных фреймворков для структурирования ответа: STAR.

🟡Структура ответа по STAR

S – Situation: контекст, 1–2 предложения
T – Task: ваша роль и задача
A – Action: что конкретно сделали вы (это самая большая часть ответа)
R – Result: чем всё закончилось, лучше в цифрах, и что вы из этого вынесли

Другие похожие фреймворки: PAR (Problem, Action, Result), CARL (Context, Action, Result, Learning) и другие, но STAR самый универсальный.

🟡Пример ответа:

S: Я работала аналитиком в приложении для изучения языков. Продакт планировал запускать оплату в один клик через Apple/Google Pay и хочет раскатить на всех до 1 сентября и оценить эффект по схеме "до-после": сентябрь против августа.

T: Моя задача – оценить эффект на выручку так, чтобы ему можно было доверять, и не сорвать запуск к сезону.

A: Показала, что "до/после" не сработает: сентябрь сам по себе дает рост конверсии, плюс в это время большая маркетинговая кампания. Продакт предложил компромисс: раскатить сначала на Android и сравнить с iOS через DiD. Я проверила параллельные тренды на исторических данных – не выполняются: на iOS недавно меняли цены. Предложила два варианта: A/B на обеих платформах (крутить три недели) или DiD, которому я бы сама не доверяла. Главный аргумент – риск: если фича плохая, при 100% раскатке узнаем об этом уже после сезона.

R: Договорились на A/B, конверсия в оплату выросла на 7%, но люди стали чаще брать месячный тариф вместо годового, и выручка на платящего упала. Сделали годовой тариф выбором по умолчанию – эта версия дала рост выручки, ее раскатили на всех. Мой вывод: спор выигрывается не аргументом «так правильно по методологии», а тем, что ты показываешь продакту риски в его терминах.

Рекомендация: хорошо, если в вашей истории продакт тоже был в чем-то прав, например насчет сроков. Так вы выглядите аналитиком партнером бизнеса, а не статистическим душнилой (это я).

Тайминг ответа: 2-3 минуты обычно достаточно

🟡Как отвечать не надо

✖«Продакт хотел раскатить фичу без теста, я сказала, что так нельзя, и в итоге мы провели A/B». Без аргументов и мотивации продакта звучит недостаточно убедительно.

✖«Я не спорю с продактами, у нас все всегда согласовано».
Это конечно круто, если так, но интервьюер может подумать, что у вас нет своей позиции.

✖«Я пошла к руководителю, и он поддержал мое решение»
Эскалация как первый шаг = вы не умеете договариваться сами.

✖Три минуты про параллельные тренды и проблему множественного тестирования
Здесь оценивают коммуникацию, так что можно не фокусироваться особо на технических деталях.

🟡Примеры вопросов на секции

- Что вы делаете со срочными влетающими задачами?
- Расскажи про свой самый большой фейл в аналитике (мой любимый вопрос).
- Приведи пример исследования, которое реально изменило продуктовый бэклог или стратегию (такой тип вопросов особенно любят в наших бигтехах).

Больше вопросов тут.

🟡Как готовиться к секции

Заготовьте 5–6 универсальных историй из своего опыта (успешный проект, факап, конфликт со стейкхолдером, сложная аналитическая задача, работа в условиях дедлайна). Одну историю часто можно адаптировать под 2–3 разных вопроса.
Выпишите ключевые метрики заранее: рост конверсии, сэкономленное время, сокращение расходов и тд.

А еще для подготовки к секции полезно пройти мок-собес, их есть у меня - записывайтесь в личных сообщениях 💅

#собес_PA #analytics

Узнали, согласны?

Собрала немного обычных моментов из жизни биолога и A/B тестера, но все события вымышлены, совпадения с реальными людьми случайны 😏
Пишите, в скольких пунктах узнали себя или коллег (я вот в большинстве пунктов).

#stat_fun

Коллеги-биостатистики опубликовали статью "Мифологизация статистики в биомедицинских исследованиях" по мотивам лектория разрушители статистических мифов.

В статье разобраны самые популярные статистические мифы, такие как проверка выборки на нормальность, применение термина достоверность в статистике и в целом про неправильные практики в тестировании гипотез.

Выражаю огромные респекты коллегам из Института Биоинформатики: Матвею Славенко, Ольге Мироненко, Максиму Кузнецову и Евгению Бакину, это просто мощнейший труд, и теперь благодаря вам появился крутой опубликованный материал, на который можно сослаться при спорах с рецензентами 💪 (а возможно и продактами тоже)

Надеюсь, подобных фундаментальных статистических разборов будет выходить больше, потому что дискуссии в чатиках это конечно прекрасно, но их не всегда удается официально процитировать)

Так что накидайте респектов нашим статистическим слонам 🐘, они обязательно прочитают!

#stats #stat_hard

С днем рождения меня! 🎉

У меня из недавнего интересного - получила приз лучший сотрудник в Литресе, вроде немного, но все равно приятно, что коллеги ценят.

Сильно расписывать не буду, убегаю праздновать (но ты же сама нам написала? все пока 🤓)

В этот день я хотела бы поблагодарить всех, кто был и остается со мной в этом году, спасибо что читаете, комментируете!

Последовательное тестирование: почему это не волшебная таблетка

Сегодня обсудим матчасть метода, а самое главное — нюанс, из-за которого его не стоит ставить в один ряд с CUPED и стратификацией, вместе с которыми его обычно и перечисляют.

🟡Проблематика

В первой части на симуляциях довольно подробно разобрали, почему ошибка первого рода растет.
Приведу конкретные числа оттуда, доля ложных прокрасов при α = 0.05.

- 1 проверка в конце — 5%
- 2 проверки — 9%
- 5 проверок — 14%
- каждый день, 2 недели — 22%

Подглядывание испортит качество наших A/B тестов, а мы не хотим завышать ошибку первого рода. Нужен метод, который позволит подглядывать корректно (мечта продактов 😏). Но тут есть парочка подводных камней.

🟡Почему нельзя применить просто поправку на множественное тестирование

Каждый раз, при столкновении с множеством тестов возникает очевидное желание – просто выбрать подходящую поправку на множественное тестирование. Например самое простое Бонферрони, либо посмотреть что-то поинтереснее, например поправку Холма (подробнее в посте про поправки).
Однако в данном случае классические способы работают не очень хорошо, так как тесты здесь очень сильно зависимые. В каждом следующем тесте используются те данные, которые уже были, плюс новые данные.
Поправки, рассчитанные на независимые или слабо зависимые тесты, в такой ситуации оказываются излишне консервативными: фактическая ошибка первого рода будет заметно ниже заявленной альфы, а мощность мы потеряем.
Нужен подход, который учитывает последовательную структуру данных. Это и есть sequential testing, последовательное тестирование.

🟡Главная идея

Есть две принципиально разные логики, их важно не путать:

1. Тратим альфу по расписанию. Альфа – верхняя граница вероятности ошибки первого рода на тест, это как бы наш кусочек пирога на весь эксперимент. Можно съесть его целиком в конце: один анализ с α = 0.05. А можно распределить между заранее заданными точками подглядывания, тогда в каждой точке критерий будет строже, а суммарно мы получим ту же альфу.

2. Строим границы, валидные в любой момент. Статистика конструируется так, что вероятность хоть когда-нибудь пересечь границу при верной H₀ не превышает α — сколько бы раз мы ни смотрели. Это семейство always-valid методов.

🟡Практические подходы

Group sequential (alpha spending): Pocock, O'Brien–Fleming

Классика из клинических исследований, где ранняя остановка вопрос этики. Фиксируем число подглядываний заранее, например 4 точки, и получаем для каждой свой критический порог. Pocock тратит альфу равномерно: пороги одинаковые во всех точках, выйти рано проще. O'Brien–Fleming очень строг в начале и почти не отличается от обычного критерия в конце. Стоит использовать, когда есть четкий план теста и считанное количество контрольных точек.

mSPRT (mixture SPRT)

Отношение правдоподобия, усредненное по распределению возможных эффектов. Позволяет смотреть непрерывно, именно это зашито под капотом у ряда коммерческих A/B-платформ. Цена: нужно задать смешивающее распределение, по сути свои ожидания о размере эффекта. Угадали с масштабом — метод работает отлично, промахнулись — теряем мощность.

Confidence sequences (always-valid CI)

Доверительный интервал, корректный одновременно во все моменты времени. Продуктово это самая приятная штука: на дашборде можно рисовать интервал каждый день, и он останется честным, сколько бы раз в него ни посмотрели. Платим шириной, такой интервал заметно шире классического на той же выборке. Важно: он защищает именно от подглядывания во времени, а не от перебора метрик и сегментов, там по-прежнему нужна поправка на множественные сравнения.

🟡Но есть нюанс: халявного ускорения теста подглядыванием не будет

А теперь самое главное. Последовательное тестирование не ускоряет тест само по себе. Оно дает право на раннюю остановку, если эффект окажется крупным. Если эффекта нет или он маленький, тест придется вести дольше, чем при фиксированном дизайне той же мощности. Для 5 проверок это примерно +3% у O'Brien–Fleming и до +20% у Pocock, для mSPRT потери еще больше.

Именно поэтому последовательное тестирование по эффективности не стоит в одном ряду с CUPED и стратификацией, хотя перечисляют их обычно вместе. Те методы уменьшают дисперсию и при правильном применении действительно ускоряют тест. Последовательное тестирование просто сделка: тест будет быстрее на сильных гипотезах и дольше или с меньшей мощностью на всех остальных. Но ведь если гипотеза сильная, то можно увидеть эффект и без последовательного дизайна, просто заложить fixed-horizon с меньшим временем. Велком в комментарии дискутировать!

Формулировка для продакта: мы не ускоряем тест, мы покупаем возможность выйти раньше при большом эффекте, но зато будет дольше в остальных случаях.

А пока по лайку 🐳 с тех, кого продакт просил подглядывать в тест, репост, кто не согласился 🤓

А еще благодарности Сергею Матросову за помощь с объяснением принципа метода 💪

#AB_tests #stats #analytics

Когда мера становится целью: закон Гудхарта

В прошлый раз разбирали как прокси-метрики могут сломаться, если их выбрать неправильно и не валидировать. А еще прокси может сломаться, если начать не просто измерять вместо исходной, а целиться именно в прокси. В двух словах это и есть закон Гудхарта.

Сначала немного контекста, с формулировками тут путаница.

🟡Гудхарт, 1975: «любая наблюдаемая статистическая закономерность разрушается, как только на неё начинают давить в целях управления». Было сформулировано в контексте про монетарную политику Британии.
🟡Знаменитое «когда мера становится целью, она перестаёт быть хорошей мерой» написала антрополог Мэрилин Стратерн в 1997.
🟡Ближе всех к нашим задачам закон Кэмпбелла (1976): чем активнее количественный показатель используется для принятия решений, тем сильнее он подвержен искажающему давлению.

В прошлый раз мы разобрали как прокси-метрика может сломаться с точки зрения статистики и как это проверить. Здесь метаанализ прошедших тестов сработает только постфактум, уже после того как связь прокси- и целевой метрики разъедется. Думаю, можно порекомендовать делать валидацию прокси раз в определенный период, но что-то сомневаюсь, что так хоть где-то делают (мы не делаем).

Разберем три механизма.

Подмена измеряемого

Ханой, 1902 год. Французская колониальная администрация борется с крысами как разносчиками чумы и платит 1 цент за крысиный хвост. Хвост можно сказать прокси метрика к целой крысе, но не сама целевая метрика. Ловцы стали отрезать хвосты и отпускать крыс обратно в канализацию, а под городом появились фермы по разведению крыс. По отчетам борьба с крысами прошла успешно: 21 июня сдали 20112 хвостов. Программу свернули, а чума всё равно пришла: 159 заболевших и 110 умерших к 1903 году.

Подмена выборки

Штат Нью-Йорк с конца 80-х публикует рейтинги смертности пациентов кардиохирургов. Метрика разумная: пациент должен знать, к кому идёт. По результатам опроса 1999 года оказалось, что 62% хирургов за год отказались оперировать хотя бы одного пациента высокого риска, и главной причиной назвали публичную отчётность. Плюс приписывали больным более тяжелые диагнозы, чтобы модель ожидала смертность повыше. То есть пациент изначально был тяжелым, и поэтому летальный исход более ожидаем. Метрику улучшили предвзятым отбором в выборку и перекодированием модели, а не фактическими улучшениями.

Короткая дорога к метрике

Появляется способ поднять метрику, ничего полезного не сделав.
YouTube в 2012 ушли от кликов к времени просмотра, чтобы победить кликбейт. Метрика была отличная, чем больше времени просмотра, тем полезнее видео.
А дальше время просмотра само стало целью, и его начали пытаться хакнуть. Ролики стали растягивать до десяти минут, потому что с этой отметки открывались вставки рекламы. Время просмотра росло, а вот удовольствие от продукта не факт: YouTube потом пришлось прикручивать к ранжированию опросы удовлетворённости, потому что сама метрика перестала отвечать на вопрос, было ли видео хорошим.

Метрика, которая была призвана бороться с законом Гудхарта, в итоге снова оказалась подвержена его влиянию.

В науке похожий механизм у импакт фактора: высокий импакт не гарантирует высокое качество статей в журнале. Обзоры одного журнала в дружественных журналах могут повысить импакт этого журнала. Кроме того, цитирования можно купить.
Журнал Cell Transplantation: два обзора в дружественных журналах дали 541 цитирование в расчёт IF за 2010 год. Импакт-фактор вырос с 3.482 в 2006 до 6.204 в 2010, в то время как без этих обзоров было бы 4.082. Тем не менее, альтернативные метрики тоже не слишком прижились, ученые, поправьте, если не так в комментариях.

Обратите внимание: ни в одном из этих случаев цифры не подделывали. Хвосты настоящие, ссылки настоящие, время просмотра настоящее. Ломается не метрика сама по себе, а ее связь с тем, ради чего мы ее считали.

Что с этим делать

🟡Разделять метрику для решения и метрику для цели. Прокси в A/B норма, та же прокси в OKR или в премии может быть проблемкой: появляется человек, заинтересованный в её росте отдельно от продукта. Думаю, вы сами можете вспомнить не один подобный пример.
🟡Считать устойчивость к накрутке проектным требованием. Хорошая прокси - та, которую нельзя улучшить, ухудшив продукт.
🟡Измерять целевую метрику раз в определенный период. Красный флаг будет если прокси растет, а целевая метрика нет.
🟡Пересматривать: валидация прокси не бессрочная.

Конечно, все эти советы для идеального мира, в реальности далеко не все из этого удается делать, но стремиться к этому надо.

Закон Гудхарта это не повод поставить крест на прокси метриках как явлении. Это повод помнить, что прокси-метрика может испортиться и перестать отражать целевую, когда все узнали, что она прокси.

#analytics #metrics

Прокси-метрики: почему корреляции недостаточно

Я давно обещала разобрать прокси-метрики, и вот этот момент настал, поехали.

Прокси-метрика — метрика, которую мы измеряем вместо целевой, когда целевую померить нельзя или слишком долго. Работает при условии: эффект воздействия на прокси должен предсказывать эффект на целевую.

В медицине это называется суррогатными конечными точками, но в этот раз сильно подробно разбирать историю не будем 😏.

Примеры, когда нужна прокси

🟡Целевая метрика слишком долгая: retention 30 дня, LTV. Решение нужно сейчас, а не через месяц. Самое простое, что тут можно сделать - взять retention 7 дня.
🟡Целевая метрика слишком шумная. Классика: ARPPU с длинным хвостом, из-за высокой дисперсии расчетный MDE выше того эффекта, который нам интересен. Но здесь поиск прокси метрик не первый шаг, лучше сначала попробовать снизить дисперсию (CUPED, стратификация).

Как искать прокси-метрики?

Кажется хорошей идеей найти метрики, которые хорошо скоррелированы с целевой. Но вот так в лоб это не будет работать.

Пример скоррелированных метрик:

«Пользователи с высокой метрикой Y дольше остаются в продукте» — это корреляция, и она не значит причинно-следственной связи. Она может целиком объясняться тем, что и Y, и удержание пользователя определяются общим конфаундером — вовлеченностью и лояльностью пользователя.

Классический пример: пользователи, добавившие 5 друзей в первую неделю, удерживаются лучше остальных. Отсюда никак не следует, что если насильно добавить всем по 5 друзей, то удержание пользователей вырастет.

Для прокси нужно другое утверждение: фичи, которые двигают Y, двигают и целевую метрику. Обратите внимание, что поменялась единица наблюдения: раньше мы сравнивали между собой пользователей, а теперь эксперименты. Одна точка в анализе это уже не юзер, а результат целого A/B теста.

Как валидировать прокси

Самый надежный способ: метаанализ собственных завершенных A/B.
Берем прошлые тесты, считаем прокси и целевую метрику, для каждого получаем точку (эффект на прокси, эффект на целевой) и смотрим, насколько хорошо одно предсказывает другое. Целевую можно дочитать задним числом: ждать месяц в момент принятия решения нельзя, а посмотреть retention 30d теста, который закончился полгода назад, совершенно нормально.

К чему может привести неправильное использование прокси-метрик

Важный момент: метаанализ смотрит назад. Он отлично отсеивает прокси, которые вообще не лежат на причинном пути (случай с 5 друзьями), но бессилен против другой поломки — когда у воздействия оказывается свой путь к целевой в обход прокси.

Ровно это произошло с препаратами от аритмии энкаинид и флекаинид. Пациентам после инфаркта давали эти препараты, которые корректировали ЭКГ, подавляя аритмию на 80%. Аритмия может привести к остановке сердца, и поэтому аритмию было вполне логично использовать как прокси метрику. FDA одобрило препараты и для подтверждения эффекта запустили масштабное исследование CAST.
Но в 1989 году исследование пришлось экстренно остановить: смертность от внезапной остановки сердца в группе с препаратом оказалась в 3,6 раза выше, чем в группе плацебо. По сути препарат устранял симптомы, но не первопричины болезни, и более того препарат усиливал проблемы, что в конечном итоге и привело к повышенной смертности.

В продукте цена ошибки конечно другая, но логика похожая. Пример: оптимизация CTR (клики по отношению к просмотрам) обложек и карточек рекомендаций. CTR честная прокси: обычно чем чаще кликают на карточку, тем больше читают. Но можно переборщить с кликбейтами и тогда эффект будет противоположный: человек кликнул, обманулся и ушел, в итоге мы потеряли пользователя. Ровно поэтому YouTube в 2012 году перестал ранжировать по просмотрам и перешел на время просмотра.

В общем, прокси-метрики это мощный инструмент, но нужно выбирать мудро, потому что некорректное применение может привести к неверным, а то и вовсе противоположным выводам.

В этот раз мы в основном разобрали некорректные прокси-метрики, примеры удачных уже не влезли в пост. Поддержите реакциями, в следующий раз разберем примеры хороших прокси! 🔥

Расскажите, используете ли вы прокси-метрики, и если да, то проводилась ли валидация на исторических данных?

#analytics #AB_tests #metrics

Последовательное тестирование: история метода. Часть 1

Продолжаю тему поправок на множественное тестирование и историю A/B тестов.
В 1930-х лаборатория парапсихологии Дюкского университета получила результаты: тысячи испытуемых угадывали карты значимо чаще случайного, это было аргументом в пользу существования телепатии 🤓

Сегодня про то, как развивалась методология последовательного тестирования: статья Феллера 1940 года про карты Зенера и разоблачение экстрасенсов → SPRT Вальда (да, того самого, что и про ошибку выжившего) → альфа-spending Lan-DeMets в 1983-м. В программе парочка мемов, немного математики, и интерактивный симулятор. Получилось легкое чтение на воскресенье, ну и ничего что уже понедельник 🤓 (не успела опубликовать вчера)

https://ubogoeva.github.io/R4Analytics/posts/sequential_testing_part1_history.html

В части 2 разберем, как эту же проблему решили для продуктовой аналитики и что можно применить на практике.

Заходите, пишите комментарии!

#stats #stat_hard #AB_tests

Топ каверзных вопросов по статистике с собеседований. Часть 2

Продолжение разбора вопросов, вторая часть. Первая часть была здесь. Поехали!

🟡Дизайн готов, A/B тест запущен. Продакт волнуется и смотрит результаты каждый день, в один день пишет, что ключевая метрика статистически значимо упала, надо отключать. Что делаем?

Тут спрятаны сразу две ловушки:

1. Проблема подглядывания. Нельзя смотреть результаты каждый день и принимать решения по первому стат значимому результату, если в дизайне теста изначально не было заложено последовательное тестирование. При таком принципе оценивания теста вероятность ложного прокраса в любую сторону стремительно растет.
2. Экстренная остановка. Важно не путать это с пунктом 1. Корректный критерий аварийной остановки закладывается заранее и обычно не завязан на пересчет p-value день в день, иначе он страдает от той же проблемы подглядывания. Обычно это простой практический порог: метрика упала на конкретное число процентов, выросло число ошибок, начались краши, возможно мы выкатили критический баг 😬.
Если продакт увидел на платформе A/B статистически значимое падение без такого заранее согласованного порога, то это все еще подглядывание в результаты A/B.

В хорошем ответе для собеседования нужно четко разделить два случая. Стоит подчеркнуть недопустимость подглядывания без специального дизайна, но обязательно сказать про возможность ранней остановки теста при критическом падении ключевых или заградительных метрик.

🟡Тест завершен, анализируем 5 ключевых метрик. Одна из них статистически значимо изменилась, p-value = 0.03. Выкатываем тест?

Для внимательных читателей канала вопрос очевидный, это ловушка на множественное тестирование. Конечно, если мы тестируем 5 ключевых метрик, то вероятность совершить ложное открытие повышается, поэтому нужно использовать поправку на множественное тестирование или принимать решение только по одной ключевой метрике. Из поправок обычно достаточно назвать Бонферрони или Холма, а вот FDR я бы сильно не рекомендовала упоминать и применять. Подробнее писала про поправки здесь, а вот здесь есть мощный технический разбор FWER на зависимых тестах

🟡Распределение p-value при A/A тесте

Этот вопрос посоветовали в комментариях к предыдущей части, тоже нередко встречается. Тут нужно вспомнить, какая гипотеза верна при A/A тесте. Так как отличий на самом деле нет, то верна нулевая гипотеза. Ожидаемое распределение p-value при верности нулевой гипотезы равномерное на отрезке от 0 до 1. Это можно увидеть на симуляциях, например здесь

Пишите в комментарии, на сколько вопросов из обеих частей удалось ответить без подглядывания! И делитесь, про что было бы интересно почитать еще 👇

#analytics #собес_PA

Топ каверзных вопросов по статистике с собеседований. Часть 1

Сегодня разберем самые интересные, на мой взгляд, вопросы и типичные ловушки. В изначальной версии получилось довольно много, поэтому мне посоветовали разделить пост на два.
Правильные ответы спрятала под спойлером, попробуйте сначала ответить сами.
Здесь не будет вопросов "что такое p-value" или "что такое доверительный интервал". Хотя они могут встретиться на HR-скринингах, на техническом интервью обычно вопросы поинтереснее. Отмечайте, сколько из этих вопросов вам уже попадалось 👇

Поехали!

🟡От чего зависит размер выборки? Иногда могут спросить формулу MDE, что в числителе, а что в знаменателе.

Можно назвать сразу все 4 параметра: MDE (минимально детектируемый эффект), дисперсия, уровень значимости и мощность. Обычно уровень значимости и мощность фиксированы, размер выборки в основном зависит от дисперсии и MDE. Для непрерывных метрик, таких как ARPPU, характерна высокая дисперсия из-за длинного хвоста, что увеличивает время проведения тестов. Для непрерывных метрик дисперсия и среднее это независимые параметры.

Бонусный вопрос: как считается дисперсия для конверсионных метрик?
Для биномиального распределения дисперсия напрямую зависит от значения среднего по формуле `p(1−p)`.

🟡Что такое ошибка первого и второго рода и какая из них хуже на практике? Как связаны ошибка первого рода и уровень значимости?

Ошибка первого рода — ложноположительный результат (нашли эффект, которого нет), ошибка второго рода — ложноотрицательный результат, не обнаружили реальный эффект (тут моя любимая картинка-мнемоническое правило).

Какая ошибка хуже зависит от конкретного кейса, нельзя дать универсальный ответ. В медицинской диагностике ложноположительный результат почти всегда более безопасен, чем ложноотрицательный, лучше перепровериться, чем пропустить болезнь. В A/B тестировании по-разному, не заметить положительный эффект фичи может быть хуже чем раскатить нейтральную, а может и наоборот, нейтральные фичи усложняют поддержку, кодовую базу, а влияние на метрики не имеют.

Уровень значимости - верхняя граница вероятности ошибки первого рода. Подробнее про это и связь их между собой здесь.

🟡Приготовили дизайн A/B, но тест идет долго, например больше месяца, продакт просит ускорить его. Что делать?

Есть ряд способов ускорения A/B, например через снижение дисперсии: CUPED и стратификация. Кроме этого, можно использовать последовательное тестирование, но с этим есть нюансы, планирую разобрать это в одном из следующих постов. Еще один способ - рассмотреть вариант с прокси-метриками.
В крайнем случае можно увеличить MDE, сократив выборку и ускорив тест, но продакта нужно предупредить, что мелкие изменения теперь не засечем. На тему ускорения A/B можно делать не один пост, здесь будет только нужная информация для старта.

Вторая часть с вопросами выйдет завтра, накидайте лайков, если формат понравился ❤️ Пишите в комментарии вопросы, с которыми сталкивались!

#analytics #собес_PA

4 неочевидных способа зафейлить A/B тест

Как испортить A/B тест поглядыванием, отсутствием проверки на множественные тестирования или незафиксированными критериями принятия решения до запуска многие знают (а если не знаете, про это еще напишу). Но сегодня речь будет про другое. Статистика и знание теории экспериментирования важная вещь, но даже с идеальным знанием статистики и A/B тестов все еще нет гарантии, что A/B тест пройдет корректно.

Ниже тру стори из моей практики, как разнообразно зафейлить АБ тест не статистикой 👇

🟡Конверсия в эксперименте в одном из сегментов получилась больше 100%

Это мое любимое, писала про похожее чуть выше, но история не устаревает. На общей конверсии этого не было видно, однако результаты A/B получились странные. В разрезе по сегментам обнаружилось: в одном из них не отправлялись события начала воронки, и конверсия получилась выше 100%. Мы не знаем, сколько пользователей заходило в воронку, и было ли это равномерно между тестом и контролем, этот сегмент однозначно зафейлен. Далее я попробовала посчитать результаты A/B без этого сегмента, но это уже методологически неверно (получился серый тест, потому что эффекта нет или после удаления сегмента не хватило мощности?) и эксп пришлось перезапускать после починки логгирования.

Важное замечание: анализ по сегментам был уже в рамках исследования, что пошло не так с A/B тестом, а не для принятия решения на основании одного из сегментов (для этого надо было изначально закладывать в дизайне и делать поправку, что отдельная история).

🟡12% пользователей оказались одновременно в тесте и в контроле из-за бага при запуске A/B

Флаги аналитики протекли в конфиг, и сплитование поломалось. Со стороны мониторинга казалось, что все ок, группы были равны (формально), однако на этапе анализа результатов выяснилось, что часть пользователей из тестовой группы по флагам были и в тесте, и в контроле. В результате корректно просплитованных пользователей оказалось меньше чем ожидалось, эксп пришлось перезапускать. Примерная оценка потерь: с таким багом сплитования нужно на 30% больше трафика при том же MDE.

🟡Некоторые пользователи попали в тест, но воздействия не получили

Сплитование на этот раз было корректным, но на бэке стояли дополнительные условия выдачи фичи, и часть тестовой группы фичу просто не увидела. Это в итоге снова нарушило рандомизацию, просто исключить пользователей из анализа не получилось, тест пришлось перезапускать.

🟡Расхождение данных между источниками, которое случилось из-за теста

По событиям из одного источника в тестовой группе увидели стат значимое падение ключевой метрики. По другому источнику (данным из хранилища DWH) получился стат значимый рост, хотя обычно источники были коррелированы. Оказалось, что события терялись чаще именно из-за тестовой фичи. На этот раз был хеппи энд, так как по более надежным данным из хранилища удалось подвести итоги и тест был признан успешным 🎉


Я бы хотела сказать, что больше подобных случаев не было, к сожалению на этом список не заканчивается, а здесь приведены самые эпичные.

Что общего у этих историй? Ни одну из них не предотвратит знание поправок на множественное тестирование или разницы между тестами Стьюдента и Велча.
Однако со зрелой платформой и культурой экспериментов половина этих фейлов не случилась бы вообще или была отловлена еще при запуске: мониторинг и алерты количества событий, проверка что пользователи реально получают фичу, расчет денежных метрик по DWH, а не по событиям и это далеко не все.

Поэтому немного вечной классики про качество данных: сложные методы хороши, но только после того, как в простых тестах удается добиться максимальной корректности запусков и расчетов на платформе. На отсутствии перезапусков можно очень неплохо улучшить time-to-market, возможно даже лучше, чем внедрением diff-in-diff, CUPED и других модных методов.

В нашем случае все уже не так драматично, мы растем и в процессах и культуре АБ тестов, что уже позволило сократить количество историй выше. Кроме этого, меняем текущую платформу сплитования на более кастомизируемую и современную (угадайте, кто лидирует этот процесс 😎).

А что из неочевидных багов в АБ попадалось вам? Пишите в комментариях 👇

Коллеги из ExperimentHub сделали крутого бота для тех, кто хочет прокачать знания в АБ тестах: @expertmaker_bot

Механика следующая: раз в два дня открывается челлендж из 5 вопросов на A/B тесты, такие, с которыми можно столкнуться на практике. Вопросы непростые, я сама закрываю челлендж на 80-90% (обидно, почему не на 100%, надо прокачиваться на курсе). После выбора ответов сразу открываются правильные с разбором, почему они именно такие. У меня в основном есть некоторые трудности с ratio-метриками, подводит недостаток практики.

Есть геймификация в виде стриков, сколько челленджей подряд закрыл, и лидерборд, где можно соревноваться с остальными игроками.

Полезно, чтобы держать себя в форме, а еще бот составляет карту навыков и слабых мест, что позволяет лучше понять, на каких темах сосредоточиться при подготовке к собеседованиям или на работе.

Помимо квиза с разными вопросами, есть еще формат квеста с серией вопросов про один кейс, можно вызвать в боте командой /quest

Короче рекомендую, заходите в бота, пишите, кто прошел челлендж на 100%, посоревнуемся 😎

#stats #stat_hard

Вчера провели лютый баттл по датавизу, здесь опишу свои впечатления, пока они свежи.

🟡Позвать Настю как эксперта по визуализации данных было очень удачным решением. Во-первых стрим получился более образовательный, с рекомендациями, как строить графики нужно и как не нужно (привет двойным осям). Во-вторых, мне понравились истории, пока мы кодили, например как спалить человека, который пользуется ИИ-агентом прям на собеседовании.

🟡В этот раз была проделана серьезная подготовительная работа над качеством картинки и звука, я пересматривала частично в записи, смотрится очень достойно, сам код тоже виден. Прикрепила к посту скриншот с типичной сценой на стриме (зацените какой дизайн крутой).

🟡Можно в следующий раз сделать звуковой гонг для старта раунда и особенно для окончания, чтобы было понятнее нам, когда пора заканчивать (обратный отсчет тоже можно). Гонг наверняка добавит атмосферности как в ЧГК

🟡Оказалось, что немного недооценила время, которое нужно для подготовки графиков, возможно сказывается недостаток практики в ggplot2. Еще выяснила, что во время такого скоростного кодинга требуется довольно высокая концентрация и из-за этого не особо получилось развлекать зрителей шутками. К счастью, Настя помогла с этим тоже, поэтому пауз было не так много, как могло быть, если проводить без эксперта. Возможно в следующий раз нужен еще один человек как ведущий/комментатор для общения со зрителями во время скоростного кодинга.

🟡Понравилось, что один из зрителей отправил свои графики в комментарии, и можно было оценить и сравнить (третий график возможно получился лучше чем у нас).

🟡Из приятного: все еще помню и могу написать пивот в R самостоятельно, отцентровать заголовок, но все это становится не таким полезным навыком, так как ллм все сделает еще быстрее и качественнее. Но на самом стриме LLM-ка очень долго думала и мне было быстрее написать самостоятельно или по старинке погуглить.

🟡Заценила Positron как IDE, все привычные хоткеи из арстудии работают, поэтому переход был относительно безболезненный. RStudio 🖥 конечно хороша, но отсутствие возможности встроить любого агента огорчает в современных условиях.

В общем и целом: формат понравился, думаем продолжить что-то на похожую тему. Возможно баттл чисто на агентах, как предлагали в комментариях или BI-система vs кодинг (правда я тут догадываюсь как все закончится). Предлагайте еще варианты, что было бы интересно посмотреть и пишите свои впечатления!

По атмосфере я себя ощущала похоже немного на видос, где программист с трудом кодит, а дизайнер с кайфом рисует, прикреплю в комментарии.

Кто не был на трансляции, обязательно посмотрите в записи, получилось сбалансированно образовательно и развлекательно, на мой взгляд

#data_vis #R #stat_fun

Стрим по датавизу уже сегодня!

Заглядывайте в 19.00 МСК на трансляцию сюда, болейте за наших 😎

Будем кодить на R и Python, вместе с Ромой, а оценивать графики будет Анастасия настенька и графики

Приходите, ставьте лайки, жмите на колокольчик, будет познавательно и весело) (надеюсь)

UPD: По-моему получилось очень душевно, мне самой понравилось)
А вот и репозиторий с данными, заданиями и нашими наработками https://github.com/rosolimo212/visualization_battle/tree/main

#data_vis #analytics

Поправки на множественное тестирование: симуляция FWER зависимых тестов

В прошлый раз я разбирала общую теорию поправок на множественное тестирование, в этот раз разберем более подробно, как оценивать FWER в случае зависимых тестов. А на практике это почти всегда так: несколько метрик считаются на одних и тех же пользователях или несколько групп сравниваем с одной контрольной группой.

https://ubogoeva.github.io/R4Analytics/posts/multiple_testing_simulation.html

Разберемся, какие бывают виды зависимости, на симуляции можно самостоятельно оценить, как будет меняться FWER в зависимости от скоррелированности метрик.

Заходите, пишите комментарии!

#stats #stat_hard

Баттл по датавизу: R vs Python 📊

Не так давно я обещала анонсировать кое-что интересное, связанное с датавизом, пора раскрыть карты:

23 июня в 19:00 МСК проводим стрим в новом формате: кто быстрее и лучше визуализирует одни и те же данные – на 🖥 или 💻?

На R пишу я - @stats_for_science
На Python будет кодить Рома - Kotelok

Формат простой: один датасет, есть вопрос, на который нужно ответить визуализацией. Всего будет три раунда, каждый следующий сложнее предыдущего. Ориентировочно займет полтора-два часа.

Зрители увидят:
- атмосферу баттла как на соревнованиях по геогессеру/тетрису
- холивар ggplot2 vs matplotlib
- что быстрее и проще кастомизировать
- величие грамматики графики (или нет)

Оценивать красоту и функциональность чартов будет приглашенный эксперт - Анастасия из настенька и графики 🔥

Ссылку на трансляцию пришлю незадолго до начала сюда.

Присоединяйтесь, будет интересно!

#data_vis #analytics

Тест Стьюдента, Велча и непараметрика на малых выборках

Возвращение долгожданных лонгридов по статистике! В прошлый раз я сравнивала тест Стьюдента и тест Велча на больших выборках и обещала разобрать отдельно, что происходит на малых выборках. Не прошло и года (или прошло), но лонгриды возвращаются в новом интерактивном формате:

https://ubogoeva.github.io/R4Analytics/posts/small_samples_simulation.html

Теперь можно самостоятельно накликать разные варианты размеров выборок, дисперсий, распределений и посмотреть на ошибку первого рода и мощность. Помимо наших любимых тестов Стьюдента, Велча и Манна-Уитни, бонусом разобрала еще тест Бруннера-Мюнцеля, грубо говоря аналог теста Манна-Уитни для неравных дисперсий. И не забыла про статью от X5 про тест Велча (Серега, респекты 💪).

Не буду здесь долго расписывать, все самое интересное разобрано в посте, заходите!

#stats #stat_hard

Иду на топовый курс по A/B тестированию 😎

А зачем еще один курс?
На экзамене по АБшкам я немного споткнулась на линеаризации ratio-метрик и sequential testing, так как не работала на практике с этим. Вообще у нас в Литресе большинство тестов закрываются классическими z- и t-тестами, но все же иногда нужно сделать что-то посложнее, например применить свитчбек или постстратификацию. Конечно, про все эти методы можно почитать на хабре самостоятельно, посмотреть доклады с конференций, но если есть курс, где это все разбирается, то я иду на курс 👇

Мне удалось подглядеть в расширенную программу курса 👀, вот что интересное подсвечу оттуда:

🟡 Сплитование – в общем-то, это база. Но при этом немалая часть зафейленных тестов именно по причине сплитования: неправильный hash+salt, наивный сплит по последней цифре ID, кривой стратифицированный сплит. Конечно, вы можете сказать, что у вас это все делает правильно A/B платформа, но этого не всегда бывает достаточно + всегда приятно разбираться в том, как оно работает.

🟡CUPED и Multi-CUPED – у нас в Литресе это постепенно внедряется, но хотелось бы избежать типичных ошибок (а их там не меньше четырёх), и сделать все четко

🟡Ratio-метрики – тема, которую хочу детально разобрать. Вот эти все дельта-методы, линеаризация, бакетизация. Всё это я знаю теоретически, но хочу разобрать именно с кодом и на синтетических данных, чтобы закрепить и применить на практике.

🟡Метод Монте-Карло это для моделирования экспериментов. A/A-тесты через симуляцию, оценка мощности, верификация критериев. Тоже база, но полезно уметь делать.

🟡Множественное сравнение: поправки Бонферрони, алгоритм Холма, FDR. Писала про это здесь, но в курсе, судя по описанию, есть ещё «размазывание поправки» как метод ускорения экспериментов — интересно посмотреть.

Курс стартует с 15 июня, еще буду делиться впечатлениями в процессе (ожидайте роста хардовых постов по статистике). Если тоже интересно разобраться в АБшках лучше среднего – залетайте, по этой ссылке для всех кто оформил, будет скидка 10% 🔥

UPD: Если что, есть рассрочка

#recommendation

Отзыв на конфу AHA-2026

Чуть раньше я рекомендовала конференцию AHA-2026, были большие ожидания от нее: мне очень нравились конференции Aha и матемаркетинг, и с 2024 года хожу на каждую. В этот раз тоже не пропустила, прилетела издалека и сходила в прошлую пятницу офлайн. 
Ну что ж, напишу свои впечатления как есть 🍿(осторожно многобукв). 

🟡Программа 

Начну с того, что конференция была всего один день, и по наполнению программы заметен сильный перекос в сторону AI, ML, агентов и всего около. В итоге было мало докладов на нашу любимую тему продуктовой аналитики в целом и A/B тестов в частности, хотя они были заявлены одним из треков конференции (направление системного снижения стоимости проверки гипотез).
Понимаю, что каждый год слушать только про A/B было бы неинтересно, но на самом деле на каждой конференции удавалось узнать что-то новое. Некоторые идеи с прошлого матемаркетинга мы даже смогли применить на практике в Литрес. Поэтому в этот раз буквально 4 доклада про продуктовую аналитику немного не попало в мой фокус интересов, хотя стоило это предположить раньше.

И еще я сама в этот раз подавалась как спикер с докладом на вечную тему про ускорение A/B, CUPED, процессы и все прочее, но к сожалению не взяли. Понимаю, что тема не новая, но на предыдущих конференциях каждый раз хотя бы один доклад был про это. Надо было добавить в тему ускорение A/B и процессов с помощью AI, тогда бы точно взяли) 

Отдельно лайк организаторам, что подготовили бумажный вариант программы и более удобный электронный, в прошлые годы были проблемы с этим. Ну правда программу стало удобнее читать, а вот интересных докладов стало меньше, но тем не менее, расскажу что мне понравилось. 

🟡Интересные доклады 

Было прикольно послушать про внедрение агента в A/B платформу в дзене, здорово, что есть уже практические кейсы применения. Правда, в нашем случае нам пока рано добавлять агентов, надо бы сначала наладить базовую автоматизацию АБшек за счет новой платформы.
Еще любопытное было про diff-in-diff и синтетический контроль, но это скорее для расширения кругозора, так как офлайн эксперименты для нас не очень актуальны.
Андрей Андреев хайпово рассказал про воспроизведение популярных UX-паттернов на больших выборках. В общем-то это все я знала, потому что писала про круглые кнопки здесь, но все равно было интересно послушать про сотрудничество с Кохави из первых уст. А еще в докладе Андрея есть небольшая отсылка на меня, чекайте)

🟡Стендовые активности 

Активностей на стендах было очень мало по сравнению с прошлыми конференциями, почти никто из бигтехов не вписались в активности, выглядит это как тревожный звоночек. Не было моего любимого стенда райфайзена 💳, без него совсем не вайб. Даже если сравнивать с прошлой Aha, не с матемаркетингом, стало намного меньше стендов и участников в целом. 

🟡Нетворкинг

Но что на конфе удалось, это нетворкинг, встретила и развиртуализировалась со многими старыми знакомыми (привет, Юра, Влад). Обсудили, что происходит с рынком аналитики в целом (про это не напишут в исследовании newhr). 

Еще кажется, что немного не оправдан ценник конференции, так как всего один день и и даже особого желания досматривать пропущенные доклады нет. Знакомые сходили на ODS на следующий день, говорят было не менее интересно, и бесплатно. Поэтому немного не уверена, приеду ли в следующий раз, но если и приеду, то скорее на матемаркетинг, как будто там больше фокус на продуктовую аналитику. 

Пишите в комментариях 👇, кто тоже был, согласны ли с моими впечатлениями, что понравилось/не понравилось больше всего? 

#analytics

Как отвечать на продуктовые кейсы на собесе: фреймворк PACE

Продолжаю тему подготовки к продуктовой секции на собеседовании. В прошлых частях разобрала, как прокачивать продуктовое мышление и какие материалы использовать для подготовки к собесу.

Сегодня разберем, как правильно выстроить ответ на практически любой продуктовый кейс. Основная сложность продуктового кейса не в том, чтобы ответить правильно, так как правильного ответа (единственного) может просто не быть. Важно, как построен ответ и проверены ли основные направления поиска. Я сама раньше хаотично накидывала гипотезы, но это неудобно для себя и для интервьюера, сложно отследить мысль, понять что ничего не пропущено.

Для структурирования ответа удобно использовать фреймворк PACE: Plan – Analyse – Construct – Execute

🟡P – Plan: уточнить контекст, прежде чем отвечать

Это самый важный и часто пропускаемый шаг. На работе вы никогда не идете анализировать падение метрики без понимания контекста, а на собеседовании тем более.

Примеры того, что стоит уточнить:

→ Это разовый скачок или плавный тренд?
→ За какой период смотрим: день, неделя, месяц?
→ Это сезонная история? Как выглядит тот же период в прошлом году?
→ Были ли недавно изменения в продукте или релизы?
→ Были ли изменения в маркетинге – новые кампании, смена каналов?
→ Не было ли внешних событий – праздники, новости, действия конкурентов?

Несколько уточняющих вопросов в начале сразу ограничивают пул гипотез и упрощают дальнейшие шаги. А еще показывают, что вы перед погружением в задачу обязательно выясняете детали.

🟡A – Analyse: построить дерево гипотез – от общего к частному

Мой любимый подход тут сразу разделить два больших блока: проблемы с данными и проблемы не с данными. Проблемы с данными включают сбои в логировании, падение пайплайнов, изменение названий событий и много чего еще. Но обычно интервьюер отвечает, что с данными всё в порядке, тогда уже можно погружаться в продуктовые причины.

Продуктовые причины тоже разбиваем на блоки по формуле метрики.

Например, кейс «конверсия выросла, а выручка упала»:

Выручка = конверсия × средний чек × трафик

→ Трафик: изменился объём или состав (микс каналов)?
А вдруг это боты или левый трафик?
→ Средний чек: упал из-за промо, скидок, изменения ассортимента?
→ Конверсия: на каком шаге воронки выросла? Может, просто привлекаем более дешёвых покупателей с меньшим средним чеком.

Кейс: «упал DAU»
DAU = новые пользователи + вернувшиеся пользователи

→ Новые: упало привлечение? Какой канал просел?
Изменился бюджет на маркетинг?
→ Вернувшиеся: упал retention? На каком дне?
Что изменилось в продукте за последнее время? Были ли запуски A/B тестов в этой части продукта или раскатки на 100%?
→ Отток: вырос churn? Были ли жалобы, негативные отзывы?
Появился новый конкурент?

Логика дерева помогает не пропустить целые ветки и не зациклиться на первой пришедшей в голову гипотезе.

🟡C – Construct: приоритизировать гипотезы

Когда дерево построено, объясните, с чего начнёте проверку и почему. Здесь нужно из всего многообразия гипотез выбрать несколько самых перспективных. Критерии приоритизации:

Вероятность – что из этого случается чаще всего?
Влияние – какая гипотеза объясняет наибольшую часть эффекта?
Стоимость проверки – что можно проверить быстро по имеющимся данным?

Можно не проверять всё подряд, нужно объяснить логику выбора, в итоге прийти к наиболее вероятной причине.

🟡E – Execute: сформулировать вывод и следующий шаг

Здесь нужно предложить дальнейшие шаги:
→ если проблемы в данных: починить логгирование, добавить события
→ если проблемы в трафике: разбираться с маркетингом
→ если проблема в новом A/B тесте, рассмотреть вариант экстренной остановки теста

И так далее, руководствуемся здравым смыслом, предлагаем реалистичные шаги.

Фреймворк PACE помогает не паниковать, когда кейс кажется сложным – просто идёте по пункта и не пропускаем ничего важного.

Пишите в комментариях, используете ли этот фреймворк или другие, а также какие кейсы попадались вам на собесах – разберём 👇

#собес_PA #analytics