PathMayo de 2026
Por qué reproducimos sus recorridos en un navegador real
Hay tres formas de probar un embudo de compra. Elegimos la más lenta y la más costosa, y aquí explicamos por qué es la única que responde a la pregunta.
Tres formas de probar un recorrido
- Encadenar peticiones HTTP imitando un navegador: rápido, barato y falso en cuanto hay JavaScript, un token antirreplay o un widget de pago.
- Pilotar un navegador reducido, sin renderizado: más ligero, pero algunos sitios detectan la falta de pintado y se comportan de otro modo.
- Lanzar un Chromium real, con renderizado, cookies y scripts de terceros, y hacerle repetir los gestos de un cliente.
Elegimos la tercera. Es la más lenta de ejecutar y la más cara de mantener, y es la única que responde a la pregunta real: ¿puede un ser humano comprarle ahora mismo?
Lo que permite ver
- El tiempo de cada paso por separado: el acceso puede ser instantáneo y el carrito interminable, algo que una medida global oculta.
- Una captura del fallo, tomada en el instante en que ocurre.
- El vídeo del recorrido fallido, en los planes que lo incluyen, cuando la captura no basta para entender.
- Las llamadas de red de cada paso, con su código de respuesta y su duración: ahí aparece a menudo el script de terceros culpable.
Lo que cuesta
Un navegador ocupa procesador y memoria durante todo el recorrido. Por eso las ejecuciones de navegador se cuentan en minutos y su cadencia es más holgada que una sonda HTTP: unas veces por hora en los planes altos, una vez al día en los de entrada. La monitorización HTTP, en cambio, se ejecuta cada minuto.
Lo que no hemos hecho
No escribimos los escenarios por usted ni ofrecemos un editor de código. Usted graba el recorrido haciendo clic, en el grabador, y corrige los pasos a mano si un selector cambia. Es una decisión consciente: un escenario que no entiende es un escenario que no va a arreglar, y un escenario roto que nadie arregla acaba desactivado.