Ayer mirando el tema de not-provided junto con Natzir de Analista SEO y Web nos dimos cuenta a raiz de ciertos posts por la blogesfera que dicen como sacar la posición de las keywords “not-provided” en base a filtros en nuestro Google Analytics, que el búscador de Google envía el tráfico a nuestra web de forma diferente desde su versión HTTPS dependiendo el navegador del usuario.
Al parecer si se está navegando desde Chrome, el comportamiento es el adecuado y no se envía los datos completos del referrer , tan sólo el dominio, pero si se trata de un FireFox o un Internet Explorer, Google nos haré llegar el tráfico a través de un enlace http ( con su referer ), pero eliminando el parámetro “q”, correspondiente a la palabra clave que ha utilizado el usuario para encontrarnos.
Asi que actualmente tenemos 2 tipos de “not-provided” , de los que podemos sacar la posición en el SERP y de los que no podemos hacerlo. Por lo tanto los filtros y perfiles que existen por internet, no son ciertos al 100% , aquí abajo está la tabla donde se ve el comportamiento de la SERP de Google en base al Navegador, http o https, y si se está logeado o no:
Desde hace poco más de una semana en el panel de configuración de los perfiles, hay una nueva opción “Configuración Social”, que al parecer se trata de lo siguiente: Google permite enlazar los streams sociales de algunas de sus redes como YouTube a vuestra cuenta de Google Analytics.
La página de ayuda, la cual no es muy extensa, dice lo siguiente:
Social Settings: Web Property Prefix
If you leave the Web Property Prefix blank, you’ll see Activities data for the domain you are tracking with Google Analytics (e.g. example.com). If you also wish to see Activities data for properties such as your YouTube channel, enter your prefixes here; for example, youtube.com/example. Make your prefix as specific as possible (i.e. do not simply enter youtube.com). Activities data is only shown for properties from which your domain has received hits.
Please note that if you enter one or more prefixes (such as youtube.com/example), you must also enter your primary domains (e.g. example.com). Otherwise, Activities data for your primary web property will be filtered out.
Es decir, no ponemos nada en esa configuración GA medirá las actividades tan sólo de tu dominio, pero deberemos incluir nuestro propio dominio, si introduciesemos alguna más, aparentemente para evitar que nadie pueda de alguna forma enviar datos a nuestro analytics de forma ilícita, y utilizando esta configuración como filtro.
Al parecer, y aunque no haya encontrado nada oficial al respecto, esto podría tener que ver directamente con el reciente anuncio de Analytics Social Data Hub, a través del cual Google ofrece la posibilidad a las redes sociales de que sus usuarios las integren con sus cuentas de Google Analtyics, para así poder medir los +1, likes, comentarios, votos, etc. Hay muchas webs ya como partners del programa: Reddit, TypePad, Delicious , Digg, Badoo, y otras pueden darse de alta como “proveedores” de datos en la siguiente dirección: https://developers.google.com/analytics/devguides/socialdata/socialSignup
Un punto importante a la hora de media una página web qué excluyas tus propias visitas, así como las de trabajadores propios de la empresa, cosa que en ocasiones no es tan sencilla como bloquear una o varias IP’s, para ellos, la mayoría de herramientas recurren a una cookie opt-out para conseguir esto, es decir fijando que no se recojan los datos de los clientes con esa cookie fijada, pero conlleva ciertos problemas como veremos más adelante.
Aquí os dejo los enlaces para hacerlo con algunas de las herramientas más conocidas:
¿ El problema ? que con estos enlaces bloquearemos el envío de datos independientemente del dominio que estemos visitando, por ejemplo si instamos el plugin opt-out de Google Analytics, tampoco enviaremos datos al resto de webs que utilicen Google Analytics, por lo cual tal vez no es lo que busquemos, siempre será funcional si corremos las estadísticas bajo un dominio propio nuestro.
Si por ejemplo quisieramos excluir las visitas nuestras en una cuenta especifica de Google Analytics, sin tener que confiar en que siempre tengamos las mismas direcciones IP, podríamos utilizar variables personalizadas para conseguir está funcionalidad.
Para ello podríamos crear una página en blanco que nos fije una variable llamada “optout”, y luego excluir las visitas que incluyan esa IP
La función a llamar para fijar la variable sería la siguiente:
pageTracker._setVar(‘optout’);
Y después crearíamos el siguiente filtro y lo aplicariamos a nuestro perfil:
De esta manera excluiremos nuestras visitas sin tener que andar pensando en las direcciones IP o cambiando los filtros cada vez que nuestra IP cambia. Cabe recordar que habría que visitar la página que hemos creado desde todos los navegadores que queramos excluir.
También podríamos incorporar la opción a nuestros visitantes de no ser trackeados de esta manera.
Detrás de una web siempre hay algún objetivo, puede ser tan simple como que alguien te lea, a que alguien compre un producto, o que se produzca un lead para tu empresa, pero siempre hay un objetivo ( Goal ) por simple que sea. Por lo tanto la fijación de objetivos es un paso obligatorio a la hora de medir vuestra web que no debéis obviar de ninguna manera, hace poco lo comentaba Oriol Farré en su post 8 errores de implementación típicos de Google Analytics y lo comentaba el ya más que conocido Avinash hace unos días en su propio Twitter.
Puedes fijar como objetivo por ejemplo el número de contactos que se realizan en tu web, que alguien se descargue un determinado archivo o grupo de archivos ( pdf’s por ejemplo ), o la gente que visita la página de tu nuevo productom y cada una de estas acciones le damos un valor.
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.
