Contexto histórico
Desde 2010 hasta 2015 predominó el enfoque de compatibilidad total, donde las empresas mantenían aplicaciones nativas para iOS y Android, cubriendo el 95% del mercado según versiones de SO. Sin embargo, con el aumento de la complejidad funcional y la transición a API modernas (como Biometric API, Camera2, Jetpack Compose), el costo de mantener código legacy superó la rentabilidad de los usuarios retenidos. Para los años 2020, la política estándar se convirtió en "n-2", que exige el desarrollo de metodologías para evaluar el verdadero efecto de la desconexión, y no simplemente un análisis correlacional de métricas.
Planteamiento del problema
El forzado de desconexión crea endogeneidad en la auto-selección: los usuarios con dispositivos obsoletos físicamente no pueden actualizarse a la versión requerida de iOS o Android, mientras que la audiencia activa con smartphones modernos actualiza rápidamente. La disminución observada de MAU puede ser el resultado de una pérdida real (churn), o de una migración a PWA (Progressive Web App) o web móvil. El clásico A/B-testing es imposible, ya que la desconexión tiene un carácter técnico y se aplica a todos los usuarios de una versión de SO en simultáneo, y rastrear la identidad entre la aplicación nativa y la versión web es difícil debido a las limitaciones de Safari y Chrome con respecto a cookies.
Solución detallada
La metodología óptima se basa en una combinación de regresión discontinua (RDD) y método de control sintético (Synthetic Control Method). Primero, se utiliza RDD con un umbral por versión de SO (por ejemplo, corte en Android 8.0 contra Android 9.0), donde los usuarios con versiones ligeramente por debajo del umbral sirven como grupo de control para los usuarios ligeramente por encima del umbral, ajustando por características suaves (modelo de dispositivo, frecuencia histórica de uso).
En segundo lugar, para evaluar la migración al canal web se construye un control sintético basado en datos históricos de DAU por cohortes de usuarios, comparables en patrones de comportamiento antes de la desconexión. Se crea una combinación ponderada de cohortes no expuestas (por ejemplo, usuarios de otras regiones con una estructura de dispositivos similar), que modela la trayectoria contrafactual de las métricas.
En tercer lugar, se aplica difference-in-differences con Propensity Score Matching para emparejar usuarios que podrían haberse actualizado pero no lo hicieron, con aquellos que sí se actualizaron, ajustando a las características técnicas de los dispositivos. Es importante rastrear la migración cross-device a través de Customer Data Platform (CDP), vinculando el device_id de la aplicación móvil con el cookie_id de la versión web mediante un único user_id en el inicio de sesión. Además, se utiliza survival analysis (modelos de Cox) para evaluar el tiempo hasta la pérdida dependiendo de la versión de SO y la disponibilidad de alternativas web.
Contexto: Un gran marketplace decidió dejar de asistir a Android 7.0 y versiones anteriores (alrededor del 8% de la base) a favor de la implementación de Biometric API para pagos seguros. El presupuesto del proyecto preveía una pérdida no mayor al 3% de la audiencia activa, compensada por un aumento en la conversión en nuevas versiones.
Opción 1: Comparar simplemente MAU antes y después de la desconexión por fechas calculando el porcentaje de pérdida. Ventajas: simplicidad en los cálculos, rapidez en obtener resultados, no requiere infraestructura compleja. Desventajas: ignora completamente la estacionalidad, la migración a la web y la auto-selección por dispositivos; alto riesgo de falso positivo sobre la pérdida, cuando los usuarios simplemente migraron a m.site.
Opción 2: Realización de un análisis de cohortes emparejando por dispositivos con Android 8.0 (los que podrían haberse quedado, pero actualizaron) contra Android 7.0 (los que no pudieron actualizarse). Ventajas: tiene en cuenta las limitaciones técnicas, permite aislar el efecto de la imposibilidad de actualizarse del desinterés. Desventajas: dificultad para obtener datos limpios debido a la fragmentación de los fabricantes OEM (Samsung, Xiaomi), diferencias en el comportamiento de usuarios de diferentes marcas y heterogeneidad geográfica.
Opción 3: Enfoque integral con Synthetic Control a nivel de regiones geográficas con una alta proporción de dispositivos antiguos (comparación de la región A, donde el 30% está en Android 7, con la región B, donde solo el 5% está en esa versión, antes y después de la desconexión) ajustando por tendencias generales del mercado. Ventajas: considera factores macroeconómicos y estacionales, permite evaluar el efecto total en el negocio. Desventajas: requiere muestras grandes y asume la ausencia de otras intervenciones simultáneas en las regiones.
Solución elegida: Se implementó Opción 3 en combinación con un análisis de cohortes de usuarios autorizados (para rastrear la migración a la web a través de inicios de sesión SSO). La elección se basó en la necesidad de separar la verdadera pérdida de la canibalización del tráfico web, lo cual es crítico para evaluar la unit-economics (los usuarios web tienen un AOV un 15% menor).
Resultado: El análisis indicó que solo el 40% de los "MAU" "perdidos" realmente se habían ido, el 35% migró a PWA, y el 25% actualizó sus dispositivos en el transcurso del trimestre. El verdadero efecto negativo resultó ser 2.5 veces menor de lo pronosticado, lo que permitió continuar la estrategia de actualización del API para el 92% restante de la audiencia con un aumento del GMV del 8% gracias a nuevas funciones de pago.
¿Cómo distinguir la imposibilidad técnica de actualizarse del rechazo conductual a actualizarse, si ambos grupos permanecen en versiones antiguas de la aplicación?
La respuesta debe basarse en el análisis de eventos de device_change en CDP. Los usuarios con rechazo conductual (lazy updaters) a menudo presentan un patrón de "actualizaciones atrasadas" en su historial (por ejemplo, se saltan varias versiones menores, pero instalan parches de seguridad críticos), mientras que los usuarios con limitaciones técnicas nunca cambian su OS version durante todo el ciclo de vida del dispositivo. Además, se analiza la huella de hardware a través de WebGL o Canvas en la versión web: si un usuario aparece en PWA con el mismo dispositivo (según User-Agent y resolución de pantalla) que en la aplicación nativa antes de la desconexión, esto confirma migración, no pérdida. También es importante segmentar según el historial de app_version: si el usuario actualizaba regularmente dentro de Android 7 (entre parches 7.0->7.1), pero no pasó a 8.0, esto indica un límite técnico, no desinterés.
¿Por qué el Propensity Score Matching estándar puede dar estimaciones sesgadas al evaluar el efecto de un forzado upgrade en condiciones de fuerte correlación entre los ingresos del usuario y el modelo del dispositivo?
El PSM estándar se basa en la independencia condicional, asumiendo que las covariables observadas explican completamente la auto-selección. Sin embargo, en el caso de políticas de sunset, hay una variable oculta — disposable income, que correlaciona simultáneamente con el modelo de smartphone (bandera contra presupuestario) y con el LTV del usuario. Los dispositivos económicos a menudo no reciben actualizaciones de SO, y sus propietarios tienen menor capacidad de pago. El PSM estándar subestimará el efecto negativo, ya que "pesará" a usuarios ricos con nuevos dispositivos como análogos a pobres con viejos, aunque sus patrones de comportamiento difieren fundamentalmente. La solución es utilizar Coarsened Exact Matching (CEM) con estratificación precisa por segmentos de precio (low-end, mid-range, flagship) antes de aplicar PSM, o variables instrumentales (IV) utilizando la política de actualizaciones de los fabricantes OEM como un choque exógeno.
¿Cómo tener en cuenta correctamente los efectos de red entre los usuarios de diferentes versiones de la aplicación al evaluar la pérdida, si la funcionalidad de "compartir producto" funciona de manera diferente en la versión antigua y nueva?
Los efectos de red crean spillover entre los grupos de tratamiento y control: si un usuario activo de la nueva versión (tratamiento) no puede compartir contenido con un amigo en la antigua versión (que no acepta el nuevo formato de deep link), esto deteriora la experiencia para ambos y puede acelerar la pérdida del grupo de control no por la política de sunset, sino debido a una degradación de la UX. Para la corrección, es necesario aplicar network-based DID (Difference-in-Differences con pesos de red). Se construye un gráfico de relaciones sociales (a través del análisis de referral codes, pedidos conjuntos o mensajes en chat de la aplicación). Se evalúa el "contagio" (contagion) de métricas: si un usuario en el grupo de control (versión antigua) tiene muchas conexiones con el grupo de tratamiento (nueva versión), su comportamiento se verá distorsionado. En el modelo, se añade un término de interacción Treatment x Network_Exposure, donde Network_Exposure es la proporción de conexiones en la red que utilizan la nueva versión. Con un alto nivel de efectos de red, el verdadero efecto de la política de sunset estará subestimado, ya que parte de los usuarios "control" han estado expuestos a un impacto indirecto, y se requiere ajuste en intention-to-treat (ITT) teniendo en cuenta esta contaminación.