Analytics Premium ComScore ClickTale Analytics Certified Partner Klipfolio Coremetrics

Sumamos una nueva herramienta a nuestro “repertorio”: Webtrekk

14/10/2016 a las 13:50

Webtrekk

Cuanto más nos sumergimos en la completa plataforma que la compañía alemana Webtrekk nos ofrece, más nos gusta. Sin ánimo de entrar en mucho detalle, sí queremos mostrárosla por encima y daros nuestras primeras impresiones sobre ella tras habernos certificado y haber realizado nuestra primera implementación.

En estos momentos, se encuentran en plena migración de interfaz. El nuevo, más limpio y minimalista, puede dar la falsa impresión de que no estamos ante una herramienta demasiado completa, pero nada más lejos de la realidad.

Como ejemplo, y para hacerse una idea de la liga en la que juega, una mezcla de roles, categorías y filtros nos permiten realizar una gestión de permisos de usuario que puede llegar a un nivel de detalle como pocas veces hemos visto.

Webtrekk

Uno de los múltiples informes que una implementación básica en Webtrekk nos ofrece.

Pero vamos a ello. Demos un repaso a vista de pájaro de los principales componentes de la plataforma.

 

TAG INTEGRATION

Aunque no compite (ni lo pretende) con gigantes en éste área como Google Tag Manager o Tealium, es una herramienta que facilita mucho la implementación de Webtrekk. Arrastrando y soltando lo que ella denomina plugins, y con una configuración mínima de los mismos, podemos comenzar inmediatamente a recoger una gran cantidad de datos de un sitio web donde previamente hayamos insertado el script correspondiente.

Nos llamó la atención la inclusión de un plugin para detectar si el usuario utiliza Ablock y otro para medir el scroll en página. Muy útiles, como también lo es el que nos permite crear encuestas para nuestros visitantes. Y, por supuesto, incluye también plugins personalizados donde podemos insertar el código javascript que necesitemos (para píxeles de remarketing, por ejemplo).

Webtrekk

Configuración de la etiqueta o plugin básico de Webtrekk

 

DIGITAL ANALYTICS

Es la herramienta de análisis propiamente dicha. Además de disponer de una gran variedad de informes, permite la creación de informes personalizados (bookmarks) a partir de éstos, gracias al alto grado de personalización que ofrece. Podemos añadir y quitar dimensiones y métricas, añadir modos de visualización, cambiar el tipo de gráfico asociado a la tabla y la métrica mostrada, etc.

Webtrekk

Tres modos de visualización de datos, configurables: mapa de calor, barras y semáforos.

Cómo no, contamos con la posibilidad de construir filtros y segmentos todo lo complejos que sea necesario. Tan sólo echamos en falta un mejor soporte a las expresiones regulares en este área. Trabaja con una versión muy simplificada de éstas.

Webtrekk

Google Analytics

Arriba: informe “Page detail” de Webtrekk. Abajo: informe “Resumen de navegación” de Google Analytics, del que os hablamos hace poco. Aunque muy similares, nos ha gustado mucho que el primero aporte gráficas de tendencia para las páginas previas y posteriores.

Aunque herramientas de pago como ésta no necesitan recurrir al muestreo o sampling, hay que tener en cuenta que los informes, por defecto, se nos presentan basados en una muestra del 20% para agilizar la carga, pudiendo nosotros, después, cambiar al 100% el tamaño. Los tiempos de respuesta no nos han parecido excesivos en ningún momento, por lo que nos hubiera gustado que el tamaño por defecto de la muestra fuera algo que se nos permitiera definir a nivel global en la configuración.

Y en cuanto a cuadros de mando, Webtrekk nos facilita mucho el crearlos. Los llama “reports”.

Webtrekk

Ejemplo de report en Webtrekk

Nos ha parecido lo suficientemente potente en este aspecto como para cubrir esta necesidad en la mayoría de los casos, sin tener que salir de la plataforma.

DMP

En el DMP jugamos con las variables recogidas por el User Relationship Management para construir segmentos diferenciados a los que poder “atacar” de manera diferente. Por ejemplo, tenemos el Profile Macro Status que, de manera configurable, nos permite saber el grado de “madurez” de un visitante. Podríamos clasificarlo como mero visitante, como alguien que se ha interesado por los productos, como alguien que llegó a comprar, como un comprador recurrente…

DMP

Lista de visitantes  en detalle, sobre la que podemos crear segmentos

Las últimas dos columnas de la captura de pantalla nos muestran unas métricas realmente interesantes y fruto de análisis avanzados incluídos en este módulo.

La primera es la probabilidad de que ese usuario no regrese nunca más al site o no vuelva a usar nunca más la app. La segunda, una estimación de la probabilidad de que el usuario termine realizando una conversión.

En la captura de pantalla figuran a cero porque en ese caso todavía no hay datos suficientes como para que el análisis arroje resultados significativos.

 

MARKETING AUTOMATION

Webtrekk

Configuración de una campaña

El último elemento del que vamos a hablar es el Marketing Automation. Basándose en segmentos (actividad en sesiones previas) o en el comportamiento en la sesión actual (tiempo real), podemos personalizar los contenidos mostrados, presentando al visitante banners con ofertas más susceptibles de interesarle, capas con invitaciones a suscribirse o productos recomendados, entre otros tipos de personalización. Potente, fácil de usar y completamente integrado en la plataforma.

 

EN RESUMEN

Webtrekk constituye una plataforma muy completa, con grandes ideas bien implementadas. Y su potente herramienta de analítica digital es digna de ser tenida en cuenta en todos aquellos casos en los que las soluciones gratuitas se nos hayan quedado cortas y nos estemos planteando dar el salto a algo más “serio”.

Aunque nos proponemos seguir hablando de Webtrekk en futuras entradas del blog, os animamos a que nos digáis en los comentarios si hay algún aspecto en particular sobre el que os gustaría saber más.

Midiendo conversiones que ocurren fuera de nuestro sitio

29/06/2016 a las 16:57

Seguramente, muchas veces han querido contabilizar conversiones que ocurren fuera de nuestro sitio como por ejemplo, en una web de generación de lead donde la venta ocurre por teléfono y no en el propio sitio.

Hace poco, trabajando para un cliente, me encontré precisamente en esta situación y quiero contarles en este post cómo lo resolví por si les puede ayudar o servir de ejemplo.

No significa por supuesto que sea la única manera de hacerlo, pero los resultados han quedado bastante bien y escribir un post siempre sirve para que otras personas aporten ideas de mejora o diferentes puntos de vista.

El sitio

Llamaré de manera ficticia a mi cliente como ACME FX. Esta empresa ofrece a sus clientes realizar pagos a empresas en el extranjero que impliquen cambio de moneda con unas comisiones sensiblemente inferiores a las que ofrecen los bancos o brokers.

Para convertirse en cliente de ACME FX, una persona debe pasar una serie de “pasos” , el primero de estos es dejar sus datos a través de la web y posteriormente responder a un cuestionario que lo clasifica como Qualified para seguir en el proceso de “conversión” a cliente o no.

 

El reto

Era precisamente este objetivo el que ACME FX quería tener en Analytics es decir, las conversiones serían cuántos de los usuarios que llegan al sitio y envían un contacto, acaban siendo marcados como Qualified. El reto de este proyecto por tanto, era el de conseguir que una acción que ocurre fuera de la sesión del usuario (un check en una casilla por parte del evaluador) acabase en Analytics como una conversión de objetivo asignado al usuario.

Y por si esto fuese poco, queríamos también que las conversiones se asignase al origen, medio y campañas de la sesión online.

 

El proceso para medir las conversiones

En esencia, los pasos que necesitamos seguir para poder realizar este proyecto o cualquier otro que requiera medir conversiones offline/online pero fuera de la sesión del usuario es:

  1. Necesitamos capturar el client id del usuario, el client id es un identificador único que le da Google Analytics a cada usuario que entra en el sitio y recomendamos recogerlo y guardarlo en una custom dimensión (aunque para este caso, guardarlo en una custom dimension no es estrictamente necesario)
  2. Una vez capturado, necesitamos enviar ese client id junto con los datos que envía el usuario en el formulario
  3. Una vez enviado, necesitamos almacenarlo, normalmente en nuestro CRM (o BBDD)
  4. Cuando el usuario realiza la conversión, enviamos un hit de evento mediante el measurement protocol indicando la acción de conversión, en ese hit incluiremos el client id que teníamos almacenado para que pueda ser asignado a ese usuario concreto.
  5. En Google Analytics, damos de alta un objetivo que se cumpla cuando llega un evento del tipo definido en el punto 4.

Eso es todo ;), realmente es tan fácil como parece.  Vamos a ver en detalle cada punto tal y como lo apliqué con mi cliente.

Punto 1

Dado que mi cliente tenía Google Tag Manager instalado, capturar su client id fue realmente sencillo, basta con definir una variable como “custom javascript” (podemos llamarla UA client ID por ejemplo) con el siguiente código:

function() {
 try {
 var cookie = {{ga cookie}}.split(".");
 return cookie[2] + "." + cookie[3];
 } catch(e) {
 console.log("No Universal Analytics cookie found");
 return "n/a";
 }
}

Realmente lo interesante es el JavaScript, esta función devolverá el valor del client id almacenado en la cookie de Google Analytics (el mérito es de Simo Ahava y su excelente post sobre 4 custom dimensión que debes capturar para mejorar tu implementación)

Una vez lo tengas, lo puedes almacenar en una variable para mandarlo junto a los datos del usuario. Adicionalmente nosotros solemos guardarlo en una custom dimension. Hacerlo en  GTM es tan sencillo como modificar la etiqueta de seguimiento de página para que la variable sea enviada como custom dimension.

custom-dimension-userid

Envío del client id como custom dimension

 

Punto 2 y 3:

Una vez capturado el client ID, lo siguiente es mandarlo a la herramienta que gestiona nuestros leads junto con los datos del cliente, dado que hay muchas formas de mandarlo,  me centraré en mi cliente. En su caso su CRM es SalesForce y lo que hicimos fue enviar el client id como campo oculto en el formulario de contacto (o cuando se pedía una demo del producto o se dejaban los datos para solicitar un informe)

Realmente enviar el client id como campo oculto es la manera más común de mandar el dato para almacenarlo.

En SalesForce (o nuestro CRM o BBDD), creamos un campo para guardar el client id y almacenamos este valor junto con el resto de información del usuario.

proceso de guardado

Proceso de guardado del cliend ID en SalesForce

Punto 4:

Ahora viene la parte entretenida. Cuando un usuario ha enviado sus datos, interviene un evaluador que decide si este usuario pasa de Lead a Lead Qualified. Es en este punto cuando queremos considerar en Analytics una conversión . Hasta hace poco, solo podíamos mandar información a Google Analytics si nos encontrábamos en una página web. Esto ha cambiado con el measurement protocol. Este protocolo, nos ofrece una vía para mandar información a Google Analytics desde cualquier dispositivo que disponga conexión a internet, en este caso nuestro CRM.

Cuando el evaluador marca la casilla de Lead Qualified lanzamos un “hit” de Google Analytics de tipo evento, en nuestro caso este hit tiene la siguiente forma:

www.google-analytics.com?v=1&t=event&tid=UA-XXXXXX-X&cid=884b4995-dd01-45c1-9dd8-f7ef158abdc3&dp=%2FsalesForce&ec=Offline%20interaction&ea=Lead%20status&el=qualified&ni=1&cd3=884b4995-dd01-45c1-9dd8-f7ef158abdc3

La explicación de los parámetros sería la siguiente:

 

Parámetro Valor Descripción
v 1 Versión de measurement protocol
t event Tipo de hit
tid <cuenta> Cuenta a la que se manda los datos
cid <Client ID> Client ID, permite relacionar los datos del CRM con los de Google Analytics
dp /salesForce Página asociada al evento, permite que filtrando la página salesForce se eliminen todos los eventos
ec Offline interaction Categoría del evento que se manda
ea Lead Status En el event action indicaremos la acción que se realiza sobre el usuario en sales force.
el Qualified Indica que el lead tiene el status de Qualified (objetivo)
ni 1 Se pone a 1 para indicar que el evento es siempre “no interactivo” con lo cual no generamos sesión con los hits del measurement protocol y no engordamos las estadísticas (dado además que los usuarios son existentes porque uso el client ID, no creo tampoco usuarios nuevos)
cd3 <Client ID> Almacena el client ID como custom dimensión

Un detalle importante es que no debemos indicar nunca ni el source ni el medium (parámetros cs y cm) en el hit de evento.

Al no indicarlos, este hit se considerará como tráfico directo con lo cual, a efectos de la conversión, aplicará el funcionamiento normal de Google Analytics que es el de tomar como fuente y medio aquellos que tenía el usuario en su última sesión online (es decir, la sesión en la que el usuario envió el lead) .

Un problema que puede aparecer es que el usuario entre de nuevo al sitio en el intervalo de tiempo que pasa desde que manda el formulario y se le clasifica como Lead Qualified, en ese caso, la fuente/medio que se asignaría a la conversión sería esta última (siempre que no sea directa) y no aquella que generó el envío del contacto.

Punto 5:

Lo que nos queda ahora es dar de alta en Analytics un nuevo objetivo, este objetivo se “disparará” cuando en Analytics se reciba un hit con el evento definido para clasificación de lead.

Objetivo

Definición del objetivo de generación de lead válido

Resultado

El resultado de todo este proceso es el que pueden ver a continuación.

Fuente y medios que generan la conversión

Informe de resultado de conversiones en Sales Force

Como podemos ver, se contabilizan las conversiones del objetivo y estas se asigna a la fuente y medio de la sesión previa online que es lo que queríamos.

Espero que el post es haya resultado útil y se animen a medir todo aquello que el usuario hace “fuera” de la sesión online.

Si tienen cualquier duda o sugerencia no duden en plantearla en los comentarios

Fernando

Google Analytics 360 Suite hoy su gran lanzamiento

15/03/2016 a las 20:28

Os adjunto la carta que Paul Muret, responsable  y creador de Google Analytics, nos ha enviado para presentarnos la evolución de la herramienta en su Suite 360.

Hola,

Hoy estoy encantado de compartir la próxima evolución de Google Analytics: Google Analytics 360 suite.

Una revolución en el marketing está en marcha – las empresas se enfrentan a una explosión de nuevos dispositivos, canales, audiencias fragmentadas y compra programática – que lleva a un aumento exponencial en el volumen de datos. Con un creciente número de señales a monitorizar, es más difícil que nunca manejar todo, encontrar información útil, y convertir esas ideas en acción.

Es por eso que hemos construido el Analytics 360 Suite. Un sistema que integra sus datos con herramientas de marketing análisis, diseñadas específicamente para cubrir las necesidades de responsables del marketing o análisis dentro de una empresa y ayudarles a:

  • Visibilidad completa de la conducta del consumidor. Los responsables de marketing necesitan la visión completa de los datos de forma inmediata para ver lo que está sucediendo con sus usuarios en todos los puntos de contacto, canales y dispositivos. Comprender el contexto completo del viaje de un usuario en lugar de medir solamente una sesión, un único dispositivo, o el último-clic.
  • Obtener información útil, no más datos. Los profesionales del marketing necesitan una enorme potencia de cálculo, data science y algoritmos inteligentes, todos trabajando juntos para ayudar a dar sentido a los datos. Esa inteligencia hace el trabajo pesado y entrega rápidamente hallazgos de valor para que el equipo se dedique su tiempo a actuar.
  • Compartir conocimientos y colaborar con todo el mundo. Poniendo los datos en manos de todos fortalece objetivos en común y potencia las sinergias para conducir a una toma de decisiones más inteligente. Reducir el tiempo invertido en informes para crear rápidamente bellas visualizaciones de los acontecimientos más significativos del negocio, y luego compartirlo con toda la organización.
  • Ofrecer experiencias atractivas a las personas adecuadas. Hacer que su marca sea útil para los consumidores. Con integraciones a través de múltiples tecnologías de Google, la suite de productos que no sólo funciona bien con éstas, sino también con otros productos, incluyendo AdWords, DoubleClick y plataformas de terceros. Esto permite a los marketers tomar acciones inmediatas y mejorar la relevancia de los anuncios y las experiencias en sus webs.

 

Analytics 360 suite

¿Qué significa esto para usted?
No habrá ningún cambio inmediato en su cuenta. La suite 360 ​​Analytics BETA se irá introduciendo en clientes GA Premium a lo largo de 2016.

Es sólo el comienzo – vamos a seguir invirtiendo fuertemente en nuevos productos, características y funcionalidades. Es un momento emocionante para los que nos dedicamos al análisis de marketing, y esperamos compartir más información con usted pronto.

Para más información acerca de todos los nuevos productos y la suite 360 ​​Analytics, visite nuestro sitio web.

Cordialmente,
Paul Muret
VP, Analytics, video & display products

¿Cómo valorar un cambio si cometiste el error de no hacer un test?

29/05/2015 a las 08:30

 

 

test_1

 

No nos engañemos, la única manera fiable de verdad de poner a prueba un cambio en nuestro sitio web o nuestra app para móvil es realizar un test (A/B o multivariante).

Supongamos que queremos cambiar el formulario para suscribirse a la newsletter, o la ubicación o el diseño del botón de añadir un producto al carrito.  Lo que se busca es optimizar, lograr que la tasa de conversión del objetivo que se alcanza a través de ellos aumente (lograr suscripciones o la adición de productos a la cesta de la compra en nuestros ejemplos).

Claro, tanto en la tasa de conversión como en el resto de métricas hay muchos factores que influyen: estacionalidad, campañas, tendencias a largo plazo debidas a la situación del mercado, etc. Pero los test nos permiten aislarnos en gran medida de todo eso. El desempeño de la versión original y los cambios a probar se va medir durante el mismo periodo y bajo las mismas circunstancias. A igualdad de condiciones, se puede decir que el factor determinante será el elemento que estamos poniendo a prueba.

Durante el tiempo que dure el test, a los diferentes visitantes que vayan llegando les iremos mostrando, o bien la versión original o la/s variante/s.

Hay muchas otras, pero la herramienta para hacer tests que incorpora Google Analytics se llama “Experimentos de contenido” y puede encontrarse en el apartado de “Comportamiento” de los informes.

 

test_2

 

Pasado un tiempo, si el experimento estaba bien planteado, obtendremos el resultado: es decir, si la alternativa propuesta supone una mejoría con respecto al original (y en qué medida) o no.

 

test_3

 

Perfecto, esta es la manera correcta de hacer las cosas. Pero es más frecuente de lo que quisiéramos encontrarnos en la situación de que se nos pida analizar un cambio en un sitio web o una app cuando éste ya se ha hecho, sin ofrecernos la oportunidad de hacer un test.

Es una situación complicada y hay que tomar ciertas precauciones para no llegar a conclusiones equivocadas. De hecho, es probable que nuestro análisis no sea concluyente.

Cosas a tener en cuenta:

 

 No debemos iniciar el análisis con ideas preconcebidas.

Por muy claro que veamos que el nuevo diseño o ubicación es mejor que el anterior, por muchos estudios que apoyen que tal o cual color incita a la acción más que otro, nunca hay que dar por hecho que el cambio va a funcionar mejor (ni lo contrario). Corremos el riesgo de “torturar” los datos hasta que nos digan lo que queremos oír, sea o no sea verdad.

 

 Hay que elegir bien cómo vamos a valorar el cambio.

No hay que basarse en valores absolutos (número de conversiones totales), sino en la tasa de conversión. Y ésta, segmentando las sesiones de modo que solo tengamos en cuenta aquellas que han llegado a ver el elemento que ha sufrido el cambio. Si no, estará entrando también en la ecuación el hecho de que pueda haber aumentado o disminuido el número de usuarios que llegan hasta la página en cuestión.

Por ejemplo, si estamos analizando el desempeño del nuevo botón “agregar al carrito” con respecto al viejo, y menos usuarios están llegando a las fichas de producto porque nuestra nueva colección no está gustando, evidentemente, si calculamos la tasa de conversión con respecto a todas las visitas, está bajará y no será por culpa del botón. Debemos aplicar un segmento que sólo tome en cuenta las sesiones que incluyeron la página de producto, en este caso.

 

Se debe buscar un cambio claro en el valor del indicador y  que coincida en el tiempo con el cambio en la web o en la app.

No hay que comparar el valor del indicador elegido en un periodo previo al cambio con el valor del mismo indicador en un periodo posterior. Eso nos puede llevar a engaño. Veamos un ejemplo:

test_4

 

A mediados de mes se cambió el elemento analizado. Si calculamos la tasa de conversión media de la primera quincena y la comparamos con la tasa de conversión media para la segunda, el resultado de la comparación nos dirá que antes del cambio la tasa de conversión era mayor. Es cierto, pero no es por culpa del nuevo botón/diseño de formulario/etc.  Lo único que se le podría echar en cara es que no fue capaz de frenar la caída. Pero no nos engañemos, una tendencia motivada por poderosas razones, como una estacionalidad natural y pronunciada, difícilmente la podrá enmendar (o estropear) un cambio de color en un botón.

Si hay estacionalidad, la eliminaríamos si comparamos el periodo con su equivalente en el año anterior. Pero seguirá habiendo otros factores que justifiquen un incremento o un descenso en el indicador.

¿Qué podríamos pensar si realizamos esa clase de análisis en esta otra situación?

 

test_5

 

Evidentemente, la tasa de conversión es superior tras el cambio, pero la tendencia venía de más atrás.

Podemos ampliar el periodo analizado lo que queramos, pero lo único que veremos será tendencias a más largo plazo debidas a causas totalmente ajenas al cambio que estamos valorando.

¿Qué nos podría indicar que el cambio introducido ha supuesto una mejora? Un cambio abrupto como éste:

 

test_6

 

Una vez confirmado que ese mismo día no hubiera otros factores que pudieran haber influido (otros cambios, el lanzamiento de un nuevo producto muy deseado y más añadido al carrito que la media…), podemos sentarnos a analizar lo que la gráfica nos muestra.

Es cierto, había una tendencia a la baja que se mantiene, pero el cambio analizado introdujo un incremento brusco del indicador, justo ese día,  a partir del cual la tendencia sigue su curso.

El nuevo formulario (o el nuevo botón, o lo que sea) parece funcionar mejor. La tasa de conversión fluctuará debido a la presencia de campañas o la falta de ellas, de cambios en nuestro catálogo, tendencias estacionales, etc. pero sobre un punto de partida un escalón por encima gracias a la optimización lograda por el cambio.

Este último ejemplo es muy claro y evidente, pero no siempre va a ser así. Insistimos en que el análisis de un cambio a posteriori es el último recurso y que siempre hay que tratar de realizar tests. Es más sencillo de lo que parece y sus resultados son siempre más fiables y concluyentes.

Y si os habéis quedado con ganas de saber más sobre cómo hacer un test en Google Analytics, cuando Google lanzó esta funcionalidad ya le dedicamos un artículo en el que explicábamos cómo usarla. Aunque la ubicación exacta y la interfaz mostrada en las capturas de pantalla han cambiado algo, la forma de crear el test es básicamente la misma. Para más detalles, te animamos a leerlo:

http://www.doctormetrics.com/2012/06/21/content-experiment/

También puedes dejarnos tus dudas sobre esta materia en los comentarios.

El tiempo es oro: tiempos de página y tiempos de usuario en Google Analytics

04/09/2014 a las 12:35

 

Vivimos con prisa y el dicho de que el tiempo es oro es más cierto que nunca.

Sin embargo, en el terreno de la analítica web, los análisis de tiempos parecen unos segundones (cuando no se olvidan por completo). Al  hablar de tiempo, nos referimos a dos tipos de métricas diferentes: los tiempos de página (site speed) y los tiempos de usuario (user timings), ambos, localizados dentro de la sección “Comportamiento” de Google Analytics.

 

Tiempos de página

No vamos a decir nada que no sepamos todos ya, pero nunca está de más un recordatorio para no perder de vista aquello que es importante. Los tiempos de carga de nuestra web son críticos. Y no solo porque, como todo iniciado en SEO sabe, los buscadores favorecen en su posicionamiento a las webs más  optimizadas, sino porque no todo el mundo tiene el mismo ancho de banda. Esto último es especialmente importante si parte de nuestra audiencia potencial procede de zonas rurales o de países en vías de desarrollo.

 

mapa_t

tabla_t

 

¿Tendrán los internautas de las zonas con peores anchos de banda  la paciencia suficiente para moverse por nuestro sitio web si éste no está bien optimizado en cuanto a velocidad de carga?

t_rebote

 

En este ejemplo, se aprecia una tasa de rebote claramente superior a la media para las regiones con tiempos medios de carga más altos. Y en mayor o menor medida, la pauta se repite para otros muchos sitios revisados. Hay más factores, desde luego, pero un tiempo de carga de la página de más de medio minuto,  no ayuda.

Hay que tener en cuenta que para la obtención de estos tiempos se mide, por defecto, un 1% de las sesiones. Este porcentaje se puede modificar introduciendo la siguiente línea en el código de seguimiento, antes de enviar la página vista.

Por ejemplo, en Classic, podríamos cambiar el 1% de muestra por un 5% mediante

_gaq.push([‘_setSiteSpeedSampleRate’, 5]);

situado antes de _gaq.push([‘_trackPageview’]);

En Universal Analytics, ese parámetro lo cambiaríamos en

ga(‘create’, ‘UA-XXXXX-Y’, {
‘cookieDomain’: ‘xxxxxx.com’,
‘siteSpeedSampleRate’: 5
});

 

Antes de lanzarnos a poner un 100%, hay que saber que hay límites en función del volumen de tráfico del site. A partir del millón de hits diarios, Google Analytics no recogerá más del 1%, no importa que hayamos especificado un porcentaje mayor.

 

Si los resultados obtenidos no son todo lo buenos que quisiéramos,  podemos detectar puntos de mejora concretos en este terreno,  mediante herramientas como la extensión del navegador Firebug con su plugin Yslow.

 

p_yslow

Fuente: Yslow.org

Otra herramienta gratuita similar es Google PageSpeed, cuya API nos permite personalizar la manera en la que se muestran los resultados de la evaluación que hace de nuestra página, encolar la evaluación de múltiples páginas sin tener que hacerlo una a una a mano, etc.

pagespeed_API

Google Analytics, para estos informes, calcula los tiempos de carga  de la misma  manera que dichas herramientas, aunque no entre en detalle sobre recomendaciones, ya que no es su fin.

 

Tiempos de usuario

Este tipo de métricas no son tan conocidas, ni su utilidad tan  evidente, pero la tienen. Se trataría de mediciones personalizadas sobre elementos determinados. Aclararemos lo que significa ésto un poco más adelante.

Por defecto, este informe está en blanco, ya que se requiere cierta implementación por nuestra parte. El comando a utilizar es:

ga('send','timing','timingCategory','timingVar', timingValue);  // para Universal Analytics

o

_gaq.push([‘_trackTiming’, category, variable, time, opt_label, opt_sample]); // para Classic

En él,  indicamos la categoría del tiempo medido, su nombre y su valor para esta medición en concreto (esos son los parámetros obligatorios). Podríamos tener una categoría para los tiempos de carga de imágenes, otra para medir los tiempos de reproducción de los videos que tengamos en él, otra para recoger el tiempo empleado en interactuar con formularios u otros elementos, etc.

Como se puede ver en los ejemplos de categorías que damos, este tipo de métricas  nos pueden servir para analizar los tiempos de carga  de elementos específicos de la web, el grado de interés que despiertan nuestros contenidos y posibles problemas de usabilidad (correlación entre tiempos altos a la hora de rellenar un formulario, por ejemplo, y la tasa de abandono). Para este último uso, no serviría recurrir a la métrica “promedio de tiempo en página” cuando en una página hay más de un elemento al que pueda dedicar su tiempo el usuario.

cronometro

 

El tiempo a enviar mediante ese comando se calculará restando el tiempo (newDate().getTime()) del momento en el que termina el hecho que queremos medir (click en el botón “stop” de un video,  cuando se ha terminado de cargar una librería, cuando enviamos el formulario…) al momento inicial (click en el botón “play”, comienza la carga del script, comenzamos a rellenar el primer campo del formulario, etc.).

Es interesante incluir código que descarte tiempos menores que cero o anormalmente altos, para eliminar irregularidades (como el que el usuario cambie la hora del ordenador durante el proceso) que puedan afectar a los valores total y medio.

A la hora de mostrar los resultados de nuestras mediciones, disponemos de tres tipos de informe:

Explorador: una tabla que nos mostrará por categoría de medición o en más detalle, para elementos concretos,  los tiempos medios y el número de muestras con las que se han calculado.

user_timing_1

user_timing_2

 

Distribución: englobará las diferentes muestras en rangos de tiempo, para que podamos ver la distribución y descartar los extremos, si fuera necesario.

ut_distr

Gráfico de visitas por ubicación: aquí volvemos a relacionar tiempos y ubicaciones geográficas, mediante un mapa como el que mostrábamos para los tiempos de página.

 

Resumiendo

Si le damos a la eficiencia de nuestra web la importancia que merece, tenemos a nuestro alcance las herramientas que nos permitirán optimizarla en ese sentido y en base a un análisis todo lo pormenorizado que queramos.

 

Product Advisor: una aplicación para vender más y mejor por Internet

04/11/2011 a las 14:21

ProductAdvisor, by Metriplica

Product Advisor es una aplicación de Metriplica que analiza nuestro catálogo online y que clasifica los productos en función del valor que tienen para los usuarios.

ProductAdvisor, by Metriplica: Video

Product Advisor categoriza los productos con rigor estadístico, identificando aquellos que son problemáticos, los que se deberían eliminar, los que hay que destacar, y los productos estrella.

ProductAdvisor: Clasificación de Productos

Cruzando la enorme cantidad de datos que genera la interacción de los usuarios con nuestros productos, es capaz de detectar aquellos que necesitan atención, dividiéndolos en los que tienen algún tipo de problema, y los que son oportunidades claras de negocio, y que deberían destacarse. Por supuesto, también detecta aquellos sobre los que de momento no hace falta preocuparse, y aquellos que realmente están funcionando mal.

Product Advisor ofrece:

  • Indicadores generales de la “salud” de nuestro catálogo: De manera gráfica, ProductAdvisor nos dice cómo se desempeña nuestro catálogo, permitiéndonos saber si nuestras acciones de mejora tienen o no el efecto deseado.

    ProductAdvisor: Insights

  • Contraste estadístico de acciones y cambios sobre los productos: en otras palabras, nos dice si las acciones que hemos tomado sobre un producto han surtido efecto o no y, si lo han hecho, si ha sido el efecto esperado.
  • Clasificación de productos según su potencialidad (Scoring): Product Advisor, ordena los productos según su “capacidad para ser vendidos”, permitiéndonos seleccionar fácilmente aquellos sobre los que debemos operar según la estrategia que se decida adoptar en un momento dado.
  • Tecnología Google © de visualización e interacción mediante Motion Charts:
    ProductAdvisor: Motion Chart
    Los Motion Charts nos permiten seguir la evolución de las visualizaciones y las ventas de los productos en el tiempo, ofreciendo así una perspectiva completa del interés que despiertan en los usuarios.
  • Exportación del listado de productos sobre los que se debe actuar: para facilitar al máximo las labores de los responsables de e-commerce, Product Advisor permite exportar la lista de productos que necesitan atención, ya sea porque tienen problemas, ya sea porque son productos de gran potencial, que no se está explotando.

Disfrute gratuitamente de producto Advisor  Instale la versión gratuita y podrá operar con él un máximo de 100 visualizaciones y 100 productos.

Comenzar a utilizar de Product Advisor es muy sencillo: si no tenemos instalada una herramienta de análisis web (o estamos utilizando una herramienta distinta a Google Analytics), basta con insertar un simple código en la página de producto, y otro en la página de agradecimiento de la venta.

Si se usa Google Analytics, sólo es necesario hacer una mínima adaptación del código original.

Analítica web, y el desafío de dotarse de las herramientas adecuadas

19/07/2011 a las 13:38

En Metriplica ayudamos a las empresas a que “midan mejor”, para resolver la pregunta del millón: ¿Qué podemos hacer para optimizar un site y que haga aquello que nosotros queremos que haga? Por ejemplo: que venda más, que la gente se registre más, o que la gente lea más contenidos…

En este vídeo, Enric Quintero, director de Metriplica explica claramente, qué es optimizar una web, pero basándose en los números, y no en la intuición.

También nos introduce en el concepto del testeo, entendido como experimentos controlados y estadísticamente contrastados, que nos dicen qué combinación de elementos funcionan mejor y hacen que una página consiga más conversiones.

Ante la pregunta de ¿quién decide cuando hay que hacer cambios en una web?, la respuesta ya no debe ser “el jefe, el de marketing, el webmaster, el de sistemas, o el diseñador”. La respuesta debe ser “los visitantes”.

Cómo usar la Analítica Web para crear campañas eficientes en Adwords (3/3)

07/06/2011 a las 17:53

Logo de Google Adwords

En semanas anteriores publicamos los primeros dos posts de esta esta serie. En el primero hablamos sobre los tipos de campañas, y la asignación de valor a los objetivos de un website. En el segundo repasamos las métricas necesarias para medir la rentabilidad de nuestras campañas en Adwords.

Se supone que ya tenemos los datos en la mano, así que ahora se trata de empezar a ganar dinero. Ya es hora de hacerle honor al título del post así que, sin más dilación, entremos en materia:

Optimización de las campañas en Adwords

Veamos… Como hemos dicho al principio, si las columnas de ROI y Beneficio Neto están en rojo, no hay que pensárselo mucho: es mejor parar la campaña, y redefinirla. Nos estamos gastando más dinero en la campaña, que lo que estamos obteniendo gracias a ella. Eso puede suceder por varias razones:

  • Las palabras clave no son las adecuadas,
  • los anuncios no llaman la atención,
  • las páginas de aterrizaje no cumplen con las expectativas del usuario,
  • no se están efectuando conversiones (aunque las palabras clave, los anuncios o las páginas de aterrizaje estén bien).

Cursos de medición web gratis

19/04/2011 a las 20:13

¿Quieres saber cómo mejorar la tasa de conversiones de tu site? Metriplica ofrece cursos gratuitos de Analítica Web en el Cibernàrium, el programa de capacitación y divulgación tecnológica de Barcelona Activa – Ajuntament de Barcelona.

Estos  cursos están destinados a profesionales, empresas y a todos aquellos que deseen aprender lo básico, y lo no tan básico, de la optimización web.

En los cursos de Metriplica aprenderás, entre otras cosas conceptos como “Adquisición”, “Conversión” y Retención”, y conocerás el papel que juegan las fuentes de tráfico, la información transaccional, la opinión de los usuarios y los aspectos técnicos en el rompecabezas de la Analítica Web.

Como medir las visitas y los resultados de tu web

En este video, Enric Quintero, Socio-Director de Metriplica, explica en detalle algunas de las ideas que se mencionan en este post.

Nota: los cursos avanzados del Cibernàrium se imparten en el Nou Centre de Capacitació tecnològica per a Professionals i Empreses, en el Edificio MediaTIC. Los cursos de iniciación en  Internet tienen lugar en l’espai Cibernàrium, del Parc Tecnològic Barcelona Nord.

Qué tener en cuenta a la hora de lanzar un test con Optimizer I

20/12/2010 a las 13:01

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.

Se advierte al usuario del uso de cookies propias y de terceros de personalización y de análisis al navegar por esta página web para mejorar nuestros servicios y recopilar información estrictamente estadística de la navegación en nuestro sitio web. Política de cookies Acepto