Cuando instales CrowdHandler y configures una sala de espera, queremos que lo hagas bien a la primera.
Nos complace decir que hemos visto a mucha gente instalar CrowdHandler directamente en el entorno de producción, en plena situación de emergencia por sobrecarga, y ver cómo les ha sacado del apuro.
Pero, por mucho que uno se esfuerce... los errores ocurren. Por eso, aquí va un aviso. Siete errores en los que hemos visto caer a los clientes, con consejos para evitarlos y garantizar una configuración más fluida.
¿Crees que estás preparado...?
Imagina que vas a lanzar un nuevo producto, servicio o promoción.
Sabes que es probable que tu sitio web tenga problemas de demanda o de carga. Quizá preveas una gran demanda porque dispones de un producto muy escaso, o un problema de carga elevada porque sabes que un número sin precedentes de visitantes accederá a tu sitio web al mismo tiempo.
Así que sabes que vas a necesitar una sala de espera. De hecho, estás incorporando la sala de espera desde el principio. Va a formar parte de la experiencia del usuario. Sabes exactamente cómo va a funcionar y cómo se integrará la cola en la solución que estás creando. Se habrá probado a fondo. Es imposible que salga mal.
...¿No?
Para asegurarnos, repasemos los problemas más habituales relacionados con la integración personalizada de CrowdHandler y cómo evitarlos.
1. Pruebas funcionales limitadas
A menudo vemos cómo los clientes prueban su integración personalizada, diseñada con esmero, con un pequeño grupo de partes interesadas internas: cinco o diez personas que realizan algunos recorridos de usuario estándar y comprueban que los usuarios se incorporan a la cola y son redirigidos al sitio web correctamente.
Sin embargo, este tipo de pruebas no te dan una idea realista de cómo funciona la página web con una cola activa. Al fin y al cabo, una vez que esos pocos usuarios han pasado por el proceso de la sala de espera y se les ha permitido acceder a la página, ya no hay cola. Pero muchos problemas de integración solo suelen ponerse de manifiesto cuando la cola se activa en una página web con mucho tráfico.
Al realizar las pruebas, es fundamental comprobar que los usuarios conservan su estado de «promocionados» (que suele indicarse mediante una cookie de CrowdHandler) en el sitio de destino. En lugar de limitarte a que los usuarios de prueba pasen de la sala de espera al sitio, debes comprobar si la sesión de CrowdHandler se mantiene.
Por lo tanto, como mínimo, deberías:
- Establece la tasa en 0; así se activará la cola.
- Aumentar la velocidad temporalmente para que algunos usuarios puedan conectarse
- Vuelve a establecer la tasa en 0 (creando así de nuevo una cola activa)
- A continuación, comprueba que los usuarios que han pasado a la página web puedan seguir completando recorridos de usuario funcionales.
Es fundamental volver a establecer la tasa en 0 después de permitir el paso a algunos usuarios porque, en ese momento, si se interrumpe la sesión de CrowdHandler de un usuario, este volverá a la cola. Sin embargo, si mantienes la tasa alta, esos usuarios no serán enviados a la cola y no sabrás que tu integración tiene un problema.
2. El entorno de producción no se corresponde con el de desarrollo
Claro, a todo el mundo le encantaría decir que sus entornos de prueba y desarrollo son un fiel reflejo del entorno de producción... pero, según nuestra experiencia, rara vez es así.
Uno de los problemas más habituales que hemos observado es que un cliente pasa días, o incluso semanas, realizando pruebas en su entorno de desarrollo o de prueba, y luego aplica la misma configuración al sitio de producción una hora antes de su puesta en marcha, esperando que funcione exactamente igual. Para cuando se dan cuenta de que no va a ser así, ya es demasiado tarde.
Esto ocurre porque los aspectos que suelen diferir entre el entorno de producción y el de desarrollo son precisamente los que podrían dar problemas en un entorno de prueba. Muchas de las medidas de protección que hay que implementar en el entorno de producción —por ejemplo, tener el sitio web detrás de una CDN, utilizar un cortafuegos o contar con protección contra bots— no suelen ser necesarias en el entorno de prueba, por lo que es posible que parte del enrutamiento o la configuración de la red sea diferente.
Así que asegúrate de prestar atención a las diferencias en:
- Enrutamiento de redes (especialmente aplicable en implementaciones de CDN y DNS)
- Protección contra bots, infraestructura de cortafuegos o configuraciones que no se ajustan a las condiciones reales
Para asegurarte de que no te encuentres con ningún problema grave en una fase avanzada, te recomendamos que realices la puesta en marcha en el entorno de producción al menos 24 horas antes de la fecha prevista. Una vez que hayas completado las pruebas funcionales en un entorno de desarrollo o de prueba, limita el alcance a una zona del entorno de producción que no te suponga ningún problema —un patrón de URL específico y protegido que probablemente no cause molestias a los usuarios reales— y realiza algunas pruebas a pequeña escala en el entorno de producción. Incluso podrías hacer una pequeña prueba en producción en plena noche.
Pero... no lo dejes para el último momento.
3. Bloqueo de direcciones IP
Las integraciones personalizadas envían la dirección IP del usuario a la API de CrowdHandler, para que podamos comprobar que no figure en ninguna lista de direcciones bloqueadas. Sin embargo, no es raro que algunos sitios web estén configurados de tal manera que, sin querer, nos envíen la dirección IP de algún servidor proxy en lugar de la del usuario… y esto activa por error el bloqueo de IP de CrowdHandler.
Esto solo suele ser un problema si estás configurando la integración por tu cuenta (si utilizas una de nuestras integraciones, ya nos hemos encargado de todo eso), pero es bastante fácil cometer un error, así que ten cuidado.
Más información: Solución de problemas en integraciones de API personalizadas
4. Fijar una tarifa demasiado alta
La mayoría de la gente cree que su sitio web puede soportar mucho más tráfico del que realmente puede. Por eso, según nuestra experiencia, los clientes suelen establecer una tasa de entrada demasiado alta.
Si es la primera vez que pones en marcha tu sitio web, no sabes cuánto tráfico puedes esperar y, sinceramente, aún no sabes cuánto tráfico puedes gestionar. No te dejes engañar por la capacidad de tu sitio web para gestionar miles de solicitudes por segundo; esto no se traduce en el número real de personas que puedes canalizar desde tu cola.
Los sitios web que pueden gestionar sin problemas más de 60 usuarios por minuto (es decir, una nueva sesión por segundo) son bastante infrecuentes, por lo que probablemente deberías empezar con 30 o menos, a menos que conozcas realmente el perfil de carga de tu sitio web.
En resumen: es mejor empezar con una tarifa baja. Así, si te llevas una grata sorpresa, es fácil subirla. Recuperar una solicitud rechazada puede resultar más complicado.
Véase también: ¿Por qué no funcionan las pruebas de carga?
5. Exclusiones de URL
Si utilizas la integración de DNS, la integración de CDN o tu propia integración del lado del servidor con un controlador frontal, este comprobará cada una de las URL para enviar a los usuarios a la cola.
Sin embargo, es probable que algunas URL sean llamadas por aplicaciones de terceros y no deban enviarse a una cola; por lo tanto, es necesario excluirlas.
Un ejemplo claro de esto es una pasarela de pago. Un usuario realiza una transacción con, por ejemplo, PayPal o Stripe, y la pasarela de pago envía un recibo de confirmación del pedido, accediendo a una URL de tu servidor. Si no has excluido esa URL, la integración de CrowdHandler (que comprueba todas y cada una de las URL, recuerda) interviene y determina que la pasarela de pago debe colocarse en una cola. El pedido nunca se completará y el usuario no podrá finalizar la compra.
Esta es otra razón para realizar pruebas funcionales completas con suficiente antelación. Establece tu tasa en 0 para asegurarte de que la cola está activa y prueba los recorridos completos de los usuarios, incluyendo aquellas aplicaciones de terceros que puedan depender de tu dominio protegido.
Más información: Solución de problemas en integraciones de API personalizadas
6. Simplificar en exceso la plantilla
Una de las principales razones por las que a la gente le gusta usar CrowdHandler son las plantillas personalizadas, y hemos visto cómo los usuarios han creado cosas realmente creativas y emocionantes gracias a la libertad que ofrecen estas plantillas.
La plantilla predeterminada, o «inicial», incluye diferentes mensajes y estados para varios casos, algunos de los cuales son más evidentes que otros. Entre ellos se encuentran: que la sala aún no esté abierta, que la sala esté llena, que el usuario haya sido bloqueado por comportamiento sospechoso y que aún no se le haya asignado un puesto en la cola.
Sin embargo, cuando los usuarios personalizan la plantilla, es habitual que solo tengan en cuenta el «recorrido ideal» y que ignoren —o, lo que es peor, eliminen por completo— algunos de los mensajes de error y estados menos evidentes. Entonces, cuando un usuario se encuentra con una de estas situaciones, se le presenta una interfaz de usuario que resulta, en gran medida, poco útil.
Es importante comprender que los usuarios necesitan ver información de retroalimentación, incluso si esa información les indica algo que no consideras positivo, como su posición actual, la barra de progreso o el tiempo de espera estimado. Según nuestra experiencia, ocultar estos elementos resulta contraproducente. Sin ellos, los usuarios empezarán a comportarse de forma impredecible o reaccionarán mal ante la falta de información. Podrías perder ventas o incluso dañar tu reputación.
7. Configuración de tiempos de espera extremos para las sesiones
Todas las aplicaciones web utilizan el concepto de tiempo de espera de sesión, y CrowdHandler no es una excepción.
CrowdHandler tiene una duración predeterminada de 15 minutos, lo cual es una duración de sesión relativamente habitual para una aplicación web. Esto significa simplemente que, una vez que un usuario haya hecho clic en algo, durante los siguientes 15 minutos CrowdHandler dará por hecho que sigue conectado.
El usuario mantiene activa su sesión haciendo clic en las páginas, pero un tiempo de espera de 15 minutos significa que podría ausentarse durante 15 minutos para prepararse un café y volver sin tener que volver a ponerse en la cola. Cuando hace otro clic, la sesión se reactiva, por lo que sigue teniendo tiempo de sobra para navegar.
Conviene recordar que el número de sesiones es solo un indicador muy simplificado de la carga de tu aplicación. Cuando los usuarios se ausentan para prepararse un café, no están generando ninguna carga en tu aplicación.
Sin embargo, hemos observado que algunos clientes establecen una duración de la sesión demasiado corta o demasiado larga.
En cualquier caso, resulta contraproducente. Si el límite es demasiado bajo, es posible que acabes reenviando a los usuarios a la cola en mitad de su visita. Si es demasiado alto, podrías tener que gestionar una cola muy larga, ya que las sesiones de los usuarios permanecen activas durante mucho tiempo después de que se hayan ido.
Más información: Uno entra, otro sale
¿Estás listo para hacerlo bien a la primera?
¿Prevés un volumen elevado de trabajo o una gran demanda y estás listo para instalar una sala de espera?