Test A/B en WooCommerce: cuándo basta un plugin y cuándo no

En WooCommerce, un plugin de test A/B basta cuando lo que quieres probar son páginas, entradas o productos que editas desde WordPress y tu web no depende de una caché agresiva. Deja de bastar cuando quieres probar el carrito o el checkout, cuando la tienda solo va rápida gracias a WP Rocket o LiteSpeed Cache, o cuando quieres enseñar una variante solo a una campaña o solo en móvil. Ahí funciona mejor una herramienta que se instala con un script. Te contamos cómo lo decidimos nosotros, con los fallos que más vemos.

WordPress tiene plugin para casi todo, y para test A/B también. El más conocido es Nelio A/B Testing, que lleva años en el repositorio oficial. La idea general de estos plugins es buena: creas una versión alternativa de una página, una entrada, un producto o un título desde el propio escritorio de WordPress, eliges un objetivo y el plugin reparte las visitas.

Lo que tienen a favor:

• Todo vive en WordPress. No hay otra cuenta ni otro panel. Editas la variante con el editor de bloques o con el maquetador que ya usas (Elementor, Divi).
• Entienden el contenido de WordPress. Saben qué es una entrada, un producto o un menú, y eso facilita probar cosas como dos descripciones de un mismo producto.
• Instalar es instalar un plugin. Si sabes instalar uno, sabes instalar este.

Y lo que conviene mirar antes:

• Un plugin más. Cada plugin suma consultas, scripts y opciones de conflicto. En una tienda con 40 plugins, el siguiente es el que rompe algo en una actualización.
• Qué cubre del checkout. Probar una página es fácil. Probar el carrito o el checkout de WooCommerce, que se rellenan con datos de la sesión y en las versiones recientes son bloques que se pintan con JavaScript, es otra historia. Comprueba qué cubre exactamente el plugin antes de contar con ello.
• Precio. Muchos de estos plugins tienen una versión gratuita limitada y planes de pago según visitas. Míralo en su web, porque cambia a menudo.

La alternativa es una herramienta externa que se instala pegando un script en el <head> de la web: a mano en el tema hijo, con un plugin de "insertar código en cabecera" o desde Google Tag Manager. La herramienta no toca WordPress. Aplica los cambios en el navegador del visitante, sobre la página que WooCommerce ya ha generado.

Es lo que hacemos con Bixlow. A favor:

• Cualquier parte de la página. Ficha, carrito, checkout, mini carrito, cabecera. Si se ve en el navegador, se puede cambiar.
• No depende de tu versión de WordPress ni del maquetador. Una actualización de Elementor no rompe tus tests.
• Segmentar sale solo. Puedes enseñar una variante solo a quien llega de una campaña de Instagram, solo en móvil o solo a quien ya había visitado la tienda.

En contra: es otra herramienta y otra cuenta, y los cambios que hagas ahí no son contenido de WordPress. Si una variante gana, alguien tiene que pasar el cambio al tema o dejarlo servido desde la herramienta.

Aquí se atascan la mayoría de tiendas, y es la razón principal por la que en WooCommerce solemos recomendar el script.

Una tienda WooCommerce sin caché va lenta, así que casi todas usan WP Rocket, LiteSpeed Cache, W3 Total Cache o la caché del hosting. Estas herramientas guardan la página ya generada y se la sirven igual a todo el mundo. Si el test decide la variante en el servidor, en PHP, la caché guarda la primera versión que se generó y se la da a todos. El test deja de ser un test.

Los plugins serios lo saben y asignan la variante con JavaScript, o te piden excluir páginas de la caché. Conviene comprobarlo con el que elijas. Una herramienta por script no tiene ese problema: la página cacheada es la misma para todos y la variante se decide en el navegador.

Aun así, hay tres ajustes de las herramientas de caché que afectan a cualquier script de testing:

1. Retrasar la ejecución de JavaScript. WP Rocket tiene una opción para retrasar los scripts hasta que el usuario interactúa (mover el ratón, hacer scroll, tocar la pantalla). LiteSpeed Cache tiene algo parecido. Si el script de testing queda retrasado, la variante no se aplica hasta que el visitante toca la página y el cambio se ve tarde. Añade el script a las exclusiones.
2. Combinar y minificar JS. Si la caché junta todos los scripts en un solo fichero, puede cambiar el orden o romperlo. Exclúyelo también de la combinación.
3. Cargar el JS en diferido. Aplazar todo el JavaScript es bueno para la velocidad, pero el script de testing tiene que cargar arriba y cuanto antes. Exclúyelo.

Después vacía la caché del plugin, la del hosting y la de Cloudflare si la usas, y compruébalo en una ventana de incógnito.

Cuando se completa un pedido en WooCommerce, el cliente llega al endpoint order-received de la página de pago. En una instalación en español suele verse como /finalizar-compra/order-received/1234/?key=.... Esa URL es el mejor objetivo para un test en la tienda.

Si cobras con Redsys (tarjeta y muchas veces Bizum) o con PayPal, el cliente paga fuera y vuelve a esa página. Quien cierra la pestaña en la pasarela no vuelve y no se cuenta, igual en las dos variantes. Y si ya tienes un plugin que manda el evento purchase al dataLayer para GA4, puedes usarlo como objetivo.

Nuestra regla es sencilla. Si todo lo que vas a probar son páginas de contenido y quieres tenerlo todo dentro de WordPress, prueba un plugin. Si lo que quieres probar es la tienda (ficha, carrito, checkout, envío), usa un script.

Las dudas son las de cualquier tienda española, con algún detalle propio de WooCommerce:

• Coste de envío en la ficha. WooCommerce no lo enseña ahí por defecto, solo en el carrito. Poner "Envío 4,95 €, gratis a partir de 50 €" junto al precio responde la duda antes de que el cliente tenga que buscarla.
• El umbral en el carrito. "Te faltan 12 € para el envío gratis" en el carrito y en el mini carrito.
• Métodos de pago antes del checkout. Iconos de Bizum, tarjeta y PayPal bajo el botón de añadir al carrito.
• Campos del checkout. El checkout por defecto pide bastante (empresa, segunda línea de dirección). Ocultar lo opcional o marcarlo bien es un test fácil.
• Compra como invitado. Si obligas a crear cuenta, prueba a no exigirlo o a ofrecerlo después del pago.

Antes de publicar cualquiera, haz un pedido de prueba completo con cada variante y desde el móvil. El checkout de bloques repinta secciones cuando cambias de método de envío, y ahí es donde salen los fallos.

Para saber cuánto vas a tardar en tener respuesta, la calculadora de tamaño de muestra te da una idea con tus visitas y tu conversión. En Bixlow, el agente propone la hipótesis y monta la variante sobre la tienda real, tú la revisas en la previsualización y nada se publica sin tu aprobación. El veredicto lo da la estadística bayesiana: no hay ganadora hasta que una variante tiene al menos un 95 % de probabilidad de ser la mejor y se cumplen una muestra y una duración mínimas. Si además quieres que una variante solo la vea un tipo de visitante, eso se configura con audiencias.

¿Bixlow tiene plugin de WordPress? No. Se instala con un script en el head o con Google Tag Manager, igual que en cualquier otra web.

¿Puedo usar un plugin y un script a la vez? Puedes, pero no pruebes lo mismo con los dos ni en la misma página a la vez. Dos tests que tocan lo mismo se contaminan entre sí.

¿Un test afecta al SEO? Un test corto que cambia textos o elementos en el navegador no suele dar problemas. No le enseñes a Google algo distinto de lo que ven tus clientes y no dejes tests olvidados durante meses.

¿Y si uso Cloudflare delante de WordPress? Funciona como cualquier caché de página: el script se sirve a todos y la variante se decide en el navegador. Purga después de instalarlo.