Un test A/B puede a veces no garantizar el éxito 

«Bueno, vamos a hacer un test A/B y vemos qué pasa». Si trabajas en producto, seguro que has oído esta frase más de una vez. A veces suele aparecer cuando alguien quiere sacar adelante un cambio que no nace de un problema claramente identificado ni de datos que lo pidan. En estos casos, el test se convierte en el aval de la decisión más que en la validación.

El origen: un cambio de UI validado con un test A/B

Un equipo transversal, encargado de aplicar la nueva línea de marca, tenía como objetivo rediseñar la vista previa de plantillas del panel: una ventana mucho más grande, casi a pantalla completa, más vistosa y coherente con el resto del producto.

• Había argumentos de marca y de coherencia visual.
• No había un problema de usuario detectado en ese punto ni datos que respaldaran el cambio.

Para despejar dudas, se hizo un test A/B con tres variantes de modal en escritorio, donde estaba la mayor parte del tráfico, con usuarios nuevos y recurrentes. Ninguna mejoró de forma clara la conversión a creación, pero tampoco la empeoraba. Así que se eligió la que mejor encajaba con la estrategia, se aplicó a todo el tráfico y después se adaptó a móvil. Parecía que no había riesgo en ello.

En todo esto hubo una pregunta que en realidad nadie llegó a formular: ¿qué métrica queremos mover y qué métrica no podemos permitirnos penalizar?

El hallazgo: semanas después perdíamos a los usuarios nuevos

Mes y medio después, con un cambio de organigrama, me asignaron el área de activación y unas métricas clave que hasta entonces no estaban asignadas a ningún equipo concreto. Yo no estuve en aquella decisión ni en el test de origen pero ahora mi objetivo era reducir los usuarios 1 day (aquellos que se registran y no vuelven nunca más) y acelerar el time to value, el tiempo que tarda alguien en obtener valor del producto.

Al revisar los datos vi que llevábamos varias semanas con un aumento importante de usuarios 1 day.

¿Qué lo había provocado? A simple vista era imposible saberlo:

• Varios equipos habían lanzado muchos cambios en esas semanas.
• No había anotada ninguna release en el panel de métricas que coincidiera con la fecha del aumento.
• El cambio de aquella modal parecía poco sospechoso en este asunto: no implicaba cambios de flujos ni de UX, aparentemente solo fue un cambio de UI.

Empecé por investigar en datos lo que esos usuarios que desaparecían en su día de registro no llegaban a hacer, rápidamente vi que no llegaban al editor, no creaban nada. Antes del editor, la mayoría de usuarios deben elegir una plantilla, y antes de elegirla, la deben previsualizar.

La conversión a la creación desde plantilla, en global, llevaba meses plana, sin variaciones; de hecho, estaba por encima del YoY. Así que intenté desgranar esa métrica y segmenté. ¿Alguna variación por idioma? Nada. ¿Por país? Nada. ¿Por navegador? Nada claro tampoco. ¿Por tamaño de pantalla? ¡Bingo! Aquí había algo.

En pantallas de móvil, sobre todo en Android, la caída era brusca, mientras el resto de tamaños seguía igual. Al seguir el recorrido de esos usuarios paso a paso, la pista apareció enseguida, llegaban al panel, abrían la vista previa de una plantilla… y ahí se esfumaban. La caída estaba justo en el paso de previsualizar a crear, y empezaba la misma semana en que la nueva vista previa llegó a móvil.

Aquel cambio "solo de UI" ya no parecía tan inocente. Más de 1/4 parte de los registros nuevos llegaban desde el móvil, así que el tema se ponía serio.

Con el equipo de QA comprobamos que el happy path funcionaba: previsualizar una plantilla y usarla no daba ningún error. Mientras, yo revisaba grabaciones de sesión y probábamos a mano en varios dispositivos móviles. Enseguida lo vimos, y era la suma de varias cosas:

• En móvil, la ventana modal ocupaba toda la pantalla y el panel desaparecía de la vista, se perdía el contexto de ubicación.
• La “modal” no tenía botón de cierre. En escritorio se cerraba pulsando fuera; en móvil no quedaba ningún "fuera" que pulsar.
• El «atrás» nativo de Android no cerraba la modal, te devolvía a la página de origen, que para un usuario nuevo solía ser Google, un blog o una plataforma de formación.

El resultado era que como usuario, o usabas esa plantilla que estabas previsualizando o acababas fuera de Genially. La realidad es que casi nadie se queda con la primera plantilla que ve, así que muchos se fueron sin saber muy bien qué había pasado. El problema era, principalmente, de accesibilidad, usabilidad y navegabilidad.

La solución: comprobar la hipótesis y resolver después

Para confirmar la causa, propuse volver a la versión anterior de la vista previa, solo en móvil. Los datos se recuperaron de inmediato.

Con la causa confirmada, mejoramos la versión nueva de esta modal de previsualización de plantilla:

• El «atrás» nativo en mobile cierra la modal, no te expulsa de Genially.
• Hay un botón de cierre visible, accesible.
• También se puede cerrar la modal pulsando fuera y hay un “fuera”, una franja superior deja ver el panel y mantener el contexto de dónde estás.
• «Usar esta plantilla» sigue como acción principal.

Hoy, además, la vista previa también tiene botón de cierre en escritorio, facilitando la accesibilidad y navegación por teclado. El resultado superó los datos de antes del cambio.

Notas para mi yo del futuro, que quizás también te sirvan a ti

1. Define bien qué métrica quieres mover y cuáles no pueden empeorar antes de cada test. La conversión a creación desde plantilla era el objetivo, pero nunca a costa de ganar usuarios 1 day o perder retención. Un test que aparentemente no mueve nada puede estar moviendo los datos que no estás mirando.

2. Un cambio sin un problema real detrás suele mover métricas que nadie espera. Un test mide lo que le preguntas, en el contexto en el que lo haces, y nada más, así que la visión global y el criterio caen sobre ti. No podemos usar los test como justificación de los cambios.

3. Accesibilidad, usabilidad y navegación son líneas rojas. Para que la vista previa de plantillas funcionara en móvil no hacía falta un test: hacía falta diseñarla con buenas prácticas. Con la IA este riesgo crece. Un encargo como «adapta esta modal a móvil a pantalla completa» se resuelve en segundos y puede saltarse lo básico (no digo que fuera lo que pasó aquí).

4. Cada métrica necesita a alguien que la guarde. Cuando todos miran todo, la responsabilidad se diluye, por muy profesional y responsable que sean los equipos. Activación y retención son métricas que no pueden caer en todos y en nadie a la vez. Mi propuesta: un reparto claro de métricas y una lectura conjunta periódica, porque facilita la alineación de equipos y además van en cascada. Sin adquisición hay poca activación, y sin activación, poca retención.

   Nota extra: Si lideras equipos de producto organizar y decidir bien quién guarda cada métrica es clave para garantizar que lo que cada equipo aporta suma al cómputo total.

5. Otras notas para recordar: Un test no respalda decisiones, plantéalo solo cuando sea necesario. Un test en escritorio no valida móvil (qué obviedad ¿verdad? Pero a veces lo obvio pasa desapercibido). Prueba todas las vías de salida, no solo el happy path. Volver atrás (un revert) es la vía más rápida de confirmar una causa, y seguramente también el test más "low cost" que hagas. Y anota cada cambio en tu herramienta de analítica (eso ayuda mucho a encontrar enanos escondidos en los datos).

Me quedo con algunas reflexiones

• ¿Cuántas decisiones de tu producto se han "validado" con un test que en realidad no validaba “nada”? Así planteado suena fatal pero a veces cometemos estos errores pensando que un test tiene poco coste, y lo mismo el coste estaba en otro lado.
• ¿Das por bueno un test cuando los resultados parece que no mejoran ni empeoran lo que estás intentando mover? Me encanta este debate sobre cómo dar por buenos los resultados de un experimento en producto, la realidad es que siempre se aprende, para bien o para mal.