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

Прокси-метрики: почему корреляции недостаточно Я давно обещала разобрать прокси-метрики, и вот этот момент настал, поехали. Прокси-метрика — метрика, которую мы измеряем вместо целевой, когда целевую померить нельзя или слишком долго. Работает при условии: эффект воздействия на прокси должен предсказывать эффект на целевую. В медицине это называется суррогатными конечными точками, но в этот раз сильно подробно разбирать историю не будем 😏. Примеры, когда нужна прокси 🟡Целевая метрика слишком долгая: 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

Есть ли жизнь после российского бигтеха?👩 Про международку сейчас много мифов — кто-то говорит, что всех загнали обратно в офисы, и найти работу можно только с разрешением на работу в определённой стране. Кто-то говорит, что на западе сплошные сокращения из-за ИИ, и аналитиков данных тем более уже заменили. Кто-то считает, что не стоит и пытаться откликаться на вакансии, если английский не С2... А вот Аня — Аналитесса-разработчица рискнула и этой весной променяла ⭐️то самое⭐️ Авито на стартап из Англии😎💅 В своём канале она сейчас делает фокус на том, какой новый опыт проживает после релокации, как старается успевать за новостями AI и применяет нейросети и агентов в работе, и как на самом деле можно в 2026 попасть в международку: ⭐️ променяла бигтех на ИП в Армении? что дальше? ⭐️ сколько стоит стать цифровым кочевником в 2026 ⭐️ что мешает вам найти международную работу🥲 ⭐️ почему Claude Code пока сам НЕ сделает вам аналитику ⭐️ про ограничения вайбкодинга для продакшна сейчас ⭐️ простые шаги для поиска удалённой работы🌎 А ещё есть посты о том, что сейчас на ru рынке аналитиков: ⭐️ почему мидл+ — самый удобный грейд сейчас👍 ⭐️ разоблачение исследования зарплат от NEWHR🌟 ⭐️ как сделать лимонад из лимонного рынка труда🍋 В общем, кладезь инфы для тех, кто хочет читать про аналитику, AI, релокацию и работу в международке без fear of missing out. Кстати, кажется, подписка на Анин канал заряжена не только на интересные офферы, но и на путешествия по красивым местам (сама всегда смотрю с удовольствием)! ➡️ @analytess 😺

Последовательное тестирование: история метода. Часть 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

Баттл по датавизу: R vs Python 📊 Не так давно я обещала анонсировать кое-что интересное, связанное с датавизом, пора раскрыть карты: 23 июня в 19:00 МСК проводим стрим в новом формате: кто быстрее и лучше визуализирует одни и те же данные – на 🖥 или 💻?…

Поправки на множественное тестирование: симуляция 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

Про необходимость знаний статистики Наверное, вы заметили, что в последнее время на канале стало меньше экспертных постов по статистике. Причин тут несколько: 🟡В первую очередь на написание качественного лонгрида уходит просто кратно (в десятки раз) больше времени, чем на обычные посты. Например, пост про тест Велча занял месяца полтора активного написания, когда на обычные посты уходит 2-3 дня. При этом не хочется полностью исчезать на недели в процессе написания лонгрида, поэтому стараюсь писать что-то не менее полезное, хоть и не настолько фундаментальное. 🟡Второй момент – я сейчас в фазе приступа синдрома самозванца, и не чувствую в себе достаточно компетентности писать сложные посты, про это раскрою чуть дальше. 🟡В последнюю очередь и не сильно всерьез еще пожалуюсь, что с точки зрения реакций и перепостов статистические лонгриды хуже заходят аудитории чем например подборки полезных материалов. Я понимаю, что долгосрочно качественный пост с разбором стат хардкора все равно будет полезнее и ценнее для аудитории, но в моменте меньшая вовлеченность огорчает, думаю меня можно понять) Мне кажется, через это проходят все авторы, но это не значит, что надо перейти только к постингу мемов и полезных материалов (не значит же?) 🤔 Отдельно хотелось бы поговорить подробнее про второй пункт. Мне кажется, что как и со многими вещами, знание статистики и уверенность в том, что ты ее знаешь подчиняется примерно такой кривой (прикрепила к посту). После старта изучения в какой-то момент наступает тот самый момент, когда ты думаешь, что понял статистику. Именно в этот момент обычно начинают вести свои курсы и открывать телеграм-каналы. И это правильно, потому что если не сделать этого сейчас, то потом возможно это уже никогда не сделаешь) Я про то, что рано или поздно этот момент просветления уходит и приходит осознание, что в статистике очень много деталей и подводных камней и упрощенное объяснение перестает устраивать. На этом моменте пропадает желание вести курсы и писать посты, потому что есть ощущение, что все намного сложнее и простые и понятные объяснения могут быть не совсем правильными. Если честно, я уже давно в этом состоянии, поэтому надо начинать писать посты, когда тебе еще кажется что ты все понял, иначе потом есть риск не начать никогда.  Но это все лирика про ведение телеграм канала и написание экспертных постов. А в заголовке я написала про знание статистики в более широком смысле: на практике в науке, аналитике данных и тд. Будет ли достаточно быть на первом пике осознания того, что ты все знаешь, чтобы решать большинство задач? На мой взгляд, для большинства задач этого действительно достаточно, и еще осторожно намекну что некоторые не доходят и до этого этапа, что не мешает быть успешными учеными.  И тем не менее, в науке многообразие тестов обычно больше, чем только t-тесты и z-тесты конверсий, поэтому не повредит еще знать ANOVA, линейные модели в целом, для множественной регрессии о методах отбора предикторов. Я выше уже писала, почему считаю что в науке статистика сложнее, можем еще раз обсудить это в комментариях. Но думаю все согласятся, что потенциальное многообразие методов явно выше, хотя и можно найти примеры, когда тоже ничего сложнее t-теста и не надо, а есть научные области в которых статистика в принципе не нужна. В общем мораль такая, что для 90-95% задач в науке и аналитике достаточно выйти на первый уровень просветления о знаниях статистики и только в редких случаях нужно углубляться дальше, чтобы решать более сложные задачи. В аналитике к сложным задачам я бы отнесла все методы снижения дисперсии, квазиэксперименты, и все остальное, что могут спросить на собеседовании на синьора в бигтехе) #stat_hard

Как прокачаться до синьора в АБ тестах? Курсов по A/B сейчас существует много, но большинство из них для старта в профессии, мало курсов для миддлов и выше. На большинстве курсов разбирают базу, что такое p-value, MDE, как сделать дизайн теста и почему нельзя подглядывать в A/B тест 😉. Не спорю, это важно и нужно знать, но что делать, если продакты постоянно просят ускорить АБ тесты, базовых z-теста конверсий и t-теста им уже не хватает. Где-то читали про то, что можно подглядывать в A/B тест, если это сдизайнить правильно, но нет понимания, как это делать на практике. В таком случае приходите на курс от ExperimentHub. Авторы крутые ребята, которые строили A/B-платформы в Т-банке и других бигтехах (и кстати заглядывайте на канал Ромы). В программе курса достаточно продвинутые штуки, все что нужно, когда база уже есть: сетевые эффекты, последовательное тестирование, CUPED/Multi-CUPED, аплифт-моделирование. Понравился еще фокус на бизнес, как приложить это на практику сразу же. Во многих курсах нет понимания, как формулы применить на практике, здесь подкупила большая связь с задачами. Я вроде про все это читала, но хотелось бы научиться это все применять на практике, поэтому иду на курс, программа оч крутая, надеюсь после этого вывести на новый уровень культуру экспериментов в Литрес) Как устроен курс: Длительность 6 месяцев Каждую неделю открывается запись лекции, конспект лекции и домашка. А еще каждую неделю тест и каждые 2 недели домашка с кодом для проверки знаний и мотивации. Курс стартует 15 июня, погнали тоже! Записаться здесь

Отзыв о курсе “Осмысленные дашборды” от Симулейтив Примерно месяц назад закончился курс, хочу поделиться впечатлениями. Я прошла все лекции и практические занятия, все четко, даже удалось ускорить дашборды (Алёна, подтверди в комментах плиз 👇). Для меня многое на курсе было повторением того, что я знаю, но все равно актуально для максимизации пользы дашбордов/графиков для бизнеса. Полезно задавать себе вопросы, с какими задачами могут приходить заказчики на дашборд и выводить нужные графики и сочетания фильтров, даже если конкретно этого графика не было в ТЗ. Также повторила базу о правилах Тафти и гештальт-принципах (правило близости, сходства, границы и тд). Из побочных эффектов теперь испытываю грусть при взгляде на некоторые графики и дашборды 😁. В общем курс рекомендую, отлично подходит для начинающих в датавизе, чтобы узнать что-то новое, а для продолжающих для структурирования информации. А совсем скоро анонсирую еще кое-что интересное на тему датавиза, даже затронем известный холивар R vs Python, так что оставайтесь на связи! #analytics #data_vis

А вот и правильные ответы про статистические факты Многие в комментариях ответили правильно – ложный факт про Наполеона. Шарль Минар создал свою знаменитую карту в 1869 году. Наполеон умер в 1821-м, за 48 лет до этого, поэтому не мог увидеть лучшую визуализацию эвер (по версии Эдварда Тафти). Все остальное – реальные факты: ✅ Байес – да, священник. Его работа «An Essay towards solving a Problem in the Doctrine of Chances» опубликована посмертно Ричардом Прайсом в 1763 году (здесь могли быть ваши шутки про байесианство 😏) ✅ Госсет и пиво – действительно работал в Guinness, при публикации взял псевдоним Student в силу политики компании. Думаю, самый общеизвестный факт ✅ Фишер и евгеника – к сожалению, правда. Как подметили в комментариях, “интересные” высказывания у него были и после войны. Сейчас даже есть дискуссия об отмене датасета iris в связи с этим, хотя данные собирал не сам Фишер, только использовал их. Тем не менее, многие рекомендуют использовать датасет Palmer Penguins на замену ирисам, и его недавно добавили в список датасетов base R. ✅ p < 0.05 – Фишер продвигал эту границу в книге «Statistical Methods for Research Workers» 1925 года как удобный рабочий стандарт, но сам предупреждал против механического применения (то есть не рекомендовал сравнивать полученное p-value с 0.05, многое может зависеть от задачи). А потом Нейман и Пирсон формализовали α = 0.05 в своей системе как вероятность ошибки первого рода – и вот мы здесь) Спасибо всем кто участвовал, но кажется для вас это было слишком легко 😎. В следующий раз подумаю над чем-то менее очевидным #stats #stat_fun

Статистические факты: найди ложные Я собрала несколько занимательных фактов про статистиков и анализ данных, однако один или несколько из них ложные. Сможете найти неверный? 👀 Поехали 👇 Преподобный Байес. Томас Байес, чьим именем названа одна из главных теорем вероятности, был пресвитерианским священником. Свою главную работу он не опубликовал при жизни – её нашёл и издал друг Байеса уже после смерти автора. Пиво и t-test. Знаменитый t-критерий Стьюдента был разработан Уильямом Госсетом для контроля качества пива в компании Guinness. Псевдоним пришлось взять, чтобы не раскрывать корпоративные секреты. Наполеон и смертельная инфографика. Считается, что график наступления Наполеона на Москву, созданный Шарлем Минаром – это лучшая визуализация в истории. Говорят, что сам Наполеон, увидев её в старости, был впечатлен, так как график наглядно показал: его армию погубили не пули, а мороз и логистика. Темная сторона Фишера. Рональд Фишер, отец современной статистики, автор ANOVA и много чего еще, был ярым сторонником евгеники и не отказался от своих взглядов даже после Второй мировой войны. p < 0.05 как порог значимости – не строгий математический факт, а личное мнение Фишера. Он сам писал, что это просто удобное значение. Пишите комментарии, какие факты точно ложные или точно истинные, правильный ответ будет через несколько дней! #stats #stat_fun