Tags populares:

Creando evento de Scroll Depth en Google Tag Manager V2

17/04/2015 a las 17:55

¿Podemos medir el comportamiento de un usuario en un sitio de una página (one page)? ¿Cómo podemos saber cuánto contenido vio? ¿Podemos obtener más datos relacionados a lo qué está viendo este usuario en el sitio?

Para todas estas preguntas la respuesta es simple, si por casualidad tienen un blog con gran cantidad de posts en el home, tienen un sitio one page  de esos que son tan populares hoy o también puede ser que tengan un diario con toda la información desplegada en una sola página, la solución a sus problemas de medición ya es cosa del pasado. Ahora solo hay que medir el avance del scroll en el sitio web para saber qué porcentaje de la página o landing está viendo el usuario.

¿Y cómo hacemos eso?, con la buena ayuda de Don Google Analytics y su hermano Tag Manager.

A continuación, les presento una guía para crear un evento Scroll Depth en sus sitios webs, pero con la última versión de Tag manager. Me imagino que ya varios saben que hace algún tiempo Google Tag Manager  lanzó su nueva versión, este cambio significa tener que familiarizarse con la nueva interface y migrar aquellas cuentas que teníamos en nuestro antiguo Tag Manager.

Entonces, ¿qué necesitamos para crear este evento?

  • Google Tag Manager V2
  • Google Analytics (Universal Analytics a través de Tag Manager)
  • jQuery 1.7 o superior (necesario para el script Scroll Depth)wp7d03dd5e_05_06

¿Y qué es el Scroll Depth?

Es un script que nos permite medir los movimientos del scroll, o mejor dicho, el avance del scroll en la web cuando un usuario interactúa con el contenido. Cuando el usuario avanza un cierto porcentaje en el sitio, va marcando la longitud (Baseline o 0%, 25%, 75% y 100%). Pero eso no es todo, además mide otros eventos como avances de scroll en pixeles, tiempo de éstos, entre otros datos.

¿Dónde podemos conseguirlo?

Pues directamente en la web del creador, haciendo clic acá.

PASO1: creando una nueva etiqueta para el script Scroll Depth

Lo primero es ir a Tag Manager y crear una nueva etiqueta para el script, debemos seleccionar el producto “Etiqueta HTML personalizada” y pegar el código del script que les dejo más abajo.para agregar nueva etiqueta hoome

nueva etiqueta sin titulopegar codigo scrip

Debemos pegar el código del script, el cual lo pueden encontrar y copiar directamente haciendo clic acá. Pero antes de insertar el código, debemos escribir lo siguiente en el cuadro de HTML:

<script>  

ACÁ VA EL CÓDIGO

 jQuery.scrollDepth();

</script>

 

Y pegan el código donde les indico “ACÁ VA EL CÓDIGO”.

paso 3 activar en todas las paginas

Posterior a eso se debe elegir el activador de esta etiqueta, que puede ser “Todas las páginas” o “Algunas páginas”. Finalmente creamos la etiqueta y procedemos al PASO 2.

 PASO2: creando variables de capa de datos

Lo primero es crear una variable para “eventCategory” vía una capa de dato, por lo tanto vamos a ir al panel principal y le daremos clic a “Crear nueva variable”, una vez ahí elegimos el tipo “Capa de dato” y seguimos los pasos que se muestran en las siguientes imágenes.

2.1 Variable capa de dato

 

agregar variable capa de dato

 

2.2 Configurar variable con nombre eventCategory

variable event category

2.3 Crear variable y guardar con el mismo nombre.

event category creado

Repetimos lo mismo para eventAction y eventLabel, es decir, vamos a crear 2 variables más de “Capa de dato” para éstos. Luego revisamos en una vista previa de la web si están estas variables.

¿Cómo visualizar una vista previa?, es muy simple, solo tienen que darle al botón al costado derecho de “Publicar” y seleccionar “vista previa”, luego van al sitio web y refrescan, les saldrá una ventana en la parte inferior del sitio con información sobre el evento. En ella podremos ver los dataLayer y las variables que hemos creado.

generar vista previa

Entonces en la vista previa veremos lo siguiente.

Si se fijan, en “Data Layer Variable” aparecen eventCategory, eventAction y eventLabel, por lo que todo va de maravilla. Podemos seguir con el PASO3.

vista previa de variables

PASO3: creando la etiqueta del evento 

El último paso corresponde a crear la etiqueta del evento, la cual es de Google Analytics, por lo tanto vamos a seleccionar ese producto, luego la versión e ingresaremos el ID de seguimiento, luego seleccionaremos “Evento” en tipo de seguimiento y buscaremos las variables que creamos para colocarlas en categoría, acción y label, tal como se muestra en la imagen de más abajo.

crear la etiqueta del evento

Luego seleccionamos continuar y creamos un activador para esta etiqueta, un NUEVO activador.crear etiqueta de evento agregar activador

 

Creamos el nuevo activador que tiene que ser de tipo “Evento personalizado” y debe tener el nombre ScrollDistance, con un filtro donde indicaremos que se tiene que activar cuando el evento personalizado contenga ScrollDistance.

crear etiqueta de evento agregar activador 2 crear etiqueta de evento guardar activador

Ya tenemos todo listo, ahora solo queda guardar el activador y publicar. Pero si antes de publicar quieren ver que todo esté correcto, le dan nuevamente a visualizar una vista previa y van a la herramienta de “Google Analytics”, entran a la analítica en tiempo real y ven los eventos que ahí aparecen. Se debe ver el evento que hemos creado para poder medir el avance del scroll en el sitio.

 

evento listo verlo en ga 1evento listo verlo en google analytica

¿Adivinen qué?

Ya hemos terminado,  le damos a publicar y disfrutemos analizando nuestros nuevos  datos.

 

final y publicar

Ahora dispondremos de este interesante evento que nos aportara información valiosa relacionada con el comportamiento de los usuarios en el sitio y cuánto contenido visualizan en él. Este evento es sumamente útil para páginas que son únicas, así como para sitios que tienen una gran longitud, como los one page, diarios, una landing es especifica y blogs con una gran cantidad de información en sus sitios.

Y ahora mucho más fácil con nueva versión de Tag Manager.

scroll-depth-chart

 

¡Hasta la próxima!

Una conexión de titanes: Google Analytics y R Statistics

13/03/2015 a las 13:43

En este post vamos a ver cómo hacer la conexión entre dos de las herramientas más potentes que conozco: Google Analytics y R statistics. Pero antes de esto, voy a explicar brevemente qué es R statistics para aquellos que no lo conozcáis (Google Analytics creo que no necesita presentación en este blog).titanes

R Statistics es un entorno de software libre enfocado a la computación estadística y a la creación de gráficos estadísticos. Funciona por librerías y los usuarios pueden crear sus propias librerías para subirlas y que sean descargadas y utilizadas por otros usuarios después de la correspondiente revisión y validación de las mismas. Dicho de otra manera, se trata de un software estadístico libre muy potente que está en constante crecimiento ya que la comunidad va creando funciones, gráficos y demás. Al poseer una comunidad muy activa e inteligente, este método de funcionamiento hace que sea una herramienta inmensa y perfecta para trabajar con Big Data y hacer Data Mining. Para todos los que usamos R statistics desde hace tiempo, esta es la herramienta que nunca puede faltar en nuestros ordenadores, cosa que no resulta nada difícil ya que funciona en múltiples plataformas y es de acceso totalmente libre.

Hechas las presentaciones pertinentes, muchos de vosotros ya estaréis viendo el montón de posibilidades que se nos presentan si conseguimos una conexión cómoda y fluida entre R y Google Analytics. Evidentemente podríamos vivir sin dicha conexión, ya que siempre tenemos la opción de descargar los datos de un informe o del Query Explorer en formato “csv” y luego cargarlos en R. Pero ¿para qué perder tanto tiempo en todo este trajín de datos si podemos lanzar queries directamente a Google Analytics desde R? Veamos cómo hacerlo:

1) Lo primero que debemos hacer es acceder a nuestra Developer Console de Google y crear un proyecto. Esto es lo que nos dará las credenciales para crear el Token que nos permitirá conectar R con Google Analytics.

2) Una vez creado el proyecto, ya tenemos acceso a un Client ID y su Client Secret que son los valores que necesitamos para crear el Token desde R. Estos dos valores se obtienen en el apartado “Credentials” dentro de “APIS & auth” como podéis ver en la siguiente imagen.

Developers Console

3) Ahora que ya tenemos los valores necesarios, podemos hacer la llamada desde R. Como veréis en el siguiente código, antes de la conexión en sí debemos cargar las dos librerías necesarias para dicha conexión.

RGoogleAnalytics 1

4) Una vez lograda la conexión entre Google Analytics y Rstatistics ya podemos empezar la fiesta de las queries para extraer los datos que queramos. En este punto lo primero que debemos hacer es construir la query mediante las funciones “Init” y “QueryBuilder”, para después ejecutarla mediante la función “GetReportData”. A continuación os dejo un pequeño ejemplo para que veáis cual es la forma de utilizar estas funciones.

RGoogleAnalytics 2

Las limitaciones a las que estamos expuestos al realizar queries son  un máximo de 7 dimensiones y 10 métricas por query. Son unas limitaciones que pueden ser molestas en algún determinado momento, pero nada grave que no se pueda esquivar mediante algo de “magia” del Data Miner ;)

Después de la mala noticia comentaros que mediante el parámetro “paginate_query” de la función “GetReportData” podemos hacer que la propia función nos haga inmunes al límite de las 10.000 observaciones (filas) de Google Analytics; ya que hace que la función vaya haciendo llamadas de 10.000 filas en 10.000 filas y posteriormente haga el merge para que nosotros ya recibamos todos los datos en una única tabla lista para el análisis.

5) Y… ya está. Una vez llegados a este punto ya hemos conseguido tener nuestros datos en un data.frame de R listo para ser explotado y aprovechado al máximo por un buen estadístico/data scientist.

 

Espero que esta guía paso a paso sobre como conectar Google Analytics con R Statistics os sirva de mucha ayuda, que los que hayáis conocido R mediante este post os animéis a explorar esta herramienta tan potente e interesante y que vuestros análisis sean muy fructíferos (y que me lo contéis en los comentarios si os apetece, por supuesto).Ü

Depurando el Measurement Protocol

04/03/2015 a las 12:32

En este post vamos a ver como depurar los datos enviados a través del protocolo de medición, pero antes veamos que es el protocolo de medición.

El Protocolo de medición es una metodología que utiliza Universal Analytics para recopilar datos de cualquier dispositivo o sistema y enviarlos a sus servidores sin necesidad de usar un código de javascript como el que se utiliza para hacer la medición web.  Estos equipos / sistemas de los que podemos recoger datos pueden ser un smartphone, tablet PC, dispositivo digital, punto de venta, etc.

El envío de los datos

Para el envío correcto de los datos estos deben contener los siguientes parámetros:

  1. v - Se utiliza para indicar la versión del protocolo de medición. El valor de este parámetro debe ser 1.
    Por ejemplo: v = 1
  1. tid - Se utiliza para indicar el ID de seguimiento. El valor de este parámetro debe ser el UA de la cuenta de analytics a la que van a enviar los datos. Por ejemplo: tid = UA-12345-6
  1. cid – Se utiliza para indicar el ID de cliente (ID que identifica de forma anónima un determinado usuario, dispositivo o navegador y es única para el visitante / usuario en particular). El valor de este parámetro debe ser un identificador único universal aleatorio (UUID) como se describe aquí http://www.ietf.org/rfc/rfc4122.txt
    Por ejemplo: cid = 36009a59-2a05-49e7-b826-2b884d0f935b
  1. t - Se utiliza para indicar la tipología del hit. El valor de este parámetro debe ser cualquiera de los siguientes: ‘pageview’, ‘event’, ‘transaction’, ‘social’, ‘item’, ‘exception’, ‘appview’ o ‘time’
    Por ejemplo: t=pageview o t=event …..

 

Hay muchísimos campos que pueden contener gran variedad de datos, como no podemos nombrarlos todos o el post no se acabaría nunca aquí podréis encontrar todos los campos que se pueden enviar:

https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters
Normalmente enviaremos los datos a http://www.google-analytics.com/collect?

Y la estructura seria la siguiente: http://www.google-analytics.com/collect?[datos a enviar]

Así que, por ejemplo, vamos a enviar un hit de pageview a nuestra web (www.miweb.com), y lo haríamos de la siguiente manera:

http://www.google-analytics.com/collect?v=1&tid=UA-12345-6&cid=35009a79-1a05-49d7-b876-2b884d0f825b&t=pageview&dp=/ 

measurement-protocol  

O podemos enviar un evento:

http://www.google-analytics.com/collect?v=1&tid=UA-12345-6&cid=35009a79-1a05-49d7-b876-2b884d0f825b&t=event&ec=home&ea=download&el=guide

 measurement-protocol

 La depuración de los datos

Ya hemos hecho todo lo indicado anteriormente para enviar datos siguiendo el protocolo de medición, ¿pero como podemos verificar que se estamos enviando los datos correctamente?

Pues Google ha lanzado el Measurement Protocol Validation Server  en una versión beta. Esta será una herramienta para depurar problemas con los hits que se generan sin una de nuestras bibliotecas de cliente. Se puede enviar hits a este servicio y esperar una respuesta en JSON con detalles si está todo correcto o si ha habido algún problema.

Por ejemplo al enviar un hit no válido como: https://www.google-analytics.com/debug/collect, la herramienta responderá lo siguiente:

{
"hit_parsing_result":[{
"valid":false,
"parser_message":[{
"message_type":3,
"description":"A value is required for parameter 'v'. Please see http://goo.gl/a8d4RP#v for details.",
"message_code":2,
"parameter":"v"
},
{
"message_type":3,
"description":"Tracking Id is a required field for this hit. Please
see http://goo.gl/a8d4RP#tid for details
."
}],
"hit":"GET /debug/collect HTTP/1.1"
}]
}

 

Igualmente si enviamos una solicitud valida como la que creamos anteriormente:

http://www.google-analytics.com/collect?v=1&tid=UA-12345-6&cid=35009a79-1a05-49d7-b876-2b884d0f825b&t=pageview&dp=/
la herramienta responderá con:

{
"hit_parsing_result":[{
"valid": true,
"parser_message": [ ],
"hit": "GET /debug/collect?v=1\u0026tid=UA-12345- 6\u0026cid=35009a79-1a05-49d7-b876-2b884d0f825b\u0026t=pageview\u0026dp=/ HTTP/1.1"
}]
}

 

Y lo mismo para el evento que creamos anteriormente:

http://www.google-analytics.com/collect?v=1&tid=UA-12345-6&cid=35009a79-1a05-49d7-b876-2b884d0f825b&t=event&ec=home&ea=download&el=guide
la herramienta responderá con:

{
"hit_parsing_result": [{
"valid": true,
"parser_message": [ ],
"hit": "GET /debug/collect?v=1\u0026tid=UA-12345-6\u0026cid=35009a79-1a05-49d7-b876-2b884d0f825b\u0026t=event\u0026ec=home\u0026ea=download\u0026el=guide HTTP/1.1"
}]
}

Algunas cosas a tener en cuenta sobre esta herramienta:

  • Simplemente se escribe el hit del protocolo de medición completo en la barra del navegador y envíalo a https://www.google-analytics.com/debug/collect
  • La herramienta aún está en beta así que igual no funciona en el 100% de los casos.
  • La herramienta solo hace este análisis, si hay algún problema con filtros, configuración de la cuenta de analytics, etc etc no será capaz de detectarlo.
  • Los datos que se envíen a esta herramienta no se mostrarán en los informes, habrá que utilizar la versión que no es de depuración como se ha idicado https://www.google-analytics.com/collect

 

¿Confías en tus datos? ¿Alguna vez te has planteado la veracidad de los datos que recoges en Google Analytics?

02/03/2015 a las 11:41

La medición y el análisis de los datos de una organización afecta directamente a la calidad de las decisiones tomadas en cualquiera de los distintos niveles organizacionales. Errores en implementación y/o configuración nos pueden llevar a plantear hipótesis equivocadas y consecuentemente a la toma de decisiones erróneas.

Garantizar la calidad de la información es un reto para la mayoría de las organizaciones, y cada vez son más aquellas que se preocupan por conocer sus propios niveles de calidad y el impacto que esto supone en el negocio.

Se trata, no solamente de asegurar que todos los elementos del sitio que queremos medir tengan incorporado el tag de seguimiento, sino que la información recogida es correcta. Hay ciertos errores que no son evidentes a primera vista, por ejemplo, si nos equivocamos en la nomenclatura de páginas, el número de páginas vistas en Analytics será correcto mientras que en realidad, la información que proporciona es errónea.

En este post, describimos los errores comunes en la medición y destacamos la necesidad de un método de evaluación que permita a las organizaciones confiar en sus sistemas de medición.

 

  1. Códigos obsoletos o mal ubicados

Es muy importante asegurar que no quedan residuos de código antiguo, una vez se ha hecho la actualización del código de seguimiento a versiones superiores. Esto a veces puede cortar sesiones, generar sesiones nuevas, etc…

Imagen1

  1. Estructuras de cuentas, propiedades y vistas

Se recomienda la creación de 3 vistas como mínimo:

  • Test: Nos sirve para probar los nuevos filtros antes de ser aplicados a la vista de producción o de consulta. En caso de error, lo podremos solucionar dentro de esta misma vista sin perder datos y sin que esto afecte a las vistas de consulta.
  • Maestro. La vista de consulta de datos, puede contener filtros. Ejemplo: exclusión de IPs, reescritura de la información recibida, etc…
  • Sin filtros. Es un sistema de seguridad que permite tener recogidos todos los datos en formato original, por si alguna vez perdiésemos los datos en alguna vista de consulta. También permite investigar incidencias que pueda haber en la recogida.

Además es importante tener una estructura limpia y crear una convención de nomenclaturas, que permita identificar rápidamente los distintos entornos. Una buena solución sería por enumeración, donde la 999 sería la vista de “test” y se ubicaría al final de la lista.

Imagen2

 

  1. Filtros y vistas

Dentro de este apartado hay muchas consideraciones a tener en cuenta y que pueden ser de distinta naturaleza. Enumeramos 3 ejemplos:

  • Filtros vs. Segmentos: A menudo hay cierta confusión entre filtros en vistas y segmentos avanzados. Los filtros en vistas se aplican de forma indefinida, una vez ejecutados no se pueden recuperar los datos que han quedado fuera del filtro. Hay que tener mucho cuidado con ello y entender muy bien las diferencias entre un segmento avanzado y un filtro dentro de una vista, ya que podríamos perder todos los datos de una vista sin opción de poder recuperarlos.
  • Robots: Es muy común utilizar robots que comprueban que los procesos funcionan correctamente. Estos robots, mientras recorren todo el sitio web ejecutan el código de javascript de Google Analytics y dan falsos registros de sesiones. Es conveniente filtrarlos también.
  • Tráfico relevante: Es importante identificar los distintos mercados de actuación ya que todo el tráfico que quede fuera de estas áreas geográficas puede que no sea conveniente incluirlo. Para ello incluiremos un filtro que nos permitirá hacer foco solamente en aquellas áreas relevantes para el negocio. Aquí se incluyen filtros del tráfico interno de una organización, etc…

Imagen3

Exclusión de parámetros

En el supuesto caso que tengamos en las urls cualquier parámetro de consulta o ID de sesión único (por ejemplo, sessionid o vid) y no deseemos verlo en los informes es importante excluirlos. Si no lo hacemos, este contenido quedaría tan disgregado que podríamos alcanzar el límite máximo de filas por informe (50.000). Google Anlaytics lo que hace entonces es agrupar en otra categoría llamada (other) perdiendo, así, el nombre de la página real.

 

Imagen4

  1. Autoreferencias

En Google Analytics, las autorreferencias son aquellos casos en los que los propios dominios aparecen en el informe de adquisición à Todas las referencias. Por ejemplo, si nuestro sitio web es www.example.com, cualquier dato del informe que incluya www.example.com es una autorreferencia.

Si aparecen muchas autorreferencias, puede deberse a un problema con la configuración de Google Analytics y, por lo tanto, es posible que las métricas aparezcan sesgadas y no se muestren las fuentes de tráfico reales a las que se atribuyen las conversiones y otros tipos de interacción en su sitio.

 Imagen6

  1. Pensamiento a largo plazo: anotaciones técnicas

Es importante tener previsión a largo plazo a la hora de dar contexto a los datos. Es muy buena práctica dotar el sistema de medición de anotaciones técnicas con el objetivo de informar  cualquier cambio de implementación y/o configuración. Estos cambios suelen afectar a la recogida de datos incrementando o disminuyendo sesiones, usuarios, etc…. Si no existe un registro de toda esta información, durante la fase de análisis es muy difícil contextualizar e interpretar posibles cambios producidos por un cambio técnico.

Imagen7

  1. Convención de nomenclaturas (campañas y contenidos)

Es importantísimo definir una convención de nomenclaturas para nuestras campañas y contenidos del sitio. De esta forma, las agencias externas que estén gestionando nuestras propias campañas pueden ajustarse a nuestra estructura al momento del etiquetado. Esto permitirá un orden mucho más limpio y evitará duplicidades y el caos.

Imagen8

 

  1. Data Quality Assurance: Asegurar la calidad de los datos

Es importante establecer una metodología que ayude a prevenir incidencias en la recogida de datos. Esto se lleva a cabo mediante un sistema periódico de revisión, rastreo y monitoreo que alerta si se ha producido algún cambio debido a la pérdida de algún tag o un error en implementación y/o configuración. La idea es minimizar el impacto de una posible pérdida de datos en el negocio.

Por ejemplo, una subida repentina y considerable en el porcentaje de nuevas sesiones podría indicar una pérdida accidental de la cookie, normalmente debido a un error en la configuración del salto de dominio.Imagen9

Código de moneda en Ecommerce Clásico con GTM

18/02/2015 a las 14:05

Con la aparición del Enhanced Ecommerce de Google Analytics ha cambiado mucho la información que disponemos para el estudio de las conversiones.
La implementación se ha vuelto más compleja y mucho más rica, Google se ha preocupado en recoger todos los datos significativos del proceso y si necesitamos alguno más siempre tenemos las dimensiones personalizadas, tal y como hacíamos antes.

No es una situación muy común, pero se puede dar algún caso en el que todavía tengamos que realizar implementaciones con el Ecommerce clásico.

La implementación del Ecommerce clásico con GTM es muy sencilla, tan solo es necesario incluir el dataLayer correspondiente y la etiqueta de transacción en el contenedor, contamos con documentación de Google donde se explica este proceso de una forma, más o menos, clara. Recientemente nos hemos encontrado con la necesidad de recoger la moneda de la transacción, dato que no forma parte del dataLayer del ecommerce clásico.

Informar de la moneda a Google nos permite tener vistas diferentes para cada país, con su moneda correspondiente, y una vista global en la que se realiza la conversión a euros de cada moneda para tener una información general de los ingresos.

Para enviar este dato a GA, en primer lugar tendremos que agregar el valor al dataLayer de la conversión.

<script>

dataLayer = [{
‘transactionId': ‘1234’,
‘transactionAffiliation': ‘Ropa Acme’,
‘transactionTotal': 38,26,
‘transactionTax': 1,29,
‘transactionShipping': 5,
‘transactionCurrency': ‘GBP’,
    ‘transactionProducts': [{
‘sku': ‘DD44′,
‘name': ‘Camiseta’,
‘category': ‘Ropa’,
‘price': 11,99,
‘quantity': 1
},{
‘sku': ‘AA1243544′,
‘name': ‘Calcetines’,
‘category': ‘Ropa’,
‘price': 9,99,
‘quantity': 2
}]
}];

</script>

En el siguiente paso iremos a GTM y crearemos una macro de tipo “variable de capa de datos” en GTM que recoja este valor, indicando el nombre de la clave que hemos incluido en el dataLayer de transacción.

macro_currency

A continuación en nuestra etiqueta de transacción añadimos el nuevo campo. Para ello desplegamos la opción “more settings” dentro de la etiqueta e insertamos el nuevo campo en “fields to set”

more_settings - fields to set

En versiones más recientes de GTM Google ha simplificado la inserción de este dato en concreto en la etiqueta de transacción, proporcionando un campo específico para ello.

añadiendo currency code en la transacción

De la misma manera que en el ejemplo anterior debemos crear antes la macro que recoja el valor del dataLayer.

Esto permite a Google recoger ese valor sobre el que basarse para realizar la conversión oportuna.

Google Proporciona un listado de los códigos de moneda sobre los que soporta la conversión, que son los que deberemos incluir en cada caso en el campo de transactionCurrency de nuestro dataLayer.

Como nota curiosa, en una experiencia reciente, hemos comprobado que a pesar de que en el listado se indica que el código de la Lira turca es TRL, Google no lo acepta y el código correcto sería TRY.

Por supuesto, en el resto de casos, es importante mantener el código especificado por Google. En el caso de que existan distintas definiciones para una misma moneda en necesario utilizar la que aparece en el listado.

Esto puede darse por ejemplo con la moneda china, el yuan o renminbi abreviado como RMB, también se ha utilizado como código de moneda en muchas ocasiones, pero en este caso el código que acepta Google para esta moneda es el oficial (CNY).

Es importante saber que Google Analytics utiliza el valor de cambio del día anterior en el que se realizó el procesamiento de los datos, por lo tanto, si contamos con una propiedad en la que se recogen los datos de las transacciones de varias divisas para mostrar los ingresos en una moneda común, por ejemplo en euros, si el valor de una moneda fluctúa, podemos encontrarnos con ingresos diferentes para un mismo producto en distintos periodos de tiempo seleccionados en los informes.

 

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.

 

 

 

Ajuste de rebote mediante temporizador en Google Tag Manager

06/02/2015 a las 18:36

Una de las métricas que nos da señales de la efectividad de las páginas en un sitio, es la “Tasa de Rebote” o “bounce rate”, cuando esta métrica está en los extremos, ya sea baja, alta o de valor cero, es porque algo no anda bien con nuestro sitio o definitivamente algo en la implementación de Google Analytics no anda como debería.  Pero cómo saber si la tasa de rebote de nuestras páginas está indicando de manera verídica la efectividad de nuestras páginas, ¿Y qué pasa con aquellos sitios que tienen una única página?, ¿Cómo poder ajustar el rebote en estos casos?

Ajuste de rebote mediante temporizador en Google Tag Manager

Bueno, a través de la creación de eventos y etiquetas en Google Tag Manager, se puede lograr ajustar y calcular el rebote de forma más precisa, sobre todo para aquellos sitios de contenido como blogs y otros que solo puedan tener su contenido en una sola páginas.

Por lo tanto,  haciendo este evento vamos a poder diferenciar aquellas visitas genuinas, de aquellas que realmente abandonan sin ningún interés en nuestro sitio.

 

Ajuste mediante Temporizador:

Una de las soluciones que nos permite Google Tag Manager, a través de la creación de eventos, es no considerar rebote cuando una página lleva abierta cierta cantidad de tiempo sin ninguna interacción por parte del visitante, asumiendo que éste ha encontrado lo que busca, consume el contenido y luego se va, sin necesariamente contabilizarla como abandonada, sino más bien como una visita completada.

Para poder hacer esta acción, se tiene que crear un evento de temporizador para que cuando ocurra ese suceso, se accioné el evento tras pasado un tiempo determinado, de esta forma se cancelará el rebote y contabilizará la interacción especifica.

A continuación, lo primero por hacer es crear una etiqueta tipo “Procesador de temporizador” y nombre de evento “gtm.timer”.

 

Ajuste de rebote mediante temporizador en Google Tag Manager-2

Lo segundo es llenar los siguientes campos, así que mucha atención.

Ajuste de rebote mediante temporizador en Google Tag Manager-3

La etiqueta se activará, en este caso, después de un intervalo de 20 segundos que equivale a definir 20000 milisegundos, o el tiempo que se considere necesario para el sitio.

En relación al intervalo,  éste será “1”, ya que queremos que el evento se ejecute en cada visita una sola vez. En caso que quisiéramos que se active varias veces de manera cíclica, se coloca la cantidad de veces que queremos que se active el evento.

Una vez creado el evento que va a procesar esta interacción de tiempo, creamos una etiqueta que tendrá por objetivo capturar  el evento en Google Analytics.

Para eso vamos a nombrar la etiqueta como “UA-Tiempo de Interacción”, o como estimen conveniente,  en este caso seguirá siento de tipo Universal Analytics y con el código de seguimiento de su cuenta de Google Analytics “UA-XXXXXXXX-X”.

Ajuste de rebote mediante temporizador en Google Tag Manager-4

Si se fijan, en este caso he creado una macro llamada “Tracking id” de tipo “Cadena constante”, para así poder guardar el código de seguimiento. La ventaja de crear esta macro, es que previene posibles errores al momento de ingresar el código, así como también permite cambiarlo de manera fácil y rápida.

 

Ajuste de rebote mediante temporizador en Google Tag Manager-5

 

Lo que no pueden olvidar es colocar  valor “Falso” en la vista sin interacción, de esta forma contará como interacción y cancelará el rebote.

A un solo un paso de finalizar, lo siguiente es crear la regla de activación para que se capturen los datos cuando ocurra el evento gtm.timer, como se muestra en la captura de pantalla.

Ajuste de rebote mediante temporizador en Google Tag Manager-6

Ahora solamente tenemos que guardar y publicar, para que así se actualice la última versión. Y con esta acción, ya se estará cancelando el rebote de una visita que ha permanecido en una página sin hacer ninguna otra interacción, en un periodo mayor a  20 segundos.

Para saber si Google Analytics está capturando esta interacción, hay que buscar “Interaccion/timer 20s”  en los informes de Eventos de Google Analytics.

Otra forma de enterarse, es descargar la herramienta gratuita de Chrome haciendo clic acá.

gtm chrome event

Y luego ir a la página y verificar que se activó el evento pasado los 20 segundos.

Ajuste de rebote mediante temporizador en Google Tag Manager-7

Hay otras formas más óptimas de ajustar el rebote que mediante un evento de temporizador, esta opción no considera la posibilidad de que un visitante pueda dejar abierta la página sin necesariamente estar interactuando con ella, puede haberla dejado abandonada en alguna pestaña de su navegador o simplemente se fue a preparar un café, no lo sabemos. Es por esta razón que existen otras mejores opciones como la realización de un evento, donde se cancele el rebote a través de interactuar con el scroll de la ventada de navegación de la página, así como también considerar dos eventos conjuntamente, el de scroll más el temporizador, para así poder ajustar el rebote de un sitio con características que requieran ajustes, como por ejemplo aquellos que tienen una sola página, blogs o webs de contenidos, entre otros.

Pero las otras opciones se las comentaré en otro post de Doctor Metrics.

¡Hasta la próxima!

 

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