¿Cómo diseñas un test A/B para una función móvil, y qué trampas añaden los ciclos de release móviles?
Los tests A/B móviles parecen experimentos web hasta que la revisión de las stores, los rollouts escalonados y la fragmentación de versiones envenenan tu muestra y tus métricas.
APRENDE HACIENDOPon a prueba tu intuición3 pasos
¿Cómo diseñas un test A/B para una función móvil, y qué trampas añaden los ciclos de release móviles?
Usa los ejemplos y la explicación de la lección para comprobar tu idea.
Reflexión personal. No se envía a ningún servicio de IA.A un ingeniero mobile senior rara vez le piden que ejecute un test A/B — el equipo de growth o data science suele ser dueño de la plataforma de estadística. Lo que sí te van a pedir que diseñes es la parte que esa plataforma no puede ver: cómo se conecta el experimento a un binario cuyo release controlan Apple y Google, y cómo eso cambia lo que significan "asignación aleatoria" y "lectura limpia" en la práctica.
#Arrancá desde el mismo lugar que la web
El diseño del experimento en sí no cambia solo porque el cliente sea una app móvil. Igual necesitás una hipótesis única y falseable ("mover el CTA arriba del pliegue aumenta la activación del día 1 en al menos 2 puntos"), una métrica primaria que mapee directamente a esa hipótesis, un pequeño conjunto de métricas de resguardo (guardrails) que no pueden empeorar (tasa libre de crashes, tasa de ANR, duración de sesión, tasa de desinstalación), y una unidad de aleatorización — casi siempre el usuario instalado, identificado por un id pseudónimo estable, no el dispositivo y no la cuenta, porque un usuario puede reinstalar o tener varias cuentas.
Antes de lanzar nada hacés un análisis de poder: dado tu tasa de conversión base y tus usuarios activos diarios, ¿cuánto tiempo necesitás correr el test para detectar el tamaño de efecto mínimo que realmente te importa, con los umbrales de significancia y potencia que acordó el equipo? En mobile este número casi siempre sale peor de lo que el equipo espera, por razones que no tienen nada que ver con la estadística y todo que ver con cómo se mueven los binarios.
#Dónde el tren de releases de mobile rompe el manual
Un test A/B en web puede enviar una variante nueva al 100% del tráfico en minutos y revertirla igual de rápido si algo se ve mal. Mobile no puede hacer ninguna de las dos cosas por el canal normal de release. Una vez que un build está aprobado y en rollout, no lo estás editando — estás esperando la revisión de App Store y Play Store para el próximo, que puede tardar desde unas horas hasta varios días, y aún después de aprobado, la adopción del nuevo binario es lenta: algunos usuarios actualizan en la hora, muchos no lo tocan en semanas, y una porción relevante nunca actualiza hasta que un requisito del sistema operativo o un gate de "por favor actualizá" los obliga.
Ese único hecho reconfigura todo el experimento:
- El experimento no puede vivir solo en código nativo. Si la variante y la lógica de asignación están compiladas dentro del binario, no podés matar una variante mala sin otro envío a la store. Los experimentos móviles reales asignan y controlan el comportamiento a través de un SDK de remote config o feature flags (Firebase Remote Config, LaunchDarkly, Statsig, un servicio de flags propio) que la app consulta al arrancar o con un timer. El binario envía las dos ramas de código; el flag decide cuál corre, y podés apagar ese flag del lado del servidor en minutos.
- La fragmentación de versiones es un factor de confusión, no una molestia. En cualquier momento tu población está corriendo cuatro o cinco versiones de la app simultáneamente. Si la función que estás probando depende de algo que solo salió en el último build (un SDK nuevo, un fix de bug, un permiso nuevo), tu grupo de tratamiento está silenciosamente contaminado por usuarios que ni siquiera pueden renderizar bien la nueva experiencia. Filtrás el experimento por versión mínima soportada, y tratás "no actualizó" como un segmento a observar, no como ruido a promediar.
- Los rollouts escalonados chocan con tu aleatorización. Las dos stores te dejan enviar un binario nuevo a un porcentaje de la población primero (el staged rollout de Play Console, el phased release de TestFlight/App Store). Si ese rollout por porcentaje es también cómo estás asignando tratamiento vs. control, acoplaste dos aleatorizaciones independientes y probablemente rompiste las dos — la población que recibe el binario nuevo y la que recibe la función nueva necesitan muestrearse de forma independiente, o tu grupo "control" termina siendo, por ejemplo, desproporcionadamente gente que no actualiza.
- La revisión de la store agrega una demora fija que no podés comprar. Si tu tratamiento manda un bug, no podés hacer un hotfix de un crash nativo como un equipo web que revierte en diez minutos. Cualquier cosa genuinamente riesgosa en un experimento — rutas de código nativo nuevas, cambios de permisos, flujos de pago — necesita un kill switch del lado del servidor como parte de primera clase del diseño, decidido antes del lanzamiento, no improvisado durante un incidente.
#Métricas que solo cobran sentido en un dispositivo real
Aparecen algunos problemas específicamente porque estás midiendo una app instalada y no la carga de una página. La fuga de usuarios es asimétrica: una mala variante web te cuesta una sesión; una mala variante mobile te puede costar la instalación entera, y las desinstalaciones son notoriamente difíciles de observar — en general solo las inferís cuando un usuario deja de aparecer, días después, sin ninguna señal limpia de cuándo o por qué. La atribución se vuelve más turbia después de ATT (App Tracking Transparency) y con los cambios de privacidad de Android, así que la identidad entre sesiones para un mismo usuario lógico es menos confiable de lo que era, lo que infla silenciosamente tu varianza. Y la conectividad importa de una forma que casi nunca importa en web: usuarios con redes inestables pueden directamente fallar al obtener el flag remoto y caer en un default sin que nadie lo note — decidí de antemano cuál es ese default, porque "falló el fetch del flag" es en sí misma una subpoblación no aleatoria (la mala conectividad correlaciona con geografía, gama del dispositivo y comportamiento).
#Trampas de análisis que conviene nombrar en voz alta en una entrevista
El sample ratio mismatch (SRM) — chequear que el split control/tratamiento que realmente observaste coincide con el que configuraste — importa más en mobile porque hay más lugares por donde la asignación se puede filtrar silenciosamente: una capa de caché sirviendo un valor de flag desactualizado, un crash que solo afecta a un brazo y saca a esos usuarios del funnel antes de que se los llegue a loguear, o un rollout escalonado de la store confundiendo quién es siquiera elegible para entrar al bucket. Los efectos de novedad también son más marcados en mobile, porque una pantalla rediseñada es una de las pocas pantallas que un usuario ve todos los días, así que una mejora temprana suele ser solo atención, no un cambio de comportamiento durable — la mitigación estándar es una corrida mínima más larga más mirar la tendencia de la métrica en el tiempo en vez de una sola lectura al "día 7". Por último, tratá esto tanto como un problema de diseño organizacional como uno estadístico: alguien tiene que ser dueño de la decisión de llevar una variante ganadora al 100% a través del próximo tren de releases, y ese rollout necesita el mismo pensamiento de fases y guardrails que el experimento original, porque "el A/B test dijo que lo lancemos" y "lanzarlo con seguridad a mil millones de dispositivos" son dos problemas de ingeniería distintos.
🧠 Tests A/B en mobile
0/3 · 0/3 answered1. ¿Por qué se considera un SDK de feature flags remoto un prerrequisito para la mayoría de los tests A/B en mobile, y no un lujo?
2. ¿Cuál es el riesgo de usar el porcentaje de un rollout escalonado de la store como el split de tratamiento/control de tu experimento?
3. ¿Por qué las desinstalaciones son una métrica de guardrail más difícil en mobile que, digamos, la tasa de rebote en web?