Глобальные контрольные группы

Привет! На связи Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала про аналитику кусочек пиццы 👋🏻

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

На самом деле нет.

Проблема в том, что мы привыкли оценивать эффекты изолированно — для каждой отдельной фичи в рамках каждого конкретного эксперимента. Но мы забываем про совокупный эффект (Cumulative Effect) и взаимодействие изменений.

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

Чтобы понять, как все наши изменения в сумме влияют на пользователя на длинной дистанции, обычного A/B-теста недостаточно. Нам нужна глобальная контрольная группа (ГКГ/ГЦГ).

ГКГ (global holdout group) — это сегмент пользователей, который изолируется от всех (или большинства) изменений и маркетинговых коммуникаций на длительный срок.

Если в классическом тесте мы держим контроль 2 недели, то ГКГ живет 3, 6 или 12 месяцев. Это наша «тихая гавань» в шторме релизов.

Как это работает на практике?

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

🏘 Тип 1. Статическая ГКГ (Static Holdout)

Вы просто отрезаете кусок аудитории (например, 5% по User ID) и «замораживаете» их навсегда.

➕ Плюс: идеально чистые данные для расчета LTV — вы точно знаете историю каждого пользователя.

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

🎢 Тип 2. Ротируемая ГКГ (Rolling Holdout)

Пользователи попадают в контроль на фиксированное время (например, на 90 дней), а затем возвращаются в общую массу, заменяясь новыми.

➕ Плюс: выборка всегда свежая, нет смещения (bias).

➖ Минус: сложнее математика. Вы не можете оценить эффекты длиннее окна ротации.

Главное ограничение использования ГКГ: «Мы теряем деньги!»

Внедрение ГКГ — это всегда битва с заказчиками. Маркетинг кричит: «Если мы не отправим промокоды этим 5% людей, мы недополучим миллионы выручки!».

Здесь важно объяснить два момента:
🟠 Мы не теряем, мы инвестируем в знание.
🟠 Без ГКГ мы летим вслепую. Мы можем тратить бюджет на SMS, которые не приносят инкрементальной выручки. Стоимость ГКГ — это плата за то, чтобы не сжигать бюджет впустую на остальной базе.

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

Резюмирую: если ваш продукт предполагает длительные отношения с клиентом (подписка, банкинг, e-commerce, телеком) — локальных тестов мало. Локальный тест отвечает на вопрос: «Как эта кнопка влияет на клики сегодня?» ГКГ отвечает на вопрос: «Становится ли наш бизнес здоровее от всего, что мы делаем?».

Ставьте реакции, если было полезно!

📈 Симулейтив | ВК | YouTube

A/B-тест в коммуникациях: реальный кейс, результаты и главная ошибка, которую мы недооценили

Привет, коллеги! На связи Евгений Буторин, руководитель CRM-аналитики в Альфа Банке 👋🏻

Делюсь свежим (и поучительным) кейсом из нашей практики по A/B-тестам. Мы тестировали изменения в push + email-цепочке, чтобы поднять пост-коммуникационную активность клиентов.

😶 Что тестировали

Гипотеза: новая версия сообщения (более персонализированный текст + эмодзи + вечерний тайминг) даст больший прирост (lift) в активности или активации клиентов, чем старая.

➖ Группа A (контроль): старая коммуникация
➖ Группа B (тест): новая версия

Метрики:
➖ Активность клиента в Т0 — активность в месяце отправки коммуникации;
➖ Активность клиента в Т1 — активность клиента на следующий месяц после отправки коммуникации.

😶 Выборка и дизайн

Целевая база: 100 тысяч клиентов. Группы стратифицировали по активности, сегменту, времени жизни клиента, тарифу и каналу привлечения.

Период проведения: 1 месяц проведения + 1 месяц вызревания.

😶 Результаты на первый взгляд

Группа B показала рост активности на 11% в Т0 и на 7% в Т1. На первый взгляд мы решили, что пилот успешен, пока не сравнили профили клиентов по сторонним коммуникациям.

😶 Главная ошибка

При стратификации мы не учли параллельные коммуникации вне этого пилота. Даже при том, что на A/B-группы по этому тесту коммуникации были строго разделены, клиенты продолжали получать триггерные рассылки, другие промо, емейлы и SMS от параллельных кампаний, win-back и сервисные рассылки.

В итоге в группах A и B оказалась разная «загрязнённость» дополнительными касаниями: в B случайно попало на 15–20% больше параллельных коммуникаций, чем в A. Это создало искажённое представление об успешности пилота — часть lift’а мы приписали нашей новой версии, хотя на деле был эффект синергии (или каннибализации) от других каналов.

Как исправляли постфактум:
🟠 Собрали полную историю всех коммуникаций (1 месяц от запуска пилота) по каждому клиенту;
🟠 Ввели новую стратификационную переменную «communication load» с типом и количеством касаний;
🟠 Перестратифицировали обе группы заново, создав чистые эквивалентные группы;
🟠 Заново пересчитали эффекты от пилота: реальный эффект нашей коммуникации упал до +4% в Т0 и +1% в Т1.

Положительный результат пилота сохранился, но значения значительно снизились.

😶 Что теперь делаем обязательно

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

Хотите строить эффективные тесты и избегать ошибок? Записывайтесь на курс по A/B-тестированию, где под руководством опытного специалиста вы начнёте проводить эксперименты, которые покажут вам реальные выводы и приведут к выгодным решениям!

📈 Записаться на курс: simulative.ru/ab-test

📈 Симулейтив | ВК | YouTube

Присоединяйтесь к решению тестовых заданий сегодня в 19:00

Павел Беляев ждёт вас на вебинаре! На примере тестового задания из Magnit Tech мы потренируемся работать со списками товаров и заказов, особенно актуальными для e-commerce.

Мы попрактикуемся:
🟠 Фильтровать выборку разными видами условий;
🟠 С помощью оконной функции выбирать текущее состояние товара в исторических данных;
🟠 А также увидим, как использовать JOIN-объединение таблиц в качестве фильтра.

➡️ Зарегистрироваться на вебинар

📈 Симулейтив | ВК | YouTube

4 реальных кейса применения оконных функций

Всем привет! Я Павел Беляев, ментор курса «Аналитик данных» и ведущий канала Тимлидское об аналитике 👋🏻

Хочу показать несколько примеров применения оконок из реальной практики аналитиков Яндекс eLama.

1️⃣ Последняя запись в исторических данных

Если имеем дело с таблицей, которая обновляется не перезаписью с нуля, а добавлением новых строк для объектов, которые изменились, вот как можно взять последнюю строку:

SELECT *
FROM
(
    SELECT *
        MAX(updated_at) OVER (PARTITION BY payment_id) AS last_update
    FROM payment
)
WHERE updated_at = last_update

Здесь payment — таблица, содержащая транзакции пользователя. Одна строка отражает состояние транзакции на момент добавления строки, т. е. на дату updated_at. Каждая транзакция имеет уникальный идентификатор payment_id, но он не уникален в рамках всей таблицы.

2️⃣ Топовые юзеры

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

SELECT *
FROM
(
   SELECT d, w, user_id, revenue,
      ROW_NUMBER() OVER (PARTITION BY d ORDER BY revenue DESC) AS rn  -- нумеруем юзеров в порядке убывания их оборота
   FROM
   (
      SELECT DATE(date_paid) AS d, 
        dateName('weekday', date_payed) AS w,
        user_id, 
        SUM(revenue) AS revenue
      FROM datamart.financial_activity
      GROUP BY 1,2,3
   )
)
WHERE rn<=15 -- Количество топовых юзеров за каждый день
   AND w='Wednesday' -- День недели. Часто пользователи активничают ритмично, например по средам.
ORDER BY d DESC, revenue DESC

3️⃣ Lifetime value

LTV часто выбирают как главную метрику компании (North Star Metric). Оконкой можно вывести LTV юзера на каждый момент времени — например, когда он совершает очередной платеж.

SELECT user_id, date_paid, 
  turnover,
  SUM(turnover) OVER (PARTITION BY user_id ORDER BY date_paid) AS LTV
FROM datamart.money
ORDER BY date_paid DESC

Заметим, что при такой записи выводится LTV на момент date_paid, а не текущий LTV. Так что можно следить за скоростью его роста.

4️⃣ Скользящее среднее

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

Тогда в течение месяца мы её ещё не знаем. Простой прогноз можно состряпать как скользящее среднее за предыдущие месяцы.

В ClickHouse прошлые значения выводит функция lagInFrame():

SELECT period, SUM(act_amount) am,
  lagInFrame(am,1,0) OVER (ORDER BY period ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS am1,
  lagInFrame(am,2,0) OVER (ORDER BY period ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS am2,
  lagInFrame(am,3,0) OVER (ORDER BY period ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING) AS am3,
  (am1 + am2 + am3)/3 AS am_avg,
FROM   datamart.money
GROUP BY ALL

Ставьте огоньки, если пригодится в работе!

📈 Симулейтив | ВК | YouTube

Вебинар: почему компаниям больше не нужны «узкие» специалисты

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

На вебинаре с Ильей Ковалёвым, старшим аналитиком данных в Dodo Brands и автором канала кусочек пиццы, разберём, почему fullstack-подход становится стандартом, какие задачи теперь решает один специалист вместо трёх и за что на самом деле платят деньги в аналитике.

➡️ Зарегистрироваться на вебинар

На вебинаре расскажем:
➖ Как выросли требования к аналитикам;
➖ Почему бизнес ищет специалиста, который понимает данные, умеет общаться с заказчиком и сам собирает решение;
➖ Реальные примеры задач, которые раньше делали три человека, а теперь делает один;
➖ Главные ошибки новичков: уход только в SQL/Python, непонимание бизнес-задач и страх ответственности.

❗️ Встречаемся 31 марта в 19:00 МСК

💬 Подключайтесь к эфиру, чтобы задать Илье вопросы про fullstack-аналитику, карьерные траектории и переход от узких ролей к комплексным задачам.

➡️ Зарегистрироваться на вебинар

📈 Симулейтив | ВК | YouTube

Propensity Score Matching: когда A/B-тест невозможен

Привет! На связи Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала про аналитику кусочек пиццы 👋🏻

Сегодня поговорим про один метод, который на первый взгляд может показаться ультимативным, но на самом деле он, как и прочие методы, применим не везде — Propensity Score Matching.

В чём суть метода?

Представьте ситуацию: вы запустили новую фичу, но не для всех пользователей случайно, а только для тех, кто сам её активировал. Классический A/B-тест не сработает — группы изначально разные. Активные пользователи включили фичу, пассивные — нет.

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

PSM решает эту проблему. Метод позволяет найти для каждого пользователя из тестовой группы похожего «близнеца» из контрольной группы. Похожего по всем важным характеристикам: траты, активность, история покупок и т. д.

Вот краткий алгоритм:

Шаг 1: строим модель, которая предсказывает вероятность попадания в тестовую группу

Берём характеристики пользователей (возраст, город, количество заказов, средний чек) и строим логистическую регрессию. Она предсказывает вероятность попадания в тестовую группу — это и есть Propensity Score.

Шаг 2: мэтчим пользователей по Propensity Score

Для каждого пользователя из тестовой группы ищем пользователя из контрольной с максимально близким Propensity Score.

Шаг 3: сравниваем метрики

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

Когда PSM работает хорошо?

1️⃣ Есть много признаков, которыми можно описать пользователей
Больше данных → точнее модель → лучше мэтчинг.

2️⃣ Группы пересекаются по характеристикам
Если в тестовой группе только VIP-клиенты, а в контроле их нет — мэтчинг не сработает. Нужно, чтобы для каждого пользователя из теста нашёлся похожий в контроле.

3️⃣ Решение о попадании в группу зависит от наблюдаемых факторов
Если пользователь активировал фичу из-за факторов, которые мы можем измерить (активность, возраст, город) — отлично. Если из-за чего-то скрытого (настроение, рекомендация друга) — PSM это не учтёт и возникнет смещение.

Как проверить, что мэтчинг работает?

Недостаточно просто проверить баланс групп по характеристикам. Нужна валидация на историческом периоде.

Примените PSM к данным ДО воздействия. Например, фичу запустили 1 июня — сделайте PSM на данных за май. Если хорошо подобранные фичи показывают «эффект» там, где его быть не может — проблема в скрытых факторах, плохом мэтчинге или в сверхвысокой чувствительности.

Так, на выборках 100k+ пользователей возникает проблема: любая мизерная разница становится статистически значимой. P-value < 0.05 при разнице в 0.01% — технически значимо, но практически шум.

Решение: не использовать всю выборку. Можно определить MDE (минимальный детектируемый эффект, например +2%), расчитать нужный размер выборки под этот MDE и ограничить выборку до этого размера - т.е. взять случайные 50k вместо всех 500k.

Так вы не будете детектить шум как значимый эффект.

На что ещё стоит обратить внимание

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

2️⃣ Работайте с выбросами. Перед построением модели сглаживайте или убирайте выбросы. Экстремальные значения могут исказить Propensity Score и ухудшить матчинг.

3️⃣ Используйте Caliper Matching. Не мэтчите пользователей, если разница в Propensity Score больше порога (например, 0.01). Лучше потерять часть данных, чем получить плохие пары.

4️⃣ Всегда проверяйте качество мэтчинга на историческом периоде. Это единственный способ убедиться, что метод мэтчит без смещения.

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

📈 Симулейтив | ВК | YouTube

Как работать с датами и временем в аналитике

Всем привет! На связи Александр Грудинин, ментор курса «Аналитик данных» 👋🏻

Сегодня поговорим про тему, которая кажется простой, но на практике входит в топ источников багов в аналитике — работа с датами и временем.

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

Примеры буду показывать на PostgreSQL, но логика применима и к другим БД.

🟠 DATE vs TIMESTAMP

DATE — просто календарная дата: 2025-03-15
TIMESTAMP — дата + время: 2025-03-15 14:30:00

Почему важно различать? Вот классический баг:

WHERE created_at = '2025-03-15'

Заказ в '2025-03-15 10:30:00' сюда НЕ попадет!

➖ Рабочий вариант #1 — приведение к дате:

WHERE created_at::date = '2025-03-15'

➖ Рабочий вариант #2 (есть мнение, что так лучше, но я сам использую предыдущий):

WHERE created_at >= '2025-03-15' AND created_at < '2025-03-16'

🟠 Часовые пояса — главная боль

Пользователь из Москвы сделал заказ в 1:30 ночи 15 марта. На сервере в UTC это записалось как 14 марта 22:30. Один заказ, два дня. Умножьте на тысячи заказов 🙃

Конвертируем UTC в московское время:

SELECT
 (created_at AT TIME ZONE 'UTC' AT TIME ZONE 'Europe/Moscow')::date AS order_date,
 COUNT(1) AS orders_count
FROM orders GROUP BY 1

В pandas то же самое:

# Указываем что данные в UTC
df['created_at'] = pd.to_datetime(df['created_at']).dt.tz_localize('UTC')
# Конвертируем в Москву
df['created_at_msk'] = df['created_at'].dt.tz_convert('Europe/Moscow')`

Важно:
➖ tz_localize = «эти данные уже в таком поясе, запомни»
➖ tz_convert = «пересчитай из одного пояса в другой»
Перепутаете — и получите сдвиг на несколько часов во всех данных 🙂

🟠 Ещё одни грабли — формат дат

Дата 03/04/2025 — это 3 апреля или 4 марта? Pandas может угадать неправильно. Всегда указывайте формат явно:

df['date'] = pd.to_datetime(df['date'], format='%d/%m/%Y')

Чек-лист для проверки:

#️⃣ Проверяйте тип данных — DATE или TIMESTAMP?
#️⃣ Выясняйте, в каком часовом поясе хранятся данные в источнике данных
#️⃣ Договоритесь с командой о едином часовом поясе для отчётов
#️⃣ Явно указывайте формат при парсинге дат

Ставьте 🔥 и сохраняйте шпаргалку к себе!

📈 Симулейтив | ВК | YouTube

Через 2 часа — вебинар, как стать универсальным аналитиком

Подключайтесь в 19:00 МСК и узнайте, почему fullstack-подход становится стандартом, какие задачи теперь решает один специалист вместо трёх и за что на самом деле платят деньги в аналитике. Вебинар проведёт Илья Ковалёв, старший аналитик данных в Dodo Brands и автор канала кусочек пиццы. Присоединяйтесь!

➡️ Регистрация

📈 Симулейтив | ВК | YouTube