Mejores prácticas para ejecutar pruebas A/B en aplicaciones de una sola página (SPA)

Este artículo es la parte 2 de la serie Pruebas A/B en aplicaciones de una sola página .

En la parte 1, presentamos el concepto de aplicación de una sola página (SPA), mostramos por qué está creciendo en popularidad y analizamos 10 de las mejores plataformas de prueba A/B que puede usar en aplicaciones de una sola página .

Pero ejecutar pruebas A/B en SPA puede ser un poco complicado debido a la forma en que funcionan. En este artículo, le brindaremos consejos prácticos sobre cómo ejecutar un experimento en un SPA y algunas prácticas recomendadas a seguir.

La evolución de los marcos SPA

Los SPA no son un concepto nuevo.

Una patente de 2002 describe una tecnología similar a la versión contemporánea de SPA.

Sin embargo, la técnica AJAX, que se utiliza como estándar de red desde 2006, facilitó su implementación. Es un conjunto de estrategias para crear aplicaciones web asincrónicas utilizando una variedad de tecnologías del lado del cliente. El software puede enviar y recibir datos del servidor en segundo plano gracias a AJAX, sin alterar el estado actual de la página ni el modo de visualización del contenido, y por tanto sin interferir en la experiencia del usuario.

La introducción de AJAX, por otro lado, no fue un momento decisivo en la adopción de SPA.

El aumento de la popularidad de los SPA es parte de una tendencia más amplia que ha sido impulsada por el rápido crecimiento del front-end y la creciente relevancia de UX en los últimos años.

Los SPA se crearon por primera vez utilizando applets de Java o programas Flash, así como las bibliotecas JavaScript o jQuery "puras".

Sin embargo, los marcos front-end como Angular.js, React.js y Vue.js, todos los cuales son marcos de JavaScript relativamente nuevos, han ayudado a su desarrollo.

¿Cuáles son las tecnologías detrás de una arquitectura SPA?

Un SPA es esencialmente un marco de JavaScript compatible con HTML5 y CSS3.

Sin embargo, al utilizar estos componentes, han surgido algunas bibliotecas y marcos distintos que se han adoptado en el mundo del desarrollo:

1. Angular

Desarrollado por Google, Angular es el más maduro y el más antiguo de los 3 marcos con documentación detallada para usar pero con una curva de aprendizaje pronunciada.

Está integrado con una arquitectura Model View Controller (MVC) original, pero en su mayoría utiliza un MVVM (Model-View-ViewModel) que permite que varios desarrolladores trabajen por separado en la misma sección de la aplicación. Puede haber algunos problemas de migración con la actualización a nuevas versiones, pero Angular tiene la mayor confiabilidad cuando se amplía y es excelente para proyectos grandes y complejos.

Gracias a TypeScript, Angular es una opción fantástica para grandes equipos de desarrolladores, y algunas empresas ya emplean esta tecnología en sus otros productos.

En GitHub, es un marco maduro y establecido, con una gran cantidad de colaboradores.

Google y sus productos como Google Drive y Gmail, así como Wix, se encuentran entre los usuarios de Angular para SPA.

2. React.js

React fue desarrollado por Facebook y hecho de código abierto. Se utilizó principalmente para crear interfaces de usuario (Facebook, WhatsApp e Instagram).

Es muy popular debido a su tamaño de código liviano y su capacidad para integrarse perfectamente con otros marcos. También tiene un método simple para migrar entre versiones. (Por lo general, una migración con un solo clic).

Se usa con frecuencia junto con Redux para administrar el estado de los componentes de la aplicación. Uber también hace uso de la tecnología React.js en sus productos.

React es una buena opción para aquellos que recién están comenzando con los marcos front-end de JavaScript, así como para las empresas emergentes y los desarrolladores ágiles. Además, esta biblioteca de JavaScript ofrece valiosas opciones de integración con una variedad de otros marcos y tecnologías, lo que es realmente útil cuando se trabaja en un proyecto con un entorno grande. De todos los marcos de SPA, React tiene la mayor cantidad de contribuciones en GitHub, lo que ayuda a los desarrolladores a solucionar problemas potenciales.

Tiene la curva de aprendizaje más fácil de los 3 marcos y se usa mejor para proyectos con un plazo corto que requieren mucha escalabilidad.

3. Vue.js

Vue.js no es propiedad de una empresa importante como Facebook o Google, pero aún se está acelerando con nuevos usuarios, especialmente en Asia. Es el más nuevo de los marcos SPA anteriores, ya que fue fundado en 2014 por Evan You, un ex empleado de Google. Una gran cantidad de documentación suele estar en chino, pero todavía hay fuentes de capacitación.

El marco es muy ligero y se puede utilizar para crear simplemente aplicaciones de alto rendimiento.

Para la mayoría de los desarrolladores, no hay problemas importantes con la creación en cualquiera de estos marcos, la decisión realmente se reduce a las características principales de cada uno.

Empresas como Baidu, GitLab y Alibaba ahora utilizan Vue.js para sus necesidades.

Cómo funcionan las aplicaciones de una sola página

Los SPA tienen un diseño sencillo. Se utilizan tecnologías de representación tanto del lado del cliente como del lado del servidor.

En un sitio web que no es SPA, cuando ingresa una URL en su navegador, el navegador envía la solicitud a un servidor y recibe una página HTML en respuesta.

En un sitio web de SPA, el servidor solo entrega el documento HTML en la solicitud inicial y los datos JSON en las solicitudes posteriores. Esto indica que un SPA reescribirá el contenido de la página actual en lugar de recargar todo el sitio web.

En pocas palabras, un SPA funciona así:

1. El cliente primero establece una conexión con el servidor y obtiene el contenido de la página, que consta principalmente de código HTML, CSS y un paquete de JavaScript que comprende todos los scripts necesarios para ejecutar la lógica de la aplicación.
2. La acción de un usuario activa la ejecución de JavaScript(s) relevantes, que luego realizan solicitudes AJAX al servidor. Los datos generalmente están en formato JSON y no requieren una actualización completa de la página web.

En lugar de la técnica normal de un navegador que inicia una página completamente nueva, una aplicación de una sola página interactúa con los usuarios modificando a la fuerza las páginas web existentes con datos novedosos del servidor web. El navegador recupera el código HTML, JavaScript y CSS necesario, u otros recursos apropiados, y los agrega a las páginas según sea necesario.

Aunque la API de historial de HTML5 o el hash de ubicación se pueden utilizar para proporcionar la navegabilidad y la percepción de diferentes páginas lógicas en la aplicación web, la página no se recarga en ningún momento durante el procedimiento y no transfiere el control a otra página.

Si desea ver un ejemplo de una Solicitud de una sola página en acción, vaya a este enlace y haga clic en la página principal, la lista de cursos más recientes y el menú superior. Cuando haga eso, notará que la página no se vuelve a cargar por completo, solo se envían datos nuevos a través del cable a medida que el usuario se mueve por la aplicación.

Este es un ejemplo de un SPA.

¿Para quién son más adecuados los SPA?

Debido a los beneficios de los SPA, ahora son la solución preferida en muchas circunstancias.

Se destacan en proyectos que involucran una variedad de tecnologías web, donde el rendimiento y una experiencia agradable para el usuario son más importantes que el contenido.

Hay muchos jugadores importantes que usan SPA. Facebook, Gmail, Google Maps, Netflix y Paypal son algunos de los ejemplos más destacados de este tipo de tecnología (ver más abajo).

¿Por qué las pruebas A/B son difíciles en los SPA?

Los tres marcos, React.js, Angular.js y Vue.js, son muy populares entre los desarrolladores de JavaScript porque permiten el desarrollo de interfaces de usuario sofisticadas que crean mejores experiencias de usuario y tasas de conversión más altas.

Son muy deseables para los desarrolladores porque

• No es necesario actualizar la página
• Las velocidades de carga de la página son más rápidas
• Las interacciones son ricas y fluidas.
• Las transferencias de datos se reducen
• Las piezas reutilizables permiten un desarrollo más rápido
• La comunidad de desarrolladores está bien establecida.

También son el recurso de referencia para cualquier persona que inicie un nuevo SPA.

Sin embargo, existe un inconveniente importante: debido a cómo funcionan estos marcos, las herramientas de prueba A/B del lado del cliente tienen dificultades para funcionar correctamente .

Cuando alguien navega por una página web en un SPA, la página, incluida la URL, no se actualiza . El estado de la página varía con cada interacción del usuario (por ejemplo, los diferentes elementos visibles en la pantalla).

Debido a que las herramientas de prueba A/B normalmente solo hacen ajustes una vez durante la carga inicial de la página, estas interacciones posteriores no se tienen en cuenta.

Aquí hay dos escenarios comunes:

1. Si tiene páginas vistas habilitadas en su SPA, recibirá una página vista cuando alguien visite una URL, pero no una segunda si navega en una página diferente donde las páginas vistas están habilitadas. Esto se debe a que el material se carga en la página actual en lugar de en una página nueva.
2. Si intenta limitar un evento a una URL específica , se encontrará con el mismo problema. La herramienta de prueba A/B "creerá" que permanece en la misma página en la que se cargó por primera vez, incluso si el usuario piensa que está en una página diferente. Debido a que las piezas se mueven dentro y fuera del sitio, puede haber dificultades para controlar los clics u otros eventos.

Para generar experiencias, el software de prueba A/B del lado del cliente y las plataformas de personalización se basan en cargas de página completas.

Debido a que este concepto está ausente cuando se utilizan marcos SPA como React, Angular o Vue, determinar si se ha agregado contenido nuevo a la página o si ha cambiado el estado del contenido existente y, lo que es más importante, cuándo inyectar contenido personalizado, se vuelve más difícil.

Por lo tanto, las herramientas de prueba A/B deben ser capaces de reconocer el contexto del visitante, por ejemplo, si han llegado a una lista de productos, detalles o página del carrito, y en qué punto se debe proporcionar material nuevo.

Esto significa que el equipo de tecnología necesita estar constantemente al tanto de los componentes modulares React SPA o Angular SPA cambiantes, así como actualizar las experiencias que influyen en esos componentes en tiempo real.

Cada interacción del usuario en React.js, por ejemplo, hace que uno o más de los elementos de la interfaz de usuario se actualicen, eliminando cualquier cambio realizado por la solución de prueba A/B.

Pruebas del lado del cliente frente a pruebas del lado del servidor en SPA

Cuando se trata de pruebas A/B en un SPA, hay dos opciones:

1. Aislar los diversos "estados" de la aplicación que desea probar y luego configurarlos para que cuando se muestre cada "estado", se llame a una API para realizar las modificaciones apropiadas. Esto se denomina activación condicional y se realiza en el lado del cliente .

Algunos ejemplos de "estados" incluyen mostrar un formulario de suscripción, cargar una lista de resultados de búsqueda, etc.

2. Codificando las modificaciones, en el lado del servidor , o una implementación personalizada para cada nueva experiencia.

Ambas opciones están influenciadas por el marco SPA que se está utilizando. Entonces, como habrás adivinado, requieren mucha cooperación entre el equipo técnico y los vendedores para que funcionen bien.

Ahora, repasemos ambas opciones y veamos qué deben hacer los equipos para tener éxito.

Activación condicional en el lado del cliente

Si todavía tiene que realizar pruebas del lado del cliente en una aplicación SPA, existe una solución alternativa.

Para asegurarse de que los scripts de prueba solo se ejecuten cuando la aplicación alcance el estado deseado, los desarrolladores web pueden usar una característica llamada modo de activación condicional .

Si no está familiarizado con la activación condicional, es un concepto simple de entender.

La activación condicional, en esencia, le brinda la capacidad de definir cuándo se debe activar un experimento de otra forma que no sea a través de su método estándar de hacerlo en una actualización de página.

Esto se puede lograr escribiendo un poco de JavaScript. Hay dos formas de hacerlo.

1. La función de sondeo

La función de sondeo es la forma más básica de utilizar la activación condicional. La función escanea la página cada 50 ms hasta que aparece un elemento específico; podría ser un modal, un div o incluso la página completa.

El experimento comienza cuando aparece el elemento.

La plataforma de pruebas A/B genera algunas líneas de JavaScript para que las modifiques según el elemento que quieras que busque la función de sondeo.

El experimento se activa una vez que la función se evalúa como TRUE .

2. La función de devolución de llamada

La ejecución de la función de devolución de llamada es similar a la de la función de sondeo, pero agrega algo de flexibilidad.

Esta función le permite ingresar cualquier condición de JavaScript que desee y, si se evalúa como VERDADERO , iniciar el experimento.

Mientras que la función de sondeo hace ping constantemente a la página para ver si un elemento específico está presente, la función de devolución de llamada es más pasiva y se basa en un controlador de eventos.

Pruebas del lado del servidor

Cuando realiza pruebas del lado del servidor, no se realizan cambios en el nivel del navegador. Más bien, los parámetros de variación del experimento ("Usuario 1 ve la Variación A") se determinan en el nivel del servidor y se conectan directamente a la aplicación de JavaScript a través de un proveedor de servicios, lo que facilita la prueba de contenido dinámico más complicado que se extiende más allá de los límites de una estática. interfaz de usuario del sitio web.

Tomemos, por ejemplo, las aplicaciones de redes sociales que en su mayoría son SPA. Si bien las pruebas del lado del cliente de frontend se pueden usar para experimentar con estos, es mucho más complicado debido al contenido dinámico involucrado, por lo tanto, cambiar a las pruebas del lado del servidor hace que el proceso sea mucho más fácil.

Ejemplos de Tests A/B en SPAs

¿Cuáles son algunas instancias del mundo real de pruebas A/B en aplicaciones de una sola página que podría encontrar?

Cambiar una imagen en una página de destino

Digamos que necesita configurar un experimento en un SPA para mostrar una imagen dinámica al 50% de la audiencia que llegó a una página específica. El marco SPA utilizado en este ejemplo es React.js, lo que significa que la página cambia y las imágenes se reemplazan periódicamente.

Si muestra la imagen variante, pueden producirse problemas de parpadeo, lo que significa que se observará una secuencia de imagen original-imagen variante-imagen original.

Este problema se puede evitar por completo activando el sondeo cuando se carga la página de destino específica.

Prueba de copia adicional debajo de la CTA

Otro experimento en un sitio SPA construido con Angular.js puede implicar mostrar una línea adicional de copia debajo de la CTA principal al 30% de la audiencia objetivo.

En este ejemplo, la Versión A mostrará la línea adicional de copia debajo de la CTA principal, mientras que la Versión B no lo hará. Enviaremos el 30 % de nuestro tráfico a la versión A y el 70 % a la versión B, y luego compararemos los resultados para ver si hay una diferencia significativa en las tasas de conversión.

Dado que el sitio web está construido con Angular.js, los elementos se cambian periódicamente. El evento de devolución de llamada aquí puede ayudarnos a mostrar los cambios en la variante.

Visualización de un vale de regalo

En este ejemplo, supongamos que cuando un usuario agrega un producto de una marca premium a su carrito, queremos que se muestre un cheque regalo exclusivo. Con la condición de que cuando el usuario retire el producto premium de la cesta, el cupón se borre de la página.

1. Lo que debe suceder aquí es que cuando un usuario realiza la acción requerida, se debe enviar un evento de activación manual. El experimento se activará como resultado de este evento.
2. Se debe disparar un evento de activación cuando el usuario retira el producto premium de la cesta, desactivando el experimento.
3. El experimento debe reactivarse para mostrar el producto premium si el consumidor lo vuelve a agregar.

Mostrando el eslogan debajo de la CTA "Comprar ahora"

Si desea mostrar un eslogan único debajo de un botón de CTA "Comprar ahora", puede activar el experimento si presiona un evento de activación en el cambio de historial.

Esto se debe a que la página que contiene el botón CTA "Comprar ahora" no se cargará al principio.

Cómo Convert eludió el problema de las pruebas en los SPA

Los experimentos en SPA deben manejarse de manera diferente a otros experimentos. Debido a que el script Convert no puede leer la URL por la que navega un visitante del sitio web, no puede desencadenar experimentos con métodos estándar.

Así que así es como se hace en su lugar.

Comience instalando el código de seguimiento de Convert como se describe en este artículo.

Luego, aplique uno de los 3 métodos a continuación:

1. Activación de sondeo

Como se mencionó, el sondeo es el proceso mediante el cual se prueban las condiciones de la experiencia para determinar si se debe desencadenar dicha experiencia.

Esto incluye monitorear la URL del visitante, las condiciones de la audiencia o las condiciones de JavaScript para ejecutar la prueba.

Convert suele activar el sondeo cuando se carga una nueva página. En los SPA, por lo general, no se cargan páginas nuevas en la aplicación web.

En ese caso, necesitaría el siguiente código para iniciar el sondeo:

 ventana._conv_q = _conv_q || [];
ventana._conv_q.push(["ejecutar","verdadero"]);

Debe determinar cuál sería el mejor evento en su SPA para activar el código anterior. Código de muestra que debe agregarse en Configuración del proyecto > Sección JavaScript del proyecto global.

 console.log('SPA/Convertir Código en Global Project Javascript ejecutado');
si (! ventana.globalExecutedTs) {
ventana.globalExecutedTs = verdadero;
var oldPushState = ventana.historia.pushState;
ventana.historia.pushState = función (datos) {
probar {
establecerTiempo de espera (función () {
devuelve oldPushState.apply(esto, argumentos);
console.log('convertir activado desde pushstate');
ventana._conv_q = _conv_q || [];
ventana._conv_q.push(["ejecutar", "verdadero"]);
}, 0);
} atrapar (e) {
consola.log(e);
}
};
ventana.onpopstate = función(evento) {
establecerTiempo de espera (función () {
console.log('convertir activado desde popstate');
ventana._conv_q = _conv_q || [];
ventana._conv_q.push(["ejecutar", "verdadero"]);
}, 0);
};
}

2. Utilice las condiciones de JavaScript en el área del sitio

Debido a que el script Convert no puede leer los cambios de URL en un SPA, debe usar una condición de JavaScript en lugar de una condición de coincidencia de URL para activar un experimento.

Encuentre una explicación detallada de cómo hacer esto en el siguiente artículo.

3. Activar manualmente un experimento

Puede desencadenar experimentos manualmente después de determinar que se ha producido un determinado flujo. Con este método, el área del sitio y las condiciones de la audiencia aún se probarán después de activar el sondeo con código. Consulte este artículo para obtener información más detallada sobre la activación manual de un experimento.

Con los 3 métodos anteriores, debería poder activar experimentos en el momento adecuado en una aplicación SPA.

¿Convert aumenta el riesgo de parpadeo en los SPA?

Respuesta corta, no.

Todos los marcos SPA son compatibles con la tecnología antiparpadeo de Convert. Convert aprovecha la tecnología SmartInsert ^TM entre bastidores para garantizar que las modificaciones del experimento se apliquen o se vuelvan a aplicar en el momento adecuado en su SPA, incluso durante las recargas de página dinámicas.

Recomendamos leer nuestro documento técnico sobre el efecto de parpadeo para obtener más información al respecto y por qué debe evitarlo a toda costa.

Problemas comunes cuando se realizan pruebas A/B en sitios de aplicaciones de una sola página

Como puede ver, hay algunas cosas a tener en cuenta al ejecutar pruebas en sitios SPA. Una vez que haya cubierto el marco utilizado, el método de prueba de la herramienta y el evento desencadenante, el problema principal suele ser que el elemento de prueba no se vuelve a cargar cuando se muestra una nueva página o vista en el navegador.

Esto puede ser causado por algunas cosas:

1. Pruebe los cambios que aparecen en la vista de la primera página, pero no en las subsiguientes

A veces, el cambio que desea mostrar solo se muestra en la primera página que carga en su navegador, pero no en las vistas posteriores. Esto se debe a que la parte del script Convert que evalúa los experimentos y los activa no se ejecuta al acceder a una nueva vista o "página" del sitio.

2. Los cambios que aparecen en el editor visual no aparecen cuando se obtienen vistas previas fuera de él

A veces puede suceder que los cambios realizados con el Editor visual no se muestren fuera de la vista previa del editor.

La mayoría de los marcos de SPA no usan la API DOM y, en su lugar, usan sus propios métodos para implementar los cambios en la página. Esto hace que el DOM no esté sincronizado cuando lo actualiza el SPA. Esto es común en React y Angular, lo que hace que los selectores de CSS que se encuentran en el código Jquery no funcionen.

3. Los cambios siguen apareciendo en las "vistas" posteriores

En este escenario, un cambio de experimento se muestra en la vista (página) correcta. Pero, al visitar nuevas vistas (páginas), el cambio no desaparece. Esto sucede porque en un sitio SPA, los cambios no se eliminan al recargar una nueva página.

El script Convert elimina el código agregado cuando las condiciones del experimento no coinciden con la vista posterior donde se implementaron los cambios cuando se llama al sondeo. Sin embargo, esto no es suficiente ya que los cambios de jquery no desaparecerán incluso al eliminar el código de experimento de la página.

Deberá ejecutar un código que revierta los cambios provocados por el experimento.

Su turno: evite estos errores al optimizar su SPA

Debido a los avances en la forma en que se procesa y proporciona la información, es posible que los SPA se acepten con más frecuencia, pero es fundamental tener en cuenta que esta nueva tecnología tiene problemas cuando se integra con plataformas de optimización y experimentación, que normalmente funcionan con configuraciones más clásicas.

Esperamos que este artículo haya cubierto los diversos componentes de los SPA, así como algunas soluciones para superar esos obstáculos en su búsqueda para brindar a los visitantes experiencias digitales más rápidas, intuitivas y personalizadas.

Sin embargo, será mejor que trabaje con un proveedor de soluciones que pueda proporcionar un soporte perfecto para los SPA, como la capacidad de detectar cambios en los componentes de la interfaz de usuario y los tipos de página para la personalización dinámica sin modificar el código fuente. Como el del cuadro de abajo.