TL;DR
Результат квазиэксперимента — не цифра, а аргумент. Causal-вывод требует особой коммуникации: нужно показать, что метод применим к данным, что допущения проверены, что ограничения честно описаны, и что рекомендация соответствует силе доказательства. Аналитик, который не умеет рассказывать quasi-experimental результат, оставляет свою работу в файле. Этот модуль про то, как структурировать narrative так, чтобы менеджмент принимал решения на твоих выводах — и при этом не верил больше, чем стоит.
Quasi-experiment отличается от A/B в одном принципиальном смысле: результат A/B защищается дизайном, результат quasi-experiment защищается аргументом. В A/B рандомизатор гарантирует, что треатед и контроль сравнимы — это автоматически, об этом можно не говорить. В quasi-experiment сравнимость нужно обосновать: «эти группы похожи потому, что...», «параллельные тренды правдоподобны потому, что...», «exclusion restriction выполнена потому, что...». Без этого обоснования причинный вывод не имеет статуса.
Это меняет требования к нарративу. В A/B типичный отчёт: «Тест показал +3.2%, p = 0.02, выкатываем». В quasi-experiment такого нарратива недостаточно — он скрывает половину аргумента. Полный отчёт quasi-experiment включает дизайн (почему так), допущения (что предполагается), проверки (что подтвердили), оценку (главную цифру), ограничения (что метод не учитывает) и рекомендацию (что делать с учётом всего этого). Каждый блок — часть аргумента, и пропуск любого из них даёт неполное доверие.
Что мы измеряем: не «работает ли фича», а «насколько надёжно мы можем сказать что фича работает». Это содержательно разные вопросы. На первый отвечает коэффициент, на второй — полный нарратив.
Что важно понимать: грамотный quasi-experimental нарратив не «продаёт» результат и не «защищает» его. Он его объясняет. Менеджер должен после прочтения понять, на каких допущениях стоит вывод и при каких условиях вывод перестаёт работать. Если он этого не понял — narrative провалился, даже если решение принято в нужную сторону.
Один и тот же quasi-experimental результат рассказывается по-разному в зависимости от аудитории. Это не упрощение для слабых — это адаптация к тому, какое решение принимает читатель и какая часть аргумента ему критична.
| Аудитория | Что хочет узнать | Что подсветить |
|---|---|---|
| PM / команда продукта | Достаточно ли уверенности для action? | Главная цифра + границы применимости. Меньше про методологию, больше про «что делать завтра» |
| VP / руководство | Стоит ли вкладывать ресурсы? Какие риски? | Размер эффекта в бизнес-терминах + ограничения как риск-факторы. Дизайн коротко, через аналогию |
| Аналитик-аудитор / data review | Можно ли доверять выводу? | Все допущения, все проверки, все альтернативные спецификации. Это режим «защита диссертации» |
| Внешняя публикация | Что узнало сообщество? | Метод подробно, результат с CI, replication-материалы, явное scope statement |
Главная ошибка — использовать один и тот же текст для всех. PM не нужны Rosenbaum bounds, аудитору обидно получить только bullet-points. Хороший аналитик пишет core-документ (полный нарратив для аудитора) и из него делает выжимки под другие аудитории.
Что важно: даже в коротком нарративе для PM ограничения должны быть. Не в виде Rosenbaum-сноски, а в одном предложении: «Этот эффект — для тех продавцов, кто активирует функцию после push. На остальных может быть меньше». Пропуск ограничений ради краткости — это наценка вранья.
Хороший quasi-experimental нарратив следует семи шагам. Это не строгая последовательность, но проверочный список: любой блок, который пропущен, ослабляет аргумент.
В модуле 6 мы оценили эффект активации платной функции «Турбо-продажи» на GMV продавца через encouragement design. Результат: LATE = +49 000 ₽ за 30 дней для compliers, F-statistic = 45 (сильный инструмент).
Теперь задача — превратить это в нарратив. Берём те же семь шагов и развёртываем.
«Команда роста хочет масштабировать "Турбо-продажи". Прямое сравнение пользователей, активировавших и не активировавших функцию, даёт смещённую оценку: активируют функцию более активные продавцы. Чтобы получить причинный эффект, мы использовали данные из недавнего A/B-теста push-уведомления — push рандомизирован, что позволяет применить метод instrumental variables».
«Push в IV служит инструментом для активации функции. Логика: push случайно увеличивает вероятность активации (продавцы вспоминают про функцию), а активация влияет на GMV. Разделив эффект push на GMV на эффект push на активацию, получаем эффект активации очищенный от selection bias».
«Метод требует трёх условий: (1) push реально двигает активацию — проверяемо; (2) push сам по себе не влияет на GMV кроме как через активацию (exclusion restriction) — содержательное допущение; (3) нет продавцов, которые получив push специально НЕ активируют — практически невероятно.
Главная уязвимость — exclusion. Push может повышать GMV через увеличение осведомлённости о платформе или активацию других функций, не только Турбо-продаж. Это ограничивает интерпретацию».
«First stage F-statistic = 45 — сильный инструмент, relevance подтверждена. Balance check по получившим и не получившим push — все ковариаты сбалансированы, independence подтверждена (это ожидалось — push рандомизирован). Reduced form (push → GMV) значим, p = 0.003.
Exclusion: посмотрели на изменение GMV у получивших push, но НЕ активировавших Турбо-продажи. Эффект небольшой (+1 200 ₽, p = 0.12). Это значит, что прямой эффект push минимален — exclusion правдоподобна».
«Эффект активации Турбо-продаж на GMV для compliers (продавцов, активировавших именно из-за push): +49 000 ₽ за 30 дней. 95% CI: 31 000 – 67 000 ₽.
Для сравнения: OLS (без учёта селекции) даёт +51 000 ₽. Близость значений говорит, что endogeneity в этой задаче небольшая».
«(1) Эффект оценён для compliers — это около 25% популяции (продавцы, реагирующие на push). На always-takers (активирующих без напоминания) эффект может быть меньше — они уже получают пользу. На never-takers — неизвестно.
(2) Эффект измерен за 30 дней. Долгосрочная динамика (вернётся ли продавец через 3 месяца) — за рамками этого анализа.
(3) Анализ исходит из того, что push содержит только приглашение в Турбо-продажи. Если push несёт другую информацию — exclusion может нарушаться».
«При текущей уверенности рекомендую: (а) масштабировать push-кампанию на остальную аудиторию — эффект для реагирующих продавцов значим и измерим; (б) НЕ делать вывод, что Турбо-продажи дают +49К всем — это эффект на compliers, и активация других сегментов может работать иначе; (в) запланировать follow-up через 3 месяца, чтобы измерить долгосрочный эффект и retention».
Это полный narrative. Под разные аудитории из него делают выжимки — для PM сократить до шагов 5, 6, 7 с одним предложением про дизайн. Для VP — добавить бизнес-перевод цифр (что 49К значит в годовом контексте, какой потенциал у масштабирования). Для аудита — оставить всё как есть, добавив подробные таблицы и robustness checks в приложение.
Чтобы свернуть полный narrative в презентацию, удобно использовать шаблон из четырёх слайдов. Это не обязательная форма, но рабочий минимум — на ней можно рассказать любой quasi-experimental результат без потери ключевых частей.
Слайд 1: Контекст + вопрос (1 предложение) + дизайн (1 предложение)
Слайд 2: Главный график (event study / RDD plot / synthetic vs actual)
Слайд 3: Оценка: δ = X% [CI: a%, b%]. Что проверили: ✓ parallel trends, ✓ placebo, ✓ bandwidth
Слайд 4: Ограничения + рекомендация (1–3 пункта)
Аналитик прислал отчёт:
«Новая система ранжирования увеличила GMV на 12%. DiD на категориях. Эффект статистически значим (p = 0.003). Рекомендуем выкатить на остальные категории».
Найдите три ошибки коммуникации в этом отчёте.
Что бы добавить минимум: один абзац про допущение parallel trends, один абзац про pre-trend и placebo тесты, один абзац про границы применимости эффекта, переформулировать рекомендацию: не «выкатить на остальные», а «протестировать на одной похожей категории перед масштабированием».
Дан результат RDD на BNPL-сервисе: у заявителей с кредитным скорингом около 650 одобрение увеличивает расходы за 30 дней на ~90 ₽. McCrary test пройден, bandwidth robustness устойчив, balance check сбалансирован.
Напишите одно-предложение headline для трёх аудиторий: (а) команды финтех-продукта (PM), (б) совета директоров, (в) внешней публикации (блог-пост).
(а) PM команда финтеха: «У заявителей с кредитным скорингом около 650 одобрение BNPL стабильно увеличивает их расходы на ~90 ₽ в первый месяц — это база для оценки юнит-экономики такого порога». Акцент: цифра + что с ней делать в продуктовой работе. Без терминов RDD — PM нужен результат.
(б) Совет директоров: «Каждое одобрение BNPL у заявителей на границе скоринга увеличивает их месячный оборот на ~90 ₽ — порог одобрения сейчас оптимизирован». Акцент: бизнес-перевод цифры + общий вывод «работает или нет». Метод вообще не упомянут.
(в) Внешний блог-пост: «На основе RDD-анализа порога одобрения BNPL мы нашли причинный эффект +90 ₽ за 30 дней на расходах заявителей рядом с порогом — методологию и проверки публикуем». Акцент: метод + результат + replication. Аудитория — другие аналитики и широкое сообщество, для них методология важна.
Разница не в правде — она везде одна. Разница в акцентах. Бизнес-перевод цифры везде должен быть. Метод — только там, где это релевантно решению читателя.
Вы построили SCM для оценки эффекта изменения surge-логики в одном городе (Новосибирск). Pre-period RMSPE = 0.4 (хорошая подгонка), эффект на средний чек = +12%. Но in-space placebo не пройден — реальный эффект попадает только в 88-й перцентиль распределения placebo-эффектов (стандартный порог — 95-й перцентиль).
Менеджер хочет знать: применять новую surge-логику в остальных городах или нет? Как сформулировать ответ?
Это сложный случай — формальная значимость не достигнута, но и эффект полностью не отбрасывается. Честный нарратив не «давайте выкатывать» и не «вообще не работает». Он про два возможных мира.
«Анализ SCM показал ориентировочный эффект новой surge-логики +12% на средний чек в Новосибирске. Pre-fit модели хороший — синтетический контроль надёжно повторяет реальную траекторию города до изменения.
Однако проверка значимости не пройдена. В placebo-тесте (применили тот же метод к 12 другим городам, на которых ничего не менялось) мы получили распределение "случайных" эффектов. Реальный эффект Новосибирска попадает в 88-й перцентиль — при стандартном пороге 95-й перцентиль. То есть 12% эффекта правдоподобно объясняются случайной вариацией.
Это означает: либо эффект небольшой и реальный, но шум не позволяет его выделить (нужно больше данных или дольше окно); либо эффекта нет вообще.
Рекомендация: (а) НЕ выкатывать пока на остальные города — статистических оснований недостаточно. (б) Запустить аналогичный пилот в 2–3 других городах параллельно (на 60–90 дней), потом повторить SCM с большим числом treated. Если эффект сохранится — будет значим. (в) Параллельно проверить — не было ли в Новосибирске других изменений (маркетинг, шторм с водителями), которые могли создать видимость эффекта».
Что важно: 88-й перцентиль не прячется. Он называется вслух — это часть аргумента. Менеджер должен понимать, что вывод стоит на границе значимости, и решение «подождать» — это содержательно правильный response, а не «ты что-то сделал не так».
Pre-registration — практика, заимствованная из академической литературы: описать дизайн анализа (метод, спецификация, ковариаты, ожидаемый эффект) ДО того, как смотреть на данные. После — обязан показать как заявленный, так и любые отклонения.
Это устраняет p-hacking и выбор спецификаций «под результат». Для продуктовой аналитики pre-registration не обязателен, но для важных решений (large rollout, investment cases) — практика отличного качества.
Минимальная форма: написать в Notion / Confluence до анализа: «Я планирую DiD на категории X с control Y, ожидаю эффект +5–10%, использую такие проверки». После анализа — сравнить с фактом. Если получилось сильно иначе — обсудить почему.
Replication — следующий шаг. Опубликовать в общий доступ команды (а лучше — внешне) код, данные и описание. Если кто-то другой не повторит ваш результат — это полезная информация. На западе это становится стандартом для high-stakes решений.