Requisitos para ejecutar programas de experimentación serios

Ejecutar programas de experimentación es un arte y una ciencia. Lo digo todo el tiempo. Los programas deben tener cierto nivel de rigor, es decir, sistemas, procesos y procedimientos. No es algo para tomar a la ligera. Creer que cualquier persona puede comenzar un programa mañana con una preparación y planificación mínimas es un error. Desafortunadamente, sin embargo, eso sucede todo el tiempo. Conduce a una gran cantidad de dinero, tiempo y esfuerzo desperdiciados, como era de esperar. Esto me lleva al tema de la preparación.

Si quiere tomarse en serio la experimentación y aumentar su nivel de competitividad en el mercado, es mejor que lo haga bien. Debe asumir que sus competidores lo están haciendo bien. Entonces, si esto resuena contigo, continúa leyendo y te garantizo que recogerás una o dos pepitas de oro para usar de inmediato.

El precursor inevitable para construir un programa de experimentación que lo haga o lo deshaga: Cálculos previos a la prueba

Cálculos previos a la prueba. ¿Alguna vez has oído hablar de ellos? ¿Los has hecho? ¿El MDE o el efecto mínimo detectable le suena familiar? ¿Qué hay de las estimaciones de duración o los tamaños de muestra? Espero que sepan de lo que estoy hablando, aunque apuesto dinero a que la gran mayoría de ustedes no lo saben, simplemente por mi propia experiencia personal con los clientes.

Antes de hacer algo relacionado con la experimentación, compruebe si tiene suficiente volumen de datos para hacerlo. Vea si puede probar algo a través de los cálculos previos a la prueba. Por volumen de datos, me refiero a visitantes y conversiones. Los visitantes pueden ser cualquier cosa que utilice habitualmente (p. ej., sesiones, usuarios, MAU, etc.). Las conversiones provienen de la métrica principal que utilizará en sus pruebas. Sepa esto:

1. No todas las empresas tienen suficiente volumen de datos para experimentar en cualquier capacidad.
2. Si puede hacerlo, sepa que no solo elige la velocidad deseada de la nada. Se basa en cálculos.

El culpable número 1 por ignorar uno o ambos puntos: el personal de ventas. Si está pensando en comprar cualquier tipo de herramienta, asegúrese de que esto sea parte de la conversación. La barrera de entrada mínima para tener un programa de experimentación: suficiente volumen de datos para ejecutar una prueba dentro de ocho semanas o menos en un carril.

Cubrí este tema en detalle hace unos meses para Experiment Nation. Sepa que si no entiende este tema y lo hace desde el primer día, lo perseguirá y definitivamente causará resultados no deseados de algún tipo eventualmente. Otra nota muy importante: sepa si su herramienta de prueba (o la que planea usar) se basa en pruebas de horizonte fijo o pruebas secuenciales. Esto afecta los cálculos y cómo ejecuta su programa.

Paso 1 (posprecursor): medición y calidad de los datos

Si superó el obstáculo de los cálculos previos a la prueba y confirmó que tiene suficiente volumen de datos para probar, el siguiente obstáculo para avanzar es la medición y la calidad de los datos. Debes saber lo que estás buscando en este trabajo; de lo contrario, te hundirás como un pez en la orilla de un río. Demasiados equipos no saben para qué están trabajando, como envíos de formularios, transacciones, ingresos, LTV, etc.

Comprenda cuáles son sus métricas primarias, secundarias y terciarias para la experimentación y el negocio en general. Entiéndelo con total claridad. No permita que persista la confusión o la incertidumbre. Asegúrate de que todos estén en la misma página.

Luego, una vez que tenga tanto, asegúrese de recopilar esos datos en los lugares correctos y de que puede confiar en ellos.

Si la medición y/o la calidad de los datos son un desastre, simplemente deténgase. Detén todo y dedica todos tus esfuerzos a hacerlo bien. Piense en la experimentación como una pirámide. Estas dos cosas son las capas fundamentales de la pirámide. Si se agrieta en algún momento, todo lo demás se derrumbará encima. Prometo.

Diré que sé que esto puede ser difícil. Hacerlos bien puede llevar más tiempo. Tal vez incluso más de un mes o dos. Sin embargo, hacerlo bien vale la pena. He visto problemas que surgen seis meses o más después de lanzar un programa, solo para que todo finalmente se detenga. Nadie es feliz en ese punto.

Una nota sobre lo que debería ser una métrica principal...

Este es un tema divisivo entre los practicantes a veces. Tengo una postura muy firme al respecto, específicamente cuando se trata de equipos de marketing y sitios web (no necesariamente equipos de productos y productos).

Las métricas primarias siempre deben ser métricas de embudo descendente. Pedidos. Envíos de formularios. MQL. Ganancia. LTV. SQL. Entiendes la idea. Algunas personas dicen que siempre deben ser la acción más cercana al cambio que está realizando o las métricas de compromiso. Equivocado. No. No. Incorrecto. BS. Quien te diga esto debe ser el que tenga que justificar el programa en seis meses o un año ante el CMO o CEO de la empresa. Estarán en el banquillo. NO tenga un programa lleno de pruebas centradas en los clics de botón, los clics, las páginas vistas, el promedio. duración de la sesión, tasa de salida, tasa de rebote, vistas de video, etc., etc. Eso no va a justificar los miles o cientos de miles de dólares gastados para hacer este trabajo. Todo el mundo quiere saber su ROI y cómo el trabajo impactó en el resultado final. Los clics en los botones no van a hacer eso.

No estoy diciendo que no midas las métricas de participación o las métricas de embudo superior, pero deberían ser métricas secundarias o terciarias. No los primarios. Agregan contexto a la historia de una prueba. No son de lo que dependen las pruebas cuando llega el momento de tomar una decisión. Tenga en cuenta que tampoco digo que nunca haya excepciones. Todavía evalúe las pruebas caso por caso.

Un consejo: para aquellos que debaten este tema entre ustedes, siempre les digo a los equipos que discutan las opciones y decidan por sí mismos. Solo asegúrese de llegar a una conclusión colectiva de que todos cumplen con seguir adelante.

Paso 2: investigación e ideación del usuario

En este punto, debe (1) saber que tiene suficiente volumen de datos para probar y (2) saber lo que está midiendo y que está recopilando datos adecuados en los que puede confiar. ¿Qué es lo siguiente? Se trata de qué probar. ¿Cuáles son sus ideas de prueba? ¿Cómo los vas a generar?

¿Adivina lo que hacen la mayoría de los equipos? Se basan en sentimientos viscerales y muchos "pensamos", "sentimos" y "creemos". Eso es demasiado subjetivo, y es una forma terrible de ejecutar un programa. Ese enfoque no está respaldado por datos en absoluto. Es lo que los practicantes llaman "prueba de espagueti", también conocido como arrojar cosas a la pared y esperar que se pegue. Las conversaciones basadas en datos no involucran mucho de ese tipo de lenguaje, y los datos que se necesitan provienen de la investigación del usuario. Me preguntan qué significa "investigación" todo el tiempo.

Bueno, existen varias metodologías que recopilan datos que incluyen, entre otros, análisis, encuestas, encuestas, pruebas de usuarios, pruebas de mensajes, mapas de calor, grabaciones de sesiones, clasificación de tarjetas, pruebas de árboles, mapeo de viajes del cliente, personas y muchos más. También hay varias herramientas para ayudarnos a completar cada uno de estos. Siempre digo que comience con uno o dos y continúe con otros a partir de ahí. Eso es ciertamente mejor que nada. Técnicamente, ya no cuento con los análisis porque todas las empresas tienen datos analíticos en estos días. Si no tienes eso, es probable que tengas peces más grandes para freír. Sin embargo, si lo tiene, esfuércese por uno o dos más allá de eso (y no diga "oh, entonces estamos bien").

Existe una metodología llamada evaluación heurística. Ahí es cuando alguien evalúa visualmente una experiencia y desarrolla ideas basadas en su experiencia y conocimientos. Hay un momento y un lugar para ello, pero la mayor parte del tiempo no está respaldado por “datos concretos”. Es bastante subjetivo y será diferente hasta cierto punto dependiendo de quién lo complete. Sepa que su programa no debe basarse en este tipo de conocimientos.

No voy a cubrir cómo hacer una investigación con gran detalle aquí, pero puede consultar uno de mis seminarios web de VWO aquí, donde hablo más sobre el modelo ResearchXL de CXL.

Paso 3: Priorización

Una vez que tenga una lista de ideas de prueba, no puede hacerlas todas a la vez. Necesita una forma estratégica y lógica de crear un plan de acción. Aquí es donde entran en juego los marcos de priorización. Muchos existen. Me gusta uno en particular: el marco PXL de CXL. Otros comunes incluyen PIE, ICE o PILL. El PXL es el más objetivo en mi opinión. Es personalizable y más robusto (en el buen sentido).

Otros modelos están bien y mejor que nada. Si tienes algo y te funciona, genial. ¡Solo tenga uno y asegúrese de que todos lo estén usando! Te salva de lidiar con un caos adicional.

Paso 4: Hoja de ruta

Las hojas de ruta le muestran visualmente lo que se está ejecutando en un momento dado. Combine su priorización y cálculos previos a la prueba y boom. Tienes una hoja de ruta. Estos se realizan mejor en diagramas de Gantt. Agregue todos sus carriles y pruebas con duraciones estimadas, dispositivos y otros metadatos útiles. Evitará superposiciones no deseadas y efectos de interacción no deseados. Ayuda a todos a planificar de manera mucho más efectiva y eficiente. Esto te salvará de más caos.

Paso 5 y más allá: Negocios como de costumbre

Ahora que todo lo que hemos cubierto está fuera del camino, es lo de siempre. Tienes una prueba a mano que vas a ejecutar. Lo envía a través del flujo de trabajo normal del experimento: maqueta > diseño > desarrollo > control de calidad > lanzamiento > monitor > conclusión > análisis > compartir y archivar > repetir.

Temas relacionados: Gestión y gobernanza de programas

Fuera de las pruebas individuales, hay otros temas a considerar en relación con un "programa" completo. Estos incluyen la gestión y la gobernanza del programa. Así es como pienso en ellos de una manera muy resumida...

Gestión del programa: ¿Cómo va a organizar y realizar un seguimiento de todo este trabajo? Averigua qué herramientas vas a utilizar para las tareas, la gestión de datos y la comunicación. (Obtuve ese desglose de Ben Labay, director ejecutivo de Speero).

Gobernanza: ¿Qué roles y responsabilidades tiene cada uno? Una forma útil de determinar esto es (1) elegir un modelo de gobierno y (2) completar un cuadro RASCI alineado con el modelo de gobierno. Modelos de gobernanza comunes para investigar y considerar: individual, centralizado, descentralizado, centro de excelencia, consejo de pruebas e híbridos.

Si no combina ambos con todo lo demás, será un caos adicional y pagará por ello en cada paso del camino. Clave estos hacia abajo. Toma tiempo extra, pero vale la pena. Si te abres camino a través de las cosas por un tiempo, las consecuencias eventualmente te alcanzarán. Prometo. (Aparentemente, he hecho bastantes promesas aquí).

Conclusión

Debería sentirse un poco (o mucho) más seguro de lo que puede hacer para comenzar a experimentar o de lo que puede hacer para subir de nivel su programa que ya se está ejecutando. No sientas que es demasiado difícil o demasiado fácil. Por lo general, está en algún lugar en el medio. Mi mayor recomendación aplicable a todo lo que he mencionado: tener un mariscal de campo. Tener a alguien que dirija todo este trabajo. No tiene que ser su rol de tiempo completo, pero alguien debería ser el dueño. Eso es por lo general cuando he visto el mayor éxito.

Para concluir, espero que tenga un programa de experimentación lleno de rigor, resultados y un poco de diversión. Al final del día, es un trabajo divertido y emocionante que puede marcar una gran diferencia para una empresa.

Si desea obtener más información sobre cómo la experimentación impulsa la innovación y el crecimiento y cómo vale la pena todo el alboroto, vea mi último seminario web con VWO.