Исторический контекст восходит к эволюции freemium моделей от статических лимитов (фиксированных 5GB в облаке) к динамическим, адаптивным ограничениям на базе Machine Learning. Классические подходы оценки эффективности таких интервенций сталкиваются с фундаментальной эндогенностью: система намеренно ограничивает пользователей с высокой предсказанной склонностью к конверсии, создавая сильный селекционный сдвиг. Ранние методы корреляционного анализа давали смещенные оценки, так как игнорировали confounding by indication, приводя к переоценке эффекта на 200-300%.
Постановка проблемы требует измерения Local Average Treatment Effect (LATE) в условиях, когда назначение лимита коррелирует с латентной мотивацией пользователя. Модель предсказывает вероятность конверсии $P(conv|X)$ и назначает ограничение при $P > \tau$, что делает группы несравнимыми по наблюдаемым и ненаблюдаемым характеристикам. Прямое сравнение пользователей с лимитом и без приводит к overestimation, так как treated-группа изначально "горячее" и готова платить.
Подробное решение базируется на Regression Discontinuity Design (RDD) на пороге $\tau$ скоринговой модели. В окрестности порога (bandwidth $h$) назначение лимита квази-случайно, так как пользователи с $P = \tau - \epsilon$ и $P = \tau + \epsilon$ статистически неотличимы. Строится непрерывная регрессия исхода на скоринговый балл с оценкой разрыва (jump) в точке $\tau$. Для повышения точности применяется Causal Forest для оценки гетерогенности эффекта, а при поэтапном внедрении используется Difference-in-Discontinuities для контроля временных трендов. Альтернативно возможно применение Inverse Propensity Weighting (IPW) с оценкой propensity score через Random Forest, но это требует условия unconfoundedness, которое редко выполняется в полной мере.
Проблема
В B2B SaaS продукте для управления задачами внедрили динамический лимит на количество активных проектов для бесплатных аккаунтов. ML-модель анализировала 50+ признаков поведения и блокировала создание новых проектов, предсказывая вероятность конверсии выше 0.75. Продуктовая команда наблюдала рост конверсии на 40% среди "залимитированных" пользователей, но не могла отделить эффект ограничения от самоотбора мотивированных пользователей. При этом полный запрет на лимиты для теста был невозможен, так как это означало бы потерю $200K MRR в месяц эксперимента.
Вариант 1: Наивное сравнение с историческими данными
Сравнить конверсию текущих пользователей с лимитом против когорты двухмесячной давности до внедрения фичи. Плюсы: требует минимальных затрат на инфраструктуру, быстрая оценка без технических изменений. Минусы: полностью игнорирует сезонность (новогодний спад активности), общий тренд роста конверсии (продукт становился зрелее) и эффект новизны; дает смещенную оценку в сторону завышения на 35-40% из-за selection bias.
Вариант 2: Классический A/B-тест с отключением ML-модели
Случайно отключить назначение лимитов для 15% пользователей, позволяя им неограниченно использовать продукт независимо от скоринга. Плюсы: золотой стандарт каузальности, прямое измерение Average Treatment Effect (ATE). Минусы: категорически отвергнут C-level из-за риска потери "горячих" пользователей, которые в контрольной группе не получат триггер к конверсии; создает значительный opportunity cost и этичные конфликты (почему одним разрешаем всё, а другим нет).
Вариант 3: Regression Discontinuity Design с гибридным подходом
Использовать естественный порог скоринга (0.75) как точку разрыва, сравнивая пользователей с вероятностью конверсии 0.74 и 0.76 как локально-рандомизированные группы (~5000 пользователей в окне ±0.05). Дополнить Synthetic Control Method для регионов, где внедрение отложено на месяц. Плюсы: сохраняет бизнес-логику для 95% пользователей; дает несмещенную оценку локального эффекта (LATE) для "пограничных" пользователей; позволяет использовать естественную вариацию без ущерба для выручки. Минусы: требует большой выборки около порога (>2000 наблюдений); оценка применима только к подгруппе с $P(conv) \approx 0.75$, а не ко всей популяции; чувствительно к манипуляциям порогом (требуется McCrary test на плотность распределения).
Выбранное решение и результат
Был выбран RDD с оптимальной шириной окна по методу Calonico-Cattaneo-Titiunik (CCT bandwidth), дополненный Causal Forest для поиска субпопуляций с негативным эффектом. Анализ выявил, что жесткий лимит дает +12% к конверсии для "средних" пользователей (около порога), но -8% к retention для power users (высокий engagement, но скоринг чуть ниже порога). На основе этого был внедрен гибридный режим: мягкие лимиты (warning only) для power users, жесткие (hard cap) для средних. Итоговый результат: рост конверсии на 8% при сохранении 30-дневного retention на уровне 96% от базового, что принесло дополнительные $450K ARR за квартал без оттока ключевых пользователей.
Как отличить эффект самого ограничения от эффекта "напоминания" (reminder effect) о платной версии?
Кандидаты часто интерпретируют рост конверсии как результат только финансового ограничения, игнорируя, что само уведомление о лимите acts as a marketing touchpoint. Для изоляции нужна дополнительная контрольная группа с "мягким" уведомлением (только информация о премиум без блокировки функции) или анализ времени между показом лимита и конверсией. Если конверсия происходит мгновенно (в течение часа) — скорее всего это reminder effect, если через 3-7 дней после нескольких попыток превысить лимит — это реальный эффект ограничения. Также можно использовать instrumental variable в виде technical latency отображения уведомления как случайной вариации интенсивности напоминания, применяя 2SLS регрессию.
Как учесть сетевые эффекты в командных продуктах (Notion, Figma), где ограничение одного пользователя влияет на коллаборацию коллег?
В B2B SaaS ограничение одного члена команды создает spillover effects: коллеги могут либо агрегировать ресурсы в один аккаунт, либо мигрировать на конкурента. Классический RDD игнорирует эти внешние эффекты, нарушая SUTVA (Stable Unit Treatment Value Assumption). Решение — cluster-RDD на уровне команды/воркспейса, где treatment определяется долей "залимитированных" пользователей в команде, или использование two-stage least squares (2SLS) с количеством ограниченных соседей по сетевому графу как инструментом. Важно измерять violation через анализ сетевой активности (network adjacency matrix) между пользователями с разными статусами лимитов, проверяя гипотезу о homophily в командах.
Как отделить истинный эффект ограничения конкретной функции от сдвига использования на менее ценные функции (substitution bias)?
Пользователи, столкнувшись с лимитом на функцию A, могут мигрировать на функцию B (например, с таблиц на текстовые документы), что создает иллюзию высокого retention, но фактически деградирует product stickiness и feature adoption depth. Для измерения нужен анализ Shannon entropy использования функций (измерение diversity of usage) или compositional data analysis (CODA). Если энтропия падает после ограничения, значит произошла каннибализация внутри продукта. Оптимальная политика должна максимизировать не just conversion, а expected LTV с учетом изменения паттерна использования, что требует моделирования через Markov Decision Process (MDP) или contextual bandit с reward function, учитывающей depth of feature adoption и engagement velocity, а не только факт конверсии.