Blog

  • Cómo funcionan las cookies de Google Analytics desde dentro

    Actualización: 17 Septiembre 2012

    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:

    1. Cambio de día
    2. Cambio de campaña
    3. 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.

    __utmm­obile

    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.

  • Utiliza Google Analytics como herramienta SEO

    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 )

    (more…)
  • Sigue tu reputación online con Google Analytics

    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.

    (more…)
  • Page Level Custom Variables with Urchin

    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.

    (more…)
  • Flow Visualization con Google Analytics

    Si hay algo que está realmente claro, es que Google está totalmente volcada con su producto de Analítica Web , Google Analytics:

    En poco menos de medio hemos pasado a la version V5 , un UI totalmente renovada a contar con las siguientes funcionalidades nuevas:

    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.

    Podéis leer el anuncio oficial aquí: http://analytics.blogspot.com/2011/10/introducing-flow-visualization.html

  • Búsquedas más seguras con Google y repercusión en la analítica web y el SEO

    A partir de ahora Google redirigirá a los usuarios logeados a una url segura ( https://www.google.com o https:/encripted.google.com ), por lo que Google Analytics dejará de reportar las palabras claves  ( keywords ) , que vengan desde el buscador, seguiremos sin embargo pudiendo ver a nivel agregado el total de las visitas que han llegado por tráfico orgánico.

    Las busquedas seguirán siendo repotardas como tráfico orgánico pero con el query fijado como “(not provided)” según comenta Phil Mui ( Product Manager de Google Analytics ) en su cuenta de twitter: http://twitter.com/#!/philmui/statuses/126369334128934912 .

    Sin embargo a través de Webmaster Tools podremos seguir viendo la información agregada del top 1000 de palabras claves por las cuales google nos ha enviado tráfico a nuestra web.

    Esto complicará un poco la medición SEO de nuestra web al no poder ver el 100% de las palabras claves por las cuales llegan a nuestra web las visitas, pero podremos seguir un porcentaje de ellas , concretamente la de usuarios que no estén logeado en ningún servicio de Google.

    La información de las busquedas por CPC no se verá afectada por este cambio.

    La verdad es que el cambio no está teniendo muy buena acogida a pesar de que dicen en Google que el cambio no será tan notable como podríamos pensar a primera vista. A parte de pensar de que si van a ofrecer los datos para búsquedas por CPC, tal vez quieran ampliar la opción de poder ver el total de búsquedas si se trata de la versión premium de Google Analytics, y que si van a ofrecer parte de la información de las búsquedas, el proclamar la seguridad de las búsquedas no sea tan seguro e ideal como se plantea.

    Más información en el post oficial: http://googleblog.blogspot.com/2011/10/making-search-more-secure.html
    http://analytics.blogspot.com/2011/10/making-search-more-secure-accessing.html

  • Piwik , Analítica Web Open Source

    Lo sé, no es algo nuevo, pero si algo que tal vez muchos deberían considerar por lo menos el probarlo. Así que partir de hoy empezamos incluir artículos sobre Piwik , un motor de analítica web que nada tiene que envidiar al resto . Esta programado bajo un backend PHP y lo mejor de todo es gratuito.

    No es la única herramienta open source, pero si una de las que están a la altura y cumple con las expectativas y con su función sin decepcionar.

    No se trata de un sistema nuevo si no que lleva ya en desarrollo constante más de 6 años ,  anteriormente se llamaba phpMyVisites. Y en estos últimos años ha ido mejorando y añadiendo mejoras sin parar. Los propios autores de la herramienta confirman además que las diferencias de medición con Google Analytics son tan solo de alrededor de un 5% ( siempre va a haber diferencias entre diferentes productos de Analítica )., por lo que podemos considerarlo bastante fiable.

    (more…)
  • Como funcionan los DNS

    A lo largo de mi vida laboral, con casi todos los clientes que me he encontrado, desconocen totalmente como funcionan los DNS , Domain Name Servers .

    Los errores típicos son no diferenciar Servidores de DNS y Zonas DNS, o bien creer que una redirección se puede realizar mediante DNS’s.

    La función general de un  servidor de DNS tan sólo es conviertir nombres de dominio. Es decir www.domino.com en 127.127.127.127 . No hay redirecciones web en las DNS’s, lo que suele suceder en todo caso la mayoría de proveedores de DNS’s nos dejan hacer redirecciones poniendo sus DNS’s, pero por detrás a su vez crean un hosting web mínimo que se encarga de esta redirección.

    Hay varias tipos de Zonas DNS, las más utilizadas son las siguientes, desde el punto de vista del cliente de un dominio:

    • Tipo A: Convierte un nombre de dominio en una dirección, por ejemplo dominio.com y como valor 127.127.127.127.
    • Tipo CNAME: Apunta un nombre de domino a otro nombre de dominio. Podemos tener por ejemplo una zona de tipo A domino.com apuntando a la dirección IP: 127.127.127.127 , y un CNAME llamado www.dominio.com con el valor dominio.com. , con lo que www.dominio.com acabará apuntando a 127.127.127.127.
    • Tipo MX: Este registro indica en que servidores se va entregar el correo para ese dominio, el valor de un registro MX siempre a de ser un nombre de dominio/zona, nunca una dirección IP y va siempre acompañado de un valor número que indica la prioridad para la entrega del correo, a menor número mayor prioridad sobre el resto de registros MX si los hubiese.
    • Tipo TXT: Este tipo de registro se utiliza para indicar desde que direcciones IP o hostnames es legítimo enviar correo. El servidor de destino puede comprobar este registro para aceptar o no el correo desde nuestro servidor.

    Cada uno en su ordenador tiene configurados unos servidores de DNS diferentes , normalmente los que les de su proveedor de internet , o bien algunos gratuitos como los de Google ( 8.8.8.8, 8.8.4.4 ).
    Como es lógico estos servidores no contienen la información de Zonas para nuestros dominios ( sería un gran problema si estos no se actualizasen al momento por ejemplo, por ello siempre se ha de terminar preguntando en los servidores asociados al dominio ), por lo tanto ellos mismos se encargan de buscar esa información, para ello se utilizar la delegación de DNS’s que funciona tal y como se ve en el siguiente gráfico:

    Esto funciona de la siguiente manera:

    Vamos a suponer que intentamos cargar el dominio google.es en nuestro navegador y que tenemos las DNS’s google configuradas en nuestra conexión a Internet.

    1. Nuestro ordenador pregunta a los servidores que tiene configurados el que dirección IP tiene que buscar nuestro dominio.com, en este caso 8.8.8.8
    2. Los servidores raiz son 13 servidores localizados por todo el mundo, los cuales son los encargados de proporcionar como mínimo el nombre de domino e IP del servidor autorizado de la zona de más alto nivel para el dominio que estamos solicitando ( tld ). El servidor con IP 8.8.8.8 pregunta a su vez a los servidores raiz, donde buscar las DNS’s para los dominios con el tld de nuestro dominio ( tld, es la extesión del dominio ), en nuestro caso .es , y la respuesta serán servidores pertenecientes a ESNIC.
    3. Estos servidores de ESNIC, lo que nos van a indicar es cuales son los servidores dns que tiene asociado nuestro dominio, serían los servidores DNS que hemos puesto al registrar el dominio desde nuestro panel de control.
    4. Se termina preguntando a los servidores DNS asociados a nuestro dominio por las zonas que queramos, bien sea www.google.es si intentamos navegar o los registros MX si queremos enviar un correo.
    Podéis probar la delegación y pasos de consulta que siguen vuestros dominios en la siguiente dirección:
    http://www.simpledns.com/lookup-dg.aspx  
  • Google Analytics en tiempo real

    Google acaba de anunciar un nuevo panel que nos permitirá ver los usuarios conectados a nuestro sitios web en Tiempo Real ( Google Analtyics Right Now ) . Si como lo oís las estadísticas en tiempo real llegnm a GA.

    Podremos ver cuantos usuarios hay en nuestra web ( basado suponemos en los últimos X minutos ), de donde están viniendo ( source / medium ), de qué localización ( ciudad país ), las páginas más activas, etc. Solo estará activo en la versión 5 de Google Analytics por lo que si todavía no te has cambiado a la nueva interfaz es una buena oportunidad para ir haciéndolo.

    Está mejora se llevará a cabo de forma totalmente transparente y no será necesario realizar ningún cambio en el código para implementarla.

    Van a ir activando este nuevo set de reportes durante las próximas semanas, pero si eres de los impacientes puedes pedir que te lo habilien en el siguiente formulario:

    https://services.google.com/fb/forms/realtimeanalytics/

    Post Oficial : http://analytics.blogspot.com/2011/09/whats-happening-on-your-site-right-now.html

  • Urchin is not vulnerable to latest Apache DoS bug CVE-2011-3192

    There’s a new important bug in apache webserver, all versions are affectedtand allows remote attackers to cause a denial of service DoS (memory and CPU consumption) via a Range header that expresses multiple overlapping ranges.

    I’ve just tested it, and looks like latest Urchin Software releases aren’t affected 6.603 and 7.100 .

    REQUEST
    HEAD / HTTP/1.1
    Host: localhost:9999
    Range:bytes=0-
    Accept-Encoding: gzip
    Connection: close
    
    HTTP/1.1 200 OK

    You can read more about this bug here: CVE-2011-3192