Una variable personalizada ( Custom Variable ) es una etiqueta nombre-valor que se puede fijar mediante javascript para mejorar el seguimiento de tu página web con Piwik.
Podemos utilizar las variables personalizas en Piwik con dos tipos de alcance diferentes ( scope ), bien a nivel de visita o a nivel de página, con un límite de 5 diferentes para cada scope. Esto nos permitirá segmentar la información de nuestras visitas forma más precisa.
Para fijar las variable deberemos llamar a la función setCustomVariable con los siguiente parámetros:
setCustomVariable (index, name, value, scope = “visit”) index: Será el slot o posición de la variable, deberemos tener cuidado de no sobreescribir la posición de forma involuntaria, se trata de un valor entero entre el 1 y el 5 name: El nombre que le queremos dar a la variable personalizada. value: El valor que contendrá nuestra variable. scope: Se trata del alcance de la variable, bien “visit” o bien “page”.
Debemos tener en cuenta que tanto el name como el value, tiene un límite de 200 caracteres, y podemos tener una variable de tipo visita en el slot 1, y una variable en el slot 1 a nivel de página, por lo que en total podemos definir 10 variables personalizas.
Si decidimos eliminar una variable personalizada, podremos utilizar la siguiente función para tal efecto, deleteCustomVariable (index, scope )
Para recuperar el valor actual de una variable, haremos uso de esta función,
getCustomVariable (index, scope )
Algunos de los ejemplos de utilización de variables personalizas puede ser los siguientes:
Fijar si una visita el usuario está logeado o no lo está.
Medir la cantidad de productos que ha visitado un usuario.
Fijar la categoría que está visitando el usuario para ver cuantas veces se ha visitado cada categoría de la web.
Fijar el tipo de visita ( primera vez, comprometido, cliente ) para cada visita y después comparar las estadísticas, incuyendo visitas, tasas de converrsión y ingresos de cada tipo de visita.
Por lo tanto las variables personalizadas nos ayudarán a segmentar la información para poder después explotarla según nuestras necesidades y de forma más efectiva.
Llevamos algún tiempo hablando de Piwik como alternativa a Google Analytics, pero existen otras alternativas como Open Web Analytics . La primera versión se publicó en el año 2006 , y hace tan solo un par de semanas ha visto la luz la última revisión la 1.5.2 . Open Web Analytics destaca tal vez por incluir las funcionalidades de varios productos, dispone de todas las funcionalidades de Google Analytics, añadiéndole los mapas de calor ( heatmaps ) y click-streams de ClickTale , se trata de una opción excelente para convertirla en una herramienta de análisis Web in-house inviertiendo un poco de dinero en hardware, los datos se mantienen bajo el dominio del cliente, por lo que es una alternativa a considerar para clientes que por temas de protección de datos o protocolos no puedan enviar la información a terceras empresas aunque sea de forma agregada.
Otra de las carácterístas de Open Web Analytics, es que puede trabajar con colas de eventos ( event queueing ), es decir los eventos (páginas vistas, visitas, etc ) no se procesan en el momento de carga del usuario, por lo que se podrían imaginar diferentes escenarios para montar el sistema de forma escalable y que pueda crecer de la misma forma que nuestra web.
Como ya vimos anteriormente de forma supercial, Piwik utiliza un javascript para registrar los datos de las visitas, donde recoge por ejemplo, la dirección de la página, el título, el id único del usuario ( para hacer seguimiento de visitantes ), la resolución del usuarios, si dispone de flash, java, realmedia u otras tecnologías, etc. Más adelante veremos con más detenimiento todos los datos que registra.
Os vamos a explicar como hacer la medición por defecto, así como configurar ciertos parámetros en la medición, como las descargas, enlaces saliente, eventos ajax, extensiones, etc.
Hace un tiempo hablamos de Piwik como herramienta de analítica web open source, además como vamos a ver en los siguientes posts no tiene nada que envidiar a las otras herramientas tanto de pago como gratuitas.
Para la instalación de Piwik, necesitaremos un alojamiento con soporte PHP >5.13 y con base de datos MySQL, dependiendo del volumen de visitas de nuestras webs, será necesario un hosting o servidor más potente y a poder ser con acceso por SSH.
La instalación de Piwik, es de lo más trivial, tan sólo deberemos subir los archivos del script, que podéis descargar desde la siguiente dirección http://piwik.org/latest.zip , a vuestro FTP y luego seguir 8 sencillos pasos por los cuales os guiará el instalador.
Uno de los grandes problemas de los sistemas de medición con tags, es la imposibilidad de medir las descargas de archivos que no puedan ejecutar javascript, como son los archivos PDF’s, Zip’s, Doc(x)s, etc , cosa que no sucede con las herramientas de medición por logs. Tanto con Google Analytics como con otras herramientas, podemos etiquetar los enlaces ( hrefs ) mediante onClicks para poder medir estas descargas, pero qué pasa con la gente que pone un enlace directo a un archivo nuestro, o por ejemplo lo que sucede desde que los buscadores indexan el contenido de nuestros archivos PDFs.
Utilizando la librería SSGA ( Server-Side Google Analytics ) y un .htaccess ( mod_rewrite ), he creado un pequeño script en PHP, que se encargará de registrar un evento en Google Analytics con la descarga y acto seguido descargará el archivo en cuestión, para ello deberemos configurar un par de variables al inicio del archivo:
// UA de la cuenta $ua = “UA-12345678-1”; // Nombre del domino configurado en Analytics $dominio = “www.thyngster.com”; // Categoría del Evento $categoria = “descargas”; // Acción del Evento $accion = “pdfs”;
Y para que la acción se haga de forma autómatica lo que haremos es redirigir todas las peticiones de PDFs que se generen en nuestro dominio, al script que hemos creado, tan solo deberemos agregar la siguiente línea a nuestro .htaccess:
Ahora ya podemos medir la gente que llegan a nuestros PDFs desde un búscador y medir las descargas de nuestra web sin tener que ir etiquetando todos los enlaces.
El Script original se ha modificado para que haga spoofing del User-Agent , language, y charset original del usuario, puesto que la petición a los servidores de Google la hace nuestro servidor, por lo tanto tampoco se va a guardar los datos de Geolocalización del usuario, ni se van a respetar sus cookies reales.
En esta ocasión vamos a ver el funcionamiento de las cookies y cómo mide las visitas y usuarios Google Analytics. Para su funcionamiento utiliza hasta 6 cookies diferentes, que son las siguientes: __utma, __utmb, __utmc, __utmv, __utmz, __utmk , incluiríamos una llamada utmx si estuvieses utilizando Website Optimizer. Actualización: __utmli , __utmmobile
__utma
Esta cookie ha de estar fijada de forma obligatoria para el correcto funcionamiento de Google Analytics, y se trata de una cookie persistente que caduca a los 2 años. El Hash Dominio, se trata de un ID único al dominio, para poder identificarlo ( se puede anular para que el seguimiento entre subdominios/dominios sea correcto fijando la variable _setAllowHash a false con la función ), se utiliza para comprobar la integridad de las cookies y la siguiente función es la que lo genera:
function _uHash(d)
{
if (!d || d=="") return 1;
var h=0,g=0;
for (var i=d.length-1;i>=0;i--)
{
var c=parseInt(d.charCodeAt(i));
h=((h << 6) & 0xfffffff) + c + (c << 14);
if ((g=h & 0xfe00000)!=0) h=(h ^ (g >> 21));
}
return h;
}
ID único aleatorio:Este ID se genera en cada petición de página, y su función es básicamente que los navegadores o proxies no cacheen la petición de la imagen ( __utm.gif ) Timestamp primera visita:Esta es la hora de la primera visita a nuestra web por parte del visitante, el formato es timestamp, básicamente marca el número de segundos que han pasado de la fecha: 1 de enero 00:00:00 UTC de 1970. Este valor no debería cambiar NUNCA. Timestamp sesión anterior:Esta es la hora en formato timestamp , en la que el usuario visito por última vez una página de nuestra web. Para fijarla Google Analytics coge el valor desde la varible __utmb, explicada más adelante. Timestamp última sesión:Esta es la hora en formato timestamp , en la que el usuario inició la visita actual.
Por lo tanto en la primera visita de un usuario los tres valores de fecha deberán ser iguales.
Contador Visitas:Esta parte no necesita mucha más explicación es el número de sessiones/visitas que el usuario a realizado en nuestra web.
__utmb
Se utiliza para saber el tiempo que pasa el usuario en nuestra página y el número de páginas que visita, o lo que es lo mismo lo que duran las visitas/sessiones de las visitas. Por defecto esta cookie expira a los 30 minutos, aunque se puede modificar este tiempo fijando la variable _setSessionCookieTimeout al tiempo que queramos, se fija el tiempo en milisegundos.
Hash Domain: El mismo hash para el dominio que teníamos en el valor __utma Contador páginas vistas sesión: Por cada página que visita el usuario durante la misma sesión o visita, este contador se irá incrementando en uno. Token: ( sin confirmar ) El código de Google Analytics tiene un mecanismo que evita que se envíen cientos de peticiones a sus servidores, este Token se encarga de llevar la cuenta de el. Cabe destacar que los propios servidores de Google tienen una limitación propia también de 500 impactos GATC ( Google Analytics tracking code ) por sesión, contando tanto las páginas vistas como los eventos. Timestamp última página vista: Es el timestamp en el cual el usuario vió una página de nuestra web, por lo tanto se actualiza con cada página vista o evento generado.
__utmc
Esta cookie se utiliza de forma conjunta con __utmb para saber si se establece una nueva sesión para el usuario. Esta cookie expira cuando se cierra el navegador, por lo que si el usuario entra y no existe esta cookie, se debe fijar una sessión nueva, por ejemplo si un usuario cierra el navegador y vuelve a entrar a los 45 minutos. Esto es diferente desde el cambio en la forma de medición de las visitas de hace unos meses. Sigue siendo válido en instalaciones no actualizadas de Google Analytics
Es valor de esta cookie tan solo incluye el timestamp en el que el usuario visitó nuestra página web.
__utmz
Está cookie se utiliza para realizar la atribución de la visita, es decir desde dónde y cómo ha llegado el usuario a nuestra web. Tiene una duración por defecto de 6 meses, que se puede modificar con la función _setCampaignCookieTimeout fijando el tiempo en milisegundos.
Los valores son DomainHash.Timestamp.ContadorSesion.ContadorCampaña.
El valor de ContadorSesion será el mismo que tenemos en el valor __utma , y el ContadorCampaña, se incrementará cada vez que se cambie de campaña independientemente del valor del Contador de Sesiones.
Google Analytics, sobreescribe siempre el valor de la campaña mientras el valor no se “Directo” , esto quiere decir:
El usuario entra a nuestra web directamente poniendo el dominio, el valor será direct.
Este mismo usuario entra al día siguiente a nuestra web el Buscador de Google: El valor sería google.
Pongamos el caso anterior de forma inversa, es decir primero entra desde Google y al día siguiente de forma directa, la atribución de la siguiente visita, se seguiría manteniendo para Google.
Si por ejemplo el usuario entrase desde un mailing etiquetado con las etiquetas de UTM, este valor también se sobreescribiría, así como si entra desde un enlace en otra web ( referrer ).
Tal y como hemos dicho la única ocasión que no se sobreescribe la atribución de la visita es cuando el tráfico es directo, siempre que no sea la primera visita. Si es durante la misma sesión el referrer tampoco se sobreescribe si cambiase en el transcurso de esta.
Los parámetros que se escriben sobre la fuente de la visita son los siguientes: utmcsr=google | La fuente desde la que han llegado a nuestra web utmccn=(organic) | El nombre de la campaña utmcmd=organic | El medio de la visita utmctr=thyngster%20urchin | La palabra clave/término utilizado. utmcct = | El contenido
Estos son además de los parámetros utilizados en el etiquetado de campañas que utiliza Google Analytics.
__utmv
Este parámetro lo podemos fijar nosotros para distinguir visitas, por ejemplo para saber las visitas de usuarios registrados o no registrados, se fija mediante el método _setVar . El formato sería el siguiente DomainHash.Valor
__utmx
Esta cookie se utiliza conjuntamente cuando se realizan test de A/B Testing o Multivariate con GWO ( Google Website Optimizer )
__utmk
Esta cookie contiene un Hash ( Digest ) de todas la variables UTM, se utiliza en el seguimiento entre dominios, para verificar la integridad de las cookies pasadas entre dominios
Como ya sabemos Google Analytics utiliza first-party cookies , es decir cookies generadas en el propio dominio del usuario, que casi nunca están bloqueadas por los navegadores, pero los impactos al __utm.gif están en el dominio www.google-analytics.com , por lo que hace el javascript es enviar los parámetros de las cookies por GET en la variable utmcc .<
Para terminar de definir como mide las visitas/sesiones Google Analytics, se incrementa el contador en los siguientes casos:
Cambio de día
Cambio de campaña
Expiración de la sesión ( 30 minutos entre páginas vistas ),independientemente de que se cierre el navegador o no.
Actualización 17 Septiembre 2012
Con el tiempo se ha quedado el post un poco desactualizado, por lo que voy a ampliarlo con el resto de información de las cookies posibles que utiliza Google Analytics:
__utmli
Esta cookie se utiliza cuando estamos utilizando la atribución de enlaces mejorada . Cuando se hace click en algún enlace se genera una cookie nueva ( __utmli ), con una caducidad de 30 segundos con el valor del ID que contenga este enlace, posteriormente en la página de destino se lee esta cookie y se añade esa información a esa visualización de página. La utilidad es poder diferenciar en el reporte de Analítica de página, diferentes enlaces que apunten a un mismo destino.
__utmmobile
Esta cookie tan solo se genera cuando se utiliza en SDK para móviles, y tiene la misma función que tiene la cookie __utma para entornos Web. Lo que hace es generar un hash MD5 en base a diferentes valores, selecciona una parte del hash y le añade por delante ‘0x-‘ . Con ella Google Analytics puede identificar los dispositivos móviles como si de usuarios únicos se tratara.
Ayer hablabamos de cómo conseguir ver los referers completos de nuestras visitas, para poder hacer seguimiento de nuestra Reputación Online . Para ello habíamos creado un filtro que nos ofreciese esa información, a través de ese filtro podemos sacar más información, en este caso saber a través de qué palabra clave ha llegado a nuestra web la visita, y en que posición de la búsqueda estaba en enlace, así como la página en la que aterrizó la visita.
El buscador de Google desde el 2009 ofrece un nuevo parámetro (“cd”) que indica la posición desde la cual envía la visita, y través del API de Google Analytics podemos utilizar la información para mostrarla junto con el país, la palabra clave utilizada y la página de destino.
He preparado un pequeño ejemplo de como mostrar toda esta información en un tabla simple de HTML, para ello vamos a utilizar la librería GA:PI() , y luego tan solo deberemos utilizar el siguiente código, cambiando los datos de nuestra de Gmail y el perfil que queramos monitorizar.
<?php // Utilizar GA como herramienta SEO // Hay que crear un filtro en GA según se explica en la siguiente dirección // https://www.thyngster.com/2012/02/08/seguimiento-de-emailings-con-google-analytics/ // David Vallejo ( @thyngster )
Tal vez deberíamos empezar a explicar qué es la reputación online y porqué debería importarte, según la wikipedia, la definición es la siguiente:
La reputación online es el reflejo del prestigio o estima de una persona o marca en Internet. A diferencia de la marca,que se puede generar a través de medios publicitarios, la reputación no está bajo el control absoluto del sujeto o la organización, sino que la ‘fabrican’ también el resto de personas cuando conversan y aportan sus opiniones.
Por defecto, en Google Analytics podemos ver la fuente desde la cual nos llegan las visitas, o lo que es lo mismo el dominio desde el cual están linkando a nuestro contenido, pero no nos facilita la información desde qué parte de esa web lo están haciendo, esto por ejemplo nos haría saber que nos están enlazando o hablando de nosotros en forocoches.com pero no sabríamos desde que post en partícular, por lo que para nosotros va a ser un trabajo casi imposible llegar a encontrar qué es lo que están diciendo de nosotros. Esto nos hace perder mucho en poder ofrecer una respuesta proactiva y rápida a nuestros clientes.
Mediante los filtros podemos, de forma sencilla, obtener esta valiosa información en nuestra cuenta de Google Analytics.
As almost of we all know , Urchin just has one User Level variables support Out of the box, , but what happens if we need to use custom variables under another scope, for example under Page Level Scope?
Well we can use this easy trick with some filters and 2 profiles to achieve this functionality.
We will need to use this tiny script to ensure that we will always have 2 uri segments before the real Uri Path.
Y ahora vuelven a la carga con el Flow Visualization una nueva forma de visualizar la ruta que siguen los usuarios y los embudos, que le da el disparo de gracia al hasta ahora utilizado Path Analysis . Estos nuevos gráficos nos harán ver de forma gráfica la información de cómo los usuarios “fluyen” por nuestra web.
A partir de esta semana empezarán a habilitarse en todos los perfiles dos nuevos tipos de visualización, “Visitors Flow” y “Goal Flow”
Visitors Flow
Esté gráfico nos va a mostrar el flujo que siguen los usuarios desde su fuente ( o cualquier otra dimensión ), así como nos mostrará el camino que han seguido y donde han abandonado la navegación.
Los nodos están automáticamente agrupados de a un algoritmo de inteligencia que agrupa a los visitantes a través del flujo más lógico a través de la web.
Podremos tambien interactuar con cualquier de los nodos, así como podremos ver los pasos anteriores y posteriores al nodo que queramos, tal y como se muestra en la siguiente captura:
Goal Flow
Viene a ser cómo una segunda generación de funnels ( embudos ), nos permitirán ver el flujo de los usuarios a través de los objetivos que tenemos definidos ( actualmente solo funcionará con objetivos basados en URLs, aunque van a extenderlos a Objetivos basados en Eventos, y otros tipos ), así como poder ver en que parte de nuevo Objetivo se han ido los usuarios:
Podremos obtener la siguinte información a través de los Goal Flows:
El valor relativo de visitas en relación a una dimensión ( fuente de tráfico, campaña, etc )
La tasas de abandono de usuarios en los caminos
Cómo los usuarios interactuan con nuestra web, incluyendo los pasos anteriores a los pasos el objetivo
Dónde y cómo navegan los usuarios por cada paso que hayamos definido.
Un cosa importante es que podremos definir los pasos de los objetivos y tendremos la información de meses anteriores y no como hasta ahora que con en los Objetivos empezabamos a tener información a partir de cuando los creabamos.
Cabe añadir que toda esta información la podremos segmentar como queramos puesto que podremos aplicar segmentos avanzados a los Flows para segmentarlos como queramos.
En resumen los Flow Visualization nos van a ayudar a ver como navegan los usuarios por nuestra web, cuales son los puntos negros, o los sitios que puedan crear bucles donde los usuarios se queden encerrados, en definitiva a comprender como interactuan los usuarios con nuestra web.
