De cero a cien experimentos: cómo escala de verdad un programa

La idea sencilla de cómo crece un programa de experimentación es que lanzas más tests. Es una idea equivocada, porque lo que te frena cambia a medida que creces, y cada etapa se rompe por un motivo distinto.

Al principio el límite es el tráfico. Solo puedes medir una cosa cada vez, y cada test tarda de tres a seis semanas.

Así que elegir bien es casi todo el trabajo, porque cada test es más o menos una décima parte de lo que vas a aprender ese año. Todo lo que hemos escrito sobre priorizar vale aquí, y el error más común es gastar esos huecos en tests cosméticos cuyo efecto nunca se habría podido detectar.

Apetece esquivar el problema del tráfico lanzando varios tests en paralelo. Con poco tráfico, así es como acabas con cuatro resultados que no concluyen nada donde podrías haber tenido dos respuestas.

Por esta zona el tráfico ya aguanta dos o tres experimentos simultáneos, y aparece otro problema: empiezan a interferir entre sí.

Aquí es donde los grupos de exclusión se ganan el sueldo. Organízalos por fase del funnel (descubrimiento, ficha de producto, carrito, checkout), haz que los experimentos de un mismo grupo sean mutuamente excluyentes y deja que los de grupos distintos se solapen. Con eso cubres casi todo el riesgo real de interferencia sin frenar el ritmo.

En esta etapa se rompe otra cosa que nadie ve venir: la gente olvida qué hay activo. Necesitas una única lista de experimentos en marcha, cada uno con responsable, hipótesis, métrica y fecha de fin. Una hoja de cálculo sirve perfectamente, pero tiene que existir.

Pasados unos cuarenta experimentos, el tráfico deja de ser el límite principal. Su sitio lo ocupa la comprensión.

Para entonces hay veinte ganadores publicados que modifican la web de forma permanente. Algunos iban segmentados, así que distintos visitantes ven cosas distintas. La mitad se lanzaron antes de que llegara nadie del equipo actual. Cuando algo hace cosas raras, averiguar por qué lleva un día entero.

Aquí es donde los programas se mueren sin hacer ruido. La gente deja de testear en ciertas zonas porque no entiende lo que ya hay, quien se incorpora tarda un trimestre en ser útil y los resultados son cada vez más extraños, porque cada test se apoya en unos cimientos que ya nadie sabe describir.

Lo que lo arregla es trabajo poco vistoso. Lleva un registro de modificaciones activas: qué se cambió, para quién, qué experimento lo justificó y qué métrica movió. Revísalo cada trimestre y apaga lo que no tenga justificación.

Publica los ganadores como código en lugar de dejarlos como experimentos permanentes. Un experimento al 100% es una modificación escondida dentro de tu herramienta de testing; cuando algo gana, debe pasar a formar parte de la web y el experimento debe cerrarse.

Y mantén un documento de aprendizajes separado de los resultados, hecho de las frases que ahora sabes sobre tus clientes y no del desenlace de cada test. Ese documento es lo que pone al día rápido a una persona nueva.

Se suele invertir de más en proceso. Un programa que lanza cuatro tests al mes no necesita un formulario de entrada, un comité que puntúe ideas y una reunión semanal de revisión. Necesita una lista priorizada y una persona que se haga cargo de ella.

Y en herramienta. Casi todas las funciones avanzadas de las plataformas enterprise existen para organizaciones donde decenas de equipos tocan la misma web. Si sois un solo equipo, necesitáis segmentación, asignación, estadística y una forma de montar variantes sin depender de un desarrollador; lo demás está hecho para una empresa que no es la tuya.

Para una marca con un tráfico modesto, de diez a quince experimentos bien hechos al año es un buen programa, y es sencillamente lo que da de sí tu muestra. Con el tiempo no se acumula el número. Lo que se acumula es que el experimento quince apunte mejor que el primero, y eso depende mucho más del documento de aprendizajes que de cuántos tests saques adelante, así que empieza ese documento con el próximo resultado que tengas.