Siguenos en:
Licencia Creative Commons
Google corrige el efecto de Instant Preview en Analytics
Google ha reaccionado con agilidad a los comentarios sobre el efecto indeseado que estaba teniendo Google Instant Preview en los informes de Analytics. (JRSanfeliu hace una cronología de los hechos). En todas las cuentas que he comprobado, han desaparecido las visitas del robot de Google Preview.
Visitas de Google Instant Preview registradas en Analytics (segmento de tráfico definido atendiendo al agente de usuario).
|
|
Google Instant Preview y Analytics. El horror.
Es probable que durante estos últimos días tu sitio web haya experimentado un apreciable incremento de tráfico. Sin embargo, quizá te haya resultado sospechoso que una parte significativa de ese incremento de visitas proceda del tráfico directo, y que, al revés de lo que uno espera de tan preciado segmento, su comportamiento en el sitio haya sido malo… pero malo, malo. Muy pocas páginas por visita, rebote exorbitante, ni una triste conversión… Si te reconoces en estos síntomas, ¡ojo! Quizá seas víctima del efecto Google Instant Preview.
Accede raudo a Analytics > Usuarios > Navegadores. Busca en la lista el navegador Safari. Si, asociado a este navegador, detectas un fuerte incremento de visitas, que coincide más o menos con el incremento de visitas de tu sitio, el sospechoso es Google Instant Preview. Y si accedes a los datos sobre versiones de Safari, y la versión que ha crecido más allá de todo decoro es precisamente la 525.13… ¡amigo, no hay vuelta de hoja! Es Google Instant Preview.
Gráfico de la evolución de las visitas del robot de Instant Preview. Agente de usuario: Mozilla/5.0 (en-us) AppleWebKit/525.13 (KHTML, like Gecko; Google Web Preview) Version/3.1 Safari/525.13.
¿Quiere esto decir -quizá te preguntes- que la gente está previendo mi web? ¿Debo suponer que los usuarios están clicando en la lupita para ver una imagen de mi sitio y decidir si acceden o no? ¿Y qué tiene esto de malo? ¿Dónde está el horror anunciado en el título del post?
Veamos.
Ante todo, te ha de quedar muy claro que este incremento de tráfico no significa en absoluto que los usuarios estén solicitando previews de tu sitio. Estas visitas no tienen nada que ver con lo que hacen o dejan de hacer los usuarios con respecto a tu web. Los datos se refieren a las visitas del robot de Google Instant Preview; indican páginas solicitadas por la araña de Instant Preview para poder generar una imagen de tu sitio y guardarla en los servidores de Google.
Todas las pruebas que he hecho hasta ahora indican que el robot de Instant Preview accede al sitio sin que el usuario haya solicitando un preview (Google explica cómo cachea los previews al final de este post), genera la imagen y la guarda. Esta página vista (“vista” por el robot, se entiende; ningún usuario ha visto nada todavía) queda registrada en Analytics, y cuando el usuario pide un preview, Google se lo sirve directamente de sus servidores, sin solicitar ninguna página al sitio web y sin que Analytics registre ninguna interacción.
Recapitulemos, porque esto es gordo. Cuando el usuario no ha pedido nada, la visita queda trackeada; en cambio, cuando el usuario pide un preview, Analytics no registra ninguna visita. Si el usuario pide 100 previews, Analytics no registrará ni una página vista. Es decir, Analytics está informando sobre interacciones con el robot, y no con los usuarios que utilizan el “preview”.
Hasta ahora, Analytics servía básicamente información de usuarios reales, y no de arañas, puesto que Analytics trackea mediante JavaScript y las arañas no suelen ejecutar JavaScript. Esto, en mi opinión, hacía de Analytics (y similares) una herramienta muy útil. Si quieres monitorizar interacciones con robots, hay formas de hacerlo, como atacar los registros del servidor, o abrirte una cuenta en Webmaster Tools. Si, en cambio, quieres monitorizar personas, Analytics es (o lo ha sido) una gran opción. Pero como el robot de Instant Preview sí ejecuta JavaScript, sus visitas quedan registradas en Analytics. La consecuencia es obvia: el tracking generado por un robot está adulterando datos que deberían referirse únicamente a personas.
Y ahora, el horror. Resulta que aunque el robot ejecuta JavaScript, no maneja cookies, y en consecuencia no hay sesión: el efecto es que cada página solicitada por el robot se registra como una visita diferente de un usuario diferente; todo son visitas de una sola página; el rebote, pues, es del 100%, así como el porcentaje de visitas nuevas; y no hay “referer”, por supuesto: todo es tráfico directo. Es decir, las visitas de Instant Preview, que presentan un comportamiento extremo, puesto que son todas de calidad ínfima, puede deteriorar de forma acusada la calidad y la relevancia de los datos de muchas cuentas de Analytics.
Había formas y fomas de integrar la información sobre Instant Preview en Analytics. Algunas habrían sido sensacionales: informes específicos de la interacción de los usuarios con la lupita. Otras, habrían sido aceptables: contabilizar la interacción con la lupa, sencillamente, como una página vista (una página generada por el usuario, claro, con su navegador y sus cookies; no una página generada por un robot). Incluso habría sido correcto no integrar la información de Instant Preview en Analytics, o no hacerlo por ahora, y con el tiempo ya se verá. Pero esto que ha hecho Google era, sin duda, la peor opción posible. Da la impresión de que los responsables de Instant Preview y los de Analytics no se han reunido nunca ni han coincidido nunca en la cafetería, porque si no esto no habría pasado. ¡Cómo! -habría dicho alguien-. ¿Que estáis haciendo un bot que ejecuta JavaScript y que va a cachear todo lo cacheable? ¡Para el carro, animal, que me la lías gorda!
En fin, sigo investigando, pero si se confirma tal como parece que las visitas del robot de Instant Preview irrumpen en Analytics sería, en mi opinión, toda una chapuza. Tanto, que parece muy razonable empezar a filtrar esas visitas para volver a tener informes que se refieran a personas, y no a robots.
Actualización (25 de noviembre de 2010): Google corrige el efecto indeseado de Instant Preview en Analytics.
|
|
|
Facebook Analytics
Y seguimos hablando de Facebook (lo sé lo sé, estamos algo cansinos insistentes con el tema). Pero esta vez me hago eco de una noticia recién salida del blog del gigante.
Ya decíamos últimamente que las estadísticas de Facebook no iban a la par que los cambios que anunció el pasado mes de mayo. Ahora ya sí.
Asemejándose al servicio de Analytics, Facebook acaba de anunciar mejoras en sus estadísticas que informarán sobre visitas, “me gustas”, y reenvíos de las fan pages, webs y plugins integradas con la red social. Y como decían mis compañeros Daniel Martinez y Fernando Sanchez con los anuncios de pago, lo van a saber todo de ti.
Y más. Ya que a partir de ahora estas gráficas mostrarán ” datos del género, edad, país, ciudad e idioma utilizado por la audiencia de una historia o una página, así como qué usuarios han hecho ‘click’ en el botón ‘me gusta’ de la red social”.
Puedes leer la noticia en:
Facebook Noticias
Webtrends
Actualización a día 13 de julio: Ya podeis ver las estadísticas de interacciones y seguidores en : http://www.facebook.com/insights/
|
Social Media Strategist y Dirección de Contenidos
|
Las custom vars siguen siendo un poco buggy
Es evidente que las custom vars son una idea estupenda. Si además funcionaran medianamente bien en todas las cuentas, serían el no va más.
De las 42 visitas con la variable de usuario seteada, ninguna de ellas pertenece ni al segmento de usuarios nuevos ni al segmento de usuarios recurrentes.
|
|
|
Mi primer Conversion Thursday
El pasado 11 de febrero tuve la ocasión de asistir al Conversion Thursday de Barcelona, evento con el que quedé gratamente contento, primero, por la afluencia de gente que asistió (en torno a ciento y pico personas); y segundo, por el nivel de los ponentes: Adrián Segovia, responsable de analítica web para ElPaís y que presentó el primer Paper de Analítica Web en castellano; Mariano Fernández, responsable de Marketing Online para LaVanguardia; y Silvia Cobo, Community Manager y blogger de lolacomomola.
Pero por otro lado quedé un poco decepcionado porque el tema era “El futuro del marketing online”, y, la verdad, es que de esto poco se habló. Más bien se enfocó a la analítica web, como suele ser habitual en este evento, y por lo que me comentan compañeros de trabajo que suelen frecuentarlo.
De todos modos sirva desde aquí mi más enérgico aplauso para que este tipo de jornadas se multipliquen, y se hable y se comparta todo lo posible conocimientos de marketing online, seo, sem, analítica, smm, etc., ya que, bajo mi punto de vista, en España todavía estamos a la cola del marketing on-line y una buena manera que existe para que las empresas superen la crisis es invirtiendo bien en sus presupuestos on-line, y más que en el off-line.
Sé que por decir esto muchos me criticarán, pero, sinceramente es lo que pienso y todos mis cliente lo saben. Y ahora la hago publico desde aquí: es más barato, más directo, más medible, en definitiva, más ROI.
Volviendo al Conversion Thursday, una cosa que me llamó muchísimo la atención y sorprendió, fue Pere Rovira. Conozco a Pere desde hace un montón de años, y hemos colaborado en proyectos en común y tengo que reconocer que fue la SALSA Y PIMIENTA de la jornada. Suspicaz en las preguntas, rompedor en el ambiente, armonizador… hizo que la jornada fuera interesante y divertida, y es con lo que me quedo de la Conversion.
Saludotes!!
Paper sobre Analítica Web en castellano
|
CEO de Tresce y Consultor de Marketing Digital
|
Obtención de la URL completa de las fuentes de tráfico mediante Analytics
Habréis visto que los informes de fuentes de tráfico de Google Analytics cortan la URL del origen de las visitas justo al final del nombre del fichero. Es decir, no incluyen información sobre los parámetros que figuran después del nombre del fichero. Si, por ejemplo, alguien entra en nuestro sitio web navegando desde la URL:
http://videosformacion.com/play.php?vid=254
Analytics, mostrará como fuente de tráfico el dominio videosformacion.com y como ruta de referencia /play.php. De esta forma, sabemos que hemos tenido una visita procedente de este sitio web, pero no podemos identificar la página precisa desde la cual se ha producido la visita.
Existe sin embargo la posibilidad de solventar esta limitación mediante el uso de un filtro avanzado, tal como se muestra en la siguiente imagen.
Este filtro guardará las URLs completas de las referencias de tráfico como si se tratara de una variable definida por el usuario, y nos permitirá consultar la información accediendo al informe “Usuarios”, en el subinforme “Definidos por el usuario”. Desde luego, no es el apartado ideal para guardar esta información. Es posible que ya estemos trabajando con otra variable definida por el usuario. Además, quizá en el futuro Analytics facilite esta información sin necesidad de aplicar filtros, mostrándola en el informe de sitios web de referencia. Por eso, puede ser aconsejable (yo suelo hacerlo así) duplicar el perfil de tracking, y aplicar este filtro al perfil duplicado, dejando intacto el perfil original.
|
|
|
Trackear errores de “Documento no encontrado” (error 404) mediante Analytics
Para una correcta monitorización del rendimiento de un sitio web, no podemos olvidar registrar los típicos errores de “Documento no encontrado” (el cásico error 404). En los sistemas de análisis web basados en registros de servidor, el acceso a esta información es trivial. En cambio, cuando utilizamos Google Analytics debemos asegurarnos de que:
- Nuestras páginas de error incluyan el código de Analytics. Tanto los servidores web como muchas aplicaciones de gestión de contenidos, permiten personalizar la página de error, de forma que no sea el clásico documento estándar generado por nuestro navegador. De hecho, la personalización de la página de error no sólo es recomendable a efectos de monitorización mediante Analytics, sino también en términos de usabilidad web.
- Hemos de modificar ligeramente el código, para poder distinguir, en los informes de contenido, las URLs que han generado un error 404.
Este es el código que proponemos para las URLs que generen un error 404:
<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol)
? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost +
"google-analytics.com/ga.js'
type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
try {
var pageTracker = _gat._getTracker("UA-XXXXXX-X");
pageTracker._trackPageview("/error_404/" +
document.location.pathname + document.location.search);
} catch(err) {}
</script>
De esta manera, en los informes de contenido podremos acceder a la información de todas las URLs que han generado un error de documento no encontrado.
|
|
|
Tutorial oficial de Google Analytics en vídeo
Ya hace unos meses que Google publicó un tutorial en vídeo sobre Analytics, que sintetiza los conceptos básicos necesarios para la obtención del Google Analytics Individual Qualification (IQ), es decir, el certificado oficial de capacitación como profesional de Google Analytics. Aunque el tutorial no se adentra en los aspectos avanzados de configuración y explotación de la herramienta, como tutorial básico es muy completo: además de los ver los vídeos, podemos acceder a la transcripción de los textos o a la visualización de los slides uno por uno. Eso sí, de momento sólo está disponible en inglés.
Además de este tutorial, la Conversion University ofrece enlaces a algunos vídeos del canal de Google en Youtube, en que se desarrollan algunos aspectos concretos de Analytics, como los segmentos avanzados, los informes personalizados o la integración entre Google Adwords y Analytics.
Para quienes estéis interesados, el derecho a examen para el Google Analytics Individual Qualification cuesta 50 dólares y consta de 70 preguntas, de las cuales hay que aprobar un 75%. Todo en inglés.
|
|
|
