Hace unas semanas en el Google I/O se presentó en modo beta, la versión de Google Analytics para dispositivos móviles, pero a pesar de lo que pueda parecer no son pioneros en este campo ya que no es la única opción disponible, y existen opciones opensource para esta tarea una de las más llamativas es Countly . No se trata de medir las páginas que se ven desde dispositivos móviles, si no de ir un paso más allá y medir aplicaciones para móviles de forma nativa.
Counly es una aplicación de analítica en tiempo real para la medición de aplicaciones móviles , se trata de un sistema de analítica básada en eventos ( event-driven ) , con el cual podrás medir cualquier opción de tu aplicación.
Seguramente a la mayoría de los que nos dedicamos al desarrollo web o la analítica web, nos ha ocurrido en más de una ocasión el encontrarnos con una web que esta hecha a mano, cientos si no miles de archivos HTML desperdigados por todos los directorios de la web y hemos descartardo medir esta página por lo inviable de modificar todos los archivos, y sobre todo mantenerlos después o tal vez nos hemos limitado a realizar una medición a través de los logs, perdiendo con ello todas las ventajas y exactitud que aporta la medición por tags.
Sin embargo Apache dispone de varios módulos que nos permiten realizar esta acción “on the fly” , o lo que es lo mismo al vuelo , sin tener que modificar archivos.
Existen varios módulos que nos pueden ayudar en esta tarea como:
Un año después de hacer pública en Google Analytics la opción de los embudos multicanal. La empresa con sede en Mountain View , saca a la luz el API para exportar esos datos para poder explotarlos e integrarlos con otras herramientas de reporting y de generación de gráficos.
Tal vez alguno se está preguntando que son los embudos multicanal, como ya sabemos la mayoría, hasta que el año pasado publicase Google esta funcionalidad la atribución de una conversión o una transacción se asignaba a la última visita, pero nuestro usuario puede haber pasado por diferentes canales de marketing, como por ejemplo una búsqueda orgánica, un banner o una campaña de marketing, aquí tenéis un video donde se explica de forma sencilla como funcionan los Multi-Channel Funnels:
En algunas ocasiones, se puede dar la circunstancia de que estemos utilizando alguna otra utilidad para etiquetar nuestras campañas, y no nos es posible cambiar el nombre de los parámetros para que los entienda Google Analytics.
He visto varias implementaciones en diferentes sitios web donde para conseguir utilizar varias herramientas sobreescriben los valores de las cookies del usuario de modo manual, pero realizar este cambio puede ser peligroso y no es necesario, Google Analytics, ya nos ofrece la posibilidad de utilizar otros claves para definir los valores por defecto que son ( utm_medium, utm_source, utm_campaign, utm_term, utm_content , utm_nooverride ).
Vamos a imaginar que nuestro sistema de etiquetado utiliza los parámetros “medio”, “fuente” y “campanya” como se muestra en la siguiente URL:
Podríamos decirle a Google Analytics que utilice esos parámetros en vez de los que utiliza por defecto, consiguiendo con ello compatibilizar las dos herramientas de etiquetado. Recordemos que podemos definir cualquier nombre y no los que están sugeridos en la siguiente tabla.
Recordemos que los 3 primeros parámetros son OBLIGATORIOS si no están definidos no va a funcionar el etiquetado. A parte de los 5 habituales hemos puesto el _setCampNOKey , utilizándolo, para quien no lo conozca, le decimos que no sobreescriba la fuenta original si esta ya existe, si por cualquier motivo el usuario fuese nuevo y no tuviese ya las cookies fijadas, sí que las creería y realizaría correctamente la atribución de la visita.
Use the right sidebar select to translate this post into your language
En esta ocasión vamos a ver cómo medir las compras que nos vienen desde Google Shopping a nuestro e-commerce.
Por defecto estas visitas llegan a nuestra web desde http://base.google.com cómo si se tratase de una visita desde el propio buscador de Google, por lo cual se nos mezclan con el resto de datos de búsquedas orgánicas.
Por suerte para nosotros hay una funcionalidad no documentada en Google Analytics, que nos permite, entre otras opciones, sobreescribir los parámetros de campaña antes de que se fijen con los valores calculados por defecto.
Se trata del método _set . El cual mediante el parámetro campaignParams, nos permitirá cambiar los valores de la campaña antes de enviar los datos a los servidores de Google Analytics.
Entonces, mirando los logs del servidor, y los referrers de que llegan desde Google Shopping, podemos ver que siempre empiezan por /products/catalog , teniendo en cuenta ese valor podemos sobreescribir los parámetros de campaña para poder separar las visitas desde los motores de búsqueda usuales como: Google Search, Google Images, etc, de los que vienen desde Google Shooping, y en base a ello, sobreescribir el parámetro de campaña para decirle a Google Analytics que es “shopping”. Lo que nos permitirá poder calcular las compras que llegan desde Google Shopping y del resto de fuentes y medios.
He creado un pequeño snippet en javascript que automatiza esta terea, extrayendo incluso la palabra clave de la búsqueda:
var ref = document.referrer;
if (ref.indexOf("/products/catalog") > 0 && ref.indexOf("google.")> 0)
{
var matches = ref.match("[\\?&]q=([^&#]*)");
if(matches==null)
{
var campaignParams = 'utm_campaign=shooping&utm_source=google&utm_medium=(organic)&utm_term=(not%20provided)';
}else{
var campaignParams = 'utm_campaign=shooping&utm_source=google&utm_medium=(organic)&utm_term='+matches[1];
}
_gaq.push( ['_set', 'campaignParams', campaignParams]);
}
Este código debe ponerse SIEMPREANTES de la llamada al _trackPageview si no, se enviarán los datos a Google antes de haber sobreescrito los parámetros de campaña.
El código completo sobre una implementación standard, quedaría de la siguiente manera:
<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-1231231234-1']);
var ref = document.referrer;
if (ref.indexOf("/products/catalog") > 0 && ref.indexOf("google.")> 0)
{
var matches = ref.match("[\\?&]q=([^&#]*)");
if(matches==null)
{
var campaignParams = 'utm_campaign=shooping&utm_source=google&utm_medium=(organic)&utm_term=(not%20provided)';
}else{
var campaignParams = 'utm_campaign=shooping&utm_source=google&utm_medium=(organic)&utm_term='+matches[1];
}
_gaq.push( ['_set', 'campaignParams', campaignParams]);
}
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/u/ga_debug.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
Personalmente no dispongo de ninguna tienda bajo la que hacer las pruebas, si tienes tu una y lo pruebas, me gustaría oir tu feedback para poder mejorar el código y el artículo.
Hace unos minutos Google acaba de anunciar que ha liberado a modo beta, una nueva funcionalidad para su herramienta de Analitica Web ( Google Analytics ) . Se trata como ya avanza sin rodeos el título del post de la posibilidad de hacer Remarketing.
Tal vez habría que definir de que trata el remarketing , en resumen no es más que ofrecer productos/campañas/anuncios en base a usuarios que ya ha estado anteriormente en nuestra web en base a sus necesidades. En este caso concreto el Remarketing será una característica que nos permitirá llegar a las personas que ya han visitado nuestro sitio web, y mostrarles anuncios relevantes al visitar otros sitios en la Red de Display de Google
Por lo que a través de Google Analytics podremos generar listas de remarketing basadas en ciertos parámetros de los usuarios de nuestra web, para poder mostrarles anuncios en base a estas.
Se irá activando de forma paulatina para todos los usuarios ya partir de finales de verano la opción estará disponible para todos los usuarios que sean administradores de una cuenta y esta además esté linkada a una cuenta de Google AdWords.
[gdocview_link url=”http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/es//analytics/features/remarketing_GA_factsheet.pdf” label=”Ver Hoja de hechos y ejemplos desde Google Viewer”]
Muchas veces nos preguntamos si es mejor utilizar páginas virtuales o eventos para medir algo en nuestra web, por ejemplo para medir enlaces salientes, clicks en elementos o descargas de archivos.
Mi opinión es que eventos, eventos y más eventos. Podría resumirlo en que una vez cargada la página cualquier otra acción que se realice es un evento generada sobre ella. Hace un tiempo cuando Google Analytics no disponía de eventos, las páginas virtuales eran la mejor opción, mejor dicho, la única opción para medir ese tipo de acciones, pero una vez implementaron el Event Tracking no tiene sentido alguno utilizar las páginas virtuales más que en casos concretos.
Los eventos tienen muchas ventajas sobre las páginas virtuales:
Más flexibilidad, los eventos se pueden categorizar por Categorías y Acciones.
A los eventos se les puede asignar un valor.
No es necesario crear un filtro ( y con ello tener 2 perfiles ), para no tener nuestros datos de páginas vistas desvirtuados.
Se pueden definir los eventos como acciones no-interaccionales, es decir no contarán en la tasa de rebote ( bounce rate ).
A pesar de estás ventajas, hay ocasiones es las que recomiendo utilizar páginas virtuales como por ejemplo:
Agregar una estructura lógica a las URI’s, si nuestra web está basada en id’s y nos es imposible implementar urls amigables.
Si necesitamos que esa acción sea algún paso intermedio o inicial de un objetivo, tan solo podemos definir eventos como paso final de una objetivo, no pasos intermedios.
Webs con fichas de productos con pestañas o tabs y que el contenido se carge por ajax, es decir sin volver a cambiar la página, por considerarlo como si fuese una página nueva. Un ejemplo sería por ejemplo las páginas de producto de la web del Corte Inglés. Ejemplo
El resto de interacciones que tenga el usuario deben ( o mejor dicho ), deberían medirse mediante eventos, las descargas, las interacciones en un flash, reproducciones de videos, control de errores, etc, etc, por considerarse eso mismo, interacciones que se realizan sobre la página que ya está cargada, y por ello los eventos están asociados a la página dónde se realizan.
Vamos a explicar como medir las interacciones sobre los elementos sociales en nuestra web, es decir sobre los típicos botones de compartir, me gusta, twittear, que están disponible en todas las webs.
Hace ya mas de un año que Google implementó el _trackSocial , mediante la cual podemos medir sobre que complementos sociales interaccionan los usuarios de nuestras web.
El formato de la llamada que debemos implementar es el siguiente:
Lejos quedan ya los tiempos donde la presencia web se basaba simplemente en tener una página web, todo ha ido evolucionando sin parar desde que en agosto de 1991 Tim Berners-Lee conectase a internet el primer servidor web de la historia y junto a él, la primera página web en el CERN, en esos momentos el mayor nodo de internet existente en el mundo.
Desde entonces no ha parado de crecer “la web” , ya no se trata tan solo de texto y enlaces como se concibió en un principio, y la verdadera revolución empezó con , tal y como se le acuño allá por el 2004 , la Web 2.0 , desde ese momento la web empezó a crecer realmente, ya no se trataba de contenido que la gente podía consultar, si no que además se le empezaba a los usuarios la posibilidad de interactuar con la web, y a participar en los contenidos, empezaron pues a ponerse de moda los webservices, las redes sociales, los blogs, las wikis, los servicios de alojamiento, agregadores, etc. Hasta entonces las webs eran contenidos estáticos, que no se actualizaban de forma habitual, pasando a centrarse en contenidos dinámicos, y sobre todo alimentados en gran parte por los usuarios que los visitaban.
A lo largo de esta semana, han aparecido por sorpresa dos nuevas métricas en los reportes de contenido de Google Analytics.
Una de ella son los “Accesos” ( Entrances si tienes la interfaz en Inglés ). Esta métrica nos indica, en cuantas visitas a una página en cuestión han sido también la primera página vista de la sesión.
La otra nueva métrica (más que nueva, resucitada)es el “Valor de página” , que antes era conocida como $ index . Esta métrica, nos indica el valor medio que han tenido las páginas durante la consecución de un objetivo y/o de una transacción electrónica en nuestro sitio web. O lo que es lo mismo está métrica nos da una idea de qué páginas han contribuido más o menos a los ingresos de nuestra página web. Si una página no ha sido visitada durante una sesión que haya convertido o terminado en una transacción el valor de página o $ Index de esa página será 0.
El valor se obtiene de la siguiente fórmula:
Ingresos Ecommerce + Valor Total del Objetivo Número de páginas vistas unicas de la página
