Categorías: A/B Testing, Google Analytics, Google Website Optimizer, Herramientas

¿Cuándo necesitas la API de Google Content Experiments?

Publicado el 17 septiembre 2013 por .

La introducción de la API de Google Content Experiments fue anunciada antes de las vacaciones con un mensaje “Google Analytics becomes a robust testing platform with Content Experiments API”. Y es cierto. La API de Content Experiments ha abierto muchas vías para explorar, y su lanzamiento ha marcado un momento muy importante para la disciplina de testing.

¿Qué significa esto? ¿Qué cambios conlleva?

En el comunicado oficial se habla de las siguientes ventajas / posibilidades:

  • Tests sin redireccionamientos. Content Experiments se basaba en redireccionamientos para servir diferentes versiones de las páginas. Cada una tenía que tener su URL única. Esto en algunos casos podía afectar la experiencia de usuario (por ejemplo, el tiempo de carga de página). Ahora, gracias a la API se puede cambiar el funcionamiento de la herramienta y utilizar un código JavaScript. Si os interesa este tema, os recomiendo estos dos artículos: Google Analytics Experiments: Haz tus tests A/B sin usar varias URLs (sólo con Javascript) Content Experiments Without Redirects (Browser-only implementation)
  • Tests de los contenidos del servidor. La mayoría de herramientas de testing ofrecen cambios en el lado del cliente (usuario) y no en el lado del servidor. La API de Content Experiments permite testear los últimos que requieren hacer database query. ¿Ejemplos? Contenido dinámico, resultados de búsqueda realizada en la web (por ejemplo, de disponibilidad de hoteles, de productos), contenido servido desde un gestor de contenido, etc. En el artículo Running a Server-side Experiment encontraréis más detalles sobre cómo realizar este tipo de testing.
  • Tests con motor estadístico propio. Content Experiments utiliza el método de multi-armed bandit  para servir las variaciones del test. Esto significa que está optimizando las “pérdidas” en cuanto a conversiones y está mostrando más a menudo las variaciones que convierten mejor. La API deja la opción de utilizar un método propio para servir las páginas, pero con la posibilidad de seguir viendo los resultados del test en la interfaz de Google Analytics.
  • Tests en entornos non-web. Estos tipos de tests son el cambio más interesante de todos los anunciados. ¿Dónde aplican? Por ejemplo, en las máquinas de venta que tenemos en la tienda física, en aeropuertos en las máquinas de checkin, en los restaurantes como MacDonalds para hacer un pedido, etc. En estos casos los tests se realizan gracias a la API y a la implementación de Measurement Protocol de Google Analytics para recoger los datos.

¿En qué casos utilizar la API?

En el vídeo más reciente sobre la implementación de Google Content Experiments, Pete Frisella explica diferentes criterios que influyen sobre si optar por la interfaz web de la herramienta o por la API (o para ser más exactos: Management API).

Aquí os dejo este material por si tenéis tiempo y curiosidad para verlo.

Y si no, os hago un pequeño resumen :)

Se trata de evaluar 5 elementos:

1. Entorno

¿El test se va a lanzar en el entorno web o non-web? Si es el segundo, entonces tenemos que utilizar la API junto con Measurement Protocol de Google Analytics.

2. Almacenamiento

¿Cómo vamos a servir el contenido? Del lado del cliente (navegador) o del lado del servidor? Otra vez, si es la segunda opción, vamos a necesitar la API. Hay que acordarse también de la correcta implementación de las cookies para que el servidor sepa qué variación enseñar y a quién.

3. Configuración

Si utilizamos algún tipo de integración por ejemplo con el gestor de contenido, y no queremos que la configuración de los experimentos esté disponible para otros usuarios en Google Analytics, entonces hay que optar por la Management API. Y en caso de utilizar un propio motor estadístico, sólo podemos configurar un experimento desde la API.

4. Motor estadístico

Content Experiments utiliza por defecto el multi-armed bandit. Sin embargo, si este método no nos conviene, a través de la API podemos conectar nuestro motor diferente. ¡Ojo! Tenemos que validar y terminar los experimentos nosotros mismos. Google Content Experiments ya no nos calculará si los resultados son significativos, pero sí que nos va a mostrar los datos en los informes y permitir su segmentación.

5. Selección de variación

Cuando el usuario entra en la página que testeamos hay que decidir qué variación mostrarle. Aquí existen dos métodos para hacerlo: del lado de cliente (usuario) o del servidor. Si lo hacemos desde el servidor, entonces tenemos que apoyarnos en la API.

¿Complicado? Sólo cuando hay que ponerlo en prácitca :) Y para esto os dejo una ayuda: Experiments – Feature Reference.

Aplicación más inmediata

Aunque los experimentos non-web suenan muy bien y personalmente tengo mucha curiosidad de cómo podrían funcionar, soy consciente que implementar Measurement Protocol y la API de Content Experiments es un curro. Entonces, ¿con qué podemos empezar? Pues yo diría que tenemos dos opciones interesantes.

Primero probar el funcionamiento de la pareja Visual Website Optimizer + API de Content Experiments. Por un lado, un editor WYSIWYG y por otro lado, el multi-armed bandit y la segmentación de los informes.

Y segundo, testear en las aplicaciones móviles. Muy pocas herramientas de testing lo ofrecen ahora mismo y parece que la API de Content Experiments ha encontrado allí su nicho.

¡Feliz testing!

Tags: , ,

Deja tu comentario