Test A/B en WooCommerce: la Guía Completa
Test a/b woocommerce: caché de página, checkout en bloques o shortcode, qué métrica sirve en cada etapa y la cuenta de muestra que define qué testear.
📚 Este artículo es parte de la guía Optimización de Checkout: el Playbook de Test A/B.
El test A/B en WooCommerce no se diferencia del test A/B en cualquier otra tienda, salvo por cuatro detalles que solo aparecen en una instalación WordPress y que hunden la mayoría de los primeros intentos: la caché de página, la convivencia entre el checkout en bloques y el checkout clásico, los conflictos de plugins y la elección de qué etapa medir. Esta guía forma parte del playbook de optimización de checkout para ecommerce y cubre los cuatro, muestra qué métrica sirve en cada etapa de la tienda y te da la cuenta que define qué puedes y qué no puedes testear con tu nivel de tráfico, con una calculadora en vivo y un ejemplo trabajado de punta a punta.
Qué tiene de distinto una tienda WooCommerce
WooCommerce es un plugin de ecommerce para WordPress, con más de 7 millones de instalaciones activas según el repositorio oficial de plugins de WordPress (wordpress.org). No incluye ningún motor de experimentación, así que el test siempre viene de fuera, por uno de dos caminos:
| Camino | Cómo funciona | Ventaja | Trampa principal en WordPress |
|---|---|---|---|
| Snippet client-side | Una etiqueta en el header intercambia contenido en el navegador del visitante | Se instala en minutos, sin deploy | Parpadeo si la etiqueta carga tarde; depende de JavaScript |
| Server-side en PHP | Un hook asigna la variación antes de montar la página | Sin parpadeo, funciona con JavaScript desactivado | La caché de página puede congelar una variación y servirla a todos |
La diferencia entre los dos modelos está detallada en la guía de test A/B client-side vs server-side. Para la mayoría de las tiendas WooCommerce, el camino client-side es el único que entra en producción en poco tiempo, y la próxima sección explica por qué.
Obstáculo 1: la caché de página
Este es el problema número uno, y es silencioso. Casi toda tienda WordPress seria corre con caché de página, sea por un plugin o por una CDN. La caché existe justamente para que PHP no se ejecute en cada visita: guarda el HTML generado una vez y devuelve ese mismo archivo a las siguientes personas.
Eso es excelente para el rendimiento y fatal para un test server-side ingenuo. Si tu código asigna la variación en PHP y la caché guarda la primera respuesta generada, todo el mundo empieza a recibir esa variación. El test sigue “corriendo” en el panel, y la división real del tráfico ya no es la que configuraste.
El test server-side correcto puede convivir con la caché: la clave de caché tiene que incluir la variación, o la decisión tiene que ocurrir en el edge, antes de que la caché responda. Eso es trabajo de infraestructura, descrito en la guía de implementación de test A/B en servidor. El error es correr el test sin tratar la caché y después confiar en el informe.
Elijas el camino que elijas, hay una comprobación obligatoria en el día uno: mira la división real de visitantes entre variaciones. Una división que debería ser 50/50 y aparece como 68/32 no es mala suerte, es un defecto de instrumentación, y el test entero sigue inválido hasta que se arregle. Esa comprobación tiene nombre, sample ratio mismatch, y está cubierta entre los errores más comunes en tests A/B.
Obstáculo 2: checkout en bloques vs checkout clásico
Según la documentación de WooCommerce, las tiendas iniciadas desde el lanzamiento de la versión 8.3, en noviembre de 2023, traen los bloques de Carrito y Checkout como experiencia por defecto, sin necesidad de configuración (WooCommerce, Cart and Checkout Blocks as Default). Las tiendas más antiguas normalmente siguen con el checkout clásico, montado por shortcode.
Para el test, la consecuencia es directa: las dos versiones generan HTML distinto. Un selector CSS escrito contra el checkout clásico simplemente no encuentra nada en el checkout en bloques, y el test corre sin aplicar nunca la variación, produciendo un empate perfecto que parece un resultado y es un defecto.
Antes de escribir cualquier variación, comprueba cuál de los dos usa tu tienda y escribe el selector contra la estructura real de la página. Si gestionas más de una tienda, no reutilices selectores entre ellas sin comprobar.
Obstáculo 3: conflictos de plugins y visitantes logueados
Dos particularidades de WordPress cierran la lista de trampas técnicas.
La primera es el conjunto de plugins. Una tienda WooCommerce típica corre decenas de ellos, y varios tocan el mismo lugar que toca tu test: optimizadores de checkout, plugins de campos personalizados, plugins de envío, plugins de popup. Cuando dos piezas de código alteran el mismo elemento, gana quien aplica último, y el resultado varía con el orden de carga. El síntoma es una variación que “a veces aparece”.
La segunda es el visitante logueado. Administradores, editores y clientes recurrentes logueados suelen ver el sitio con la barra de administración, con la caché desactivada y a veces con precios distintos. Incluir a ese público contamina los dos lados de forma despareja. La regla práctica es excluir del experimento a los usuarios logueados con roles administrativos, y decidir conscientemente si los clientes logueados entran o quedan fuera, documentando la elección.
La cuenta que define qué puedes testear
Aquí está la parte que resuelve la objeción más común de quien tiene tienda: “mi tienda es demasiado pequeña para testear”. Casi siempre la frase está equivocada, y lo que está mal es la etapa elegida para medir.
Considera una tienda con 6.000 visitas por semana y una tasa de conversión general del 1,8% (visita a pedido). Para detectar una ganancia relativa del 20% con 95% de confianza y 80% de poder, la muestra necesaria es de 23.507 visitas por variación, lo que lleva 55 días.
Cálculo por aproximación normal de dos proporciones, 2 variaciones (50/50). Cambia los campos y mira el impacto en vivo.
Configura la calculadora de arriba con tasa base 1,8, efecto mínimo detectable 20 (relativo) y 6.000 visitantes por semana para reproducir ese número. Casi dos meses es un plazo que la mayoría de las tiendas no va a aceptar, y ahí es donde el equipo o abandona o, peor, corta el test por la mitad.
Ahora cambia la etapa que mides. La misma tienda recibe 1.200 inicios de checkout por semana, y el 45% de ellos se convierten en pedidos. Testear un cambio dentro del checkout, midiendo la tasa de finalización desde el inicio del checkout, con una ganancia relativa del 10%, exige solo 1.931 visitantes por variación, lo que lleva 23 días.
Aproximación normal de dos proporciones, división igual entre las variaciones. La fecha usa tu zona horaria y recalcula en vivo.
| Diseño | Tasa base | Volumen que lo alimenta | Muestra por variación | Duración |
|---|---|---|---|---|
| Tienda entera, visita a pedido, ganancia del 20% | 1,8% | 6.000 visitas/semana | 23.507 | 55 días |
| Etapa de checkout, inicio a pedido, ganancia del 10% | 45% | 1.200 inicios/semana | 1.931 | 23 días |
La diferencia no es magia estadística, viene de dos cosas a la vez: las tasas base altas necesitan muestras mucho menores para la misma ganancia relativa, y el embudo filtra a las personas que ya mostraron intención. Testear dentro del checkout es el camino de menor coste de muestra en casi toda tienda pequeña y mediana.
El contrapeso honesto: medir la etapa no es lo mismo que medir el negocio. Un cambio que mejora la finalización del checkout puede, por ejemplo, subir la tasa y bajar el ticket medio si empuja a los clientes a terminar más rápido. Por eso el ingreso por visitante es siempre un guardrail, incluso cuando la métrica primaria es la etapa.
Un ejemplo trabajado que puedes reproducir
Supón que ese test de checkout corrió hasta los 1.931 visitantes por variación completos. El checkout clásico (control) cerró 869 pedidos, una tasa de finalización del 45,00%. La variación con menos campos cerró 949 pedidos, 49,15%.
Pasando esos cuatro números por el mismo motor de significancia que usa este blog: z = 2,579, valor p de alrededor de 0,0099, con un intervalo de confianza del 95% para la diferencia entre +1,00 y +7,29 puntos porcentuales, y una mejora relativa observada del +9,2%. El intervalo no cruza el cero, así que la ganancia es real.
Ese ancho es la lectura honesta de una muestra pequeña. Un test de 1.931 por variación responde “¿ayudó?” con confianza y responde “¿cuánto?” solo dentro de una banda ancha. Si tu decisión depende del tamaño de la ganancia y no solo de su signo, la guía de significancia estadística explica cómo leer el intervalo en lugar de la estimación puntual.
Qué métrica usar en cada etapa de la tienda
| Dónde vive el cambio | Métrica primaria | Guardrails |
|---|---|---|
| Home y páginas de categoría | Tasa de visita a la página de producto | Ingreso por visitante, tasa de salida |
| Página de producto | Tasa de agregado al carrito | Ingreso por visitante, tasa de devolución cuando esté disponible |
| Carrito | Tasa de inicio de checkout | Ticket medio, ingreso por visitante |
| Checkout | Tasa de finalización desde el inicio | Ingreso por visitante, tasa de error de pago |
| Precio, envío y promociones | Ingreso por visitante | Margen, ticket medio, tasa de conversión |
La regla detrás de la tabla: cuanto más cerca está la métrica primaria del cambio, más rápido cierra el test, y cuanto más lejos está del dinero, más imprescindible se vuelve el guardrail. La página de producto y el carrito reciben tratamiento detallado en la guía de test A/B de página de producto y en la guía de carrito abandonado.
Paso a paso para tu primer test
- Elige la etapa con la mayor pérdida absoluta. Suma cuánta gente se va en cada paso del embudo y ataca el paso que pierde más personas, no el que se ve más feo.
- Escribe la hipótesis antes de abrir la herramienta. Qué cambia, por qué, cuál es la métrica primaria, qué efecto mínimo justificaría implementarlo.
- Dimensiona antes de correr. Calcula muestra y duración con el tráfico real de esa etapa. Si la respuesta es más larga que tu ventana aceptable, cambia la ambición o la etapa, nunca el rigor.
- Instala la etiqueta y comprueba la división real. En el día uno, confirma que la distribución coincide con lo que configuraste. Comprueba también en móvil, y sin sesión iniciada, en una ventana privada.
- Déjalo correr en semanas completas. Las tiendas tienen una estacionalidad fuerte por día de la semana. Terminar a mitad de semana compara lunes contra sábado.
- Lee primero el intervalo de confianza. Una estimación puntual aislada se convierte en una promesa que el dato no puede cumplir.
- Implementa a la ganadora como corresponde, en el tema o en el plugin. Una variación servida por snippet es temporal; la ganancia permanente solo existe cuando pasa a ser código de la tienda.
Errores comunes de test A/B en WooCommerce
| Error | Señal de alerta | Arreglo |
|---|---|---|
| Ignorar la caché en un test server-side | División de tráfico lejos de lo configurado | Variar la clave de caché por variación, o ir a client-side |
| Escribir el selector para el checkout equivocado | Empate perfecto y una variación que nunca aparece | Comprobar antes si la tienda usa bloques o el shortcode clásico |
| Incluir administradores logueados | Pocas sesiones con comportamiento muy atípico | Excluir roles administrativos y documentar la decisión sobre clientes logueados |
| Medir solo la conversión de toda la tienda en una tienda chica | Tests que corren meses y se abandonan por la mitad | Medir la etapa, con ingreso por visitante como guardrail |
| Terminar a mitad de semana | Un resultado que cambia de signo según el día de lectura | Correr en bloques semanales completos |
| Testear durante una gran promoción | Comportamiento de compra completamente distinto | Evitar periodos atípicos o tratarlos como un test aparte |
| Correr tres tests en el mismo embudo a la vez | Resultados que no suman al implementarlos | Un test por etapa, o un diseño factorial declarado de antemano |
| Dejar la variación ganadora en el snippet para siempre | La ganancia depende de que la herramienta siga cargando | Implementarla en el tema o el plugin y quitar el test |
Haz esto automático con Donnu
La parte difícil de testear en una tienda WooCommerce casi nunca es la idea, es la operación alrededor: confirmar que la división de tráfico salió bien y leer el resultado sin convertir una estimación imprecisa en una promesa de ingresos. Donnu cubre exactamente ese tramo: pegas un snippet que no bloquea la carga de la tienda, defines la métrica, y Donnu sigue la división real de tráfico, te avisa cuando se desvía de lo configurado, y devuelve el veredicto con el intervalo de confianza del 95% por delante, sin declarar ganadora antes de que la variación acumule al menos 200 visitantes y 7 días en el aire.
Empieza una prueba gratis de 14 días y corre tu primer test en el paso que pierde más personas. Para el panorama completo, mira el playbook de optimización de checkout y la lista de herramientas de test A/B para WordPress.
Referencias
- WooCommerce. Cart and Checkout Blocks as Default. Documentación oficial. woocommerce.com/document/cart-checkout-blocks-status.
- WordPress.org. Página del plugin WooCommerce en el repositorio oficial. wordpress.org/plugins/woocommerce.
- Google Search Central. A/B testing best practices for Search. developers.google.com/search/docs/crawling-indexing/website-testing.
- Kohavi, R., Tang, D. y Xu, Y. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. Cambridge University Press, 2020. Material de apoyo en experimentguide.com.
Lee también:
Preguntas frecuentes
- ¿WooCommerce trae test A/B integrado?
- No. WooCommerce es un plugin de ecommerce para WordPress y no incluye ningún motor de experimentación, así que el test siempre viene de fuera: un snippet client-side que intercambia contenido en el navegador, o una implementación server-side en PHP que asigna la variación antes de construir la página. Cada camino tiene su propia trampa en una instalación WordPress, y la mayor de lejos es la caché de página.
- ¿Por qué la caché de página rompe los tests A/B en WooCommerce?
- Porque la mayoría de las tiendas WordPress sirven HTML pregenerado desde un plugin de caché o una CDN, así que un test server-side que elige la variación en PHP puede tener esa respuesta congelada y entregada a todo el mundo. El síntoma clásico es una división de tráfico muy lejos del 50/50 que configuraste. Los tests client-side no sufren esto, porque el HTML es idéntico para todos y el intercambio ocurre después, en el navegador.
- ¿Puedo testear la página de checkout de WooCommerce?
- Sí, pero el objetivo del selector depende de qué checkout corre tu tienda. Según la documentación de WooCommerce, las tiendas creadas desde la versión 8.3 en adelante, publicada en noviembre de 2023, traen los bloques de Carrito y Checkout como experiencia por defecto, mientras que las tiendas más antiguas normalmente siguen con el checkout clásico por shortcode. Los dos producen HTML distinto, así que un selector escrito para uno simplemente no encuentra nada en el otro.
- Mi tienda tiene poco tráfico. ¿Igual puedo testear?
- Depende de qué etapa elijas medir. La conversión de toda la tienda tiene una tasa base baja y necesita una muestra grande: en el ejemplo trabajado de más abajo, detectar una ganancia relativa del 20% sobre una base del 1,8% lleva 55 días con 6.000 visitas por semana. Testear dentro del checkout, donde la tasa base es mucho más alta, cierra en 23 días con solo 1.200 inicios de checkout por semana. Cambiar la etapa que mides cambia la viabilidad sin renunciar a nada de rigor.
- ¿Qué métrica debería usar una tienda WooCommerce en un test?
- La métrica primaria tiene que estar lo más cerca posible de lo que la mudanza realmente altera, y el ingreso por visitante siempre debe estar entre los guardrails. Un cambio en la página de producto pide tasa de agregado al carrito como primaria; un cambio en el checkout pide tasa de finalización de pedido desde el inicio del checkout. En ninguno de los dos casos se puede dejar fuera el ingreso por visitante, porque es la métrica que expone una ganancia de volumen comprada con un ticket menor.
- ¿Necesito un plugin para correr tests A/B en WooCommerce?
- No necesariamente. Las herramientas basadas en snippet funcionan pegando una etiqueta en el header del sitio, lo que se puede hacer con un plugin de inserción de código, con el tema o con tu gestor de etiquetas. Un plugin dedicado facilita la instalación pero suma un elemento más al conjunto de plugins de la tienda, y el conflicto entre plugins es una de las causas más comunes de comportamiento extraño en una instalación WordPress.