A veres se puede dar el caso de que estemos utilizando una medición dual ( o incluso triple ) en nuestros sitios webs, o lo que es lo mismo envíando los datos a más de una cuenta de Google Analytics al mismo tiempo.
Por lo que nos interesa por ejemplo si estamos haciendo un seguimiento de enlaces salientes en nuestra web, estamos midiendo algunos elementos en Ajax o tal vez estemos modificando el bounce rate lanzando un evento de forma automática, que este evento se lance en todos los trackers que tengamos configurados en nuestro sitio web.
Se podría hacer haciendo un _trackEvent para cada nombre de forma manual que tengamos configurado, pero si cambia por lo que sea puede haber algún problema. Por ello el API del JavaScript de Google Analytics nos ofrece algunos métodos de los que podemos hacer uso para hacerlo todo de forma automática sin tener que andar introduciendo los nombres de los trackers a mano.
Imaginemos que tenemos una implementación del tipo:
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['first._setAccount', 'UA-XXXXX-1']);
_gaq.push(['_trackPageview']);
_gaq.push(['second._setAccount', 'UA-XXXXX-2']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
Y queremos enviar nuestros eventos a las 2 cuentas a la vez ( se podría crear una función para las páginas, los tracking sociales, o los tiempos de usuario si fuese necesario )
Para ello crearemos una función como la siguiente:
Si hace un par de días comentabamos en nuestro post de migración a Universal Analytics , que estabamos pendientes de la información de cómo realizar la medición entre dominios con Universal Analytics. Por fin ya tenemos esa información disponible.
Para la realizar la medición entre dominios (o cross-domain tracking) con universal analytics, el principio sigue siendo el mismo, es decir pasar el valor de las cookies entre los dominios. En este caso tan solo hay que pasar el valor de una cookie “_ga” .
Hay un cambio importante, y es que los links utilizados para pasar los datos entre los dominios tienen una caducidad, por lo que a partir de ahora no deberíamos modificar todos los enlaces a nuestro segundo dominio al imprimir la página, por que pasados 2 minutos estos no serán válidos. Con lo cual nos toca trabajar con Event Listeners para modificar el link cuando se haga click en algún enlace o bien en cualquier otro evento que queramos.
El primer paso que debemos hacer es fijar el allowLinker a true, tal y como ya había que hacer en la versión anterior, para realizar este paso, crearemos el tracker de la siguiente manera.
ga('create', 'UA-XXXX-Y', {'allowLinker': true});
El módulo “linker” se carga de forma automática, así que ahora tan solo nos queda añadir a nuestros enlaces la información de las cookies.
Universal Analytics nos ofrece 2 formas de conseguir este dato, una es conseguir el valor del linker que tendremos que utilizar para que lo podamos añadir nosotros, o bien la función decorate que se encargará de darnos el link final que tendremos que utilizar.
Cómo saber los parámetros para en linker
Para ello tendremos que poner el siguiente código:
ga(function(tracker) {
var linker = new window.gaplugins.Linker(tracker);
var linkerParam = tracker.get('linkerParam');
});
Entonces tendremos en la variable linkerParam el valor del linker, que debería tener este formato:
_ga=1.38895075.1749825416.1359153636
Ahora tan solo tendríamos que poner ese valor en los enlaces a nuestro segundo dominio, bien por querystring (?) ó utilizando un hash (#) .
Si hemos habilitado el allowlinker en nuestro dominio de destino, este actualizará los datos de las cookies del dominio con las que le estamos enviando, consiguiendo con ello la continuidad de la visita y del usuario.
Utilizando el método Decorate
Se trata de una utilidad que nos devolverá en enlace con el valor del linker añadido al enlace que le hayamos proporcionado.
ga(function(tracker) {
var linker = new window.gaplugins.Linker(tracker);
var salida= linker.decorate('http://www.google.com');
});
A partir de este momento en la variable salida, tendríamos el siguiente valor.
Bien, pues básicamente estas son las maneras que tenemos para obtener la información que necesitamos para poder pasar los valores de nuestras cookies entre nuestros dominios.
Os propongo un pequeño snippet para JQuery, que os ayudará a etiquetar los enlaces de forma automática y cada vez que se hace click en los enlaces a nuestro segundo dominio, recordemos que se debe hacer así porqué si se hace al cargar la página y el usuario no hace click antes de 2 minutos la página de destino no aceptará los valores de la cookie
ga(function(tracker) {
// Corremos todo dentro de una llamada de Universal Analytics
// para asegurarnos que de que se ejecu si se ha cargado.
// El dominio externo, modificar segun necesidades
var externalDomain = 'thyngster.com';
// Iniciamos la utilidad del linker
var linker = new window.gaplugins.Linker(tracker);
// Monitorizamos todos los clicks de nuestro site
$('a').click(function() {
// Si el enlace incluye el dominio que hemos definido arriba
// modificamos el enlace con los parametros de las cookies
href = $(this).attr('href');
if(href.indexOf(externalDomain)>-1)
{
// Generamos nuestro enlace
var linked_url = linker.decorate($(this).attr('href'));
// Actualizamos el enlace
$(this).attr('href',linked_url);
}
});
});<
Para la medición entre dominios con formularios sería básicamente lo mismo, pero deberemos cambiar la dirección a la cual apunta el formulario, basándonos por ejemplo en el evento “onSubmit”.
Y esto es todo lo que debemos saber para poder medir diferentes dominios de forma conjunta con Universal Analytics.
Si tienes alguna duda o problema, deja un comentario o contáctame por medio del formulario.
Hace unos días Google anunció la Beta pública de Universal Analytics . Una nueva forma de medir la analítica basada en el usuario y no en las visitas como se realizaba anteriormente.
Es decir, actualmente y sobre todo con el aumento del uso de dispositivos móviles, los usuarios utilizan varios dispositivos para conectarse a una web, y no tan solo dispositivos si no también navegadores.
Podemos tener por ejemplo un usuario que se conecta a nuestra web a través de diferentes navegadores, o incluso desde diferentes dispositivos. Con Universal Analytics la intención en basar la medición en el usuario, pudiendo unificiar todos los medios mediantes los cuales accede a nuestros servicios.
Para ello desde Google han creado un nuevo protocolo, Google Analytics Measurement Protocol, podéis ver hacer click en este Cheatsheet para ver la equivalencia del protocolo actual con el nuevo.
Mediante este protocolo podremos enviar los datos de nuestros usuarios desde un entorno web, desde una aplicación para móviles, o desde cualquier otro entorno que nosotros queramos envíando los datos directamente al endpoint de Universal Analytics.
Tal vez el reto para la gran mayoría de usuarios sea la migración del etiquetado actual de nuestros sitios web al nuevo. Pero si nos fijamos bien, no es tan complicado o trabajoso como pueda parecer en un principio y tan solo conlleva el cambio de cómo lanzamos los datos.
<!-- Google Analytics -->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-XXXXXX-Y');
ga('send', 'pageview');
</script>
<!-- End Google Analytics -->
La siguiente tabla nos muestra los cambios a la hora de hacer nuestras llamadas, comparando como lo haríamos con Google Analytics a cómo debemos hacerlo con Universal Analytics. Esto es un 80% de lo nuevo que debemos aprender para realizar nuestras nuevas implementaciones.
Universal Analytics carga algunas funcionalidades como el seguimiento de ecommerce de manera externa con el fin de poder mantener el código principal lo más liviano posible. Es decir si queremos realizar la medición de un ECommerce deberemos especificar que queremos cargar el plugin para trabajar con transacciones.
Para hacerlo, tan solo deberemos añadir una línea de código a la etiqueta que tengamos en nuestra página de la siguiente forma:
ga('require', 'ecommerce', 'ecommerce.js');
Listo, ya podemos enviar nuestras transacciones, sencillo no ?.
A su vez, el nuevo analytics.js , añade dos nuevos tipos de hits, que para los entornos web habituales no nos van a ser de mucha utilidad pues está centrado en las aplicaciones. Se trata de las Excepciones y los vistas de aplicación (appview y exception), ámbos se envian de igual manera que los anteriores mediante el método “send”.
Con el primer tipo de hit, podremos enviar que pantalla de nuestra aplicación se está visualizando ( el equivalente a una página vista ), y con el siguiente las excepciones/problemas con lo que se encuentre el usuario, por ejemplo un problema de la base de datos.
Configuración de un perfil en Universal Analytics
Sin duda alguna este es uno de los dos mayores cambioes, puesto que a partir de ahora el control de sesiones (visitas) y de fuentes, se realiza desde los propios servidores de Google Analytics.
Añadir nuevos motores de búsqueda para que se muestren como resultados orgánicos, el tiempo de duración de una visita (por defecto 30min), el tiempo de duración de las campañas (por defecto 6 meses), ahora se realiza desde la interfaz web de Google Analytics. No es necesario añadir configuraciones a nuestra página.
Las siguientes acciones se realizan ahora desde el interfaz:
_addIgnoredOrganic
_addIgnoredRef
_setCampaignCookieTimeout
_setSessionCookieTimeout
_addOrganic
_clearIgnoredOrganic
_clearIgnoredRef
_clearOrganic
El otro cambio importante es que desaparecen las variables personalizadas (custom variables) en favor de las dimensiones personalizadas (custom dimensiones) .
Ahora se crean en el interfaz y los enviaremos los datos en base al índice de nuestra dimensión, por ejemplo dimension1, dimension2 (dimension[0-9]+) . Tanto el nombre de la variable como el alcance ( scope ) , se fija durante la creación de la dimensión.
A pesar de parecer algo más laborioso de implementar tiene una gran ventaja sobre la versión anterior de Google Analytics, Universal Analytics permite crear 20 dimensiones personalizadas (y otras tantas métricas) , en la versión Premium este límite se amplía a 200 por propiedad.
Hay algunos pequeños cambios en los límites y quotas, si antes el límite era de 10M de hits por mes y propiedas, con Universal Analytics este límite será 200.000 hits por visitante al día. Lo que mejora el límite anterior sin duda alguna.
El límite de hits por sesión se sigue manteniendo en 500.
Como podemos ver, los cambios para la medición de nuestras webs, no son tan complicados, y básicamente en la mayoría de situaciones se basa en cambiar el típico _gaq.push(), por ga(”) .
A nivel de las cookies se simplifica todo de manera enorme puesto que pasamos de utilizar cuatro cookies, a utilizar tan solo una que tiene por defecto el nombre de “_ga ” (podremos cambiar el nombre en la configuración del tag si fuese necesario),yla cual contiene el básicamente el ID de usuario .
NOTA Actualmente no hay documentación sobre cómo realizar al medición entre dominios con Universal Analytics. En los foros por parte de ingenieros de Google, se ha comentado que la documentación se haría pública a finales de este mes.
La forma de configurar nuestro dominio para funcione, es fijar el allowlinker a true, y poner también el dominio para las cookies (antiguo _setDomainname).
AngelFish Stats acaba de anunciar las nuevas funcionalidades que incluirá la primera actualización de la herramienta, las tres novedades más importantes que incorporará serán las siguientes:
Nuevo método de tracking Urchin/GA:
Este nuevo método de tracking permitirá procesar los logs antiguos que tengamos de Urchin o de Google Analytics ( utilizando _setLocalRemoteServerMode o_setLocalServerMode , que se encargan de enviar una copia local del beacon que se envía a los servidores de Google Analytics ). Si eras usuario de Urchin, ahora tan solo tienes que reimportar los logs, en vez de migrarlos.
Nuevo método de tracking: Session ID
Con la nueva actualización también podremos realizar el seguimiento de nuestros usuarios mediante el Session ID que generan algunos entornos web, por ejemplo JSSESSIONID, PHPSESSIONID, que seguramente habremos visto en muchas ocasiones en las urls de algunas sites. Esta opción a parte de ser más exacto que el de IP+UA , puede ser muy util para entornos móbiles y cookieless.
Mejora de velocidad
Se ha mejora la velocidad de procesado de los logs, de carga de la interfaz, y en general ha habido mejoras en todos los aspectos de la herramienta.
A parte de estas novedades, se han corregido errores y mejorado la interfaz de usuario. Y podemos esperar una versión para entornos Windows en las siguientes actualizaciones.
A raiz de una conversión el día de hoy me ha dado por ponerme un poco al día con el Google Tag Manager . Por lo cual he estado revisando cuales han sido las mejoras que se han incorporado desde su salida y cómo aprovecharlas.
Concretamente voy a explicar cómo utilizar el dataLayer. Muchos tal vez os estéis preguntando que esto, y en resumen no se trata más que de un objeto que podemos utilizar para pasarle los datos que queramos al Google Tag Manager. Y es imprescidible para la utilización de eventos.
He leído estos meses algunos posts, donde para explicar como utilizar eventos simplemente se limitan a inyectar un código en javascript que hace un push al objeto de google analytics ( _gaq ) , y esta no es de ninguna manera la forma correcta de hacerlo, más bien lo considero una forma de desaprovechar el poder del Tag Manager.
ATENCIÓN: Para poder utilizar el dataLayer debemos declarar el objeto antes de incluir el tag del Google Tag Manager. Este se suele situar justo al inicio de la etiqueta <body>, por lo que podremos poner nuestro código en el <head> de nuestra web.
El código es el siguiente:
<script>
dataLayer = [];
</script>
Vamos a tratar el ejemplo de la medición de enlaces salientes mediante un onclick , por lo que en lugar del código habitual, utilizaremos la siguiente llamada en nuestros enlaces ( al final del artículo incluyo un pequeño snippet en javascript utilizando JQuery que nos automatizará todo el trabajo )
Con esto lo que estamos haciendo es enviar 2 variables al Tag Manager, para después en el interfaz y a través de macros poder lanzar los eventos con estos datos que estamos enviando.
Desde hace años los usuarios llevan pidiendo a Google la posibilidad de poder realizar el seguimiento de los E-Commerce en diferentes monedas y hoy acaban de anunciar que en unas semanas será posible enviar a Google Analytics los datos de nuestro de nuestras transacciones en la moneda local utilizando tan sólo un perfil.
Cómo funciona la conversión.
Google Analytics se encargará de realizar al convesión a la moneda configurada en el perfil utilizando para ello los mismos valores utilizados en Google Billing.
Para el funcionamiento del soporte multi-moneda se han añadido las siguientes dimensiones y métricas al sistema:
Dimensión
DescripciÓn
Tipo de Moneda
Moneda de la transacción
Métrica
DescripCiÓn
Local Transaction Revenue
Total de la transacción en la moneda local.
Local Transaction Shipping
Total coste de envio en la moneda local.
Local Transaction Tax
Total Impuestos en la moneda local.
Local Item Revenue
Ingreso Producto en la moneda local.
Actualmente esta opción está disponible tanto el tracking web ( incluído el Measurement Protocol ) , como en el SDK para Android, en breve estará disponible.
Google Play permite el seguimiento de campañas en las instalaciones de nuestras app en , y el SDK que nos ofrece Google para utilizar Google Analytics en nuestra aplicaciones para Android automatiza casi todo el trabajo de realizar este siguimiento.
Esto quiere decir, podemos saber desde qué página han llegado los usuarios a Google Play antes de instalar nuestra aplicación, con ello pudiendo realizar una atribución correcta a esa instalación.
Para realizar este seguimiento deberemos etiquetar el enlace a la app que estamos promocionando al igual que hacemos con el etiquetado de campañas, es decir añadiendo a url, los parámetros utm_source, utm_medium, utm_content, utm_term, utm_campaign , por lo que en nuestros anuncios o enlaces deberíamos tener una url similar a esta:
Como podemos ver se trata de pasar en el parámetro referrer, los valores utm de la campaña, a diferencia del etiquetado habitual, para la medición de Google Play tan sólo es necesario el valor para la fuente, siendo el resto de parámetros opcionales. Este parámetro es obligatorio si queremos que el siguimiento funcione correctamente.
O para simplificarlo podríamos poner un código QR con la url y los valores de campaña
QR CODE
Pódeis utilizar este formulario para generar tanto la dirección, como el código QR: Google Play URL Builder
Una vez el usuario haya llegado a Google Play y haya instalado nuestra aplicación, esta lanzará un intent llamado INSTALL_REFERRER , que incluirá los parámetros por lo cuales ha llegado el usuario a nuestra aplicación.
Lo haremos añadiendo lo siguiente a nuestro AndroidManifest.xml
En resumidas cuentas:
1. Etiquetamos los enlaces a nuestra aplicación con el Google Play URL Builder.
2. Se instala la aplicación y acto seguido el Google Play envía los datos del referrer a nuestra aplicación.
3. Nuestra aplicación recibe los datos del valor referrer y el SDK de android los utiliza para actualizar los datos de campaña.
NOTA: Las campañas de adwords con autotagging, no es necesario etiquetarlas.
Esto es uno de esos posts que estaban en la recamara, desde casi que empezó el blog, pero con la descontinuación de Urchin por parte de Google, se había quedado ahí.
Como ya sabemos Urchin era una herramienta de Analítica Web, que se basaba en tags, guardando los hits que genera en el tag de javascript para luego procesarlos. Pero con el lanzamiento de AngelFish Stats, el tema vuelve a tener sentido.
Estos sistemas utilizan cookies para el seguiemiento de las visitas, y con el fin de poder acceder a ellas, hay que habilitar en los logs de nuestro servidor que se impriman las cookies que envía el navegador, inflando con ello el tamaño de nuestros logs, dependiendo de las cookies que utilice nuestra web, nos vamos tranquiliamente a un 100% más de espacio que ocupan nuestras, por ejemplo en este blog, he realizado un muestreo y el hecho de imprimir las cookies en los logs , supone un incremento del 85% de media por línea, lo cual si tenemos muchas visitas puede ser un problema.
Tanto Urchin , AngelFish Stats, y otras herramientas, utilizan de forma exclusiva a su beacon ( gif transparente de 1×1 pixeles ), para todos los datos que muestran y el resto de hits para el típico reporte de IT , es decir para ver los códigos de estado, y demás que da la página, que en mi experiencia casi nadie les presta atención.
Por lo tanto no es descabellado el pensar en tan sólo logear estos impactos para reducir de forma considerable el tamaño de nuestros archivos de logs.
Básicamente estamos fijando un variable llamada onlylog que filtra el parámetro Request_URI por la siguiente expresión regular “^/__utm.gif” , es decir los impactos que empiecen por __utm.gif, que en el caso de Urchin o Google Analytics, son los que necesitaremos para el procesado. Si estuviesemos hablando por ejemplo de AngelFish, utilizaríamos “^/agf.gif” . Y acto seguimos le decimos a apache que siga esa regla a la hora de generar nuestros logs.
Como podemos ver simplemente guardando los hits al gif de seguimiento, conseguimos reducir el tamaño de los logs que necesitamos guardar a un 9.5% del log original, y si además lo comprimimos con un simple Gzip, este porcentaje se va al 1.35% .
También conseguiremos, reducir el tiempo de procesado de nuestros perfiles, pues la herramienta no tendrá que analizar todas las lineas que se generarian de forma habitual, consiguendo con ello una mejora que en la mayoria de las situaciones superará el 50% de tiempo de procesado.
Como podemos ver, nuestra herramienta pasará a tener que procesar el 6.3% de las hits que tendría que procesar de forma habitual.
Así que si los reportes de IT, no son imprescindibles para nosotros, esta solución nos ahorrará muchísimo espacio en nuestros sistemas, así como una ahorro de tiempo de procesado en nuestros perfiles, y por supuesto no debemos olvidarnos, que también conseguiremos reducir el I/O que genera nuestro apache hacía el disco duro al tener que escribir muchísimas menos líneas, y al tener que escribir sobre archivos más pequeños.
AngelFish Stats, la que se hace llamar la alternativa a Urchin , ya está disponible oficialmente. Recordemos que se trata de una Analítica Web que viene a cubrir el nicho que dejó Urchin al ser discotinuado por Google, y siendo actualmente la única herramienta de Analítica Web In-House disponible actualmente y con el soporte de una empresa en su backend, con la seguridad que esto aporta.
Actualmente tiene las mismas funcionalidad de las que disponía Urchin 5, pero por informaciones de la compañía en los próximos meses irán ampliando las características del producto para equipararlo con Urchin 6/7 y posteriormente superar las funcionalidad que ofrecía este último.
Actualmente tan solo está disponible una versión para sistema Linux 64 bits, pero en las próximas semanas se publicarán sendas versiones para Windows Server 2008 R2 y Windows Server 2012.
Se espera que para el segundo cuatrimestre de este año empiece a funcionar su sistema de partnership, si tuvieseis alguna duda, o quisieráis ayuda sobre la herramienta podéis poneros en contacto conmigo y os intenteré ayudar en todo lo posible.
Si queréis más información sobre la herramienta, podéis acceder a los webinars que ofrece ActualMetrics sobre la herramienta, podéis ver el listado de los próximos en la siguiente dirección:
http://analytics.angelfishstats.com/webinar/
Seguramente todos os habréis preguntando alguna vez, cómo funciona el código de Google Analytics, ( bueno seguramente pocos os lo habréis preguntado ). Pero para quien se encargue de realizar las implementaciones en sitios, le interesará saber como funciona, bien por necesidad o simplemente por curiosidad.
Vamos a ver que es lo que va haciendo el código durante su carga, así como algunos trucos / consejos, de cómo evitar errores en nuestras customizaciones, es tan importante cuidar la Analitica Web de nuestros sites, como que esta tarea no influya en la navegación o experiencia de nuestros usuarios.
Vamos a utilizar el siguiente ejemplo de código:
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-Y']);
_gaq.push(['_setSiteSpeedSampleRate', 100]);
_gaq.push(['_setCustomVar',1,'post_type','post',3],['_setCustomVar',2,'author','thyngster',3]);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
var _gaq = _gaq || [];
Al inicio del Script se inicializa un objeto llamado _gaq ( Google Analytics Queue ), que se encarga básicamente de ir guardando las llamadas al API de Google Analytics, es la base del sistema de tracking asíncrono. De esta manera tenemos las llamadas al API en una variable que se ejecutarán en el orden que se hayan añadido ( FI-FO ) en cuanto se cargue ga.js . De esta manera no es necesario paralizar la carga de los demás javascripts de la página de mientras.
Un vez se carga el javascript de Google Analytics, el objeto _gaq se convierte en un Objeto de typo Analytics . A partir de ese momento las llamadas que se hagan al API, se ejecutarán en el mismo momento que se llamen.
Para añadir llamadas, utilizaremos _gaq.push, de la siguiente manera:
Si estamos obsesionados con el WPO de nuestro site podemos ahorrar mucho tiempo de ejecutión ( en terminos relativos ), al hacer tan solo 1 push con todas los métodos, sin alterar el funcionamiento real del script.
Recordemos que por ahora, no se ha enviado ningún dato a Google, y lo que el código hace a continuación es crear de forma dinámica una etiqueta <script>
var ga = document.createElement('script');
Ahora le dices que el type de ese elemento script es “text-javascript”
ga.type = 'text/javascript';
Y además le decimos que añada que se trata de un elemento asíncrono
Ahora el script, detectará el protocolo que está utilizando la página que va a cargar el javascript, Y añade el source del script. Esta acción la realiza para evitar errores de seguridad a la hora de cargar el javascript, porqué por ejemplo si estuviesemos en un entorno seguro ( https/SSL ), e intentasemos cargar un contenido externo que no esté bajo https, el navegador nos arrojaría una alerta de contenido no seguro.
