A/A-тест: проверяем дизайн эксперимента ещё до старта (Ч. 6)

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

Что такое A/A-тест❓

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

Смысл: если между двумя одинаковыми группами метод находит «значимую разницу» чаще, чем должен, — дизайн сломан, и на боевом A/B мы будем ловить фантомные эффекты.
По сути A/A — это плацебо для рандомизированных тестов: куча «экспериментов», где эффекта заведомо нет.

Что именно проверяет A/A ❓

➖ Долю ложных срабатываний (FPR). Она должна быть около α (например 5%). Больше — критерий ловит несуществующее.
➖ Отсутствие перекоса. Средняя разница между группами ≈ 0, доверительные интервалы накрывают ноль как положено. ➖ Дисперсию метрики — ее потом кладём в расчёт MDE и размера выборки (про MDE — в следующий раз).
➖ Здоровье пайплайна: корректный сплит, нет утечек, метрика считается корректно и так далее

Как читать распределение p-value ❓

Гоняем много A/A-сплитов и смотрим на распределение p-value. Под нулем (эффекта нет) оно должно быть равномерным на [0, 1]:

➖ равномерное → всё честно, FPR на уровне α ✅
➖ горка у нуля (слишком много маленьких p) → FPR раздут, критерий врет в сторону ложных срабатываний
➖ горка у единицы (слишком много больших p) → критерий переосторожен, тест недомощный
То есть A/A — это не «прогнали разок и ноль», а проверка калибровки всего критерия.

Почему A/A «краснеет» — частые причины

Если FPR улетел вверх, чаще всего виноваты:

➖ Зависимые наблюдения, посчитанные как независимые. Напр. у одного юзера куча сессий/визитов, а мы считаем их независимыми → занижаем дисперсию → FPR взлетает. Лечится анализом на уровне единицы рандомизации (юзера) / кластеризацией.
➖ Ratio-метрики (CTR = клики/показы и т.п.) — обычная дисперсия врёт, нужен дельта-метод / бутстрап / линеаризация. Про них дальше будет отдельно.
➖ Подглядывание (peeking): смотрим на тест много раз и останавливаемся на «значимом» — без поправки FPR раздувается.
➖ Тяжёлые хвосты — t-тест плывет; помогают бутстрап, трансформации, CUPED.
➖ SRM — группы не 50/50, хотя должны быть → баг в сплите или инструментации.

Как прогонять A/A ❓

1️⃣ Живой A/A — реально льём трафик на две одинаковые группы и меряем. Дорого по времени, зато честно ловит проблемы инструментации и сплита.
2️⃣ Ретроспективный A/A на истории — многократно случайно бьём исторические данные на две псевдогруппы, каждый раз считаем критерий → строим распределение p-value. Быстро и дёшево (это по сути бутстрап / перестановки — о них ещё поговорим).
На практике сначала гоняют ретроспективный, чтобы откалибровать критерий, а живой — как финальную проверку пайплайна.

Что важно держать в голове

➖ A/A валидирует не «есть ли эффект», а сам инструмент: сплит + метрику + критерий.
➖ Цель — FPR ≈ α и равномерные p-value. Отклонение = чинить до боевого запуска.
➖ Заодно достаём дисперсию для расчёта MDE.
➖ Один прогон ничего не доказывает — нужна масса разбиений.

Что обсудим дальше...

➖ MDE — какой минимальный эффект вообще реально поймать
➖ Бутстрап и перестановки — как честно считать значимость и гонять ретро-A/A
➖ Ratio-метрики — почему они ломают дисперсию и как их правильно считать

❤️‍🔥 Подписывайтесь и поддержите канал бустом
↗️ Менторю и помогаю выйти на оффер
❓Гоняете A/A перед запуском или только лысого?!

@data_driven_bogdan

Обзор собеседования

Компания: Концентрация
Вилка: +-250к
Должность: ДА
Формат: удаленка/гибрид
Этапы собеседования: HR – Тех. собес – Offer
Дата собеса: июль 2026

Возвращаем рубрику «обзор собесов»
За последнее время накопилась пачка собесов — будем разбирать...

1️⃣ Дашборд по эффективности продаж

Руководитель отдела продаж: «нужен дэш по эффективности продаж». Что положишь в дашборд?

Первое — не бежать строить, а уточнить у заказчика:
➖ какую задачу решаем и какие решения будут по дашборду принимать;
➖ для кого он — сам руководитель, менеджеры или топы (от этого зависит уровень агрегации);
➖ что у них вообще считается «эффективностью», за какой период и в каких разрезах.

Дальше по сути кладём.

Метрики:
➖ план/факт и % выполнения плана — главный якорь эффективности;
➖ выручка, число сделок, средний чек;
➖ конверсия по воронке;
➖ длина сделки (sales cycle);
➖ выручка и сделки на менеджера, активность (звонки, встречи);
➖ повторные продажи / отток — по желанию.

Разрезы: по менеджеру и команде, продукту, региону/каналу, сегменту клиента и во времени.

Структура: сверху верхнеуровневые KPI и план/факт, ниже воронка, дальше лидерборд по менеджерам и динамика с drill-down.

Проверяют продуктовое мышление: метрики под решения и умение сузить скоуп вопросами к заказчику.

2️⃣ Сломалась витрина с долгами

Дано: дашборд с долгами поставщикам — одна сводная, поставщики построчно, метрика одна: сумма долга в рублях.
Тебе пишут на праздниках дэш не работает, а документации по нему нет.
Заходишь, смотришь в метрики — где было 50 млн, теперь 0, а где-то суммы кратно ниже.
Ошибка и в дашборде, и в витрине. Что делаешь?

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

3️⃣ Теория SQL

➖ Свежие значения по каждой валюте → ранжирование оконкой

ROW_NUMBER() ... PARTITION BY currency ORDER BY dt DESC в CTE и фильтр сверху rn = 1

➖ Разница джойнов / UNION-UNION ALL
➖ Как соединить таблицы валют и товаров

4️⃣ Теория вероятностей

Кинули монетку 10 раз — 10 орлов.
Вероятность решки на 11-м?
Если монета честная монета → 50%, прошлые броски не влияют.
Но 10 орлов подряд намекают, что монета может быть нечестной — тут уместен байес.
Правильный ответ — проговорить оба взгляда, а не выдать сходу 1/2.

❤️‍🔥 Подписывайтесь и поддержите канал бустом
↗️ Менторю и помогаю выйти на оффер

@data_driven_bogdan

Вилки по рынку

Скинули мне тут сайтик с офферами по СНГ рынку
Еще сыроват конечно, но для тех кто не в курсе вообще за вилки — может потыкаться

https://gdezarplata.duckdns.org/companies

❤️‍🔥 Подписывайтесь и поддержите канал бустом
↗️ Менторю и помогаю выйти на оффер

@data_driven_bogdan

С нуля до 250к за 2 месяца: из востоковеда до ведущего аналитика данных🍌

В начале июня ко мне на менторство пришел К. (имя изменено) с запросом: востоковед по образованию, IT-бэкграунда нет, хочет в DA. И уже в начале августа он получил первый оффер, а еще через две недели вышел на позицию ведущего АД в одну из ведущих российских финтех-компаний на 250к. Два месяца от старта до оффера.

К. — тип ученика, который до меня уже что-то учил сам. И это как раз часто очень обманчивая точка: кажется, что база есть, и можно собеситься, а на деле знания сырые и разрозненные.

просто я вроде учил, но не было системы, и я не понимал что зачем и на каком этапе применять
я смотрел собесы, и вроде что-то и понимал, но из-за того что системы нет, кажется что не понятное

Вот это ощущение "не понятное" лечится не количеством курсов, а системой, и вот как мы шли:

➖ Обучение. Составили роадмап под конкретную цель: что учить обязательно, что учить поверхностно, а что не трогать вообще — потому что этого либо не спрашивают на собесах, либо не используют в работе. Созвоны раз в неделю: разбор материала, вопросы, корректировка темпа. Между созвонами я на связи по любым вопросам как в рамках роадмапа, так и в целом
➖ Резюме и легенда. Проработали опыт и позиционирование, переписали резюме до состояния, когда оно реально продает. Результат — количество скрининговых собеседований выросло кратно, и поиск работы перестал быть лотереей с откликами в пустоту.
➖ Мок-собеседования. После каждого блока проводили мок собесы, максимально приближенные к реальным: опыт, теория, задачи по SQL, разбор ошибок после.
➖ Собеседования и оффер. Дошел до 3х финалов — и это при том, что месяцем раньше он вообще не понимал, о чем его спрашивают на записях собесов. Итог — оффер на позицию ведущего аналитика данных на 250к, ровно через два месяца после старта менторства.
➖ Выход. Стандартные 2 недели от оффера до первого рабочего дня.

К. сделал результат не потому, что я хорош, а потому что делал то, о чем мы договаривались.
Системно уделял время, не уходил учить «то, что интереснее», не пропадал между созвонами и сам проявлял инициативу.

Два месяца с нуля быстро даже по моим меркам. Обычно менторство занимает 4–6 месяцев, и то, не обещаю, что у всех будет так же: слишком многое зависит от стартовой базы, количества свободного времени и рынка в конкретный момент. Но этот кейс показывает верхнюю планку того, что вообще реально при нормальном вложении сил.

Мог ли он дойти сам? Скорее да — но не за два месяца, а за год-полтора, буксуя на каждом этапе там, где сейчас получал ответ за пять минут. Ментор не заменяет твои усилия, он убирает потерянное время.

Отзыв самого К.:

В начале июня я обратился к Богдану с просьбой стать моим ментором.
Уже в середине августа, спустя почти 3 месяца, выхожу на новую работу ведущим аналитиком данных в одной из ведущих российских финтех-компаний на хорошую зарплату. Богдан составил роадмап, который закрыл мои пробелы в знаниях, и был на связи по любым вопросам в его рамках. Раз в неделю мы созванивались и разбирали пройденное, что помогало мне держать темп обучения.
После первого месяца добавились мок-собеседования, максимально приближенные к тому, что было на реальных интервью. Также Богдан помог с составлением легенды и резюме, после выхода практически сразу начал откликаться и ставить собеседования, что ускорило процесс поиска работы. Отдельно отмечу сроки: первый оффер я получил уже через два месяца после старта, а вышел на работу через две недели после него. При том, что на входе знаний у меня фактически не было — какая-то база по SQL была, но настолько сырая, что на реальных собесах она бы меня не вытащила.

Cовет тем, кто только думает про менторство: слушайте ментора и делайте.
Богдану краба🦀🤝 и огромная благодарность за проделанную работу.

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

До 28.08 действуют текущие условия: 25 000 ₽ в месяц, 100% предоплата. Кто успеет зайти — останется на них до конца работы.

С 28.08 будет два тарифа: 25 000 ₽ предоплатой + 140% от оклада постоплатой или 40 000 ₽ предоплатой + 120%.

Подробнее расписал на сайте
Записаться и задать вопросы

❤️‍🔥 Подписывайтесь и поддержите канал бустом

@data_driven_bogdan

✍️ Михаил Шуфутинский пишет код

Задача на разметку данных

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

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

Как устроено событие 🧩

Событие почти всегда составное. Оно собирается из блоков твоего прила — от общего к частному — и заканчивается действием (action), которое совершил юзер.

Схема примерно такая:
где_блок_часть блока_действие
Например: main_banner_promo_scroll или cart_delivery_address_click.
По имени события должно быть сразу видно, откуда оно прилетело и что означает (это конечно, не всегда выполнимо, но целимся в это)

С чего начинать 👇

➖ Принимаем to be дизайн c cjm'ом (путь клиента по фиче)
➖ Идем в доку. Если она есть. И если она актуальная (спойлер: чаще всего одно из двух не выполняется). Если процесс новый, можно ничего не искать
➖ Смотрим текущие события в as is формате — как размечено то, что уже есть в БД (если этот процесс сейчас стримится). По сути восстанавливаем картину по тому, как события реально проливаются в базу. Не идеально, но работает + можно вкурить нынешние косяки...
➖ На всем этом этапе супер важно синковаться: тестировщики и разрабы, которые шарят за домен или будут это реализовывать. Ну и бизнес, чьи хотелки мы вообще-то и реализуем.

Мой совет 💡

Лучше всего идти напрямую к разрабам. У них уже есть картина реализации и модель, по которой события отдаются с бека или фронта.
Они конкретно скажут где, как, что и почему — а не «ну вроде так должно быть».
Через вторые руки эта информация теряется, а потом ты сидишь и гадаешь, почему в витрине не то, что ты ожидал.

DoD (definition of done) по таким типам задач обычно выглядит так:
Дока на конфе с новыми событиями + после выкатки — тесты на корректную отработки в поставленной логике.

❤️‍🔥 Подписывайтесь и поддержите канал бустом
↗️ Менторю и помогаю выйти на оффер
❓ Сталкивались ли вы с разметкой?

@data_driven_bogdan