Pruebas A/B en WordPress enterprise, dimensionadas al tráfico que realmente tenés

Más del que tienen la mayoría de las páginas B2B enterprise. La cifra se desprende de dos datos: tu tasa de conversión actual y el tamaño de la mejora que querés poder detectar. Cuanto más chica es la mejora, más tráfico hace falta para llegar a verla.

Por eso partimos de tus números y no de una regla general. Una calculadora pública de significancia te da la aritmética en un minuto, y por lo general baja expectativas. Si una página no llega, tenés que enterarte antes de comprar una licencia de testing, no después.

Esos datos salen de tu analítica, y por eso la medición se verifica antes de diseñar cualquier experimento.

En un sitio que corre Gutenberg: bloques individuales, secciones completas, landing pages enteras, titulares, imágenes, llamados a la acción, formularios, menús y widgets.

• Los tests a nivel de bloque son los más baratos de correr y los más fáciles de atribuir.
• Los tests a nivel de página responden preguntas más grandes y necesitan proporcionalmente más tráfico.
• Los tests de menú y navegación tocan todas las páginas, así que necesitan una ventana más larga y un monitoreo más de cerca.

Una variable por test, siempre. Si cambiás dos cosas a la vez, una victoria no te dice cuál de las dos la produjo.

Un poco, y conviene ser deliberado al respecto. Toda herramienta de testing carga script de tracking en el frontend, y ese costo cae sobre cada visitante mientras que el beneficio cae solo sobre la variante ganadora.

Hay dos cosas para vigilar. El peso del script en la ruta crítica de renderizado, que aparece directo en los Core Web Vitals. Y el caché de página completa sirviéndole una variante cacheada a un visitante que había sido asignado a la otra, que no rompe la página: corrompe el resultado. Las dos se resuelven durante la configuración, junto con el resto del trabajo de nuestra página de optimización de velocidad.

Genera la misma obligación que cualquier otro tracking. Los experimentos asignan visitantes a variantes y registran lo que hacen, así que donde aplica el GDPR la herramienta va detrás de tu banner de consentimiento de cookies, no al lado.

La consecuencia práctica es que solo medís tráfico con consentimiento, lo que achica tu muestra efectiva y alarga el test. Eso es una razón para preverlo al dimensionar el experimento, no para saltearse el paso del consentimiento.

No, si las variantes se manejan bien. La guía de Google sobre esto viene estable desde hace años:

• Apuntá el canonical a la URL que querés que se indexe.
• Usá una redirección temporal, no permanente, para los tests de redirección.
• Mostrale a los crawlers lo mismo que a los visitantes.
• Bajá el test una vez que terminó.

El modo de falla real es operativo antes que técnico. Un test que quedó corriendo un año, hasta que ya nadie se acuerda de haberlo configurado, se convirtió silenciosamente en cloaking permanente.