Once días pagando por tráfico que no podía comprar
Caso real · Comercio electrónico con 45.000 sesiones al mes y un checkout roto en un solo navegador
Un diagnóstico técnico web orientado a negocio no audita la web entera: audita las rutas por las que entra el dinero y las vigila segmentadas por navegador y dispositivo. La diferencia importa porque los fallos que más cuestan no son los que ralentizan la home. Son los que rompen el pago en un único segmento sin mover ninguna de las métricas que el equipo de marketing mira a diario.
Este caso es exactamente eso.
El punto de partida: ventas que caen con el tráfico intacto
El director de marketing lo resumió así:
> «Pagamos por traer tráfico a una web que a veces no funciona, y nos enteramos cuando alguien se queja.»
La frase venía de una experiencia reciente y concreta. Un comercio con checkout en tres pasos, 32.000 € mensuales en paid, y un mes en el que las ventas cayeron sin explicación aparente.
Lo que había pasado: una actualización rutinaria del plugin de reseñas introdujo un error de JavaScript que bloqueaba el botón de pago solo en Safari sobre iOS. En ningún otro navegador. En ningún otro dispositivo.
Y aquí está lo que hace este tipo de fallo tan peligroso: ninguna de las métricas que el equipo miraba a diario se movió. El tráfico, igual. Las sesiones, igual. Las visitas al checkout, igual — la gente llegaba al último paso perfectamente. Lo único que cayó fueron las ventas.
En un informe semanal, una caída de ventas con tráfico estable se lee como un problema de conversión. Y un problema de conversión sin causa evidente se atribuye a lo de siempre: estacionalidad, competencia, «el mercado está raro este mes».
Pasaron once días hasta que un cliente escribió por el formulario de contacto diciendo que no podía pagar. Once días con el presupuesto de paid corriendo al 100%, comprando tráfico de iPhone que, por definición, no podía convertir. Unos 3.400 € en tráfico inservible, más la facturación perdida.
Lo que no hicimos
No propusimos cambiar la web ni migrar de CMS. Es lo que este cliente ya había oído de dos proveedores: «tu plataforma está anticuada, hay que rehacerla». Puede que algún día toque. Pero no era la causa del problema y no lo habría evitado: un rediseño de nueve meses no arregla un error de JavaScript que aparecerá igual en la web nueva la próxima vez que se actualice un plugin.
No propusimos una plataforma de WPO. Existen suites de observabilidad con licencias de cinco cifras anuales, pensadas para equipos de ingeniería que gestionan decenas de aplicaciones. Este cliente tiene una web. Necesitaba vigilancia sobre cuatro rutas, no un centro de control.
No hicimos optimización técnica por deporte. Hay una tentación clara aquí: entregar un informe de Lighthouse con cuarenta recomendaciones ordenadas por severidad técnica. La mayoría son irrelevantes para el negocio. Solo nos interesaba lo que ocurre en las rutas que llevan dinero, y solo si el arreglo tiene impacto medible en conversión o ingresos. Un LCP que mejora 200 milisegundos en la página de aviso legal no es un resultado. Es una diapositiva.
Cómo hicimos el diagnóstico técnico y qué montamos después
1. Diagnóstico de las rutas críticas, no de la web entera
Empezamos identificando los cuatro recorridos que generan el ingreso: entrada desde campaña → ficha de producto → carrito → checkout, con sus variantes de landing. Ahí se concentra el 90% del riesgo y prácticamente todo el valor.
Sobre esas rutas, auditoría de rendimiento y errores combinando datos de laboratorio y de campo:
- Core Web Vitals y CrUX, para saber qué experimentan los usuarios reales, segmentado por dispositivo y navegador — exactamente donde se escondía el problema original.
- Lighthouse y WebPageTest, para reproducir en condiciones controladas y aislar causas.
- Registro de errores de JavaScript en producción, capturando qué falla, en qué navegador, en qué versión y en qué punto del recorrido.
El diagnóstico destapó tres cosas que nadie sabía: un error de consola recurrente en el paso 2 del checkout en Android 9 y anteriores, un script de terceros que retrasaba 1,8 segundos la interactividad de la ficha de producto en móvil, y una landing de campaña que tardaba el doble que el resto porque cargaba una tipografía que no usaba en ningún sitio.
Esa tipografía llevaba ahí veintidós meses.
2. Monitorización activa por segmento
Aquí está la diferencia entre auditar y proteger.
Una auditoría es una foto: te dice cómo está la web hoy. Pero el problema original no era una web mal construida — era una web que se rompió un martes por la tarde. Ninguna auditoría, por buena que sea, detecta eso.
Implantamos monitorización continua de las rutas críticas segmentada por navegador, sistema operativo y tipo de dispositivo. El sistema comprueba periódicamente que los recorridos de compra se completan, y vigila la tasa de finalización de cada paso desglosada por combinación técnica.
Esto es lo que convierte un fallo invisible en un fallo evidente. Un problema que solo afecta a Safari iOS diluye su señal en el total: si iOS es el 25% de tu tráfico, la caída global es de uno o dos puntos y se pierde en el ruido semanal. Aislado por segmento, salta a la vista de inmediato.
3. Alertas de anomalía con criterio de negocio
Definimos umbrales sobre lo que importa: caída de la tasa de finalización de checkout en cualquier segmento, aparición de un error de JavaScript nuevo en una ruta crítica, degradación de tiempos por encima de un límite acordado.
Las alertas llegan al canal que el equipo ya usa —Slack, en este caso— con contexto suficiente para decidir en treinta segundos si hay que actuar: qué ha caído, en qué segmento, desde cuándo y cuánta facturación hay en riesgo.
Y una regla operativa que el cliente incorporó por su cuenta tras el primer aviso: si el checkout falla en un segmento, se pausa la inversión dirigida a ese segmento hasta que se resuelva. Dejar de comprar tráfico que no puede convertir es la decisión más rentable disponible en ese momento, y no requiere aprobación de nadie.
4. Priorización por impacto en ingresos
Todo lo detectado se ordenó por dinero, no por severidad técnica. Cada hallazgo con su estimación de sesiones afectadas, conversión perdida y facturación en riesgo.
Con ese criterio, de los diecisiete hallazgos iniciales, cuatro concentraban el 85% del impacto estimado. Se ejecutaron esos cuatro. Los otros trece quedaron documentados en una lista de mantenimiento sin urgencia, que es donde deben estar.
Resultado
El siguiente fallo se detectó en 40 minutos. Ocurrió cuatro meses después: una actualización del gestor de consentimiento bloqueó el evento de compra en Chrome sobre Android. La alerta saltó esa misma tarde. Se corrigió a la mañana siguiente.
Once días frente a menos de una hora. Ahí está toda la propuesta de valor del proyecto, resumida en una comparación.
Se recuperó un 6% de conversión en móvil eliminando el script de terceros que bloqueaba la interactividad de la ficha de producto. No era un fallo, era un lastre permanente que llevaba dos años ahí y que ninguna auditoría anterior había vinculado a ingresos.
El presupuesto de paid dejó de correr a ciegas. La regla de pausa por segmento se ha activado dos veces desde entonces. En ambos casos, el ahorro de una sola tarde de inversión mal dirigida superó el coste mensual de la monitorización.
Y una consecuencia cultural: cuando ahora las ventas caen sin causa aparente, el equipo ya no dice «estacionalidad». Mira primero si la web está funcionando. Es una hipótesis que antes ni se planteaba, porque no había forma de comprobarla.
Por qué lo hacemos así
Hay una asimetría que casi nadie tiene en cuenta: cuando la web se rompe, la inversión en paid no se rompe con ella. Las campañas siguen sirviendo, las pujas siguen ejecutándose y el presupuesto sigue consumiéndose con normalidad mientras el tráfico que compras llega a una puerta cerrada.
Esa asimetría es la que convierte un fallo técnico menor en un problema de marketing caro. Y es la razón por la que el diagnóstico técnico de una web comercial no es un asunto de IT: es una medida de protección del presupuesto de medios. Que lo pague el departamento equivocado es un detalle contable, no un argumento.
Protegerlo no exige rehacer la web ni contratar una suite de observabilidad. Exige saber cuáles son tus cuatro rutas críticas, vigilarlas segmentadas por navegador y dispositivo, y que alguien reciba un aviso cuando dejen de funcionar.
Notablemente más barato que once días de tráfico pagado a una página que no vende.
Dónde no aplica: si no vendes ni captas leads a través de la web, o si tu inversión en paid es marginal, la monitorización continua no se paga sola. El umbral aproximado está en torno a los 10.000 € mensuales de inversión: por debajo, una auditoría puntual y revisiones periódicas suelen bastar.
Preguntas frecuentes
¿Por qué caen las ventas si el tráfico se mantiene estable?
La causa más frecuente y peor diagnosticada es un fallo técnico en un segmento concreto: un error de JavaScript que rompe el pago en un navegador, una versión de sistema operativo o un tipo de dispositivo. El tráfico, las sesiones y hasta las visitas al checkout siguen intactas porque el usuario llega; simplemente no puede completar. Antes de atribuirlo a estacionalidad, conviene revisar la tasa de finalización de checkout desglosada por navegador y dispositivo.
¿Cómo se detecta un error que solo afecta a un navegador?
Segmentando. Un fallo que afecta al 25% del tráfico produce una caída global de uno o dos puntos, indistinguible del ruido normal. Aislado por combinación de navegador, sistema operativo y dispositivo, el mismo fallo aparece como una caída del 100% en ese segmento. Requiere registro de errores de JavaScript en producción y monitorización de la tasa de finalización por segmento.
¿Qué diferencia hay entre una auditoría técnica y una monitorización?
La auditoría es una foto del estado actual: detecta problemas que ya existen. La monitorización es continua: detecta el momento en que algo se rompe. Una web puede pasar una auditoría impecable el lunes y romperse el martes con una actualización de plugin. Son complementarias, no alternativas.
¿Cuántas páginas hay que vigilar en un ecommerce?
Las rutas que generan ingreso, normalmente entre tres y seis: entrada desde campaña, ficha de producto, carrito, cada paso del checkout y las landings de campaña activas. Vigilar la web completa multiplica el coste y el ruido de alertas sin añadir protección relevante.
¿Merece la pena pausar campañas cuando falla la web?
Sí, y en el segmento afectado exclusivamente. Si el checkout no funciona en un navegador, cada euro dirigido a usuarios de ese navegador es gasto puro. Automatizar o protocolizar esa pausa es una de las decisiones de mayor retorno inmediato disponibles, y no requiere ninguna herramienta especial: solo saber a tiempo que ha ocurrido.
¿Los Core Web Vitals afectan a la conversión o solo al SEO?
A ambos, pero por vías distintas. En SEO son una señal de posicionamiento de peso moderado. En conversión el impacto es directo y suele ser mayor: retrasos en la interactividad de fichas de producto y checkout se traducen en abandono medible. En este caso, eliminar un script que retrasaba 1,8 segundos la interactividad recuperó un 6% de conversión móvil.
¿Sabrías si tu checkout dejara de funcionar en un solo navegador? Cuéntanos cuáles son tus rutas de compra y qué vigilas hoy. En la primera conversación sabremos si tu caso necesita monitorización, saneamiento técnico o solo un par de alertas bien puestas — y las tres tienen tamaños muy distintos.
Otros casos de uso
Otros proyectos donde resolvimos el mismo tipo de problema.