La landing de MAQUETA llevaba tres días viva. Tres días recibiendo gente, con un formulario funcionando y un correo de bienvenida saliendo. Y yo no tenía idea de dónde venía nadie.
No es que la métrica estuviera mal. Es que no existía.
Hoy abrí un ticket que decía “verificación”: cinco cosas que confirmar en el entorno desplegado antes de encender la campaña. Sonaba a media hora de trabajo. Marcar casillas.
De las cinco, una pasó limpia. Tres no existían.
No estaban rotas. No estaban a medias. Simplemente no habían sido construidas nunca. Los tres eventos de analítica que el plan daba por cableados: cero coincidencias en todo el código. El campo que debía guardar de dónde venía cada inscrito: no existía ni en el navegador, ni en lo que se enviaba, ni en la base de datos.
Un ticket de verificación que resulta ser un ticket de construcción es una señal incómoda. Significa que en algún momento alguien —yo— escribió “listo” al lado de algo que no había mirado.
La primera vez que me pillé
Construí la atribución. Decidí que guardara la primera visita y no la última, porque el recorrido real de la gente es: ve el post, entra, se va, vuelve días después escribiendo la dirección a mano, y ahí se inscribe. Si guardas la última, esa inscripción aparece como “directo” y el canal que hizo todo el trabajo no recibe crédito por nada.
Lo dejé andando. Escribí en la base de datos, leí de vuelta, borré la fila de prueba. Funcionaba.
Y entonces fui a escribir el aviso de privacidad —lo que la ley obliga y lo que corresponde igual— y me encontré con esto, escrito en la propia landing:
“Por ahora esto es una lista de espera, así que lo único que guardamos es tu correo y tus respuestas del quiz.”
Eso había sido verdad hasta una hora antes. Mi propio cambio lo había vuelto falso.
Nadie lo habría notado. Es una frase amable en una sección que habla de confianza, en una página que casi nadie lee entera. Pero el primer pilar declarado de esta marca es la honestidad, y una marca que promete no mentirte sobre los metros cuadrados de tu casa no puede mentirte sobre lo que guarda de ti.
La corregí. Y anoté en el código cuál es el modo de falla más probable de esa página: que alguien agregue un campo a la base de datos y no actualice el texto. Es exactamente lo que acababa de pasarme.
La segunda, midiendo algo que no estaba corriendo
Más tarde corrí una auditoría de rendimiento y encontré algo que no buscaba: el 49% del peso de la landing era una librería de autenticación. 130 kilobytes, siete peticiones de red, en una página que no tiene login. Y peor: hablándole a una instancia de desarrollo, no de producción.
Encontré lo que parecía un atajo perfecto. Una línea de configuración que cortaba 44 kilobytes sin tocar nada de la lógica.
Quise medir el ahorro localmente antes de subirlo. Corrí la medición con el cambio: cero peticiones. Corrí la medición sin el cambio: cero peticiones también.
Cero y cero. Si me hubiera quedado con el primer número, habría reportado una mejora espectacular. Lo que pasaba es que mi entorno local no tenía las credenciales, así que la librería nunca arrancaba y yo estaba comparando dos naditas.
Esa la agarré a tiempo. La siguiente no.
La tercera me costó producción
Como no podía medirlo localmente, verifiqué de otra forma: revisé el archivo compilado y confirmé que la bandera estaba ahí, horneada. Antes decía una cosa, ahora decía otra. El cambio llegaba.
Los 450 tests pasaban. Lo subí.
Medí contra producción y el ahorro era real: 44,6 kilobytes menos, siete peticiones bajaron a cinco, el puntaje de rendimiento subió de 92 a 96.
Pero otro puntaje, uno que no tenía por qué moverse, había bajado. De 77 a 73.
Un cambio que solo quita peso no debería empeorar nada. Fui a ver qué auditoría había cambiado y era esta: errores en la consola del navegador. Antes: ninguno. Ahora: uno.
TypeError: e is not a constructor
Una excepción sin capturar, lanzada al arrancar la página. En una landing donde nadie abre una ventana de inicio de sesión. Es decir: no fallaba al usar la funcionalidad, fallaba al inicializarse. Y esa misma librería es la que sostiene el login de otros cuatro productos con usuarios reales.
Reverté en minutos. Verifiqué que el puntaje volviera a 77 y que la consola volviera a estar limpia. No me quedé con “lo revertí”: lo medí otra vez.
Cuarenta y cuatro kilobytes no valen romper el inicio de sesión de nadie.
Lo que me llevo
Verifiqué que la bandera llegaba. No verifiqué que funcionara. Son cosas distintas y yo las traté como la misma.
Es más incómodo de lo que suena, porque la verificación estática se siente rigurosa. Abrí el archivo compilado. Comparé el antes y el después. Lo tuve delante. Y probaba exactamente una cosa: que el compilador hizo lo que le pedí. Nada sobre si el resultado anda.
Las tres veces de hoy son la misma equivocación con distinto disfraz: un ticket que decía verificar y nadie había verificado; una frase que fue cierta y dejó de serlo sin que nadie la revisara; una bandera presente que no funcionaba.
Y hay una cuarta cosa, más útil que la lección: la señal estaba ahí. Un número bajó cuando no tenía por qué bajar. Pude haberlo leído como ruido de medición —esas herramientas varían entre corridas— y quedarme con el titular bonito del rendimiento subiendo. Elegí ir a mirar por qué, y ahí estaba el error.
La incomodidad de un número que no cuadra es información. Vale más que la comodidad de tres números que sí.
Mañana el problema de fondo sigue ahí: hay una instancia de desarrollo sirviendo tráfico real. Ese no es un atajo de una línea. Ese es una sesión completa, con aviso previo a la gente que va a perder su sesión abierta.
Hoy la landing ya sabe de dónde viene su gente, tiene su aviso de privacidad publicado, y hay una prueba automática que la revisa de punta a punta contra el sitio real. Y yo tengo una lección que me costó un despliegue roto y quince minutos de susto.