Blog

  • Soporte multi-divisa en Google Analytics

    Desde hace años los usuarios llevan pidiendo a Google la posibilidad de poder realizar el seguimiento de los E-Commerce en diferentes monedas y hoy  acaban de anunciar que en unas semanas será posible enviar a Google Analytics los datos de nuestro de nuestras transacciones en la moneda local utilizando tan sólo un perfil.

    Cómo funciona la conversión.

    Google Analytics se encargará de realizar al convesión a la moneda configurada en el perfil utilizando para ello los mismos valores utilizados en Google Billing.

    Para el funcionamiento del soporte multi-moneda se han añadido las siguientes dimensiones y métricas al sistema:

    DimensiónDescripciÓn
    Tipo de MonedaMoneda de la transacción
    MétricaDescripCiÓn
    Local Transaction RevenueTotal de la transacción en la moneda local.
    Local Transaction ShippingTotal coste de envio en la moneda local.
    Local Transaction TaxTotal Impuestos en la moneda local.
    Local Item RevenueIngreso Producto en la moneda local.

    Actualmente esta opción está disponible tanto el tracking web ( incluído el Measurement Protocol ) , como en el SDK para Android, en breve estará disponible.

    Como fijar la moneda local en Google Analytics

    _gaq.push(['_set', 'currencyCode', 'EUR']); // ga.js
    ga('set', 'currencyCode', 'EUR'); // analytics.js
    cu=EUR // Google Analytics Measurement Protocol
    setCurrencyCode("EUR"); // Android SDK

    IMPORTANTE: Hay que tener en cuenta que hay que enviar el valor de la moneda local de la transacción antes de la llamada al _trackTrans.

    Hay que enviar la divisa es formato ISO 4217 , soporta actualmente todas las monedas disponibles en el interfaz de Google Analytics, podéis ver el listado completo en:
    Listado completo de monedas soportado por Google Analytics

  • Seguimiento de las fuentes de instalación para aplicaciones de Android

    Google Play permite el seguimiento de campañas en las instalaciones de nuestras app en , y el SDK que nos ofrece Google para utilizar Google Analytics en nuestra aplicaciones para Android automatiza casi todo el trabajo de realizar este siguimiento.

    Esto quiere decir, podemos saber desde qué página han llegado los usuarios a Google Play antes de instalar nuestra aplicación, con ello pudiendo realizar una atribución correcta a esa instalación.

    Para realizar este seguimiento deberemos etiquetar el enlace a la app que estamos promocionando al igual que hacemos con el etiquetado de campañas, es decir añadiendo a url, los parámetros utm_source, utm_medium, utm_content, utm_term, utm_campaign , por lo que en nuestros anuncios o enlaces deberíamos tener una url similar a esta:

    https://play.google.com/store/apps/details?id=com.google.android.apps.giant&
    referrer=utm_source%3DFUENTE%26
    utm_medium%3DMEDIO%26
    utm_term%3DTERMINO%26
    utm_content%3DCONTENIDO%26
    utm_campaign%3DCAMPA%25C3%2591A

    Como podemos ver se trata de pasar en el parámetro referrer, los valores utm de la campaña, a diferencia del etiquetado habitual, para la medición de Google Play tan sólo es necesario el valor para la fuente, siendo el resto de parámetros opcionales. Este parámetro es obligatorio si queremos que el siguimiento funcione correctamente.

    O para simplificarlo podríamos poner un código QR con la url y los valores de campaña

    Código QR compaing Tracking
    QR CODE

    Pódeis utilizar este formulario para generar tanto la dirección, como el código QR:
    Google Play URL Builder

    Una vez el usuario haya llegado a Google Play y haya instalado nuestra aplicación, esta lanzará un intent llamado INSTALL_REFERRER , que incluirá los parámetros por lo cuales ha llegado el usuario a nuestra aplicación.
    Lo haremos añadiendo lo siguiente a nuestro AndroidManifest.xml

    <receiver android:name="com.google.android.apps.analytics.AnalyticsReceiver" android:exported="true">
      <intent-filter>
        <action android:name="com.android.vending.INSTALL_REFERRER" />
      </intent-filter>
    </receiver>

    En resumidas cuentas:
    1. Etiquetamos los enlaces a nuestra aplicación con el Google Play URL Builder.
    2. Se instala la aplicación y acto seguido el Google Play envía los datos del referrer a nuestra aplicación.
    3. Nuestra aplicación recibe los datos del valor referrer y el SDK de android los utiliza para actualizar los datos de campaña.

    NOTA: Las campañas de adwords con autotagging, no es necesario etiquetarlas.

    Más información
    https://developers.google.com/analytics/devguides/collection/android/v2/campaigns

  • Optimiza tu sistema para utilizar herramientas de analitica in-house

    Esto es uno de esos posts que estaban en la recamara, desde casi que empezó el blog, pero con la descontinuación de Urchin por parte de Google, se había quedado ahí.

    Como ya sabemos Urchin era una herramienta de Analítica Web, que se basaba en tags, guardando los hits que genera en el tag de javascript para luego procesarlos. Pero con el lanzamiento de AngelFish Stats, el tema vuelve a tener sentido.

    Estos sistemas utilizan cookies para el seguiemiento de las visitas, y con el fin de poder acceder a ellas, hay que habilitar en los logs de nuestro servidor que se impriman las cookies que envía el navegador, inflando con ello el tamaño de nuestros logs, dependiendo de las cookies que utilice nuestra web, nos vamos tranquiliamente a un 100% más de espacio que ocupan nuestras, por ejemplo en este blog, he realizado un muestreo y el hecho de imprimir las cookies en los logs , supone un incremento del 85% de media por línea, lo cual si tenemos muchas visitas puede ser un problema.

    Tanto Urchin , AngelFish Stats, y otras herramientas, utilizan de forma exclusiva a su beacon ( gif transparente de 1×1 pixeles ), para todos los datos que muestran y el resto de hits para el típico reporte de IT , es decir para ver los códigos de estado, y demás que da la página, que en mi experiencia casi nadie les presta atención.

    Por lo tanto no es descabellado el pensar en tan sólo logear estos impactos para reducir de forma considerable el tamaño de nuestros archivos de logs.

    SetEnvIf Request_URI "^/__utm.gif" onlylog
    LogFormat "%h %v %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" \"%{Cookie}i\"" urchin
    CustomLog /var/log/apache2/access.log urchin env=onlylog

    Básicamente estamos fijando un variable llamada onlylog que filtra el parámetro Request_URI por la siguiente expresión regular “^/__utm.gif” , es decir los impactos que empiecen por __utm.gif, que en el caso de Urchin o Google Analytics, son los que necesitaremos para el procesado. Si estuviesemos hablando por ejemplo de AngelFish, utilizaríamos ^/agf.gif” .
    Y acto seguimos le decimos a apache que siga esa regla a la hora de generar nuestros logs.

    2,4G access_log
    233M access_log_filtered
    33M access_log_filtered.gz

    Como podemos ver simplemente guardando los hits al gif de seguimiento, conseguimos reducir el tamaño de los logs que necesitamos guardar a un 9.5% del log original, y si además lo comprimimos con un simple Gzip, este porcentaje se va al 1.35% .

    También conseguiremos, reducir el tiempo de procesado de nuestros perfiles, pues la herramienta no tendrá que analizar todas las lineas que se generarian de forma habitual, consiguendo con ello una mejora que en la mayoria de las situaciones superará el 50% de tiempo de procesado.

    access_log 3764983 líneas
    access_log_filtered 235680 líneas

    Como podemos ver, nuestra herramienta pasará a tener que procesar el 6.3% de las hits que tendría que procesar de forma habitual.

    Así que si los reportes de IT, no son imprescindibles para nosotros, esta solución nos ahorrará muchísimo espacio en nuestros sistemas, así como una ahorro de tiempo de procesado en nuestros perfiles, y por supuesto no debemos olvidarnos, que también conseguiremos reducir el I/O que genera nuestro apache hacía el disco duro al tener que escribir muchísimas menos líneas, y al tener que escribir sobre archivos más pequeños.

  • AngelFish Stats ya a la venta y versión trial disponible

    AngelFish Stats, la que se hace llamar la alternativa a Urchin , ya está disponible oficialmente. Recordemos que se trata de una Analítica Web que viene a cubrir el nicho que dejó Urchin al ser discotinuado por Google, y siendo actualmente la única herramienta de Analítica Web In-House disponible actualmente y con el soporte de una empresa en su backend, con la seguridad que esto aporta.

    Actualmente tiene las mismas funcionalidad de las que disponía Urchin 5, pero por informaciones de la compañía en los próximos meses irán ampliando las características del producto para equipararlo con Urchin 6/7 y posteriormente superar las funcionalidad que ofrecía este último.

    angelfish-dashboard-screenshot

    A su vez está disponible para su descargar una versión trial de 15 días en la siguiente dirección: http://analytics.angelfishstats.com/trial/

    Actualmente tan solo está disponible una versión para sistema Linux 64 bits, pero en las próximas semanas se publicarán sendas versiones para Windows Server 2008 R2 y Windows Server 2012.

    Se espera que para el segundo cuatrimestre de este año empiece a funcionar su sistema de partnership, si tuvieseis alguna duda, o quisieráis ayuda sobre la herramienta podéis poneros en contacto conmigo y os intenteré ayudar en todo lo posible.

    Si queréis más información sobre la herramienta, podéis acceder a los webinars que ofrece ActualMetrics sobre la herramienta, podéis ver el listado de los próximos en la siguiente dirección:
    http://analytics.angelfishstats.com/webinar/

  • Aprende cómo funciona el javascript de Google Analytics y optimízalo

    Seguramente todos os habréis preguntando alguna vez, cómo funciona el código de Google Analytics, ( bueno seguramente pocos os lo habréis preguntado ). Pero para quien se encargue de realizar las implementaciones en sitios, le interesará saber como funciona, bien por necesidad o simplemente por curiosidad.

    Vamos a ver que es lo que va haciendo el código durante su carga, así como algunos trucos / consejos, de cómo evitar errores en nuestras customizaciones, es tan importante cuidar la Analitica Web de nuestros sites, como que esta tarea no influya en la navegación o experiencia de nuestros usuarios.

    Vamos a utilizar el siguiente ejemplo de código:

    <script type="text/javascript">
    var _gaq = _gaq || [];
    _gaq.push(['_setAccount', 'UA-XXXXX-Y']);
    _gaq.push(['_setSiteSpeedSampleRate', 100]);
    _gaq.push(['_setCustomVar',1,'post_type','post',3],['_setCustomVar',2,'author','thyngster',3]);
    _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/ga.js';
    var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
    })();
    </script>
    var _gaq = _gaq || [];

    Al inicio del Script se inicializa un objeto llamado _gaq ( Google Analytics Queue ), que se encarga básicamente de ir guardando las llamadas al API de Google Analytics, es la base del sistema de tracking asíncrono. De esta manera tenemos las llamadas al API en una variable que se ejecutarán en el orden que se hayan añadido ( FI-FO ) en cuanto se cargue ga.js . De esta manera no es necesario paralizar la carga de los demás javascripts de la página de mientras.

    Un vez se carga el javascript de Google Analytics, el objeto _gaq se convierte en un Objeto de typo Analytics . A partir de ese momento las llamadas que se hagan al API, se ejecutarán en el mismo momento que se llamen.

    Para añadir llamadas, utilizaremos _gaq.push, de la siguiente manera:

    _gaq.push(['_setAccount', 'UA-XXXXX-Y']);
    _gaq.push(['_setSiteSpeedSampleRate', 100]);
    _gaq.push(['_setCustomVar',1,'post_type','post',3]);
    _gaq.push(['_trackPageview']);

    Si estamos obsesionados con el WPO de nuestro site podemos ahorrar mucho tiempo de ejecutión ( en terminos relativos ), al hacer tan solo 1 push con todas los métodos, sin alterar el funcionamiento real del script.

    _gaq.push(['_trackPageview'],['_setSiteSpeedSampleRate', 100],['_setCustomVar',1,'post_type','post',3],['_trackPageview']);

    Recordemos que por ahora, no se ha enviado ningún dato a Google, y lo que el código hace a continuación es crear de forma dinámica una etiqueta <script>

    var ga = document.createElement('script');

    Ahora le dices que el type de ese elemento script es “text-javascript”

    ga.type = 'text/javascript';

    Y además le decimos que añada que se trata de un elemento asíncrono

    ga.async = true;

    Así que actualmente disponemos de una variable llamada ga con el siguiente valor:
    <script type=”text/javascript” async=””>

    Ahora el script, detectará el protocolo que está utilizando la página que va a cargar el javascript, Y añade el source del script. Esta acción la realiza para evitar errores de seguridad a la hora de cargar el javascript, porqué por ejemplo si estuviesemos en un entorno seguro ( https/SSL ), e intentasemos cargar un contenido externo que no esté bajo https, el navegador nos arrojaría una alerta de contenido no seguro.

    ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';

    Por lo tanto ya tenemos el código completo que queremos añadir nuestra página, en concreto este:

    (more…)
  • Detecta errores de implementación en Google Analytics

    Hace relativamente poco lancé Analytics Debugger una herramienta de depurado online para nuestra implementación analítica, pero también nos podemos basar en nuestros datos actuales para detectar posibles errores.

    Para detectar algunas situaciones no es necesario saber de programación o saber depurar datos “sniff-ando” los hits que se envían a los servidores de Google, para ello os propongo 4 situaciones que podéis comprobar para detectar posibles problemas con vuestras implementaciones.

    Nombres de host / Hostnames

    En el reporte de Nombres de host, no deberían aparecer más que los dominios de los cuales estemos haciendo seguimiento. Se puede dar el caso de que alguien se base en nuestra implementación para utilizarla en su web y sin querer no cambie el UA, y con ello haga que nuestros datos se inflen de forma incorrecta.

    Suele ser una buena práctica para evitar este tipo de situaciones, el crear un filtro dentro de los perfiles para excluir los hits que no se estén generando desde nuestro dominio.

    Autoreferencias

    Si en el reporte de referencias ( bajo el apartado de tráfico ), viésemos que se encuentra nuestro dominio ( o alguno de ellos si estuviesemos haciendo medición entre dominios ) podríamos encontrarnos ante un problema de implementación, seguramente en la medición entre dominios o subdominios. Debido a la forma en la que funciona Google Analytics, es imposible realizar una implementación entre dominios dónde podamos evitar las autoreferencia al 100%, pero si en tu caso estás superan el 5% del tráfico de referencia, deberías revisarlo, o si tienes dudas contratar un servicio de auditoría a algún experto. No sirve de nada tener datos y que estos sean erróneos.

    Hace unos meses escribí un post en DoctorMetrics, que os ayudará sin duda a resolver casi cualquier problema de autoreferencias que tengáis: http://www.doctormetrics.com/2012/06/08/evita-las-autoreferencias-en-google-analytics-de-una-vez-por-todas/

    Páginas que no tengan tan solo 1 página vista como métrica.

    Este tipo de casuística, nos puede indicar que tal vez tengamos sin habernos dado cuenta el tag duplicado en nuestras páginas, si no en todas en algunas. Es raro que no haga páginas con tan solo una página vista, así que si es tu caso investígalo comprobando la implementación del tag de Google Analytics en tu web. Si ordenas el reporte de contenido por número de páginas vistas te será insultantemente sencillo detectar este tipo de problemas.

    Porcentajes de rebote/salida anormalmente bajos.

    Todos sabamos que cuanto menor sea el porcentaje de rebote y de salida de nuestras páginas mejor, pero si es demasiado bajo puede que haya algún error en la implementación de nuestra web en alguna de nuestras páginas.
    Por ejemplo si tuviesemos alguna página donde su rebote o porcentaje de salida fuese del 1% por por poner un valor, sería como para dedicarle, sería genial tener un valor tan bajo, pero es altamente improbable que esto sucede en el 99% de las situaciones.

    El porcentaje de rebote medio cambia entre el tipo de web de la que se trate, por ejemplo una página de contenido, pongamos como ejemplo un blog, siempre tenderá a tener un porcentaje de rebote mayor que una tienda online. Hay estudios sobre el porcentaje de rebote dependiendo de la industria a la que esté enfocada el site que podemos encontrar con facilidad para ver los porcentajes de rebotes habituales, para poder tener una idea sobre que datos serían extraños.

    Siguiente con el tema principal, si detectasemos unos porcentajes de rebote inusuales, tanto a nivel del sitio, como a nivel de alguna página, deberíamos comprobarlo para ver si hay algo que no esté funcionando correctamente.

    Os pongo un ejemplo, imáginemos que estamos en una página A en la cual tenemos el tag de google analytics sin utilizar el setDomainName, y en esa página ponemos un enlace a una página B y en esta utilizamos el setDomainName y lo fijamos a www.dominio.com. Esto va a hacer que las cookies que utiliza Google Analytics se reseteen, haciendo con ello que la página A tenga un rebote y de salida del 100% .
    Podría suceder, por experiencia propia, que la página A funcione el tag correctamente, y por temas de programación en la página B haya algún conflicto del javascript de Google Analytics con alguno de nuestra web y qué tal solo suceda por ejemplo con algún ISP en concreto,igual algún ISP tenga problemas a cargar alguno javascript externo, y por ello falle el trackeo. O simplemente que falle con algún tipo de navegador.

    La segmentación cruzada de la que podemos hacer uso en Google Analytics será quien nos ayude a encontrar estos problemas.

    Pongamos el caso contrario, unos porcentajes de rebote tendiendo a cero, podríamos por ejemplo estar lanzando un evento de forma automática al cargar nuestra web, que esté alterando el Bounce Rate de nuestra página y con ello del de nuestra web. Puede ser intencionado, por ejemplo que se lance un evento cuando se empieza la reproducción de un video, pero si el video comenzase de forma automática al cargar la página este evento de inicio de repruducción debería estar marcado como no interaccional.

    ¿ Se os ocurre alguna otra situación que nos indique problemas con nuestra implementación ?

  • Importando los costes de tus redes de display en Google Analytics

    Google Analytics ofrece desde hace un tiempo la posibilidad de importar costes de las campañas en nuestros perfiles tu cuenta, por ejemplo los costes de anuncios en FaceBook, Bing, Yahoo o Linkedin.

    Deberemos crear una fuente de datos por cada una de las redes que tengamos, accederemos a este menú desde el enlace superior que pone “Administrador” , deberemos ponerle un nombre y una descripción, tal y como podéis ver enla siguiente captura:

    cost-import-2
    cost-import-1
    cost-import-2

    Una vez realizado este paso deberemos anotar el “ID único” de nuestra fuente de datos, que nos hará falta más tarde para importar los datos, en la siguiente captura podeis ver donde obtener este dato:

    (more…)
  • Piwik – Últimas novedades: Anotaciones, Analítica de Página, Transiciones, Reportes Sociales

    En los últimos meses la gente de Piwik, no ha parado de sacar novedades muy interesantes en su software open source de analítica web

    Ayer mismo sacaron a la luz la versión 1.10 , que incluye anotaciones, analítica de página  ( Page Overlay ), Reportes sociales, auto actualizaciones de datos geográficos y otras  muchas más novedades.

    Anotaciones

    Ahora es posible añadir anotaciones en los reportes de Piwik, para poder poner comentarios que expliquen subidas de tráfico en nuestros datos. Esto nos ayudará a entender los datos que vemos en los reportes, y las anotaciones que podemos

    anotaciones-piwik
    Anotaciones en Piwik

    Analítica de página ( Page Overlay )

    Se trata básicamente de un mapa de clicks de los usuarios. Mediante el cual podremos ver en que enlaces de nuestras páginas hacen clicks las visitas para poder analizar los patrones de tráfico de nuestro sitio web.

    overlay-piwik
    Analítica de página en Piwik ( Page Overlay )

    Nuevo reporte de Redes Sociales

    En esta última actualización Piwik ha añadido un nuevo reporte que nos muestra las visitas que llegan a nuestra web desde un medio social. No se trata más que de un segmento de los datos de referrals, pero que nos permite ver de forma directa las visitas redirigidas a nuestro sitio desde medios sociales.

    Ejemplo de reporte social en Piwik
    Ejemplo de reporte social en Piwik

    Transiciones

    Esta funcionalidad no ha sido añadida en esta última versión liberada ayer, si no en las anteriores, pero ha pasado algo desapercibida, por lo que merece la pena comentarla. Nos recuerda a los Flow Charts que añadió hace algo más de un año Google Analytics, aunque eso si por ahora algo más limitado y nos ayudará a ver como llegan los usuarios a nuestras páginas y a donde van de forma visual y agradable.

    Captura de funcionalidad de transiciones en Piwik
    Captura de funcionalidad de transiciones en Piwik

    Estas no son todas las novedades que se han incorporado en los últimos meses, hay muchas más:

    • Mejoras en la Geo Localización ( ahora se muestran datos de ciudades y son más precisos )
    • Posibilidad de configurar la actualización de la base de datos geográfica de forma automática.
    • Posibilidad de filtrar las visitas por User Agent, hasta ahora solo se podía filtras las visitas por IP desde la adminstracion.
    • Ahora se pueden ver las visitas anteriores de un usuario recurrente.
    • El administrador puede ahora replicar los reportes personalizados entre las cuentas.
    • Site Search, puedes configurar el parámetro de búsqueda en tu web, para conseguir datos sobre que buscan los usuarios en tu web.
    • Soporte para tablets en su aplicación web, así como un sin fín de mejoras en esta.
    • Auditorias externas de seguridad en la aplicaciones y cientos de bugs solucionados.
  • Cómo funciona el setDomainName y la medición entre dominios

    Todos sabemos que Google Analytics permite la medición entre dominios,  pero las instrucciones para hacer esta medición han ido cambiando con el tiempo. Para la realizar la medición entre dominios ( cross-domain tracking ),  se utilizan las siguientes funciones:

    • _setAllowLinker():
      Esta función habilita la posibilidad de poder transferir las cookies entre los dominios a través de las funciones _link() y _linkByPost.
    • _link() : Esta función en la encargada de enviar las cookies entre los dominios, se utiliza con un evento onclick en los enlaces que vayan a los otros dominios, y lo que hace es añadir los parámetros de las cookies (utma, utmb,utmc, utmz ) a la dirección.
    • _linkByPost(): Esta función es la que se encarga de enviar los valores de las cookies si el enlace entre dominios se realiza a través de un formulario.
    • _setDomainName() : Esta función es la que se encarga de generar el hash de dominio que se utiliza en las cookies así como de fijar el dominio para el cual son válidas las cookies.

    Hay 2 tipos de escenarios posibles, la medición entre subdominios, y las medición entre dominios diferentes:

    Medición entre subdominios

    Podríamos imaginar que tengamos varias versiones de nuestra web por paises y para cada país un subdominio, por ejemplo: spain.midominio.com , ireland.midominio.com , france.midominio.com, etc.

    Para realizar esta medición, no es más que necesaria la utilización del _setDomainName(), para fijar el dominio sobre el cual se han fijar las cookies.

    Debemos saber que la valided de una cookie, se hace de forma descendente, vamos a intentar explicarlo:

    (more…)
  • Analytics Debugger – Depurado online de la analítica de tu web

    Ayer lanzamos la beta de Analytics Debugger , se trata de una herramienta online para realizar la depuración de la analítica web de tu site.

    La herramienta te ofrece la información sobre como está configurado el tag de Google Analytics con todas las personalizaciones incluídas, independientemente de cómo se haya realiza la implementación o de si se está utilizando algún Tag Manager, sin necesidad de tener ningún conocimiento de programación, ni depender de ningún plugin, herramienta o navegador concreto.

    La herramienta realiza un examen exhaustivo de cómo está configurado el tag de Google Analytics, muestra la información concreta y de manera visual de los datos que realmente se están enviando a los servidores de Google.

    A parte de esto, comprueba y muestra un depurado más suave de +20 herramientas de Analítica Web, Optimización, Display y Tag Management . Aquí tenéis el listado completo de herramientas con las que funciona:

    (more…)