Author: David Vallejo

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

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.

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.

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:

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

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

A partir de hoy, Google Analytics cambia la forma en la que mide las sessiones de los usuarios,

¿ Qué cambia ?
Actualmente, Google Analytics finaliza una sesión cuando:

•     El tiempo transcurrido entre páginas vistas para un usuario es mayor que 30 minutos.
•     Al final del día.
•     Cuando un usuario cierra su navegador.

En el nuevo modelo, Google Analytics finalizará una sessión en las siguientes circunstancias:

•     El tiempo transcurrido entre páginas vistas para un usuario es mayor que 30 minutos.
•     Al final del día.
•     Cuando cualquier información de campaña para un usuario cambie. Con información de campaña nos referimos a: utm_source, utm_medium, utm_term, utm_content, utm_id, utm_campaign y la función de auto-tagging de AdWords (gclid).

Beneficios

Se equipara la definición de session con la definición de visita, por lo que si alguien sale de su sitio y vuelve poco después con un valor de tráfico de origen diferente, se mide en cada visita con su propia sesión.
Google Analytics iniciará una nueva sesión cada vez que cambie la información de la campaña, por lo tanto, la atribución será la mas exacta posible,
Como a pesar de que el usuario cierre por poco tiempo el navegador ( por ejemplo, si se cuelga el navegador o se reiniciar el ordenador )  va a continuar la sesión, se va a poder medir con mucha más exactitud el compromiso de un usuario con el sitio web.

Impacto esperado
Según Google  y los datos que manejan, el impacto en el número de visitas será inferior al 1% en la mayoría de las cuentas.
Todo el histórico de datos anteriores, no se modificará y se mantendrá como está actualmente, y debido al cambio entre los datos nuevos y antiguos , se pueden producir alertas en “Google Analytics Intelligence” en algunas cuentas.

Blog oficial: http://analytics.blogspot.com/2011/08/update-to-sessions-in-google-analytics.html

This time we’re going to setup an Urchin profile, so we can track how many files are being fully downloaded .

The first step is to change the logformat that we’re using to add a new variable to it, we are going to add  %X directive, according to Apache documentation it prints connection status when the response is completed

(This directive was %c in late versions of Apache 1.3, but this conflicted with the historical ssl %{var}c syntax.)

More info: http://httpd.apache.org/docs/current/mod/mod_log_config.html

This will allow us to know if the file download have been completed or not, by default Urchin just tracks the status code of the requests, but Apache will return a 200 code even if the file has not been fully downloaded, it will even record that all bytes have been downloaded.

Just to avoid problems with Urchin logformat ( usually configured as auto ), we’re going to append this data to Cookie value, like this:
LogFormat “%h %v %u %t \”%r\” %>s %b \”%{Referer}i\” \”%{User-Agent}i\” \”r_status=%X;%{Cookie}i\”” urchin

We only need to setup an advanced filter to extract the connection status value and then put it just before the request_stem

Now we should have 2 different entries for each file request, the first is going to tell us the download that have been succesfully finished, and then the count of aborted downloads.

Now we just need to use 2 simple regex to filter the top content report data:

To see finished downloads: ^/\+
Te see not finished downloads: ^/X

Acabo de sacarme el certificado individual de Google Analytics GAIQ . Adjunto una captura 🙂

 

Google se anima a añadir medición social a través de Google Analytics, suponemos que animados por el lanzamiento de Google +1 hace unas semanas y de Google+ ayer mismo.

Por ello, a partir de ahora Google Analytics:

• Google Analytics medirá de forma automática los clicks en Google +1’s .
• Se introduce un nuevo tag para que puedas medir los clicks a otras acciones social desde el lado del cliente.
• Se agregan nuevas reportes dedicado a lo social tanto en GA como en Webmaster tools.

Se podrá acceder a los siguiente reportes:

Se acaba de publicar la nueva versión de Urchin, concretamente la versión 7.100, que se puede descargar desde la propia web oficial de Urchin:  http://www.google.com/urchin/download.html

Este es el listado de mejoras y errores solucionados es el siguiente:

• Interfaz de reporte
  • Se han actualizado los lenguajes Alemán y Japonés
• Segmentos Avanzados
  • Se ha eliminado la opción de crear segmentos avanzados de reportes en los cuales no se pueden crear segmentos. Anteriomente, el archivo rs2 tenía un flag combinado, el cual controlaba la visibilidad del popup de los segmentos cruzados y el selector de segmentos avanzados. En Urchin 7.100 se han añadido flag separados para el control de la Segmentación avanzada. Este cambio afecta al rs2 por defecto por tanto, a todos los usuarios que hayan personalizado sus reportes en Urchin 7.
  • En Urchim 7.100 se ha deshabilitado la metrica de visitas en los segmentos avanzados puesto que no está todavía disponible en el Urchin Data API.
• LDAP Integration
  • Se ha solucionado un problema con la integración LDAP , la utilidad ldapauth fallaba si alguno de los parámetros DC,OU or CN contenía un espacio.
• Log Processing
  • Se ha solucionado el problema de que Urchin no reconociese el parámetro utmcc enviado por el código de Google Analytics, al estar ‘url-encoded’ , a partir de ahora si los reconoce.
  • Después de cancelar el proceso de un perfil  “congelado” , Urchin no podía reanudar el funcionamiento sin reinicarse , en Urchin 7.100 este problema ha sido subsanado.
  • Se ha solucionado un problema de conectividad en PosgressSQL cuando se perdía la conexión durante el procesado de datos.

• Actualización de la utilidad Uconf2sql
  • Anteriormente, uconf2sql no escapaba ningún caracter especial para las cadenas de texto. Esto provocaba el siguiente error durante la migración de datos desde Urchin 5:
    ERROR: (9003-942-329) Failed to query the database
    DETAIL: You have an error in your SQL syntax; check the manual that corresponds
    to your MySQL server version for the right syntax to use near ‘s)’ AND usac_id = 1′
    at line 1
    Este problema ha sido arreglado en Urchin 7.100 .
• Administración
  • Se ha añadido el idioma Chino, a la configuración de perfiles.
  • Se ha solucionado el reiniciado de procesos desde el interfaz.
• API v2
  • El API de Urchin ya no falla cuando la fuente de logs es un FTP.

• Reporting
  • El problema de codificación con el idioma chino ha sido solucionado.
• Integración con Adwords
  • Se ha añadido soporte para la autenticación “2-step verification” , podéis leer más al respecto en la siguiente dirección http://adwordsapi.blogspot.com/2011/02/authentication-changes-with-2-step.html
• Varios
  • Se han actualizado y añadido las ayudas inline de Urchin, así como las del Help Center