Iniciamos esta semana una serie de post sobre errores comunes que se suelen cometer a la hora de lanzar un test de Optimizer.

El objetivo es que antes de lanzar un test, estemos seguros de que la configuración es la adecuada y por tanto los datos del test serán válidos.

1 problema: Voy a instalar Optimizer y mi página tiene Analytics

Si bien en la mayoría de los casos, la instalación de Google Analytics y Google Optimizer no presenta problemas y se limita a copiar el tag de optimizer tras el de analytics, existe una situación que es bastante problemática (y cada vez más frecuente) y se produce cuando en el tag de analytics hemos usado el método _setDomainName (“<nombre dominio>”).

Este método es usado cuando  nuestro site está formado por múltiples subdominios como por ejemplo: tienda.midominio.com, blog.midominio.com, www.midominio.com. y permite que las cookies de Google Analytics no se borren cuando un usuario navegue a través de los diferentes subdominios.

El problema es que Google Analytics y Google Optimizer comparten una serie de cookies, entre ellas la que permite identificar al usuario para, en caso de que vuelva posteriormente a la página donde llevamos a cabo el experimento, podamos ofrecerle la misma versión.

Si colocamos el tag de Optimizer estándar en una página donde tenemos un tag de Google Analytics modificado con el _setDomainName, lo que nos pasará es que algunas de las cookies creadas por Analytics, serán borradas por el Optimizer y viceversa. En la práctica, esto implica que un usuario que llegue a la página donde llevamos a cabo el test verá una versión diferentes cada vez que recargue la página (o realice una visita posterior).

Además cada vez que entre a la página de test, el usuario será considerado como nuevo por lo que lo contaremos varias veces estropeando los datos del test.

Solución:

Para evitar este problema tendremos que hacer 2 modificaciones al tag de optimizer.

1. Situar el siguiente script  antes del script de control
   

   <script>
   
   _udn=".midominio.com";
   
   </script>
   
   

2. Añadir la siguiente línea a los códigos de seguimiento y conversión

   gwoTracker._setDomainName(".midominio.com");

A continuación muestro un ejemplo de cómo podría quedar un tag:

var gwoTracker=_gat._getTracker("UA-XXXXXXXX-X");

gwoTracker._setDomainName(".midominio.com");

gwoTracker._trackPageview("/YYYYYYYYYY/test");

Con esta simple solución, nos aseguramos que nuestro experimento funcionará correctamente con un Analytics preparado para realizar un seguimiento multidominio.

Igualmente, esta solución se puede aplicar para realizar implementaciones de Optimizer donde, por ejemplo, la página de destino o conversión se encuentra en otro subdominio.

En próximas entregas seguiremos comentando elementos que debemos tener en cuenta a la hora de preparar un experimento, mientras tanto, si te estas peleando con un experimento y quieres comentarnos tu caso, te animamos a que nos escribas un comentario.

Un saludo y felices fiesta a todos

Dr. Optimizer.

Iniciamos una serie de 3 post enfocados en la optimización de nuestra web y más concretamente en cómo seguir una estrategia ganadora a la hora de diseñar un test online.

Para ello haremos uso de múltiples herramientas siguiendo la máxima de la Google Trifecta

¿En qué página empiezo a testear?

Una de las primeras preguntas que nos hacemos a la hora de realizar un test sobre una web es: ¿Por qué página comenzamos a testear?

Enseguida nos vienen a la mente una serie de páginas candidatas como:

• La home. En teoría, es la página que ven los visitantes cuando llegan a nuestro site por tráfico directo y por tanto una buena candidata a testear por el tráfico que tiene.
• Nuestras landing pages. Páginas por las cuales llegan nuestras visitas desde Google, adwords, campañas de publicidad etc. En general, estas páginas se diseñan para ofrecer detalles sobre un determinado producto y por tanto, testear sobre estas páginas puede ser una buena manera de aumentar nuestras ventas de dichos productos (o cualquier otra acción deseada).
• Partes de un proceso. En el caso de una web de ecomerce, las páginas de proceso como el de compra, suelen ser elecciones lógicas. Si queremos que aumenten las ventas nada mejor que mejorar el proceso a través del cual se realizan.

El problema con todas estas candidatas es que se basan únicamente en nuestra intuición, no existen ninguna evidencia que soporte estas elecciones.

Si seguimos adelante y decidimos testear sobre alguna de las páginas que nuestra intuición nos dice que son las mejores pueden pasar dos cosas:

1. Nuestra intuición se equivoca y el test no produce ninguna mejora o incluso provoca un empeoramiento de las conversiones. A la larga esto suele minar la confianza en los test y pueden llegar a provocar que se abandonen por falta de resultados
2. No nos equivocamos y realmente la página escogida aumenta las conversiones de forma significativa. A la larga, esto hace que nuestra confianza en nosotros mismos y nuestra intuición crezca y que, cuando se produzca el batacazo (que podemos asegurar se producirá), este sea mayor.

¿Y cómo podemos entonces escoger una buena página candidata, basándo nuestra decisión en información en vez de intuición?

La solución está en añadir un poco de ciencia a este proceso, por ciencia entendemos a usar algún tipo de herramienta de medición web, como por ejemplo Google Analytics, que nos permita seleccionar con criterio (con datos reales) la mejor página a testear.

En qué debemos fijarnos

A la hora de buscar problemas en una página debemos fijarnos en 3 datos fundamentales, al menos en las primeras fases de testeo.

Estos son:

1. Tráfico que tiene la página, con especial importancia en su ratio de conversión
2. Tasa de abandono
3. Tasa de rebote

Tráfico y conversiones de la página

A la hora de encontrar una página adecuada para el test, nos interesan aquellas con un volumen elevado de tráfico y sobre todo de conversiones.

Esto se debe a que, a mayor tráfico mayor es el impacto de nuestros cambios y sobre todo, a mayor número de conversiones mayor es el número de alternativas que podremos probar y obtendremos resultados significativos en un tiempo aceptable.

Para determinar qué páginas tienen mayor tráfico en nuestra web y cuáles son usadas por las visitas para llegar a nuestro site, podemos utilizar los reportes de la categoría “Contenido” de Google Analytics. Especialmente el “Contenido Principal” y el “Páginas de Destino Principales”.

Fig.1 Informes de la categoría “Contenido” de Google Analytics.

Tasa de abandono

Este valor nos indica el porcentaje de visitantes que abandonan nuestro site por una determinada página, cuanto más alto más debemos preocuparnos ya que nos estará indicando posibles problemas con los contenidos de nuestras páginas.

No obstante debemos recordar que siempre debemos leer las métricas teniendo en cuenta su contexto, es normal que ciertas páginas tenga una alta tasa de abandono, el final del proceso de una compra es un ejemplo. Una vez que el usuario a finalizado una compra y satisfecho la necesidad que lo llevó a la web no existe ningún motivo para que continúe en la misma y por tanto es normal que abandone el site por la página de confirmación

Este valor debería inquietarnos cuando lo encontramos en páginas como la home, la ficha de un producto o bien en alguno de los pasos de un proceso de compra. En estos casos deberíamos dedicar tiempo a investigar los motivos de este abandono y si es justificado.

Para determinar las tasas de abandono, podemos utilizar el informe de “Principales Páginas de Salida” de la categoría “Contenido” de Google Analytics

Tasa de rebote

Este valor nos indica el porcentaje de visitantes que abandonan nuestro site sin hacer ninguna acción en el mismo, es decir, llegan a una página e inmediatamente abandonan el site.

Valores altos de esta métrica pueden indicar varios problemas, entre ellos:

• Contenidos poco persuasivos o de poco interés
• Estamos fallando en atraer la atención de las visitas y conseguir que se dirijan o continúen en nuestro site
• Captación de tráfico de poca calidad a través de SEO, adwords etc.

Como comentamos antes, estos valores deben mirarse siempre en contexto pero son especialmente preocupantes en landing pages o en la home de nuestro site.

Un buen método para tomar esta decisión es realizar un listado de páginas candidatas en base a criterios como tráfico, tipología de la página (landing, home, proceso), interés para el negocio y los ratios de rebote de cada una de ellas.

Al final, obtenemos un grupo de páginas consideradas problemáticas sobre las que poder testear.

Fig. 2 Gráfico de candidatos ideales a la hora de testear, nos interesan aquellas con mucho tráfico (conversiones) y que tengan problemas. Este gráfico es una traducción del presentado por Bryan Eisenberg en su libro Always be testing.

Vale, ya tengo las páginas problemáticas ¿y ahora qué?

Una vez identificadas las páginas problemáticas, toca decidir que página concreta testear.

Fig. 3 Ejemplo de varias páginas con problemas encontradas gracias al Analytics.

En nuestra opinión, una buena elección es seguir una estrategia de “dentro hacia fuera”, esta estrategia consiste en seleccionar la página con problemas que se encuentra más “profunda” en la jerarquía de contenidos (y sé que a veces es complicado por la naturaleza anárquica de la web)

Con esto evitamos el fenómeno de arreglar una página como la home, y que al pasar al siguiente paso las visitas se encuentren con una página llena de problemas que puede causar un nivel mayor de frustración.

El método de “dentro hacia fuera” nos asegura que a medida que vamos solucionando los problemas, podremos garantizar que las visitas no serán dirigidas a otras páginas problemáticas ya que las hemos ido optimizando.

Fig. 4 En una estrategia de “dentro hacia fuera”, nos centramos primero en optimizar las páginas en el nivel más profundo de la jerarquía

Identificado el dónde, necesito saber a quién y con qué…

Hemos aprendido con este post el primer paso de la metodología para conseguir diseñar un buen test, identificar la zona de nuestra web donde debemos activarlo.

En los próximos posts explicaremos como identificar al público de nuestra web con mayor propensión a la conversión y qué elementos utilizar en el test, para maximizar las probabilidades de éxito.

Una de las preguntas que más frecuentemente nos hacen  es:  ¿Puedo instalar el tag de Google Optimizer si tengo instalado el Google Analytics?

La respuesta es que sí, no existe ningún problema por tener ambos tags a la vez. En este post explicaremos que debemos tener en cuenta a la hora de poner el tag de Optimizer en una página que ya dispone del Tag de Analytics.

 

Partes del Tag de Optimizer

Antes de comenzar con la explicación, recordemos los tags que se utilizan en Google Optimizer:

Control Script:

Es el tag que se encarga de entregar al visitante una combinación específica dentro de todas las posibles.

Se sitúa al comienzo de la página.

Section Script:

Es el tag que “encapsula” las zonas de la página donde vamos a probar cambios, un título o una imagen por ejemplo.

Se usa solo en el caso de test multivariantes y se sitúa al comienzo y al final del elemento de la página a testear.

Tracking script

Se encarga de realizar el seguimiento del los visitantes que llegan a la página a testear

Se sitúa antes del cierre de la etiqueta body.

Conversion script

Se encarga de realizar el seguimiento de las conversiones, es decir, el número de visitantes que llegan a la página objetivo.

Se sitúa antes del cierre de la etiqueta body.

Cómo dato adicional, decir que el Google Optimizer utiliza actualmente el mismo código de seguimiento que el Google Analytics (ga.js)

 

Antes de empezar

En una página marcada con el tag de Analytics debemos plantearnos lo siguiente:

• Que tenga el tag antiguo de Analytics, el urchin.js
• Que disponga del nuevo tag de Analytics, el ga.js

 

Página tageada con Urchin.js

Control script: Se sitúa al comienzo de la página

Section script: Se sitúa “encapsulando” las zonas que quiero variar

Tracking y control scripts: Se sitúan a continuación del tag de seguimiento de Google Analytics.

 

Página tageada con ga.js

Control script: Se sitúa al comienzo de la página

Section script: Se sitúa “encapsulando” las zonas que quiero variar

Ya que ambas herramientas comparten el tag de seguimiento, podemos reutilizar la llamada al ga.js para introducir el código de Optimizer de la siguiente manera.

Tomando el track original de Google Analytics:

<script type=”text/javascript”>

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);

document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));

</script>

<script type=”text/javascript”>

var pageTracker = _gat._getTracker(“UA-XXXXX-X”);

pageTracker._trackPageview();

</script>

Si estamos en la página que queremos testear (test page) debemos añadir las líneas marcadas en rojo:

<script type=”text/javascript”>

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);

document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));

</script>

<script type=”text/javascript”>

var pageTracker = _gat._getTracker(“UA-XXXXX-X”);

var optimizerTracker = _gat._getTracker(“UA-XXXXX-X”);

pageTracker._trackPageview();

optimizerTracker._trackPageview(“/XXXXXXXXXX/test”);

</script>

Si estamos en la página objetivo (target page) debemos añadir las líneas marcadas en rojo:

<script type=”text/javascript”>

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.” : “http://www.”);

document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));

</script>

<script type=”text/javascript”>

var pageTracker = _gat._getTracker(“UA-XXXXX-X”);

var optimizerTracker = _gat._getTracker(“UA-XXXXX-X”);

pageTracker._trackPageview();

optimizerTracker._trackPageview(“/XXXXXXXXXX/goal”);

</script>

Cómo pueden ver, los cambios que se han de realizar en caso de tener instalado el Google Analytics son mínimos.

En próximos post explicaré situaciones y casos especiales que se pueden dar que pueden requerir un poco más de configuración adicional.

Espero que está información les resulte útil y les ayude a empezar a testear cuanto antes.

Doctor Optimizer.