31 días sin leads: qué reveló la investigación
Un commit cambió el CTA de la home: 31 días sin generar leads. El post-mortem: causa raíz, dos bugs silenciosos y una métrica de GA4 mal configurada.
Treinta y un días. Ese fue el tiempo que el sitio pasó sin recibir un solo lead nuevo, un número lo bastante feo como para hacernos parar todo e investigar. El resultado fue un post-mortem con una causa raíz clara y dos bugs más que no tenían nada que ver con ella, pero que escondían el problema real desde hacía semanas sin disparar ninguna alarma.
La causa raíz: un clic que terminó en el CTA equivocado
Rastreando los commits, encontramos al responsable un día después del último lead recibido: un commit cambió el link del botón principal del hero de la home. Antes apuntaba a /contato. Después del cambio, pasó a apuntar al Raio-X, nuestra herramienta de diagnóstico automático que graba la pantalla del visitante para generar un informe. A partir de ese commit, quien hacía clic en el botón más visible de la home ya no caía en el formulario de contacto: caía en otra funcionalidad.
Por qué el Raio-X nunca convertía
El Raio-X no estaba parado: registramos 159 solicitudes en 3 días solo en la etapa de grabación de pantalla. Ninguna se convirtió en lead. La causa es una dependencia de plataforma: el Raio-X usa la API getDisplayMedia del navegador para capturar la pantalla, y esa API simplemente no existe en el Safari de iOS ni en el Chrome de Android. El tráfico frío que llega desde redes sociales es mayoritariamente mobile, así que la mayoría de quienes hacían clic se topaba con una funcionalidad inaccesible en el dispositivo que estaban usando.
La solución tuvo dos partes. Primero, el CTA principal del hero volvió a apuntar a /contato: el Raio-X pasó a ser una opción secundaria. Segundo, agregamos una verificación de compatibilidad antes de intentar grabar la pantalla. Cuando el navegador no lo soporta, el visitante ya no se queda sin alternativa: ahora ve un aviso que lleva a una opción de subida manual de video.
Un segundo bug, encontrado en el camino: tiempo negativo
Investigando el embudo, apareció un bug independiente en el propio formulario de contacto. La protección antibots rechaza envíos que ocurren en menos de 5 segundos después de que el formulario se abre, una señal común de automatización. El cálculo de tiempo transcurrido no tenía protección contra valores negativos: si el reloj de la computadora de quien completaba el formulario estaba adelantado respecto a nuestro servidor, el tiempo transcurrido daba un número negativo, que es menor a 5 segundos igual que cualquier otro. El envío se descartaba en silencio, pero la respuesta para el visitante seguía siendo de éxito (HTTP 200). Había gente completando el formulario, viendo la confirmación de envío en pantalla, y el lead nunca llegaba a ningún lado.
Un tercer problema, en un sistema totalmente separado
La investigación también encontró un tercer bug, sin relación con los dos primeros: la rutina automática de reenganche de leads que no responden (el lead-nurture) estaba rota en producción desde hacía semanas. La causa era un error de tipo en la consulta a la base de datos, una comparación entre un enum y un texto. El efecto era el mismo que en los otros dos: la rutina devolvía código de éxito aunque fallara, así que ningún email de reenganche estaba saliendo y nadie lo notó, porque nada ahí parecía una falla.
El GA4 también estaba mal, solo que al revés
Reconfigurando las métricas de conversión en Google Analytics 4 después de los arreglos, encontramos otra pieza suelta: dos conversiones estaban marcadas como "conversión principal" en GA4, pero ninguna de las dos existía realmente en el código del sitio. La plataforma mostraba "sin datos" para ambas desde siempre. Es decir, el cero de conversiones que aparecía antes no medía lo que creíamos que estaba midiendo: era un problema de configuración, no un retrato real del desempeño del sitio.
La lección: un bug silencioso no dispara ninguna alarma
Dos de los tres bugs de código comparten una característica peligrosa: el formulario que descarta el envío y responde 200, y la rutina de lead-nurture que falla en la consulta y responde 200 de todas formas. En ambos casos el sistema reportaba éxito mientras hacía lo incorrecto, sin que apareciera ningún registro de error. El problema del CTA era de otra naturaleza (un link que apuntaba al lugar equivocado, sin status code involucrado), pero tuvo el mismo efecto práctico: nada se rompía de forma visible, el clic ocurría, la página cargaba. La falla silenciosa, ya sea un HTTP 200 indebido o un link mal configurado, es el tipo de problema más peligroso justamente porque no hay ninguna alarma lista para dispararse. La única forma de detectarlo fue cuando un número esencial (leads nuevos) quedó visiblemente en cero por demasiado tiempo, y alguien fue a buscar el porqué.
La configuración de GA4 que corregimos aquí fue solo el comienzo: la arquitectura completa de atribución de conversión (cómo medimos el origen de campaña y de referidos sin exigir banner de cookies) está detallada en Cómo medimos la atribución de conversiones sin banner de cookies.
Si el embudo de tu sitio también depende de un CTA, un formulario y una rutina de automatización corriendo sin que nadie chequee el resultado real, vale la pena revisarlo con la misma mirada antes de que aparezca el número en cero. Cuéntanos tu contexto y vemos si tiene sentido mirarlo juntos.