Исторический контекст
В период с 2010 по 2015 год доминировал подход полной совместимости, когда компании поддерживали native-приложения для iOS и Android, охватывая 95% рынка по версиям ОС. Однако с ростом сложности функционала и переходом на современные API (такие как Biometric API, Camera2, Jetpack Compose) стоимость поддержки legacy-кода превысила маржинальность удерживаемых пользователей. К 2020-м годам стандартом стала политика "n-2", требующая разработки методологий оценки истинного эффекта отключения, а не просто корреляционного анализа метрик.
Постановка проблемы
Принудительное отключение создает эндогенность самоотбора: пользователи с устаревшими устройствами физически не могут обновиться до требуемой версии iOS или Android, в то время как активная аудитория с современными смартфонами обновляется оперативно. Наблюдаемое падение MAU может быть результатом истинного оттока (churn), либо миграцией в PWA (Progressive Web App) или мобильный веб. Классическое A/B-тестирование невозможно, так как отключение носит технический характер и применяется ко всем пользователям конкретной версии ОС одновременно, а отслеживание идентичности между нативным приложением и веб-версией затруднено из-за ограничений Safari и Chrome в работе с cookies.
Подробное решение
Оптимальная методология базируется на комбинации разрывной регрессии (RDD) и синтетического контроля (Synthetic Control Method). Во-первых, используется RDD с порогом по версии ОС (например, отсечка на Android 8.0 против Android 9.0), где пользователи с версиями чуть ниже порога служат контрольной группой для пользователей чуть выше порога, с корректировкой на плавные характеристики (модель устройства, историческая частота использования).
Во-вторых, для оценки миграции в веб-канал строится синтетический контроль на основе исторических данных DAU по когортам пользователей, сопоставимых по поведенческим паттернам до отключения. Создается взвешенная комбинация когорт, не подвергшихся воздействию (например, пользователей других регионов с аналогичной структурой устройств), которая моделирует контрфактуальную траекторию метрик.
В-третьих, применяется difference-in-differences с Propensity Score Matching для сопоставления пользователей, которые могли бы обновиться, но не сделали этого, с теми, кто обновился, с корректировкой на технические характеристики устройств. Важно отслеживать cross-device миграцию через Customer Data Platform (CDP), связывая device_id мобильного приложения с cookie_id веб-версии через единый user_id при авторизации. Дополнительно используется survival analysis (модели Кокса) для оценки времени до оттока в зависимости от версии ОС и доступности веб-альтернативы.
Контекст: Крупный маркетплейс решил отказаться от поддержки Android 7.0 и ниже (около 8% базы) ради внедрения Biometric API для безопасных платежей. Бюджет проекта предполагал потерю не более 3% активной аудитории с компенсацией за счет роста конверсии в новых версиях.
Вариант 1: Простое сравнение MAU до и после отключения по датам с расчетом процента потери. Плюсы: простота расчета, скорость получения результата, не требует сложной инфраструктуры. Минусы: полностью игнорирует сезонность, миграцию в веб и самоотбор по устройствам; высокий риск ложноположительного вывода об оттоке, когда пользователи просто перешли на m.site.
Вариант 2: Построение когортного анализа с матчингом по устройствам с Android 8.0 (которые могли остаться, но обновились) против Android 7.0 (которые не могли обновиться). Плюсы: учитывает технические ограничения, позволяет изолировать эффект невозможности обновления от нежелания. Минусы: сложность получения чистых данных из-за фрагментации OEM-производителей (Samsung, Xiaomi), различий в поведении пользователей разных брендов и географической гетерогенности.
Вариант 3: Комплексный подход с Synthetic Control на уровне географических регионов с высокой долей старых устройств (сравнение региона А, где 30% на Android 7, с регионом Б, где таких 5%, до и после отключения) с корректировкой на общие тренды рынка. Плюсы: учитывает макроэкономические факторы и сезонность, позволяет оценить общий эффект на бизнес. Минусы: требует больших выборок и предполагает отсутствие других одновременных интервенций в регионах.
Выбранное решение: Был реализован Вариант 3 в комбинации с когортным анализом авторизованных пользователей (для отслеживания миграции в веб через SSO-логины). Выбор обусловлен необходимостью отделить истинный отток от каннибализации веб-трафика, что критично для оценки unit-economics (веб-пользователи имеют на 15% меньший AOV).
Итог: Анализ показал, что только 40% "потерянных" MAU реально оттекли, 35% мигрировали в PWA, а 25% обновили устройства в течение квартала. Истинный негативный эффект оказался в 2.5 раза меньше прогнозируемого, что позволило продолжить стратегию обновления API для оставшихся 92% аудитории с ростом GMV на 8% за счет новых платежных фич.
Как отличить техническую невозможность обновления от поведенческого отказа обновляться, если обе группы остаются на старых версиях приложения?
Ответ необходимо строить на анализе device_change events в CDP. Пользователи с поведенческим отказом (lazy updaters) часто имеют паттерн "отложенных обновлений" в истории (например, пропуск нескольких минорных версий, но установка критических патчей безопасности), в то время как технически ограниченные пользователи никогда не меняют OS version в течение всего lifecycle устройства. Дополнительно анализируется hardware fingerprint через WebGL или Canvas в веб-версии: если пользователь появляется в PWA с тем же устройством (по User-Agent и разрешению экрана), что и в нативном приложении до отключения, это подтверждает миграцию, а не отток. Важно также сегментировать по app_version history: если пользователь регулярно обновлялся внутри Android 7 (между патчами 7.0->7.1), но не перешел на 8.0, это указывает на технический лимит, а не нежелание.
Почему стандартный Propensity Score Matching может давать смещенные оценки при оценке эффекта forced upgrade в условиях сильной корреляции между доходом пользователя и моделью устройства?
Стандартный PSM основывается на условной независимости, предполагая, что наблюдаемые ковариаты полностью объясняют самоотбор. Однако в случае с sunset-политикой существует скрытая переменная — disposable income, которая коррелирует одновременно с моделью смартфона (флагман против бюджетника) и с LTV пользователя. Бюджетные устройства чаще не получают обновления ОС, а их владельцы имеют более низкую платежеспособность. Стандартный PSM недооценит негативный эффект, так как "взвесит" богатых пользователей с новыми устройствами как аналогов бедных со старыми, хотя их поведенческие паттерны различаются фундаментально. Решением является использование Coarsened Exact Matching (CEM) с точным стратифицированием по ценовым сегментам устройств (low-end, mid-range, flagship) до применения PSM, или инструментальных переменных (IV) с использованием политики обновлений OEM-производителей как экзогенного шока.
Как корректно учесть сетевые эффекты между пользователями разных версий приложения при оценке оттока, если функционал "поделиться товаром" работает по-разному в старой и новой версии?
Сетевые эффекты создают spillover между treatment и control группами: если активный пользователь новой версии (treatment) не может поделиться контентом с другом на старой версии (которая не поддерживает новый формат deep link), это ухудшает опыт обоих и может ускорить отток контрольной группы не по причине sunset-политики, а из-за деградации UX. Для корректировки необходимо применить network-based DID (Difference-in-Differences с сетевыми весами). Строится граф социальных связей (через анализ referral codes, совместных заказов или сообщений в чате приложения). Оценивается "заражение" (contagion) метрик: если пользователь в контрольной группе (старая версия) имеет много связей с treatment-группой (новая версия), его поведение будет искажено. В модель добавляется интеракционный член Treatment x Network_Exposure, где Network_Exposure — доля связей в сети, использующих новую версию. При высоком уровне сетевых эффектов истинный эффект sunset-политики будет занижен, так как часть "контрольных" пользователей фактически подверглась косвенному воздействию, и требуется корректировка на intention-to-treat (ITT) с учетом этой контаминации.