CRO en Shopify sin adivinar

Casi todo el reporte de conversión es una historia armada después de que llegaron los números. Alguien cambió un botón, esa semana subieron los ingresos, y el cambio ya es una victoria con un porcentaje pegado. El porcentaje no es una medición. Es la diferencia entre dos semanas ruidosas, y si no hubieras cambiado nada también habrías tenido un número.

Hacer trabajo de conversión de forma que el resultado signifique algo no es difícil, pero exige comprometerse con unas cuantas cosas antes de empezar. Justo esas son las que la gente evita, porque son las que hacen posible estar equivocado.

Decide la métrica única antes de tocar nada

Escribe, antes de construir el cambio, el número único que decide esto. No un tablero. No "conversión y ticket promedio y rebote". Una métrica primaria, y la dirección en la que tiene que moverse.

La razón de que sea una es aritmética. Cada métrica adicional con la que estás dispuesto a declarar victoria es otra oportunidad para que el ruido te entregue un triunfo. Vigila seis métricas y algo va a subir; la probabilidad de que al menos una se mueva a favor por accidente se acerca a la certeza. En estadística se llama comparaciones múltiples. En una tienda se llama "bueno, subió el ticket promedio".

Elige la métrica más cercana a lo que cambiaste, no la más lejana. Si cambiaste la página de producto, mide la tasa de añadir al carrito o el paso de producto a checkout, no el ingreso por sesión, que está aguas abajo de los costos de envío, los códigos de descuento, la mezcla de tráfico y todo lo demás que pasó esa semana. El ingreso es lo que te importa; es una mala cosa que medir, porque es el número más ruidoso del sitio.

Las métricas secundarias están bien, y tienen exactamente un trabajo: detectar daño. Si subió el añadir al carrito y subió con él la tasa de devoluciones, no ganaste, moviste un problema aguas abajo. Declara los límites de seguridad al mismo tiempo que la métrica primaria, y decláralos como umbrales y no como cosas que vas a mirar.

Tamaño de muestra y regla de parada, acordados por escrito

Antes de que corra la prueba, dos números quedan escritos: cuántas sesiones o conversiones necesita cada variante, y la fecha en que vas a parar. Ambos salen de tu tasa de conversión base actual y de la mejora más pequeña que de verdad valdría la pena publicar.

Esa última entrada es la que la gente se salta, y es la que determina si la prueba es siquiera posible. Una tienda que convierte al 2% con un par de cientos de pedidos al mes no puede detectar una mejora relativa del 3%. Tampoco una del 10%, no dentro de un trimestre. Hacer la aritmética primero suele ser lo más valioso que ocurre en un proyecto de conversión, porque la respuesta honesta muchas veces es "esta tienda no puede correr experimentos con este tráfico" — que no es un fracaso, es una redirección hacia trabajo que no necesita estadística para justificarse.

La regla de parada importa tanto como el tamaño. Revisar una prueba en marcha todos los días y detenerla cuando se ve significativa es un procedimiento que fabrica significancia a partir de ruido: una prueba sin efecto real cruzará el umbral en algún momento si sigues mirando. O fijas la duración por adelantado y no miras, o usas un método diseñado para monitoreo continuo y aceptas sus intervalos más anchos. Lo que no puedes hacer es asomarte y parar el día bueno.

Dos reglas más, baratas, que evitan la mayoría de los desastres. Corre semanas completas, para que días entre semana y fin de semana estén representados por igual. Y nunca empieces ni concluyas cruzando una promoción: una prueba que abarca una rebaja mide la rebaja.

Un arreglo de fricción no es un experimento

Esta distinción ahorra más tiempo que cualquier otra cosa de aquí. Hay dos tipos de trabajo de conversión y se rigen por reglas distintas.

Un arreglo de fricción es un defecto. El selector de variantes no muestra qué opciones están agotadas. El costo de envío aparece por primera vez en el último paso del checkout. El botón de añadir al carrito en móvil queda debajo de tres párrafos de copy. La guía de tallas abre un PDF. Estos no necesitan experimento, porque el contrafactual no es interesante: nadie está argumentando que la versión rota podría ser mejor. Publícalo, anota la fecha, sigue.

Un experimento es una pregunta genuina donde personas razonables discrepan y la respuesta podría ir para cualquier lado. ¿Una descripción de producto larga vende mejor que una corta? ¿Quitar el campo de código de descuento del carrito aumenta los checkouts completados, o molesta a quien sí tiene un código? ¿Un bundle sube el ticket promedio lo suficiente para pagar las unidades que canibaliza? Eso vale la pena probarlo, y solo eso.

Casi todo lo que se vende como programa de conversión son arreglos de fricción disfrazados de experimentos, porque un experimento se puede reportar con un número y un arreglo no. Está al revés. Los arreglos son donde está casi todo el valor, y fingir que son experimentos quema semanas de tráfico demostrando algo que ya se sabía.

Encontrarlos es un ejercicio distinto de probarlos: una lectura página por página de la tienda buscando defectos. Esa es la forma de nuestro trabajo en CRO Inspector — inspeccionar inicio, colección, producto y carrito, y producir una lista priorizada de cosas que están mal. Nada de esa lista necesita una prueba.

Qué puedes y qué no puedes probar en el checkout

El checkout no es una página que controles, y eso sorprende siempre. Es de Shopify, se renderiza desde sus plantillas, y la superficie que te toca está definida por puntos de extensión y no por un DOM que puedas reescribir. Una herramienta de pruebas que funciona inyectando JavaScript y mutando la página no funciona ahí, y no debería: un script de tercero reescribiendo un formulario de pago es exactamente lo que la seguridad del checkout existe para impedir.

Lo que sí puedes cambiar es real, y es código y configuración en vez de un editor visual. Las checkout UI extensions colocan tu contenido en targets definidos: un bloque de confianza cerca de la sección de pago, un campo de instrucciones de entrega, una oferta en un momento concreto. Las Functions cambian la lógica misma: qué calcula un descuento, si un carrito puede proceder, qué opciones de envío aparecen y en qué orden.

Eso se puede probar, pero la unidad de variación es algo que despliegas, no algo que activas en un panel. En la práctica, los experimentos de checkout son más lentos y más gruesos que los de la tienda: estás comparando periodos, o enrutando una parte del tráfico por tu propia lógica, y ambas cosas son más trabajo que un editor visual. La ventaja es que lo que aprendes es real. Un cambio en esa capa aplica a cada comprador, incluidos los que tienen bloqueadores de scripts y nunca vieron tu herramienta de pruebas.

Antes de todo esto, revisa que la medición misma sobreviva la frontera del checkout. Si tu analítica pierde la atribución cuando una sesión pasa de la tienda al checkout de Shopify, cada número de conversión que tienes está mal de una forma que ningún diseño de prueba arregla. Dejar el tracking correcto es un prerrequisito, no una línea de trabajo paralela.

Por qué la mayoría de las victorias no sobrevive

Toma cualquier tienda con un historial documentado de victorias de conversión y suma los incrementos reclamados. Si fueran reales y acumulativos, la tienda convertiría a una tasa a la que no convierte ninguna tienda. No lo hace. Así que o las victorias no eran reales, o no duraron, y ambas cosas son lo bastante comunes como para esperarlas por defecto.

Dominan tres causas. La primera es parar temprano, ya discutida: una prueba detenida en cuanto se veía bien es una prueba que midió una fluctuación. La segunda es que el efecto fue real pero pequeño y propio de un momento: una mezcla estacional de tráfico, una campaña, una respuesta de novedad que se desvaneció cuando los visitantes recurrentes se acostumbraron al nuevo layout. La tercera es que nunca corrió contra un control adecuado, porque la comparación fue este mes contra el anterior, y el anterior tenía otro tráfico.

La defensa es escribir el resultado con honestidad en el momento. Qué se probó, sobre qué tráfico, cuánto tiempo, qué se movió y cuánto, con el intervalo, y qué hicieron las métricas de seguridad. Un párrafo por prueba. No cuesta nada, y es lo único que evita que un programa acumule folclore que nadie puede rastrear hasta un número.

Y vuelve a correr las que importaron. Si un cambio valía un cuarto de punto de conversión, vale confirmar seis meses después que lo sigue valiendo. Casi nadie lo hace, que es justamente por lo que los incrementos reclamados nunca cuadran.

Cómo se ve esto en la práctica

Un programa de conversión sensato en una tienda Shopify mediana en su mayoría no son experimentos. Es: arreglar los defectos que encontró una auditoría, dejar la medición confiable de punta a punta, y después correr un número pequeño de preguntas reales bien hechas — una a la vez, dimensionada con honestidad, detenida en la fecha, escrita.

Ese programa se ve más lento que un tablero lleno de pruebas, y produce menos números. Los números que produce son verdaderos, que resulta ser la única propiedad que compone.