Saltar al contenido principal
Tradicionalmente, Kameleoon ha permitido operar A/B tests en el (usando un motor JavaScript) o en el (usando un SDK del lado del servidor). Sin embargo, como las estrategias de caché agresivas son comunes por motivos de rendimiento, las solicitudes HTTP pueden no llegar nunca a los servidores de aplicaciones de backend. En su lugar, un servidor web frontal responde directamente con una versión cacheada de la página solicitada. En estas configuraciones no se pueden utilizar los SDKs del lado del servidor, ya que la lógica de asignación de un visitante a un experimento se produce en el código de la aplicación de backend, lo que significa que muchas solicitudes no pueden procesarse porque en su lugar se devuelve una versión cacheada de la página. En otras palabras, el código que implementa el reparto de tráfico entre las variaciones de un experimento no se ejecutaría. Para resolver este reto, los módulos de A/B testing de Kameleoon están disponibles para los principales servidores web. Esto permite al servidor web determinar la variación utilizada por cada visitante. El servidor puede responder con una versión cacheada de la variación correcta, de modo que la aplicación pueda beneficiarse de las estrategias estándar de caché. El testing web a nivel de servidor web es un nivel intermedio entre el frontend y el backend.

​
Conceptos generales​

Un módulo de servidor web de Kameleoon es un componente de bajo nivel (escrito en C para un rendimiento óptimo) que realiza la asignación de variaciones cada vez que una solicitud HTTP dispara un experimento A/B. A continuación, redirige internamente la solicitud a una URL potencialmente distinta correspondiente a la variación elegida. Por ejemplo, si un visitante visita la página https://www.shop.com/plasma-tvs.html y hay un experimento en ejecución en esa página de categoría, con tres variaciones, el servidor web redirige internamente la solicitud HTTP a https://www.shop.com/plasma-tvs.html (versión original), https://www.shop.com/plasma-tvs.html?version=B (primera variación) o https://www.shop.com/plasma-tvs.html?version=C (segunda variación). A continuación devuelve una versión cacheada de estas páginas (o pasa la llamada al servidor de aplicaciones para generar una nueva si ha caducado el valor de TTL). El A/B/C test es completamente transparente para los usuarios finales. El visitante solo ve en el navegador la URL canónica https://www.shop.com/plasma-tvs.html. La configuración del experimento (incluyendo el establecimiento de URLs de destino y de redirección; por ejemplo, añadiendo el parámetro ?version=B) se completa en la plataforma Kameleoon. El módulo del servidor web refresca periódicamente su configuración desde los servidores y la base de datos de Kameleoon. Para una planificación y despliegue cómodos de los A/B tests, están disponibles todas las funcionalidades habituales de Kameleoon, incluidas iniciar, pausar y detener tests; cambiar la desviación; y modificar la configuración.
Debido a las limitaciones técnicas del modelo cliente-servidor en la web, el uso de condiciones de URL es la única forma de configurar la segmentación de experimentos a nivel de servidor web. Del mismo modo, utilice siempre redirecciones de URL en Kameleoon para configurar las variaciones a nivel de servidor web. Los impactos negativos en rendimiento y SEO asociados a la redirección desde el frontend (navegador) no son un problema con las redirecciones del servidor web. Por el contrario, las redirecciones internas del servidor web son perfectamente seguras y se consideran una buena práctica, ya que se procesan internamente en el servidor web (son rápidas) y son transparentes para los rastreadores de los motores de búsqueda.

​
Operar experimentos A/B en el servidor web​

  1. En la app de Kameleoon, cree un nuevo experimento A/B con el Code editor.
  2. En Kameleoon, cree las variaciones que desea implementar para el experimento. Para cada variación, elija la opción de redirección de URL e introduzca la nueva URL deseada.
  3. Elija la segmentación del experimento añadiendo una o varias condiciones de segmentación por URL. Cualquier URL coincidente en el servidor web disparará el módulo del servidor web para esa solicitud y activará una redirección interna. El módulo almacena una cookie (first-party) llamada kameleoonVisitorCode para las solicitudes coincidentes.
Solo se tienen en cuenta las opciones de redirección de URL para los experimentos en el servidor web. Se ignoran otras modificaciones en las variaciones, como cambios de código JavaScript o CSS realizados con el editor gráfico.
A continuación, puede elegir la desviación y lanzar el experimento de la forma habitual. Pausar o detener el experimento también funciona como se espera.
La exclusión de tráfico no funciona con los experimentos A/B en el servidor web. La analítica de la versión original del experimento incluirá datos de los visitantes del grupo excluido, en lugar de excluir a esos visitantes del experimento por completo.
Para ayudar con posibles tratamientos en el lado del servidor (tracking, implementación de variaciones), el servidor web añade una cabecera HTTP a cualquier solicitud que coincida con un experimento de Kameleoon, cuando la opción está activada en el archivo de configuración de Nginx (kameleoon_headers on;). La primera cabecera se llama kameleoon-experiment y su contenido tiene el formato experimentID=variationID, donde experimentID representa el ID del experimento disparado y variationID representa el ID de la variación asignada. La segunda cabecera se llama kameleoon-redirection y su contenido tiene el formato variationID=redirectionURL, donde variationID representa el ID de la variación asignada y redirectionURL representa el parámetro utilizado para la redirección.

​
Plataformas soportadas​

​
Módulo para servidor Nginx​

El módulo soporta las versiones 1.18.0, 1.20.2 y 1.21.4 de Nginx; el paquete Docker está disponible aquí. La última versión del módulo soporta la versión 1.27.1 de Nginx; el paquete Docker está disponible aquí.
El módulo se prueba en una arquitectura x86_64.
También debe instalarse en paralelo un script Python (y ejecutarse periódicamente mediante una tarea CRON; se recomiendan intervalos de 30 o 60 minutos). Para usar el script son necesarias credenciales de Automation API (para autenticación OAuth 2.0). Consulte el artículo sobre credenciales de API para más detalles.

​
Módulo para servidor Apache HTTPd (obsoleto)​

El módulo de Apache httpd soporta la versión 2.4 y se ha probado en una distribución CentOS con arquitectura de CPU x86_64.
También debe instalarse en paralelo un script Python (y ejecutarse periódicamente mediante una tarea CRON; se recomiendan intervalos de 30 o 60 minutos). Este script refresca o actualiza el archivo de configuración de Nginx generado que necesita el módulo de Kameleoon. El script también recarga el archivo de configuración.