Analytics Premium ComScore ClickTale Analytics Certified Partner Klipfolio Coremetrics

Google Data Studio: adiós al límite de 5 informes

02/02/2017 a las 19:32

A partir de hoy, la versión gratuita de Data Studio, la solución de Google para la creación de cuadros de mando e informes que os presentamos en su día,  ya no nos va a limitar a 5 informes o reports por cuenta.

Y como esa era la única diferencia entre esta versión y la de pago (Data Studio 360), Google dejará de cobrar por la segunda durante el resto de 2017 a los clientes que la tuvieran contratada.

Data Studio: ejemplo de cuadro de mando (Fuente: Google)

Un ejemplo de cuadro de mando realizado con Data Studio (Fuente: Google)

 

Entendemos la decisión de Google porque conocemos bien la herramenta. Estamos certificados, trabajamos con ella y seguimos de cerca los avances y novedades que se van incorporando. Es sólida y su amigable interfaz permite crear cuadros de mando muy completos en poco tiempo. Pero es una beta y se nota: se echan de menos conectores con más fuentes de datos dsitintas, por ejemplo. Y también había algunas carencias de partida difíciles de explicar, como la ausencia de semanas ISO en los selectores de periodo. Esta en concreto, fue subsanada hace unos días y ya es posible, al fin, seleccionar semanas comenzando por el lunes.

data studio beta logo

Google está mejorando Data Studio rápidamente y teniendo en cuenta las sugerencias de los usuarios. La propia herramienta nos enlaza con el foro oficial desde la ayuda, animándonos a participar. A mejoras como las nuevas opciones en los selectores de fechas, se van a ir uniendo otras muy demandadas como los segmentos avanzados en el conector con Google Analytics.  Cuando la palabra “beta” desaparezca de su nombre, si el ritmo de mejora no decae, podemos llegar a tener una herramienta bastante completa y potente.

Para terminar, es importante remarcar que está previsto que algunas de las características que están por llegar no estén pensadas para ofrecerse en una herramienta gratuita, lo que justificará volver a comercializar una versión 360 de pago en un futuro.

Podéis leer el comunicado oficial de Google aquí.

Y si no conocéis todavía Data Studio, un buen comienzo puede ser este video:

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.

Analiza tus productos con todo lujo de detalle

29/03/2016 a las 11:06

Analiza tus productos con todo lujo de detalle

 

Google Analytics, y especialmente con el comercio electrónico mejorado que ya os ayudamos a saber implementar,  nos permite medir el desempeño de los productos o servicios individuales que ofrecemos en nuestra web.

En los informes estándar, podremos analizar cuánto hemos vendido de cada uno de ellos, por ejemplo. Y con el comercio electrónico mejorado, incluso el porcentaje de veces que un producto visto fue añadido al carrito o comprado.

 

POST_DR_METRICS_Dimensiones personalizadas de producto_2

 

Pero en muchas ocasiones, los análisis los haremos agrupando dichos productos en categorías u otra clase de agrupaciones con algo en común.

Podemos segmentar o filtrar en base a la información que recogemos de los productos:

  • Nombre
  • Identificador
  • Precio (usando como criterio que estén en una franja u otra, por ejemplo)
  • Marca
  • Categoría (en el comercio electrónico, la categoría puede estar compuesta de hasta 5 niveles).
  • Variante (colores, tallas, etc.)
  • Cantidad
  • Cupón (para cuantificar la influencia de ofrecer o no descuentos)

Pero, ¿y si esta información se nos quedara corta? ¿Y si nuestro producto es muy complejo y está definido por una gran cantidad de variables por las que podría interesarnos analizar su desempeño?

Imaginemos que nuestro negocio es una inmobiliaria, y nuestra transacción, la solicitud de visita a un inmueble. A la hora de buscar vivienda o local, se van a tener en cuenta factores como el número de habitaciones, la superficie útil, cercanía a ciertos servicios, si tiene ascensor o no, etc. Si disponemos de esa información y permitimos al usuario realizar búsquedas filtrando por ella, ¿por qué no recogerla también en las transacciones? Podríamos, de manera sencilla y sin salir de Google Anaytics, analizar la influencia en la tasa de conversión de todos y cada uno de los posibles valores para esas variables.

Aquí es donde entran en juego las dimensiones personalizadas, que tanta flexibilidad aportan a la herramienta. La aparición de las dimensiones y métricas personalizadas de ámbito “producto” facilitan mucho su uso en el ecommerce a la hora de la implementación.

 

POST_DR_METRICS_Dimensiones personalizadas de producto_3

 

¿Cómo pasamos sus valores a Google Analytics?

Si estamos implementando con Google Tag Manager (lo más recomendable), el código para un producto en el comercio electrónico mejorado o enhanced ecommerce tendría este aspecto:

‘products’: [{  

        ‘name’: ‘Nombre del producto’,

        ‘id’: ‘123456’,

        ‘price’: ‘1000.00’,

        ‘brand’: ‘Marca del producto’,

        ‘category’: ‘Textil/Hombre/Camisas/Manga larga/Algodón’, // categoría (hasta 4 posibles niveles de subcategoría)

        ‘variant’: ‘Blanca’, // variación que no implica un cambio de identificador de producto

        ‘quantity’: 1, // Cantidad del producto adquirida

        ‘coupon’: ” // Descuento a nivel de producto individual

       }]

Si quisiéramos “enriquecer” la información recogida mediante dimensiones personalizadas de ámbito “producto”, tan sólo tendríamos que añadirlas a la lista de variables estándar:

‘products’: [{  

        ‘name’: ‘Nombre del producto’,

        ‘id’: ‘123456’,

        ‘price’: ‘1000.00’,

        ‘brand’: ‘Marca del producto’,

        ‘category’: ‘Textil/Hombre/Camisas/Manga larga/Algodón’, // categoría (hasta 4 posibles niveles de subcategoría)

        ‘variant’: ‘Blanca’, // variación que no implica un cambio de identificador de producto

        ‘quantity’: 1, // Cantidad del producto adquirida

        ‘coupon’: ”, // Descuento a nivel de producto individual

        ‘dimension1’: ‘valor para la dimensión 1’,

        ‘dimension2’: ‘valor para la dimensión 2’,

        ‘dimension3’: ‘valor para la dimensión 3’

      //y así con todas las dimensiones que necesitemos (y de las que dispongamos).        

       }]

La correspondiente etiqueta de GTM, cuando detecte la transacción y la envíe a Google Analytics, enviará automáticamente y sin que tengamos que hacer nada, toda la información adicional que hemos asociado a los productos.

Es decir, no habrá que definir variables en GTM que recojan esa información adicional ni tendremos que especificar en la etiqueta de la transacción qué variable corresponde con cada dimensión personalizada. Es por esto que sea necesario referirnos en el datalayer a las dimensiones de esa manera (‘dimension1’ por ejemplo) y no por su nombre (‘Número de habitaciones’ en el ejemplo de la inmobiliaria).

Ahora solo quedaría analizar nuestros productos utilizando estas nuevas variables como dimensiones secundarias en los informes estándar o mediante informes personalizados.

Desde luego, si el producto tiene cierta complejidad y disponéis de dimensiones personalizadas libres, os animamos a “enriquecer” de esta manera tan sencilla pero potente vuestras implementaciones.

 

¿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.

Cómo conocer la ruta del consumidor y el aporte de cada canal digital

13/02/2015 a las 10:41

 

Por Cristóbal Bello.

 

Desde el momento en que  se comenzaron a conocer las métricas de conversiones asistidas en Google Analytics, se abrió una nueva manera de analizar la ruta del consumidor o el “consumer journey”. Dándole una nueva perspectiva a las personas en marketing de cómo funciona (o trabajan en equipo) los canales, como mailing, search, social media o display en la generación de conversiones o ingresos.

Cabe destacar que no todas las marcas y sus acciones generan una ruta del consumidor larga, más bien algunas resultan cortas, ya que depende del tipo de conversión, lead, tipo de producto que cada sitio posea.

Desde el punto de vista del tiempo, para saber si la ruta es larga o corta, es decir si se toman muchos o pocos días antes de generar una conversión, hay que observar el reporte de lapsos de  días en el menú de conversiones

Conversiones -> Embudos Multi-Canal -> Lapso de Tiempo

post_crist_1

Si un porcentaje representativo de conversiones  está sobre cero días, vale la pena conocer un par de datos más. Para eso hay que ir a:

Conversiones -> Embudos Multi-Canal -> Conversiones por Contribución

post_crist_2

 

DEFINIENDO LAS MÉTRICAS

1. Las conversiones por contribución

Son la cantidad de compras y leads,  donde cada canal descrito a nivel de fila ha contribuido conversiones sin ser  el canal de último clic o el último de la ruta

2. El valor  de las conversiones asistidas.

Simplemente es el dinero que estos canales generaron sin ser el último canal de la ruta.

3.Conversión de último clic o directa.

Es la cantidad de compras y leads provenientes de la última fuente de tráfico previa a la conversión.

4.Valor de las conversiones por interacción de último clic o directa.

El dinero que estos canales aportaron de dicha manera.

¡Y la última métrica! (y relevante en este post):

5. Conversiones de contribución/de interacción de último clic o directa.

Esto es una relación expresada con una simple división:

post_crist_3Cuando el resultado es cercano a 0 quiere decir  que existen pocas conversiones por contribución  y el  canal funcionan de manera más directa.

Cuando el resultado es igual a 1, quiere decir que la cantidad conversiones por contribución son  iguales a las de último clic.

Cuando el resultado es mayor a uno quiere decir que las conversiones por contribución son mayores y el canal aporta más asistiendo.

Esto nos indica en que etapa de la ruta a la compra funcionan  los medios. Por ende, cada canal lo podemos agrupar por su valor en las famosas etapas como se muestra a continuación, dibujando finalmente el consumer journey.

post_crist_4

 

post_crist_5Es interesante darse cuenta de como se comporta los medios digitales según la naturaleza de cada sitio, por ejemplo:

–          El  resultado número  1, posee a los canales más dispersos, y varios que actúan más de manera indirecta que directa, influenciado por el hecho de que la conversión es una compra.

–          En el resultado numero 2 los canales resultan ser todos directos, influenciado  por que la conversión es una solicitud de contacto, existiendo una ruta más corta en comparación con el primer resultado.

TAKE AWAYS

Para las marcas, entender la manera en que la audiencia interactúa con ellas y el camino que generan resulta relevante, ya que entrega un entendimiento, mapeo y posibilidades de mejoras hacia el cliente. Esto, desde el punto de vista de interferir de mejor manera en la comunicación de los canales, sabiendo como influye  cada uno en la venta final.

Por un camino paralelo, resulta interesante poder conocer como influye cada campaña  pagada en search o inclusive cada keyword. Esto permite por ejemplo cuestionarse la táctica de landing pages según posición de campañas, u optimizar keywords solo de last click, o potenciar orgánicamente nuevas keywords. El juego aquí será amplio, dependiendo de  cuantas campañas, y cuánto y cómo influyan en la ruta de compra.

PD: Google Analytics permite obtener estas métricas y  analizarlo a nivel únicamente de  AdWords

Por último, hilar en lo más fino va a consistir en evaluar cual  vendría siendo el mejor modelo de atribución en base a la realidad de cada sitio. Existen 7 modelos de atribución, el más usado por defecto es el de last click, pero lo visto anteriormente crea la oportunidad de volver a optimizar el presupuesto desde otros puntos de vista.

NOTA

Comprender como se recopilan los datos de atribución que posee Google puede resultarte importante (lo es 🙂 ). Para ello, recomiendo leer esta ayuda de google.

 

 

 

Posibles errores en el envío de eventos a través de GTM

13/01/2015 a las 11:51

 

peligro

 

A estas alturas, nadie duda de la comodidad (y la conveniencia en el 99% de los casos) de implementar Google Analytics a través de un gestor de etiquetas como Google Tag Manager (alias GTM). Pero hay que tener cuidado y saber muy bien como funciona para evitar errores como el que vamos a ver a continuación.

En una implementación directa, enviábamos los eventos mediante la inserción en nuestra página de un código con la siguiente sintaxis:

ga(‘send’,‘event’,‘category’,‘action’,‘label’, value);//value es un entero.

Ejemplo:  ga(‘send’,‘event’,‘button’,‘click’,‘nav buttons’,4);

Label y value son opcionales.

Con una implementación mediante GTM, ponemos esos datos en una estructura de datos llamada datalayer: 

dataLayer.push({‘event’:’eventoGA’,’category’:’<event_categoria>’,’action’:’<event_accion>’,’label’:’<event_label>’,’value’:<event_value>});

Los recogemos de ella mediante una etiqueta de GTM que detecta que se ha producido un evento. Normalmente (y ahí está el problema), utilizamos etiquetas genéricas, que sirvan para todos los eventos posibles:

 

GTM_events_1

 

GTM_events_2

 

 

GTM_events_3

 

El datalayer es una estructura de datos persistente a nivel de página. Es decir, mantiene sus valores mientras no abandonemos la página actual (o los modifiquemos mediante una acción datalayer.push).

Movidos por la costumbre de cuando implementábamos directamente, cuando hemos de registrar un evento para el que no necesitamos los valores opcionales label y/o value, no los incluimos en el datalayer.push:

dataLayer.push({‘event’:’eventoGA’,’category’:’<event_categoria>’,’action’:’<event_accion>’});

Pero ojo, que ésto no manda el evento a Google Analytics. Es GTM quien lo hace. Y si utilizamos una etiqueta genérica como la que mostrábamos más arriba, estará enviando también valores para label y value. Presuntamente, no hay valores para ellos, por lo que enviará valores nulos, tal y como pretendemos.

Pero, ¿qué ocurre cuando en esa misma página se ha lanzado previamente un evento que sí utilizaba los citados parámetros opcionales? Al ser el datalayer persistente mientras no abandonemos la página actual, lo que ocurrirá será ésto:

 

EVENTO A :

dataLayer.push({‘event’:’eventoGA’,’category’:’ev_A_cat’,’action’:’ev_A_act’,’label’:’ev_A_lab’,’value’:9.99});

Lo que recogeremos y enviaremos a Google Analytics mediante GTM será:

Categoría: ev_A_cat

Acción: ev_A_act

Etiqueta: ev_A_lab

Valor: 9.99

 

EVENTO B (posterior al A, en la misma página, no usa label ni value) :

dataLayer.push({‘event’:’eventoGA’,’category’:’ev_B_cat’,’action’:’ev_B_act’});

Lo que recogeremos y enviaremos a Google Analytics mediante GTM será:

Categoría: ev_B_cat

Acción: ev_B_act

Etiqueta: ev_A_lab

Valor: 9.99

Nuestra etiqueta de GTM está buscando en el datalayer valores para esos dos últimos parámetros y los encuentra.

Puede parecer que no es un error grave (no se alteran los datos que sí necesitamos para los eventos de tipo B, pero si posteriormente realizáramos un análisis en base al número de eventos con un valor u otro en “etiqueta” o “valor”, obtendremos un número mayor del real de eventos que cumplan el criterio.

Para evitar que se nos “ensucien” los datos de eventos, proponemos dos soluciones:

A) Hacer etiquetas y reglas diferentes para eventos que no usen los campos opcionales. Por ejemplo, podríamos tener un evento de tipo ‘eventoGA1’ que solo usa categoría y acción y otro, ‘eventoGA2’, que los use todos. Habría una etiqueta para cada uno de ellos que solo enviaría a Google Analytics los valores requeridos. La regla que las dispararía comprobaría que el evento sea del tipo correspondiente:

 dataLayer.push({‘event’:’eventoGA1’,’category’:’ev_A_cat’,’action’:’ev_A_act’,’label’:’ev_A_lab’,’value’:9.99});

 dataLayer.push({‘event’:’eventoGA2’,’category’:’ev_B_cat’,’action’:’ev_B_act’});

B) Actualizar todos los parámetros en el datalayer para todos los eventos. Es decir, tratándolos como si no fueran opcionales. Esto nos permitiría mantener en GTM una etiqueta de gestión de eventos genérica. Dicha etiqueta mandaría siempre a Google Analytics todos los parámetros de evento, incluidos los opcionales. Pero, para los eventos que no los necesiten, pasaríamos sus valores a nulo (usando solo las comillas como valor):

dataLayer.push({‘event’:’eventoGA’,’category’:’ev_B_cat’,’action’:’ev_B_act’,’label’:”,’value’:”});

Nos inclinamos por la segunda opción. Mantiene una estructura más sencilla en el contenedor de GTM y no implica más trabajo de implementación en la web.

 

Medición de aperturas de una app desde referentes

02/12/2014 a las 11:05

 

pescando_smartphone

 

Excepto en aplicaciones de pago para smartphones (y ni tan siquiera en ellas, si lo pensamos bien), de poco sirve que los usuarios descarguen nuestras apps si luego no las van a utilizar o si las abandonan al poco tiempo de empezar a usarlas.

Quitando los casos de terminales con escasa capacidad de almacenamiento o de usuarios celosos de mantener “limpio” su equipo, muchos ni se molestan en desinstalarlas. Y es ahí donde podemos realizar algún intento de reactivación . Algunas apps utilizan un sistema de notificaciones para ésto, pero requiere su implementación y es posible desactivar las notificaciones por parte del usuario, por lo que no siempre funcionaría.

Una alternativa más sencilla a este tipo de intentos se puede emplear cuando la instalación de la app implicó alguna clase de registro y disponemos de las direcciones de correo electrónico a las que enviar una campaña a través de ese medio. En el mensaje que enviaremos, podemos  informar de las novedades y mejoras que hayamos podido introducir en la aplicación y animar a seguir usándola, incluyendo un enlace a la misma, la clave de este asunto.

En cualquier caso, sea cual sea el tipo de campaña de “repesca” que planeamos lanzar, os habréis dado cuenta de que cuando tocamos sobre un hipervínculo en nuestro smartphone o tablet, el sistema operativo nos da la opción de elegir la aplicación con la que lo podemos abrir.

Por ejemplo, para un enlace como el siguiente:

https://play.google.com/store/apps/details?id=com.mi_app&hl=es

Android nos mostraría las siguientes opciones:

 

completar_accion_con

 

Para que una aplicación esté incluida en la lista de aspirantes, en el fichero AndroidManifest.xml (para Android) o info.plist (para IOS) asociado a ella, debemos haber definido con qué tipo de protocolos es capaz de lidiar (https en este caso).

Para nuestra app, cuyo lanzamiento queremos provocar desde un enlace, podríamos incluso inventarnos el nombre de un protocolo, de manera que no haya otra app capaz de abrirlo y lo haga la nuestra directamente.

 

ANDROID:
Añadir tras <activity>:

<intent-filter>
<action android:name=”android.intent.action.VIEW” />
<category android:name=”android.intent.category.DEFAULT” />
<category android:name=”android.intent.category.BROWSABLE” />
<data android:scheme=”xxx” android:host=”yyy”/>
</intent-filter>

IOS:
<key>CFBundleURLTypes</key>
<array>
     <dict>
          <key>CFBundleURLName</key>
          <string>com.standalone.[ nombre de la app]</string>
          <key>CFBundleURLSchemes</key>
          <array>
                <string>xxx</string>
         </array>
    </dict>
</array>

 

Donde ponemos xxx figuraría el nombre o siglas para  el tipo de llamada ante la que respondería la aplicación. El host yyy sería el dominio ficticio que constaría en la llamada. Y el enlace que insertaríamos en el código HTML de nuestra campaña (anuncio en una web, correo, otra app, etc.), sería algo así (etiquetado para Google Analytics):

 

<a href=”xxx://yyy/?utm_source=Newsletterdeprueba&utm_medium=Email&utm_campaign=te_echamos_de_menos”>Pincha para abrir la app</a>

 

Es importante que este enlace incluya los parámetros de campaña habituales, ya que luego los recogeremos desde la app para atribuir la sesión al referente adecuado.

Google nos facilita el código que habría que añadir en la aplicación para realizar esa tarea, por lo que bastará con copiarlo en ella.

 

ANDROID: https://developers.google.com/analytics/devguides/collection/android/v3/campaigns

IOS: https://developers.google.com/analytics/devguides/collection/ios/v3/campaigns

 

Con estas sencillas modificaciones seremos capaces de medir en Google Analytics la efectividad de nuestros esfuerzos a la hora de recuperar a esos usuarios que perdieron interés por nuestra aplicación para smartphone o tablet.

ga_app_adq

 

Metriplica, el mejor servicio de analítica web 2014

04/11/2014 a las 16:52

premio

No lo decimos nosotros, sino quienes han confiado en nuestra propuesta y nos han dado su apoyo y reconocimiento. A todos ellos, clientes, colegas de profesión, compañeros de viaje y amigos, les damos nuestro más sincero agradecimiento y les dedicamos este premio, el eawards Madrid 2014 como “Mejor servicio de Analítica Web“, categoría donde, tras ser seleccionada de una amplia lista de candidatos, Metriplica era finalista.

Los eawards, premios a los mejores negocios online, contaron este año con la participación de 151 candidatos, que se presentaron en distintas categorías tales como “Mejor empresa de Social Media”, “Mejor servicio de logística”, “Mejor agencia de creación y diseño de Tiendas Online”, entre otras.

Y es que, pese a haber sido pioneros en España en temas de analítica web, seguimos innovando con servicios como la medición de tiendas físicas, divulgando mediante nuestro blog y nuestras participaciones en diversos eventos y foros de encuentro, así como formando a través de nuestros cursos online.

Esperamos poder seguir haciéndolo por muchos más años, porque detrás de todo ello, lo que hay es un equipo de personas apasionadas por su trabajo, que no escatiman en esfuerzo, dedicación e ilusión ni un solo día.

Gracias de nuevo de parte de todos nosotros: Anna, Dani, David, Enric, los dos Felipes, Fernando, Julià, María, Marta, Nuria, Pol, Raúl, Richard, Vicente, Xavi, así como los que formaron parte del equipo en algún momento y los que se van a incorporar a esta gran familia que no para de crecer.

img_821

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.

 

El modelo de atribución basado en datos

20/05/2014 a las 09:56

data-driven-hero-v2

Fuente: http://analytics.blogspot.com.es/

 

Una funcionalidad de Google Analytics de la que no habíamos hablado todavía es Data-Driven Attribution o el modelo de atribución basado en datos.

Establecer un modelo de atribución multicanal realista es complejo y, normalmente, algo que hacemos utilizando criterios bastante subjetivos. Sabemos las combinaciones de canales que mejores resultados nos están dando, pero es difícil valorar el mérito de cada integrante de esas secuencias de contacto. Con esta funcionalidad, Google Analytics nos ahorra ese trabajo. Y, además, lo hace de una manera algorítmica.

Utiliza como base la información de rutas de conversión del embudo multicanal, así como los datos de flujo de comportamiento de aquellos usuarios que no convierten.  Para ser más concretos, además de los datos del tráfico procedente de búsquedas orgánicas, del directo y del de referencia, el método Data-Driven Attribution analiza los datos de todos los productos de Google que hayamos enlazado con Analytics, como AdWords, la red de display de Google o DoubleClick for Advertisers. También incorpora la información de costes que hayamos podido importar. Necesitaremos, como es natural, tener activo el seguimiento de comercio electrónico y definidos los objetivos.

Con toda esta información, detecta cómo la presencia de un punto de contacto comercial en particular (definida por el tipo de canal y su posición relativa a otros puntos de contacto) se relaciona con cambios en la tasa de conversión.

 

Ejemplo de modelo

Informe del explorador del modelo. (Fuente: http://analytics.blogspot.com.es/)

Es decir, los modelos probabilísticos resultantes muestran la probabilidad de que un usuario realice una conversión en un punto determinado de la ruta, dada una secuencia particular de eventos. Es importante destacar que el algoritmo tiene en cuenta el orden en el que un determinado punto de contacto entra en juego. Por ejemplo, “Display precediendo a Búsqueda de Pago” se modela por separado de “Búsqueda de Pago precediendo a Display”.

Vemos un ejemplo (simplificando un poco): Tenemos una combinación de Búsqueda Orgánica, Display e Email (en ese orden) que arroja un 3% de probabilidades de conversión. Cuando eliminamos Display, la probabilidad baja a un 2%. El incremento del 50% observado cuando Display está presente sirve de base para el cálculo de atribución.

data-driven-how-it-works

Fuente: http://analytics.blogspot.com.es/

No solo es una manera mucho más avanzada de establecer el modelo sino que, así como la información en la que se basa es cambiante en el tiempo, también lo es el modelo, que se autoajusta en función esas posibles variaciones. Una vez habilitada esta funcionalidad, comienza inmediatamente a recoger datos. Tendremos el primer modelo a los 7 días, actualizándose éste con una frecuencia semanal.

Aunque el algoritmo utilizado es el que desarrolló el premio Nobel de economía Lloyd S. Shapley para la justa distribución de los resultados de un equipo entre sus miembros, el analista no tiene por qué abandonar su actual modelo de atribución para abrazar “a ciegas” el nuevo que nos presenta Google. Éste está disponible junto a los tradicionales en la herramienta de comparación de modelos de atribución y en el informe de análisis del ROI.

Desde este último, si vemos que ciertos canales tienen un éxito mucho mayor que el resto (mejores valores para el ROAS o el CPA, por ejemplo) según los cálculos obtenidos por el modelo de atribución basado en datos, podemos plantearnos incrementar nuestra inversión en dichos canales. En la misma línea, si detectamos canales que no funcionan bien bajo el prisma de este modelo, deberíamos revisar nuestra estrategia de marketing al respecto y optimizar nuestros  esfuerzos en ellos.

Podemos, y así lo recomiendan desde Google, ir adquiriendo confianza en el modelo gradualmente, poniéndolo a prueba de manera controlada. Se trataría de trabajar sobre combinaciones concretas de canal y tipo de objetivo que éste nos destaque (por el lado positivo o todo lo contrario) y verificar después si el resultado es el previsto. Llegados a un punto, podríamos dejar de lado las comparaciones con anteriores modelos y trabajar en exclusiva con éste.

De hecho, si nuestro negocio online está arrancando, no tendremos más remedio que comenzar a trabajar con uno de los modelos basados en reglas hasta alcanzar el volumen de datos de entrada mínimo a partir del cual puede realizar sus cálculos el nuevo: 10,000 rutas y 400 conversiones por tipo al mes.

En resumen, el modelo de atribución basado en datos es una estupenda funcionalidad. Con los modelos actuales ya vemos qué secuencias de canales funcionan mejor. Con el que estamos tratando, vamos un paso más allá y obtenemos una medida de la efectividad de cada canal en cada posición de esas secuencias. Es más, combinando esos valores con los datos de e-commerce y de costes de campaña, obtenemos un cálculo adecuadamente ponderado de su rentabilidad.

Por último,hay que señalar que se trata de algo concebido para la versión Premium de Google Analytics, sin previsión de incorporarlo también a la versión gratuita. Casi un año después, sigue estando solo disponible para la herramienta de pago y sin visos de que esto cambie. Un aliciente más (y no pequeño) para que todos aquellos a los que nos preocupa la precisión a la hora de evaluar la rentabilidad de nuestras campañas de marketing, demos el paso hacia la “hermana mayor” de esta herramienta de analítica web.

 

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