Split a/b y multivariate testing en portales de empleo

Publicado en Otros el 10 de diciembre de 2007 por .

La pregunta del siglo a la hora de optimizar una landing page de un portal de empleo sería… ¿Cuando utilizamos split a/b testing?  ..¿cuando usamos multivariate testing? Utilizaré ejemplos de portales de empleo en España, para poder utilizar ejemplos reales…

El Split A/B testing consistiría en probar dos versiones, dos creatividades, dos urls, dos copies, dos botones. Versión “a” contra versión “b”. Un testeo fácil, rápido y directo, como se argumenta en grokdotcom.

El multivariate testing consistiría en probar dos o más elementos de una misma página, o sea, podemos definir un número ilimitado de variaciones a través de distintas combinaciones y testearlas entre ellas.

Hay que ir con cuidado a la hora de utilizar el A/B testing, tal y como nos cuentan en webcredible. Podríamos utilizar a/b testing para medir un cambio en un botón, o en un copy, por ejemplo:

Imaginemos que somos parte del equipo de marketing online de infojobs y no estamos satisfechos con el ratio de conversión del proceso de alta de candidatos, que se realiza a través del enlace en azul que dice “date de alta gratis”. Para optimizar esta acción (el alta de candidato) desde la home de infojobs, podriamos hacer unos tests. Cambiar el  enlace por un botón con el mismo texto, o cambiar el “contenido” del texto enlace al alta de candidato.

Haríamos una prueba y mediríamos los resultados. Lo podríamos hacer con a/b testing.

No podríamos utilizar a/b testing, si además de este cambio decidieramos introducir nuevos cambios: cambiar el buscador de empresa, la parrilla de resultados, la disposición de los logos. El split a/b testing sirve para medir un cambio, testea dos url diferentes. Si hacemos más de un cambio, no habrá forma de medir que nos ha hecho mejorar o empeorar nuestros resultados: split a/b testing no sirve para esto.

Eso sí, por contradictorio que parezca, split a/b testing nos puede ayudar a introducir un nuevo diseño de un sitio web. Vamos a poner como ejemplo a el portal de formación “infoempleo“. El equipo de infoempleo planeo introducir un nuevo diseño y varias nuevas funcionalidades en su portal. Cambios bastante importantes tanto de look como del uso de la web. Muy orientados a la web 2.0, un cambio en si muy atrevido, pero muy arriesgado.

Me imagino que los chicos y chicas de infoempleo.com antes de lanzarse a la piscina, además de realizar testeos de usabilidad harían algún a/b testing. Con el a/b testing podrían medir y saber almenos si el nuevo y revolucionario diseño mejoraba o no el anterior en conversión, procesos de alta, submisión de cv, búsqueda de ofertas, etc…

No me quiero creer que infoempleo lanzó su nueva cara de su nuevo portal sin saber que iba a pasar…o sea, estoy convencido que no lanzaron su nueva página al “azar” y medir después las consecuencias de este cambio…Y menos con herramientas gratuitas en el mercado que te permiten hacer esto. Es como tener una bola de cristal en tus manos que te predice que va a pasar y en lugar de usarla, sabiendo que te va a leer el “futuro”, la guardamos en el armario, o nos bendamos los ojos y no queremos saber que va a pasar.

Si no hubieran hecho esto estaríamos ante dos situaciones:
a) que el cambio les hubiera ido bien y se hubieran salvado…
b) factor de riesgo total: que hubiera ido mal…y que hubieran lanzado una página web que ellos “creyeron” que era más “bonita” pero que no mejoraba en nada la anterior…con las consecuentes pérdidas de conversión, facturación, clientes…y la desconfianza hacia el equipo que tomó esas decisiones.

Aún así, este análisis solo nos daría una visión global del cambio, al tratarse de dos diseños totalmente opuestos, no podríamos medir cual de los elementos del nuevo diseño ayudó a hacer una de las versiones mejores o peores, tal y como cuenta en su blog Bryan Eisenberg en Clickz.com. Con un a/b testing en este caso sólo podemos saber si el nuevo diseño tendrá mejor o peor impacto, y si va a tener peor impacto quizás sería mejor no lanzarlo, pero como también coincide Jakob Nielsen en su lista de ventajas y desventajas del a/b testing, un a/b testing sobre un nuevo diseño solo nos puede aportar esta información y nada más.

Aquí entra en liza el multivariate testing. Esto es lo que ahora mismo debería estar haciendo cualquier sitio web para optimizar su conversión: tanto infojobs, como infoempleo, como laboris, como monster, como totaljobs, etc…

En el multivariate partimos de un concepto de una página web con diferentes secciones. Una sección podría ser un buscador, un banner, un login form, una imagen, cualquier elemento de tu página web. Para realizar un testeo del tipo multivariate podremos crear distintas variaciones de las secciones que queramos evaluar. Cada conjunto de variaciones de las secciones de una página, creará una combinación de resultados. Gordon H. Bell, en offermática, nos viene a decir que no todo termina en a/b testing, sino todo lo contrario, todo el testeo de optimización empieza en el multivariate testing.
El multivariate testing no nos da la opinión de los usuarios sobre nuestros sitio web, pero si que nos da cifras, que nos indican si los elementos que vamos o no a introducir van a generar mejor o peor conversión.

En un experimento podemos evaluar miles de combinaciones de un sitio web. ¿Eso es positivo? ¿Podemos sacar conclusiones reales? ¿Nos ayuda a entender mejor la mejora de la conversión?

La triple respuesta a estas preguntas es un sí rotundo. Ahora pongámonos en la piel del equipo de monster. Como bien sabemos monster es el portal de empleo líder en Inglaterra, pero tan solo ocupa la cuarta posición del mercado español. Imagino que Monster estará estudiando como hacerse un hueco en el mercado de empleo, mejorando mucho sus páginas de destino y funcionalidades.

Para sus cambios en funcionalidades, quizás es mejor que utilice el a/b testing y vaya introduciendo cambios según los resultados de los distintos experimentos. Pero para cambios de optimización de elementos de una página, es mejor que apueste por los experimentos de multivariate testing.

Si Monster puede realizar un experimento con cientos de combinaciones a través de multivariate testing, ahorrará tiempo y dinero, tal y como nos los cuentan en marketingexperiments.com, que si lo hace con a/b testing (un experimento a la vez). Monster debe tener una lista de desarrollos a implementar extraordinarios. Cada cambio implica un tiempo, recursos, presupuesto, etc…Ahora imaginemos, que los cambios presupuestados para una landing page, desde que se lanza, en tareas de optimización, se traducen en una línea de tiempo de 1 mes. Ahora imagínate que en un experimento, en el trabajo de un día, puedes preparar un multivariate testing, y que al cabo de dos semanas, si Monster dipone del tráfico sufienciente, puede obtener conclusiones y resultados. O sea, que de “gastar” 31 días de desarrollo y planning, podemos pasar a emplear tan solo 5 días de planning y desarrollo, y optimizar esos 26 días restantes a otros proyectos.

Y en esos 5 días de “trabajo real” sabremos que combinación nos da un aumento de la conversión y por consiguiente de la facturación y absolutamente del tiempo y dinero que hemos ahorrado para llegar a estas conclusiones con tanta antelación, de no haber usado multivariate testing. Ya sabemos lo que puede reportar para un portal de empleo un incremento de la conversión de hasta un 2% con una audiencia de entre 100,000 y 200,000 usuarios únicos al día…Creo que si el director de cualquier de estas empresas me lee, sabe ya la diferencia entre saberlo antes utilizando multivariate o saberlo después al azar….

Optimizar, avanzar, rendibilizar y en definitiva poder competir en el mundo online.

Otra cosa es.. ¿que herramientas nos pueden ayudar a realizar estos experimentos? y si google optimizer puede ayudarnos a medirlos, pero esto lo analizaremos en el próximo artículo.

Mi duda más grande es….¿porqué les da tanto pánico a los portales apostar por herramientas de testeo como estas? ¿Quién será el portal más innovador en este terreno en el mercado de empleo? ¿Quién va a saber sacarle partido antes al análisis del comportamiento de los usuarios para mejorar la conversión de forma mucho más sencilla y rápida ahorrando en tiempo, recursos y presupuesto y ganando en facturación? ¿Cuando el primer portal lo lance, va a marcar la tendencia del mercado y todos los demás le van a copiar, o no?¿Qué opináis…?

Etiquetas: , , , , , ,

Sobre Ferriol Egea

Ferriol Egea es un experto analista en la optimización de negocios online. Ahora es director de marketing online de la Lavanguardia.com

Puedes encontrar a Ferriol en:



6 Comentarios en Split a/b y multivariate testing en portales de empleo

  1. cubi&co

    Increible! Muy muy buen artículo. Del todo interesante y perfectamente comprensible para aquellos que no estamos del todo metidos en el asunto este.

    Sigue así, gracias!

  2. admin

    Gracias por el comentario! Para mí lo más importante es concienciar al mundo online de este país, de utilizar técnicas que ya se utilizan en las grandes empresas de Japón, EEUU, Inglaterra, etc…y ayudarles a vencer los miedos a la hora de utilizar algo “nuevo” y distinto…que a la hora de la verdad les ayudará a ganar mucho tiempo y dinero..y ahorrará disgustos que ahora ya son inútiles y desde aquí off course, invitar a la reflexión entre todos de como introducir estas técnicas de forma óptima.

    Cuando sale un producto así, la primero que se les pasa por la cabeza es: ¿nos llevará mucho tiempo de desarrollo? Cuando la pregunta adecuada tendría que ser…conseguiremos un mejor ROI? Y esa respuesta, responde (valga la redundancia) todas las demás…

  3. David Martín

    Si a algunas empresas le da miedo quitar un flash, y te dicen que eso forma parte de la imagen de al web que a la gente le gusta el movimiento, o quieren todavía web que se vean por completo a 800X600, (dicen que la gente no hace scroll y que asi se ve más bonito) no ponen código de conversiones de Adwords…

    De todo esto me he encontrado. Imagínate lo del análisis de este tipo, yo tampoco lo he puesto en práctica, aunque lo estuve estudiando en Adwords para mi anterior empresa, pero ahora con el cambio, primero tendré que crear una campaña, ya te seguiré leyendo para informarme mejor a este respecto.

    Saludos

  4. admin

    Si, muchas empresas cuando escuchan la palabra testeo ya se asustan. Y la primera pregunta que te hacen es “si va a conllevar mucho desarrollo”…con lo cual ya te indica que se están tirando atrás…

    Lo que no se dan cuenta, es que este testeo, les va a hacer ahorrar tiempo, malas decisiones, dinero e inversión..y por supuesto dejar de ir a ciegas a la hora de optimizar ratios de conversión.

    El día que lo haga una, lo harán todos….no tendrán más remedio. El mercado americano y el japonés están muy por delante del europeo, y ni que decirlo del español.

    Mientras las empresas de aquí empiezan a modernizarse…las americanas y japonesas ya están no uno, sino almenos dos pasos grandes por delante…con herramientas como offermática….

  5. Pepe

    Hola Admin:
    Te puedo asegurar que los de Infoempleo realizar estudios de a/B testing. Y que analizan con detenimiento la conversión de sus landing pages. !!!Han pasado de un 2% de OI al 10%!!!

  6. ferriol

    Pues realmente celebramos que Infoempleo.com sea una de las empresas online más avanzadas en el uso de herramientas de testeo para optimización.

    Y si han pasado de un 2% al 10%, es una prueba más del éxito de éstas estrategias.

    Felicidades Infoempleo!

2 Trackbacks For This Post

  1. mcdave.net » links for 2008-01-07 Says:

    [...] Split a/b y multivariate testing en portales de empleo | Trucos google analytics – optimizer (tags: analytics testing design) [...]

  2. Chatea con Eduard | un blog de analítica web Says:

    [...] Split A/B y Multivariate Testing en Portales de Empleo, por Ferriol Egea [...]

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

Puedes usar las siguientes etiquetas y atributos HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>