Un test "gana". La métrica primaria sube, el intervalo de confianza cierra limpio, y el equipo lo lanza. Tres semanas después los tickets de soporte empiezan a subir y nadie conecta una cosa con la otra. La reforma dejó la sala preciosa, pero la cocina huele a gas.

Es el error más común en los programas de CRO, y no tiene nada que ver con la estadística. Es un problema de cómo planteas el experimento. Cuando un solo número decide si el test funcionó, ese número se vuelve lo único que alguien mira, y el resto del sistema se degrada en silencio.

Una métrica primaria nunca viaja sola

Todo experimento necesita una jerarquía de métricas, no una métrica. Con tres niveles cubres casi todo.

La métrica primaria responde la pregunta para la que diseñaste el test: si el usuario avanzó al siguiente paso, completó la compra, envió el formulario. Es la que decide si te quedas con el cambio.

Las métricas secundarias explican lo que pasa alrededor de ese cambio. Clics en opciones adyacentes, interacción con un módulo que ni tocaste, el camino que tomó el usuario hasta convertir. No deciden el test, pero te dicen por qué la primaria se movió como se movió.

Las métricas guardrail son los indicadores de salud que no pueden empeorar. Abandono de carrito, cancelaciones post-compra, ticket promedio, tiempo de carga. Son el freno de mano. Un cambio puede levantar la primaria diez puntos y aun así lo matas si una guardrail se pone en rojo, porque esa guardrail está midiendo si el uplift era real o lo pediste prestado de otra parte del funnel.

La mayoría define la primaria en el plan del test y trata las guardrail como un detalle, cuando las define. El orden debería ser al revés: decide qué te niegas a romper antes de decidir qué quieres mejorar.

Cuando ganar es perder

Hay tres patrones que se repiten, y los tres parecen un éxito en el dashboard que estabas mirando.

El CTA agresivo. Reescribes un botón para que sea más ruidoso e insistente, y los clics se disparan. La métrica secundaria se ve genial. Después la tasa de avance al siguiente paso cae, porque el botón ruidoso atrajo a usuarios que no entendían qué estaban clicando. Moviste volumen de clics informados a clics confundidos y lo llamaste uplift.

El upsell forzado. Empujas productos adicionales con más fuerza en el checkout y la tasa de venta de ancillaries sube. Pero el ingreso real por visitante baja, porque la fricción extra empujó una parte de los carritos al abandono. Optimizaste una línea del recibo y le cobraste impuestos a toda la transacción.

La eliminación de fricción útil. Un paso de confirmación, una pantalla que aclara, un campo extra: lo cortas para "agilizar" el flujo. El CTR a lo largo del funnel mejora al instante. Lo que la ventana del test es demasiado corta para mostrarte: la calidad de los leads bajó, o las cancelaciones subieron, porque esa fricción estaba haciendo el trabajo de asegurar que el usuario entendía a qué se apuntaba. No toda fricción es desperdicio. A veces es el producto explicándose a sí mismo.

En los tres casos la primaria hizo exactamente lo que esperabas. El daño estaba sentado en un número que nadie ascendió a criterio de decisión.

Squeeze contra optimize

Bajo presión de fecha límite, es fácil confundir movimiento con progreso. La urgencia fabricada, los defaults tramposos, el contador que se reinicia cuando recargas la página: todo eso mueve un KPI primario de forma fiable. Estás exprimiendo el funnel, no optimizándolo.

La diferencia aparece en las guardrail, con retraso. El churn, las solicitudes de reembolso, las quejas a soporte y la tasa de bajas son donde se pagan las conversiones prestadas. Una táctica de squeeze produce un uplift limpio en la semana uno y una erosión de confianza que no termina de registrarse hasta que el experimento lleva tiempo cerrado y el resultado ya está en el reporte como victoria.

Una regla que funciona: si un cambio no sobrevive a que se lo expliques al usuario en lenguaje claro, no es una optimización. Es un peaje que cobras antes de que lo noten.

Las guardrail no son solo métricas de negocio

La salud técnica entra en la misma categoría, y es la parte que la mayoría de los planes de experimento se saltan.

El rendimiento de la página es una guardrail. Una variante que suma 400ms al tiempo de carga puede mostrar una tasa de conversión más alta en el test y aun así costarte dinero a escala, porque la latencia golpea a todos los usuarios mientras el uplift de conversión golpea a una parte.

Los errores de JavaScript son una guardrail. Si tu variante sube la tasa de errores en consola, está en rojo, sin discusión, aunque el funnel se vea sano. Estás lanzando un resultado construido encima de usuarios que por suerte no pasaron por la ruta rota.

La segmentación esconde el resto. Una guardrail puede estar perfectamente sana en desktop y quemándose en mobile, y el agregado va a promediar el incendio hasta dejarlo en algo que parece sobrevivible. Revisa los segmentos antes de confiar en el total: el tráfico que convierte y el tráfico más frágil rara vez son los mismos dispositivos.

El objetivo nunca fue ganar tests

La meta de un programa de A/B testing no es una tasa alta de victorias. Es tomar mejores decisiones con menos humo. Un equipo que lanza cada test "ganador" sin revisar qué costaron esas victorias no está experimentando, está corriendo una máquina de justificar lo que ya quería hacer.

Reportar un test como no concluyente porque dañó una guardrail es señal de madurez profesional, no de fracaso. Significa que el sistema de medición está haciendo su trabajo: atrapar el cambio que se habría visto bien en el readout y mal en los números del trimestre. Quien reporta esos resultados con honestidad es quien construye un programa que compone con el tiempo, porque las victorias que sí lanza son reales.

No optimices para el clic. Optimiza para la decisión.