En CrowdHandler, suele ser la primera pregunta que nos hacen: «¿Admitís el sistema “One In, One Out”?». Y la respuesta es: «Sí, lo admitimos... pero, para la mayoría de los usuarios, no lo recomendamos».
Sabemos por experiencia que limitarse a establecer la tasa de entrada adecuada es una forma más eficaz de gestionar el tráfico que el sistema «uno entra, uno sale», y es la mejor solución para la gran mayoría de nuestros clientes.
Por desgracia, muchos propietarios de sitios web escuchan «sí, admitimos la política de “uno entra, uno sale”», pero no escuchan la segunda parte de nuestro consejo. Para ellos, el concepto de «uno entra, uno sale» les parece tan lógico que les cuesta imaginar que el tráfico se pueda gestionar de otra manera. Así que siguen adelante, activan la configuración de «uno entra, uno sale» y ponen el sitio en marcha… solo para encontrarse con que se acumulan las colas y los usuarios se quejan de la espera.
Entonces, ¿qué hay de malo en la regla de «uno entra, uno sale»?
El problema es que la simplicidad de la fórmula «uno entra, uno sale», tal y como la entendemos la mayoría de nosotros, no se ajusta a la realidad del tráfico web y los recorridos de los usuarios. El umbral de «uno entra, uno sale» puede resultar tanto irrelevante como problemático.
¿Irrelevante? Bueno, imagina que tienes una página web con una capacidad para 1.000 usuarios y estás admitiendo 100 usuarios por minuto. Sabes que la sesión media de un usuario dura diez minutos, por lo que, partiendo de cero (sin usuarios), cabría esperar alcanzar la capacidad máxima en diez minutos. A partir de ahí, si el principio «uno entra, uno sale» funcionara como muchos dan por hecho, la ecuación sería simplemente 1.000/10. Lo normal sería que el primer grupo de 100 usuarios finalizara su visita en el minuto 10, momento en el que permitirías la entrada a los siguientes 100 usuarios, y así sucesivamente.
Quienes prestaron atención en clase de álgebra quizá se hayan dado cuenta de que, a estas alturas, la variable de capacidad de 1000 se ha anulado por sí sola. Bastaría con fijar la tasa de entrada en 100 y se obtendría exactamente el mismo efecto.
Sin embargo, la regla «uno entra, uno sale» no solo es irrelevante en este contexto, sino que resulta claramente problemática. Esto se debe a que la sencilla ecuación «uno entra, uno sale» también pasa por alto dos factores cruciales: los tiempos de espera de las sesiones y la capacidad de gestión de pedidos.
Problema número uno: tiempos de espera de la sesión
Vale, supongamos que el recorrido medio de un usuario puede durar diez minutos. Pero hay bastantes usuarios que nunca llegarán a finalizar la compra —y, si lo hacen, es posible que nunca lo sepas (a menos que hayas configurado el «checkout busting»). Por eso, en lugar de dejar que las sesiones de los usuarios se prolonguen y puedan afectar a la capacidad de forma permanente, las cerramos automáticamente.
El tiempo de espera predeterminado de CrowdHandler es de 15 minutos, lo que significa que se mantendrá el turno de cada usuario durante 15 minutos tras su última actividad. Esto permite a los usuarios tomarse un descanso, responder a un correo electrónico urgente o comparar precios rápidamente en otra página web durante su visita, y volver a la cola sin tener que empezar de nuevo.
Así pues, si tenemos en cuenta esos 15 minutos, la duración media real de la sesión de un usuario es de 25 minutos. Volviendo a nuestra ecuación, 1000/25 significa que la tasa efectiva es de solo 40 entradas y salidas por minuto si aplicamos la regla «uno entra, uno sale» con 1000 usuarios. Según nuestro cálculo original, cabría esperar que una cola de 3000 personas se vaciara en 30 minutos, con una espera media de 15 minutos. Pero, si tenemos en cuenta el tiempo de espera de la sesión, los primeros 1 000 usuarios saldrán de la cola en los primeros 10 minutos, y luego los 2 000 usuarios restantes se irán a un ritmo de 40 por minuto, lo que llevará 50 minutos. Así pues, la cola completa tardará en realidad una hora en vaciarse, con una espera media de 30 minutos. El doble de tiempo.
«¡Ah!», piensas. «Pero no voy a dejar entrar a los primeros 1.000 usuarios a un ritmo de 100 por minuto; voy a maximizar la tasa y confiaré únicamente en la regla “uno entra, uno sale” para que los primeros 1.000 usuarios entren en el primer minuto, maximizando así mi capacidad». Pues bien, esa es una mala idea por dos razones, pero la primera es esta: con la regla «uno entra, uno sale», en nuestro escenario de ejemplo, los 2.000 usuarios restantes en la cola no avanzarán en absoluto durante 25 minutos, cuando empiecen a caducar las primeras sesiones registradas. Esos usuarios verán una posición en la cola que no avanza y una estimación de tiempo de espera terrible. Justo el tipo de experiencia de usuario que intentas evitar. Además, a menos que tengas muy en cuenta el tiempo de espera de la sesión en tu umbral de «Uno entra, uno sale», a la larga tendrás menos compras, además de una cola que se resiste a avanzar.
Problema número dos: Capacidad de caja
Este problema se debe a otro malentendido: basar la configuración de «One In, One Out» en las cifras de las pruebas de carga.
Las pruebas de carga suelen aumentar el tráfico de forma gradual (¡igual que cuando se configura una tasa en CrowdHandler!) y, a menudo, simulan el tráfico diario, lo que supone que hay más visitantes navegando que comprando. Sin embargo, durante el lanzamiento de un producto con gran afluencia de público o en un escenario de lanzamiento de una nueva colección, la proporción de compras será mucho mayor que en el tráfico normal. Debes dar por hecho que la mayoría de los usuarios que introduzcas al inicio de un recorrido de usuario realizarán la compra en cuanto tengan la oportunidad.
En muchos sentidos, no importa cuántos usuarios simultáneos creas que tu sitio web puede gestionar. La cuestión es cuántas compras o transacciones puede gestionar por minuto. Aunque muchos sitios web pueden gestionar 1.000 usuarios simultáneos, muy pocos pueden procesar 1.000 compras por minuto. Basar la configuración de «uno entra, uno sale» en las métricas de usuarios simultáneos no tendrá en cuenta el pico de transacciones reales que se produce durante un lanzamiento o una oferta, y es más probable que el sitio web se cuelgue ante la avalancha de pagos que se producirá en el minuto 10 de nuestro escenario de ejemplo, si dejas entrar a 1.000 usuarios en el primer minuto.
Una analogía útil es la de una tienda física con capacidad para 1.000 personas, pero que solo cuenta con 10 cajas registradoras. Aunque la tienda puede acoger cómodamente a 1.000 clientes, solo puede tramitar de forma eficiente 10 pedidos por minuto. Dejar entrar a 1.000 clientes a la vez solo provocará largas colas de gente frustrada, sin que se avance nada a medida que se van acumulando las transacciones. Lo mismo ocurre en Internet, salvo que el riesgo no es solo el de las largas colas, sino también el de que los servidores se colapsen.
Cómo hacerlo bien
Una forma de mitigar los problemas relacionados con la política «One In, One Out» sería realizar algunos cálculos complejos durante la configuración. Estos podrían incluir aspectos como aumentar la capacidad de «One In, One Out», reducir los parámetros de tiempo de espera de las sesiones, calcular las proporciones entre sesiones y finalizaciones de compra, asegurarse de que la opción «Eliminar la sesión al finalizar la compra» esté activada y calcular los tiempos reales de recorrido de los usuarios.
De hecho, nos entristecía tanto ver cómo los clientes saboteaban sus rebajas con una configuración incorrecta de «One In, One Out», que hemos añadido un verificador que realiza estos cálculos y les muestra recomendaciones:
Para algunos clientes —aquellos para quienes las sesiones simultáneas son realmente un parámetro crítico de la aplicación; que están seguros de comprender todos los resultados de sus pruebas de carga y tienen una idea clara de la configuración óptima para los tiempos de espera de las sesiones y su impacto en el umbral «One In, One Out»—, estos cálculos pueden tener sentido. Si eres uno de esos clientes, te felicitamos.
Sin embargo, para la mayoría de los clientes, la respuesta es mucho más sencilla: olvídate de los cálculos complicados basados en límites teóricos y pruebas de carga poco fiables, y céntrate en los indicadores que realmente influyen en la experiencia del usuario. El éxito radica en conocer tu rendimiento máximo comprobado, no en un número hipotético de usuarios simultáneos.
Para la mayoría de las páginas web, esto significa ajustar la tasa de entrada a una cifra ligeramente superior a la tasa máxima sostenible de finalización de compra. (Un buen punto de partida es dividir el número máximo de pedidos que hayas gestionado con éxito en un periodo de una hora entre 60 y, a continuación, fijar la tasa en un valor ligeramente superior a ese resultado). Esto permitirá un buen flujo de visitantes hacia tu página web.
Empieza con un ajuste conservador y, a continuación, supervisa de cerca el rendimiento. Si la cola se alarga pero el sitio web sigue funcionando correctamente, siempre puedes aumentar la frecuencia; la función «Autotune» de CrowdHandler te puede ayudar en este sentido.
En resumen: céntrate en los resultados contrastados
Como estrategia de gestión de colas, puede parecer lógica, pero una interpretación simplista del principio «uno entra, uno sale» no tiene en cuenta los factores reales que intervienen en la ejecución. A menudo da lugar a problemas como largos tiempos de espera, clientes frustrados y fallos en el proceso de pago, ya que los cálculos se basan en hipótesis: métricas poco fiables o poco realistas.
Por lo tanto, aunque lo apoyamos, nuestro consejo es: no establezcas un umbral de «uno entra, uno sale» sin comprender exactamente lo que significa, y céntrate en tus tasas de finalización de compra en lugar de en las métricas de usuarios simultáneos. Si te centras en el rendimiento demostrado y en la realidad de los límites de tu sitio web, mejorarás la experiencia de usuario para todos.