MAISON CODE .
/ Growth · AB Testing · Edge · Performance · Statistics · Vercel

Pruebas A/B en el borde: sin parpadeo, sin cambios de diseño

Por qué las pruebas A/B 'useEffect' perjudican tu SEO y UX. Cómo implementar experimentos del lado del servidor utilizando Middleware y Cookies. Ingeniería de crecimiento sin parpadeos.

AB
Alex B.
Pruebas A/B en el borde: sin parpadeo, sin cambios de diseño

Las herramientas de prueba A/B tradicionales (Optimize, VWO) funcionan inyectando JavaScript.

  1. El navegador carga la página A.
  2. JS se ejecuta, verifica la cookie.
  3. JS reescribe DOM en la “Página B”. Esto provoca FOOC (Flash of Original Content). El usuario ve el título anterior durante 0,5 segundos y luego pasa al nuevo. Destruye tus Core Web Vitals (CLS) y reduce la confianza. ¿La solución? Middleware de borde.

Por qué Maison Code habla de esto

En Maison Code Paris, actuamos como la conciencia arquitectónica de nuestros clientes. A menudo heredamos stacks “modernos” construidos sin una comprensión fundamental de la escala.

Discutimos este tema porque representa un punto de inflexión crítico en la madurez de la ingeniería. Implementarlo correctamente diferencia un MVP frágil de una plataforma resistente de nivel empresarial.

Por qué Maison Code prueba en el borde

Nos negamos a comprometer el rendimiento por los datos. El marketing quiere experimentos. La ingeniería quiere velocidad. Edge Testing ofrece ambas cosas. Ejecutamos la lógica en servidores Cloudflare/Vercel (The Edge), a 5ms del usuario. El HTML llega pre-renderizado. El usuario nunca ve el interruptor. Ésta es la única forma de realizar pruebas en un sitio de lujo.

1. La Arquitectura

Movemos la lógica al CDN (Vercel Edge/Cloudflare Workers). La decisión ocurre antes de que se genere el HTML.

  1. Solicitud: el usuario presiona /.
  2. Edge: comprueba la cookie experiment-id.
  3. Borde: Si falta, tira los dados (50/50). Establece galletas.
  4. Edge: Reescribe la respuesta (lado del servidor).
  5. Navegador: Recibe el HTML específico para la Variante B únicamente. CLS cero. Cero parpadeo.

2. Implementación en Next.js/Middleware

Usamos el archivo middleware.ts para interceptar la solicitud.

// middleware.ts
importar {NextResponse} desde 'siguiente/servidor';
importar { getBucket } desde '@lib/ab-testing';

middleware de función de exportación (solicitud: Solicitud) {
  const COOKIE_NAME = 'prueba-ab-hero';
  let cubo = request.cookies.get(NOMBRE_COOKIE)?.valor;

  // Si no hay depósito, asigna uno
  si (! cubo) {
    cubo = Math.random() <0,5? 'control': 'variante';
  }

  // Reescribe la URL internamente (invisible para el usuario)
  url constante = request.nextUrl.clone();
  if (depósito === 'variante') {
    url.nombreruta = '/variantes/b';
  } más {
    url.nombreruta = '/variantes/a';
  }

  respuesta constante = NextResponse.rewrite(url);
  
  // Establece la galleta adhesiva
  respuesta.cookies.set(NOMBRE_COOKIE, depósito);
  respuesta de devolución;
}

3. Importancia estadística (las matemáticas)

No se limite a realizar una prueba durante 2 días. Necesitas Poder estadístico. Si tiene 100 visitantes y 5 conversiones (5%) frente a 7 conversiones (7%), eso es ruido. Utilice una calculadora bayesiana. Normalmente requerimos:

  • Muestra mínima: 1000 visitantes por variante.
  • Duración: 2 ciclos comerciales completos (2 semanas). El problema de mirar a escondidas: No detengas la prueba en el momento en que se vea verde. Esto es “P-hacking”. Comprométete con la duración antes de comenzar.

4. El Impacto SEO (Seguridad de Google)

Google odia el contenido duplicado. Si tiene / y /variant-b, use etiquetas canonical. Apunte ambas versiones válidas a la URL canónica /. O, dado que estamos haciendo Edge Rewrites, la URL permanece / para el usuario. GoogleBot normalmente verá el Control (a menos que persista en las cookies). Advertencia: No “encubrimiento” (muestre a Google una cosa y a los usuarios otra). Google comprueba el JS renderizado. Las pruebas perimetrales son más seguras porque brindan respuestas distintas del servidor.

5. Indicadores de funciones frente a pruebas A/B

  • Marca de función: “Activa el nuevo pago para que el 10% de los usuarios prueben si hay errores”. (Seguridad).
  • Prueba A/B: “Muestre un botón rojo frente a un botón azul para probar la conversión”. (Crecimiento). Usamos herramientas como LaunchDarkly o Statsig para administrar ambos. Comparten la misma lógica subyacente (representación condicional), pero la intención es diferente. Los indicadores de funciones son para ingeniería. Las pruebas A/B son para el producto.

6. El análisis de parpadeo (costo de UX)

Si utiliza pruebas A/B del lado del cliente… Y tu parpadeo es de 500ms… Pierdes el 10% de los usuarios incluso antes de que vean la variante. Tus datos están corruptos. Estás probando “Control vs (Variante + Retraso)”. No estás probando “Control vs Variante”. Las pruebas de borde eliminan la variable Delay. Es la única manera científica de probarlo.

7. El grupo resistente

Si realizas 10 experimentos a la vez… ¿cómo sabes el impacto total? Cree un Grupo de resistencia global. El 5% de los usuarios nunca ve ningún experimento. Compare el grupo “Todos los experimentos” con el grupo “Holdout” después de 6 meses. Esto demuestra el valor a largo plazo de su programa CRO.

9. Las métricas que importan (más allá de la tasa de clics)

No se limite a medir los “clics”. Esta es una métrica de vanidad. Medida Ingresos por Visitante (RPV). La variante A puede tener menos clics, pero un AOV (valor promedio de pedido) más alto. Si optimiza para clics, es posible que esté creando “Clickbait”. Realizamos un seguimiento:

  1. Tasa de conversión: ¿Compraron?
  2. AOV: ¿Cuánto gastaron?
  3. RPV: Valor combinado.
  4. Retención: ¿Volvieron?

10. La prueba segmentada (personalización)

Las pruebas A/B en “Todos los usuarios” son contundentes. Pruebe en Segmentos.

  • Prueba A: Mostrar “Envío gratuito” a los VIP que regresan.
  • Prueba B: muestra “10 % de descuento” a los nuevos visitantes. Diferentes cohortes se comportan de manera diferente. Utilice Edge Middleware para detectar el segmento (a través de Cookie o Geo) y realizar la prueba adecuada. El “talla única” está muerto.

11. Pruebas A/B/n (multivariadas)

¿Por qué probar solo A versus B? Prueba A vs B vs C vs D. El algoritmo del bandido: En lugar de una división fija 50/50… El algoritmo dirige dinámicamente el tráfico a la variante ganadora mientras se ejecuta la prueba. Si la versión C gana, envíe el 80% del tráfico a C. Esto maximiza los ingresos durante la prueba. Esto es Aprendizaje automático en el borde.

12. El conflicto de consentimiento de cookies (GDPR)

“¿Podemos probar si rechazan las cookies?” No. Si un usuario rechaza el seguimiento, no puede asignarle una identificación persistente. Estrategia:

  1. Modo estricto: Si no hay consentimiento, muestra Control. No realizar seguimiento.
  2. Modo de sesión: utilice una cookie de solo sesión (se borra al cerrar). Esto es legalmente gris pero más seguro.
  3. Modo anónimo: agrupación basada en el ID de solicitud (aleatorio). Sin antecedentes persistentes. Por defecto usamos Privacidad. Si dicen que no, ven el sitio predeterminado. Respete al usuario primero, optimice los ingresos en segundo lugar.

13. La integración de análisis (GA4 / Mixpanel)

The Edge decide la variante. Pero GA4 necesita saberlo. Inyectamos la decisión en el objeto “ventana”.

ventana.ab_test = {
  experiment_id: 'prueba_héroe',
  variante: 'B'
};

Luego, GTM (Google Tag Manager) lo recoge y lo envía como “Propiedad de usuario”. Esto le permite dividir sus informes GA4 por variante. “Muéstrame la tasa de retención de la variante B”. Sin este enlace, sus datos son ciegos.

14. La estrategia de prueba de precios (ingresos peligrosos)

Probar los precios es peligroso. Si los usuarios se enteran, se enojan. La prueba de “descuento”: Prueba A: Precio estándar (€100). Prueba B: “Oferta por tiempo limitado: \€90”. Esto es seguro. La prueba “Premium”: Prueba A: Precio estándar (€100). Prueba B: Embalaje Premium incluido (€120). Pruebe las propuestas de valor, no sólo los precios. Si prueba el precio bruto (\€100 frente a \€110) para exactamente el mismo artículo, corre el riesgo de sufrir una pesadilla de relaciones públicas.

15. La primera prueba del móvil (zona del pulgar)

La mayoría de las pruebas A/B fallan en dispositivos móviles porque están diseñadas para computadoras de escritorio. La “Zona del Pulgar”: En dispositivos móviles, se debe poder acceder a la CTA con un pulgar. Prueba A: Botón adhesivo estándar. Prueba B: “Botón de acción flotante” (FAB) en la parte inferior derecha. A menudo vemos una conversión de +15% con solo mover el botón 50 píxeles hacia abajo. Pruebe la ergonomía física, no sólo los colores.

16. Conclusión

Las pruebas A/B son el método científico aplicado a los ingresos. Pero si tu “Ciencia” rompe la experiencia del usuario (Flicker), invalidas los resultados. Prueba en el borde. Mantenga la velocidad. Respeta las matemáticas. El crecimiento es un juego de centímetros, no de millas.

17. La advertencia de parpadeo final

Si tomas una cosa de este artículo: No aceptes Flicker. El parpadeo no es sólo “feo”. Es corrupción de datos. Sesga su prueba hacia los usuarios con Internet rápido (que ven menos parpadeo). Tiene un prejuicio contra los usuarios de dispositivos móviles. Invalida toda tu hipótesis. Muévete al borde. O no realizar ninguna prueba.

¿Adivinas qué funciona?

Implementamos canales de experimentación Edge sin parpadeos.

Configurar pila de crecimiento. Contrate a nuestros arquitectos.