Tags populares:

Importación de datos a Google Analytics sin usar API

14/05/2015 a las 16:59

Desde hace un tiempo en la interface de Google Analytics encontramos una nueva funcionalidad: el análisis de costes externos. Siempre hemos podido subir datos externos a Google Analytics pero nunca nos lo habían puesto tan fácil como con esta nueva actualización.

Captura de pantalla 2015-05-07 a las 10.35.34 a.m.

¿Qué significa esto? Que ya podemos, por ejemplo, subir datos de campañas que realicemos fuera de los productos de Google desde la misma interface de Google Analytics, sin utilizar otras herramientas como la API.

Por ejemplo, si estamos realizando una campaña de mailing podemos subir apertura de email, clics y costes. Con estos datos podemos analizar y comparar todos nuestros esfuerzos de marketing online en la misma herramienta.

¿Cómo subir datos de una campaña de Email marketing a Google Analytics?¿Qué pasos debemos seguir?

1. Etiquetar todas las campañas externas

(*Algo que debemos hacer siempre, no sólo en estos casos)

Para poder realizar esta subida de datos externos debemos etiquetar las url de nuestro mailing con los valores al menos de fuente, medio, campaña.

Por ejemplo:

www.doctormetrics.com/?utm_source=newsletter&utm_medium=email&utm_campaign=Universal_Analytics

 2. Creación base de datos

Queremos realizar el seguimiento de los clics, el coste y las aperturas de nuestra campaña de email marketing llamada “Universal_Analytics”.

¿Qué pasos debemos seguir?

  • Vamos a Google Analytics, Administrador y hacemos clic en la propiedad que deseemos, en la tabla seleccionamos importación de datos y lo asignamos a una o varias vistas.

Captura de pantalla 2015-04-20 a las 11.34.29 a.m.

  • Configuramos el tipo como “Datos de costes”
  • Captura de pantalla 2015-05-07 a las 10.08.17 a.m.Asignamos a los datos un nombre fácil de identificar por ejemplo, “Universal_Analytics”
  • Incluimos las dimensiones y las métricas que se desee  impresiones, clics y coste. En este caso, los clics serán las aperturas de email.

3. Exportar datos de nuestro proveedor

Hasta aquí todo lo hacemos desde la interface de Google Analytics, ahora nos toca la descarga de datos ¿Y esto, cómo lo hacemos?

Fácil, desde nuestro proveedor de Email marketing (mailchimp, master base…) descargamos los datos relativos a aperturas de email, clics y costes y los guardamos como un archivo csv.

Importante tener en cuenta:

  • Acepta codificación UTF-8
  • Tiene un límite de archivo de 5MB, pero no nos asustemos con el límite porque podemos subir un total de 50 conjuntos de datos por propiedad.

Es necesario realizar cambios en este archivo para adaptarlo a lo que Google Analytics necesita. Tranquilos Google nos facilita el trabajo, podemos descargar un archivo csv con los enunciados e instrucciones de cómo debemos subir los datos.

Cosas a tener en cuenta:

  • Los encabezados de columna debe corresponderse con los nombres que espera Google Analytics. Por ejemplo, él espera ga:source así que no seamos creativos y pongamos ga:fuente porque al subir el archivo nos va a dar error.
  • El formato de fecha debe tener el formato AAAAMMDD.

4. Subimos los datos a Google Analytics

Llegó el momento de la verdad, volvemos a la cuenta de Google Analytics y accedemos a la pestaña Administrar subidas .

  • Hacemos clic en “Administrador” en la barra de menús situada en la parte superior de cualquier página.
  • Hacemos clic en Importación de datos.
  • Hacemos clic en el enlace Administrar subidas correspondiente al conjunto de datos Universal_Analytics
  • Hacemos clic en el botón Subir archivo.

Si hay algún error  se ve reflejado en la columna Estado de la tabla de subidas.

5. Consulta los datos en los informes

Debemos tener en cuenta que los datos subidos deben procesar y combinar con los existentes, es probable que pasen hasta 24 horas antes de que podamos visualizar los datos en los informes.

Para ver los datos accedemos a nuestro Google Analytics y hacemos clic en el informe adquisición/campañas/análisis de costes.

importacion_datos_google

¿Ya habéis probado esta funcionalidad? Si tenéis dudas relacionada con este post o estáis trabajando con importación de costes podéis dejar vuestro comentario :-)

 

Cómo hacer consultas en Google BigQuery – guía básica de SQL

04/05/2015 a las 09:55

Como muchos sabréis, Google BigQuery es la solución Big Data de Google. Se trata de un servicio web que permite almacenar y consultar grandes volúmenes de datos en pocos segundos.

BigQuery

En el caso de la analítica web, se pueden importar todos nuestros datos de Google Analytics (sólo para cuentas Premium). Pero no los datos a los que estamos acostumbrados de GA, sino gigantescas tablas que contienen absolutamente toda la actividad registrada de cada sesión durante su paso por nuestro site: desde el identificador de la visita hasta el número de hit dentro de una sesión, pasando por todas las dimensiones y métricas ya disponibles en Analytics. Así pues, cualquier información que deseemos sobre nuestras visitas está a nuestro alcance haciendo la consulta (también llamada query) adecuada, que además se procesará en pocos segundos a pesar de las miles de filas que probablemente tendrá nuestra tabla de datos.

Pero, ¿cómo se hacen las consultas en BigQuery? Pues bien, con un lenguaje de programación basado en SQL, por lo que es muy importante entender y dominar este lenguaje para poder explotar al máximo esta herramienta. Teniendo en cuenta que las consecuencias pueden ser catastróficas si tomamos acciones a partir de datos erróneos, una query equivocada no es algo que nos podamos permitir.

En este post describiremos la estructura básica de las consultas en BigQuery e intentaremos entender las principales cláusulas del lenguaje SQL para ser capaces de realizar cualquier query que necesitemos.

La estructura básica de una consulta en BQ es la siguiente:


SELECT expr1 (AS alias1), expr2 (AS alias2), …

FROM [tabla1]

([INNER | CROSS | [LEFT | RIGHT | FULL] OUTER] JOIN [tabla2] ON condicionesJoin)

WHERE condiciones

GROUP BY expr1|alias1, expr2|alias2, …

ORDER BY expr1|alias1 [DESC|ASC], expr2|alias2 [DESC|ASC], …

LIMIT n;

*Los campos entre paréntesis son opcionales y la barra vertical | indica los distintos valores posibles.


Veamos con detalle cada una de sus partes:

 

SELECT (obligatorio)

Las dimensiones y métricas que queremos extraer. Cada una de ellas será una columna de la tabla resultante. Podéis encontrar los nombres de todas las variables que están disponibles en BigQuery (para datos de Google Analytics) aquí:

También pueden ser operaciones aritméticas entre métricas y funciones agregadas sobre variables. En este último caso necesitaremos la función GROUP BY, de la cual hablaremos más adelante.

Los nombres por defecto no son cómodos para trabajar ya que suelen ser muy largos (por ejemplo, la fuente de tráfico es trafficSource.source), por lo que se puede asignar un alias a las variables mediante la cláusula AS, con el cual podremos hacer referencia a esa variable en otras funciones de la query y además será el nombre con el que aparecerá en la tabla de datos resultante.

 

FROM (obligatorio)

Todas las variables que se incluyan en el SELECT se extraerán de una tabla, a la cual haremos referencia a través de la cláusula FROM. Por defecto, Bigquery guarda tablas diarias, es decir, tenemos una tabla para cada día en la que cada fila es una visita y cada columna una dimensión o métrica. Los usos más comunes de la cláusula FROM son:

  • Datos de un día:

FROM [<Dataset>.<Table Name>]

Los nombres del dataset y de la tabla los podemos encontrar en la interfície de BigQuery:

BQinterface

 

Como podéis ver, los nombres de las tablas con datos de GA tiene la forma: ga_sessions_ seguido por la fecha correspondiente en formato YYYYMMDD.

Para este ejemplo, FROM [99999999.ga_sessions_20150428] extraería los datos para el día 28 de abril de 2015 del Dataset 99999999.

  • Datos dentro de un rango de fechas:

FROM TABLE_DATE_RANGE([<Dataset>.ga_sessions_],TIMESTAMP(‘YYYY-MM-DD’),TIMESTAMP(‘YYYY-MM-DD’))

De esta forma podremos extraer datos dentro de un rango de fechas, cosa realmente importante ya que los análisis de datos no suelen (ni deben) hacerse con datos de un solo día.

Por ejemplo, para extraer datos del 10 al 20 de abril de 2015 utilizaríamos:

FROM TABLE_DATE_RANGE([99999999.ga_sessions_],TIMESTAMP(‘2015-04-10′),TIMESTAMP(‘2015-04-20′))

  • Tablas intermedias

También se puede utilizar como tabla una que resultaría de otra query. La estructura sería la siguiente:


SELECT expr3, expr4, …

FROM (        SELECT expr1, expr2, …

                    FROM [tabla]

                    WHERE condiciones1

                    GROUP BY expr1, expr2, …

                    ORDER BY expr1 [DESC|ASC], expr2 [DESC|ASC], …

                    LIMIT n)

WHERE condiciones2

GROUP BY expr3, expr4, …

ORDER BY expr3 [DESC|ASC], expr4 [DESC|ASC], …

LIMIT n;


Como os podéis imaginar, en el primer SELECT (será el que obtendremos con la consulta) solo podremos utilizar aquellas variables que estén definidas en la tabla intermedia. Este tipo de estructuras se pueden utilizar para obtener métricas que no están predefinidas y que requieren cálculos intermedios.

 

WHERE (opcional)

Condiciones sobre los datos que queremos extraer. No es necesario que sean dimensiones o métricas incluidas en el SELECT, pero sí en la tabla con la que estamos trabajando (la del FROM, aunque sea el resultado de una query o un JOIN). Se pueden utilizar condiciones múltiples usando AND y OR.

Notas:

  • La cláusula WHERE filtra los datos que pedimos, pero no reduce la cantidad de datos procesados.
  • Para datos de tipo INTEGER se suelen usar los operadores aritméticos para definir las condiciones. Algunos ejemplos son: = (igual a), != (no igual a), > (mayor que), < (menor que), >=(mayor o igual que)…
  • Para datos de tipo STRING también se pueden utilizar = o !=, pero en este caso si se comparan con una expresión fija se tienen que poner entre comillas (‘). Por ejemplo, trafficSource.medium = ‘referral’ exige que el medio sea referral. También es común utilizar IS NULL y IS NOT NULL para exigir que el valor sea o no, respectivamente, NULL, que es el valor que se asigna a las variables cuando no hay información disponible.

 

GROUP BY

Agrupa los distintos valores de las dimensiones especificadas. Se pueden hacer agrupaciones por varias dimensiones a la vez.

Se utiliza junto a funciones agregadas (en el SELECT). Vamos a entender qué hace exactamente el GROUP BY junto a las dos funciones agregadas más frecuentes: COUNT y SUM. Podéis encontrar el resto de funciones agregadas aquí:

Imaginemos que tenemos la  tabla siguiente (supongamos en este ejemplo que tiene como nombre “tabla”):

variable1 valor1
A 10
B 15
C 12
A 10
D 8
C 11
A 9
  • COUNT

Si queremos saber en cuántas filas aparece cada una de las distintas categorías de la variable1 utilizaremos la función COUNT, la cual se tiene que utilizar con GROUP BY.

Usando:


SELECT variable1, COUNT(variable1) AS count

FROM tabla

GROUP BY variable1

ORDER BY count DESC;


Obtendríamos:

variable1 count
A 3
C 2
B 1
D 1

 

Es decir, con COUNT estamos pidiendo contar las filas, y con GROUP BY estamos haciendo que acumule el número de filas si tienen la misma categoría de la variable1. Además, hemos pedido (con ORDER BY) que la tabla aparezca ordenada según los resultados de la cuenta de forma descendiente (utilizando el alias que le hemos dado a la cuenta: “count”).

  • SUM

Si queremos saber el valor total de valor1 asociado a cada categoría utilizaremos la función SUM, la cual se tiene que utilizar con GROUP BY.

Usando:


SELECT variable1, SUM(valor1) AS total

FROM tabla

GROUP BY variable1

ORDER BY total DESC;


Obtendríamos:

variable1 total
A 29(=10+10+9)
C 23(=12+11)
B 15
D 8

 

Es decir, con SUM haremos que se sumen valores, y con GROUP BY decidimos qué valores se tienen que sumar: aquéllos que tengan la misma categoría de la variable1. Además, hemos pedido (con ORDER BY) que la tabla aparezca ordenada según el resultado total de mayor a menor.

 

ORDER BY (opcional)

Ordena los datos de forma descendente (DESC) o ascendente (ASC). Por defecto se utiliza el orden ascendente.

 

LIMIT (opcional)

Número máximo de filas de la tabla de datos resultante.

 

Unión de tablas (JOIN)

En análisis avanzados puede que necesitemos hacer varias consultas por separado pero que nos interese tener todos los datos en una única tabla. En estos casos, ¿cómo podemos unir distintas tablas? La respuesta es con la función JOIN, con la cual podremos unificar dos tablas (o más, concatenando JOINs) en una si nuestras tablas comparten alguna de las variables.

En BQ hay hasta 5 tipos de JOIN, que son:

– INNER JOIN

– LEFT OUTER JOIN

– RIGHT OUTER JOIN

– FULL OUTER JOIN

– CROSS JOIN

Notas:

1) La tabla resultante del JOIN es sobre la cual trabajaremos, así que en el SELECT solo podremos pedir variables de alguna de las tablas unidas. Una forma abreviada para pedir todas las columnas de la tabla resultante del JOIN es utilizar * (es decir, SELECT *).

2) Para hacer referencia a cualquier variable primero tenemos que indicar a qué tabla pertenece seguido por el nombre (o el alias) de la variable en esa tabla (separados por un punto “.”). Veremos un ejemplo más adelante. Esto se aplica en todas las cláusulas: SELECT, ON, GROUP BY, ORDER BY…

3) La condición para unir las tablas puede ser sobre múltiples columnas (utilizando AND y OR).

Veamos en qué se diferencian los distintos tipos de JOIN mediante un ejemplo.

Supongamos que tenemos las siguientes tablas (de nombres “tabla1” y “tabla2”, respectivamente):

variable1 valor1 valor2
A 10 1500
B 15 1800
C 12 2100
A 11 3800

 

variable1 variable2 valor3
A X 250
B Y 300
D Y 100
E Z 175

 

INNER JOINInnerJoin

Dadas dos tablas de datos, con INNER JOIN la tabla resultante tendrá únicamente las filas que cumplan la/s condición/es.


SELECT *

FROM tabla1 (AS aliasTabla1)

INNER JOIN tabla2 (AS aliasTabla2)

ON tabla1.variable1 = tabla2.variable1;


Notad cómo se hace referencia a la variable1 en la cláusula ON, que es donde se especifica la condición de la unión (ver nota 2).

La tabla resultante sería:

tabla1.variable1 tabla1.valor1 tabla1.valor2 tabla2.variable1 tabla2.variable2 tabla2.valor3
A 10 1500 A X 250
A 11 3800 A X 250
B 15 1800 B Y 300

 

LEFT OUTER JOIN

LeftOuterJoin

Dadas dos tablas de datos, con LEFT OUTER JOIN obtendremos una tabla con el mismo número de filas que la primera tabla (la que esté a la izquierda de la función LEFT OUTER JOIN). En aquellas filas donde haya coincidencia (según la condición establecida) con la segunda tabla, se añadirán los valores de esta última, y para las filas donde no haya coincidencia, las entradas de las columnas de la segunda tabla se rellenarán con NULL.


SELECT *

FROM tabla1

LEFT OUTER JOIN tabla2

ON tabla1.variable1 = tabla2.variable1;


La tabla resultante sería:

tabla1.variable1 tabla1.valor1 tabla1.valor2 tabla2.variable1 tabla2.variable2 tabla2.valor3
A 10 1500 A X 250
A 11 3800 A X 250
B 15 1800 B Y 300
C 12 2100 NULL NULL NULL

 

Es decir, a las filas donde se cumple la condición (INNER JOIN) se les añade el resto de filas de la tabla1 (porque es la que está a la izquierda del JOIN) con valor NULL en las columnas que corresponden a variables de la tabla2.

RIGHT OUTER JOIN

RightOuterJoin

Equivalente a LEFT OUTER JOIN pero conservando la tabla2 entera (la de la derecha de RIGHT OUTER JOIN).

FULL OUTER JOIN

FullOuterJoin

 

Dadas dos tablas de datos, con FULL OUTER JOIN obtendremos una tabla con todas las filas de la primera y de la segunda tabla, haciendo el “match” donde se cumple la condición y rellenando con NULL donde no.


SELECT *

FROM tabla1

FULL OUTER JOIN tabla2

ON tabla1.variable1 = tabla2.variable1;


La tabla resultante sería:

tabla1.variable1 tabla1.valor1 tabla1.valor2 tabla2.variable1 tabla2.variable2 tabla2.valor3
A 10 1500 A X 250
A 11 3800 A X 250
B 15 1800 B Y 300
C 12 2100 NULL NULL NULL
NULL NULL NULL D Y 100
NULL NULL NULL E Z 175

 

Es decir, para las filas en las que se cumpla la condición habrá el “merge” entre las variables de la tabla1 y la tabla2, y para las filas en las que no se cumpla se asignará NULL a las variables de la tabla a la que no pertenecen.

CROSS JOIN

CrossJoin2

Dadas dos tablas de datos, con CROSS JOIN obtendremos una tabla en la que cada fila de la primera tabla se habrá juntado con todas las filas de la segunda tabla, por lo que no es necesario poner ninguna condición. Por lo tanto, si tenemos una tabla de 3 filas y otra de 5, la tabla resultante del CROSS JOIN tendrá 3*5=15 filas.

Se recomienda no usar este tipo de JOIN ya que es muy poco eficiente.


SELECT *

FROM tabla1

CROSS JOIN tabla2;


La tabla resultante sería:

tabla1.variable1 tabla1.valor1 tabla1.valor2 tabla2.variable1 tabla2.variable2 tabla2.valor3
A 10 1500 A X 250
B 15 1800 A X 250
C 12 2100 A X 250
A 11 3800 A X 250
A 10 1500 B Y 300
B 15 1800 B Y 300
C 12 2100 B Y 300
A 11 3800 B Y 300
A 10 1500 D Y 100
B 15 1800 D Y 100
C 12 2100 D Y 100
A 11 3800 D Y 100
A 10 1500 E Z 175
B 15 1800 E Z 175
C 12 2100 E Z 175
A 11 3800 E Z 175

 

Vemos que las filas 1-4 corresponden a unir cada fila de la tabla1 con la primera fila de la tabla2, las filas 5-8 corresponden a unir cada fila de la tabla1 con la segunda fila de la tabla2, y así sucesivamente.

 

Llegados a este punto ya tenemos los medios para realizar cualquier tipo de consulta (o como mínimo para entender que hace cualquiera que se nos ponga delante). Para terminar con el post, dejémonos de teoría y vayamos a la práctica con un ejemplo aplicado a la analítica web:

¿Cómo sería la query necesaria para obtener el número de transacciones asociadas a cada categoría de dispositivo (desktop, mobile, tablet)?

La respuesta es:


SELECT device.deviceCategory AS CategoriaDispositivo, SUM (totals.transactions) AS TotalTransacciones

FROM TABLE_DATE_RANGE([99999999.ga_sessions_],TIMESTAMP(‘2015-04-10′),TIMESTAMP(‘2015-04-29′))

GROUP BY CategoriaDispositivo

ORDER BY TotalTransacciones DESC;


1) En el SELECT pedimos la categoría del dispositivo (device.deviceCategory), al cual hemos renombrado como “CategoriaDispositivo”, y calculamos el número total de transacciones (totals.transactions), al cual llamamos “TotalTransacciones”.

2) En el FROM pondríamos la tabla de datos para la que querríamos hacer el cálculo. En este ejemplo, el cálculo se habría hecho para el periodo comprendido entre el 10/04/2015 y el 29/04/2015.

3) Como hemos usado la función SUM necesitamos el GROUP BY. En este caso, agrupamos por categoría de dispositivo (fíjate que hemos utilizado su alias, CategoriaDispositivo) de manera que se sumarán el número de transacciones de aquellas sesiones cuya categoría de dispositivo es la misma.

4) Con el ORDER BY ordenamos en función del número total de transacciones que hemos obtenido, de mayor a menor.

Con esta query obtendríamos una tabla con aspecto parecido a éste:

EjemploBQ

¿Habrías sido capaz de hacerla tú solo? Si es que sí, enhorabuena! :D Y si es que no, no te desanimes, es cuestión de práctica. ;)

Podéis encontrar muchos más ejemplos de consultas para GA en el “BigQuery Cookbook” (aunque en algunos de ellos los nombres de las dimensiones y métricas no están actualizados). Y mucha más información sobre las consultas en BigQuery en la documentación oficial de Google.

 

Espero que esta pequeña guía os haya servido para entender un poco más cómo funcionan las consultas en BigQuery (y en SQL en general). Para los que aun no hayáis tenido la posibilidad de utilizar esta herramienta, os animo a que la probéis ya que tiene un potencial enorme de cara a explotar nuestros datos de Google Analytics y conocer un poco más a nuestros usuarios. Y bueno, si tenéis alguna duda relacionada con este post o estáis trabajando en una query que no conseguís resolver, podéis dejar vuestro comentario y os intentaré ayudar en la medida de lo posible. :)

 

 

 

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.