Lanzar un experimento roto es peor que no lanzar ninguno. Contamina los datos, confunde a quien visita la página y, a veces, rompe la propia página. Revisarlo bien antes de activar tráfico no es opcional.
Este es el proceso que sigo siempre, independientemente de la herramienta.
Primero lo básico: ¿la variante aparece de verdad?
Parece obvio. No siempre lo es. Una variante puede verse perfectamente en el modo preview y fallar en producción por un problema de timing, un conflicto de CSS o un selector que dejó de existir.
Siempre hago QA dentro de una sesión real del navegador, no solo en el panel de previsualización. Cargo la URL pública, confirmo que aparece la variante y abro la consola. Si el experimento introduce errores nuevos, paro y los investigo.
Revisa cada dispositivo y breakpoint
La mayoría de los tests afectan a desktop y móvil. Algo que funciona a 1440 px puede quedar completamente roto a 375 px. Reviso ambos. Si el test solo está dirigido a desktop, también compruebo la exclusión: en móvil debe aparecer el control, sin efectos secundarios.
También pruebo los navegadores más usados por la audiencia. GA4 te dirá cuáles son. Como mínimo, reviso Chrome, Safari y Firefox.
Autoriza las IP del equipo para mostrar la variante
Este paso suele desaparecer cuando hay prisa. En lugar de repartir enlaces de preview que caducan o requieren acceso a la herramienta, añado las IP del equipo a las condiciones de segmentación. Así pueden visitar la URL real y ver la variante correcta sin exponerla al resto del tráfico.
La ventaja es importante: el equipo prueba la página real, no una versión aislada dentro de un entorno de previsualización.
Cómo hacerlo en Adobe Target
Abre la actividad, entra en la audiencia de la variante y añade una regla dentro de la categoría “Network”. Selecciona “IP Address” e incorpora cada dirección como condición. Puedes combinar varias con el operador “OR”. Guarda la audiencia y las visitas desde esas IP entrarán automáticamente en la variante.
Si el equipo trabaja desde distintas ubicaciones o utiliza VPN, pide la IP actual antes de configurarlo. Pueden comprobarla rápidamente en whatismyip.com.
Cómo hacerlo en Monetate
En Monetate, la segmentación se configura mediante reglas a nivel de experiencia. Abre la experiencia, entra en targeting y añade una condición con el atributo “IP Address”. Puedes introducir direcciones individuales o rangos CIDR si el equipo utiliza un bloque de red estable. Configura la regla para que acepte cualquiera de las IP y guarda.
Comprueba cómo se combina esa regla con el resto de condiciones. Con lógica AND, la IP tendrá que cumplir también todos los demás criterios. Si quieres que el equipo pueda saltarse el targeting normal, suele ser más claro crear una experiencia de QA separada que solo se active para esas IP.
Comprueba que los eventos llegan a Analytics
El test puede verse perfecto y estar recogiendo datos inútiles. Abro la pestaña Network del navegador o GA4 DebugView y compruebo que el evento de exposición se envía cuando se muestra la variante. También pruebo cada interacción ligada a los objetivos.
Si utilizas eventos personalizados, revisa que nombre, parámetros y valores coincidan exactamente con la configuración de GA4. Una errata en el nombre basta para pasar una semana analizando datos que nunca existieron.
Prueba también el control
Es fácil olvidarlo. El control debería verse exactamente igual que antes del experimento. El CSS o JavaScript inyectado a nivel de actividad puede afectarlo aunque no pretendas cambiar nada visual. Siempre abro una sesión asignada al control y confirmo que sigue intacto.
Busca flicker
El flicker ocurre cuando la página muestra durante un instante el estado original antes de renderizar la variante. La persona ve un destello del contenido anterior y luego el cambio. Además de ser una mala experiencia, puede sesgar el resultado: quien nota el salto podría comportarse de otra forma.
Para detectarlo, limito la conexión a Slow 3G desde Chrome DevTools y recargo. Si alcanzo a ver la versión original, aunque sea una fracción de segundo, ajusto la implementación. La solución suele estar en cargar antes el script del experimento o configurar correctamente el snippet anti-flicker de la plataforma.
Pide una segunda revisión
Tengo la costumbre de pedir a otra persona que revise el test antes de lanzarlo, preferiblemente alguien que no lo haya construido. Hará clic donde tú no pensaste hacerlo, lo abrirá en otro dispositivo y encontrará aquello que ya no ves por llevar demasiado tiempo dentro de la implementación.
Con las IP autorizadas, el proceso es sencillo: envías la URL pública y esa persona confirma exactamente lo que aparece.
La última comprobación antes de activar
Antes de abrir el tráfico, recorro una vez más esta lista:
La variante aparece correctamente en producción.
El test no introduce errores en la consola.
Desktop y móvil están verificados.
Los eventos de analítica se envían con los valores correctos.
El control no ha cambiado.
No hay flicker visible con una conexión lenta.
Al menos otra persona ha comprobado la variante.
Son unos quince minutos. Me han evitado publicar experimentos rotos más veces de las que me gustaría admitir.
