Consultas a la API de Google Analytics con fechas actualizadas automáticamente

Al seleccionar las fechas de inicio o fin en nuestras consultas, en el Query Explorer, podemos utilizar today, yesterday o el patrón NdaysAgo además del patrón básico YYYY-MM-DD. Pero, ¿qué pasa si necesitamos datos de las últimas N semanas o los últimos N meses? La cosa se complica y no tenemos muchas mejores opciones que introducir a mano las fechas que necesitamos. Parece una tontería, pero es algo poco práctico cuando queremos usar la misma consulta para distintas fechas, o incluso peor cuando queremos hacerla de forma periódica para hacer informes semanales o mensuales, por ejemplo. Con la conexión entre R y Google Analytics (de la cual hablamos anteriormente aquí) parecería que no tenemos mejor suerte ya que ni siquiera acepta today, yesterday o NdaysAgo, sino que únicamente acepta el patrón YYYY-MM-DD. Pero, en realidad, ‘jugando‘ un poco con las funciones de tiempo de R sí que podemos consultar estas fechas relativas y, de hecho, cualquier otra que nos propongamos. En este post veremos la forma de hacer consultas de algunos de los periodos dinámicos más comunes: los últimos N días, las últimas N semanas (de lunes a domingo) y los últimos N meses. A partir de aquí, se podrían modificar fácilmente para consultar otras fechas relativas que se necesiten en cada caso concreto. Para conseguirlo, lo único que necesitaremos será modificar adecuadamente los parámetros que corresponden a […]

The post Consultas a la API de Google Analytics con fechas actualizadas automáticamente appeared first on Blog de Analítica Web, Optimización y Conversión – Doctor Metrics.


Source: http://feeds.feedburner.com/DoctorMetrics

Consultas a la API de Google Analytics con fechas actualizadas automáticamente

Google Tag Manager event tracking using data attribute elements

On the last #tip we talked about how to debug/qa our data attributes , and now we’re going to learn about how to natively track events/social interactions within Google Tag Manager .

We’re going to learn it, basing our tracking on Google Analytics Events and Social Interactions. Of course this can be expanded to any other tool just changing the data attributes, but hey, this is about to learning not about give me a copy and paste solution.

Let’s start saying that data-* attributes it’s and standard HTML5 mark up that we can use to manage our page functionality based on that data instead of relaying on classes or id.
A data attribute is intended to store values that are mean to the page or application and that doesn’t fit in any other appropiate attributes.

In our care the data that we’re storing is the hitype that we’ll be firing. In our example it could an “event” or a “social interaction” . For this we’re setting a data attribute named “wa-hittype“, and this attribut will hold the current hit to be fired, in our case “event” or “social”.

We’ll be using some other data attributes to define our events category, action, label, value and non-interactional switch, please take a look to the following table for more details:

Data Attr Description
data-wa-hittype Type of hit we want to fire on user’s click
data-wa-event-category The Category value for our event
data-wa-event-action The action value for our event
data-wa-event-label *optional. The label for our even
data-wa-event-value *optional. The value for our event if any
data-wa-event-nonint *option. Is the event non interactional?

Let’s check an example:

<a 
 data-wa-hittype="event" 
 data-wa-event-category="Ecommerce" 
 data-wa-event-action="Add To Cart" 
 data-wa-event-label="SKU0001" 
 data-wa-event-value="12.00"
 href="#"
>Add To Cart<a/>

So we have a data attribute that will allow us to know when fire a tab based on a CSS selector, and we’ve too all the info needed to populate the information for our event.

Next step is to configure some variables to read these values when the user clicks on the element.

So now when the user clicks on some element, we’ll have all our event needed data on those new variables. Let’s work on the trigger that will make our tag to fire.

We’re using the In-build {{Click Element}} Variable and some magic with a CSS Selector.

There we’re, now we just need to setup our event tag, add our variables to the tag fields, and set the trigger on this new event tag.

Now everytime you need to track a new click on some page element, you’ll just need to ask the developers to add some “standard” data mark-up to the right element.  Even if you do something wrong, the variables will take care of fixing the values were possible (like an event value expecting an integer value instead of a string) or setting a right boolean value for the non-interactional switch for the event.

Any suggestion or improvement to this tracking method is welcome 🙂

P.D. Yeah! I know I talked about tracking Social Interactions too, but I’m pretty sure that you’ll be able to figure it out. Think about like a good moment to learn how to do things instead of just trying to copy and paste and hoping it will work.

Metodologías de Análisis del usuario

Llega el verano y a la gente le aumentan las ganas de leer… O eso se dice, quizás se refiera a novelas y demás literatura para evadirse, pero por si acaso he pensado en prepara una serie post de los chulos para explicaros algunas cosas en las que estamos trabajando actualmente.

En esta serie de posts hablaremos del análisis a nivel de usuario. Es decir, acercándonos lo máximo posible a las personas reales y no quedándonos solo en páginas o sesiones sueltas. Un paso difícil de dar, no vamos a negarlo, pero que hace más reales todas las conclusiones que obtenemos de la analítica.

Todo lo que ya se ha hablado y de lo que se está hablando

Sobre esto y sobre el famoso customer journey veréis mucha información por la red, la mayoría en inglés aunque con grandes artículos también en castellano. El análisis del usuario esta de moda lo que provoca que haya mucha gente hablando de este tipo de enfoque últimamente. Pero creo que tenemos un problema, y según voy viendo es que todo el mundo habla de lo mismo:

  • Por un lado se nos presenta el concepto de customer journey, que es genial y difícil de rebatir, pero la mayoría simplemente lo describe conceptualmente lo cual sirve en la práctica para poco. Al fin y al cabo no nos dedicamos a realizar mapas mentales de los usuarios para poder dar charlas de psicología sino que lo que buscamos es que los negocios mejoren sus resultados.
  • Por otro lado tenemos el tan de moda análisis multicanal: Modelos de atribución, secuencias de campañas, etc. Aquí hay mucha chicha pero que solo podemos aprovechar en entornos de marketing pues no se nos habla de la web en si, sino de que tan solo tocamos la adquisición del tráfico cruzada con las conversiones; a nivel de usuario, eso sí. Es una información genial, pero solo con eso no podemos decir que conozcamos a nuestros usuarios

Siempre parece que nos falten piezas para resolver este puzle. Por un lado sabemos que nuestros análisis a nivel de sesión (visitas, rebotes, funnels, etc.) no son todo lo realistas que cabria esperar, por otro tampoco sabemos como llevar esta riqueza de datos al mundo de los usuarios; al menos con Google Analytics.

Este es el motivo de esta serie de post que vais a ir viendo publicados: Vamos a ver que posibilidades tenemos para hacer este tipo de análisis. Para ello usaremos mucha información y conceptos propios. Es decir, lo que os voy a contar es cosecha propia y difícilmente podréis verlo en algún libro, es el resultado de buscar como resolver distintos problemas que nos hemos ido encontrando en entornos donde sabemos que la orientación a usuario es vital para entender los datos.

El Customer Journey y los problemas del análisis cuantitativo del usuario

Partamos de la base. Sabemos que los usuarios son en realdiad personas y que la mayoría de nosotros necesitamos varios inputs para tomar una sola decisión. En definitiva, no llego a una web por una publicidad, veo un producto y lo compro siguiendo un estricto funnel de compra. Antes de la compra viene la decisión de compra y antes de esta viene una evaluación mental que todos hacemos de los productos y servicios que se nos ofrecen. De esta indiscutible verdad nace el concepto del «customer journey» que nos explica con distintas teorías cómo el usuario va avanzando en su proceso de decisión por distintos estados mentales hasta la compra. Es decir, nos explica el «viaje del cliente».

Entre las distintas formulaciones que nos han hecho los grandes gurús del marketing en la práctica cada uno hace su mix. Hay muchas perspectivas y no te puedes casar con todas. Nosotros trabajamos con un esquema como el que sigue, donde intentamos mezclar las partes de funnel de decisión de compra, con el concepto de lealtad del usuario y con los estadios del usuario heredados del inbound marketing.

Es un esquema. Pero hay otros. De cara a lo que vamos a hablar en este post no tiene mucha importancia, solo lo incluyo para ilustrar que podéis encontrar muchas metodologías para abordar el customer journey.

El problema de este esquema que os planteo (y de tantos otros) es que es que es imposible de medir completamente pues tenemos una gran cantidad de áreas desinformadas (en la fase de conciencia ni siquiera conocemos al usuario y en la de evaluación los inputs externos se escapan de nuestro control). Además aunque consiguiésemos estimar todos los valores posibles nos encontraríamos con tal cantidad de datos cruzados que sería imposible ver nada en ellos. A fin de cuentas estos esquemas son modelos conceptuales que no necesariamente van destinados a poder realizar analítica cuantitativa sobre ellos sino a sentar las bases de lo que estamos estudiando.

La solución

Al final lo que necesitamos es una metodología (o varias) que nos arrojen datos cuantitativos y sencillos de entender a la vez. Y es que los seres humanos, las personas, somos limitados. Muy limitados. No podemos intentar mirar a Matrix y entender lo que sucede, necesitamos que la información se transforme en algo comprensible para nosotros. Esto no es cierto siempre, todos conocemos a maquinas mentales que se se miran una cuadricula de 60×60 filas y son capaces de darte conclusiones al instante. Pero lo común es que esto no sea así y lo cierto es que tan importante es disponer de los datos como que cualquier persona involucrada en un proceso de decisión los entienda. Ahi, en la búsqueda de este modelo, es donde todos llevamos años dándole vueltas a «cómo representar los datos que tenemos sobre el customer journey para poder entenderlos y sacar conclusiones de ellos». Y esto no es fácil… parece casi imposible… siempre falla algo…

Tras darme contra un muro varias veces, el camino que por mi parte he tomado es el de desistir en este intento. Ya esta bien. Es el momento de aceptar nuestras limitaciones y abordar estos problemas de otra forma más sencilla, más plausible. Buscamos sencillez, encontrémosla simplificando el problema: trabajemos por focos.

¿qué es esto de los focos? pues no es otra cosa que NO intentar crear un modelo que lo contenga todo, sino distintos modelos parciales en los que cada uno resuelva una parte vital de la información (un foco) que nos interesa. Así pues nos podemos permitir simplificar la información y obviar agujeros en la misma y sacar los insights que nos interesan uno a uno. El truco está por lo tanto en describir y desarrollar los focos que realmente nos importan del usuario, sabiendo que controlándolos todos el mundo del usuario pasará a estar un poco más a nuestros alcance.

Así que el trabajo que hemos realizado a sido el de detectar y proponer soluciones para esos focos, siempre con la visión puesta en el usuario. Y así, poco a poco hemos resuelto distintos de ellos que os vamos a ir presentando. Los focos que de momento tenemos identificados son los siguientes:

  • La desviación sesión/usuario:
    Que nos tiene que indicar lo importante que es para nuestro negocio hacer análisis a nivel de usuario. Vital sobretodo para no perder el tiempo con estas historias si no va a aportarnos nada que no sepamos ya.
  • Análisis del funnel de touchpoints:
    Análisis de Funnels pero llevados al mundo de los usuarios y por lo tanto con implicaciones distintas en la definición de pasos y en las métricas a observar de estos
  • Evolución de las preferencias de uso de los usuarios:
    Inputs sobre cómo afecta lo que aprende el usuario de nuestra web al uso que hace de la misma
  • Objetivos de avance en el customer journey:
    Que nos tienen que permitir cuantificar el éxito en las primeras visitas del usuario al site, para saber si estas van iniciar un proceso de decisión o un descarte directo
  • Análisis de la fidelización:
    Cómo son las revisitas y las recompras al site. Cómo obtener KPIs de fidelización
  • y por supuesto, el análisis de conversiones multicanal:
    Que nos tiene que ayudar a gestionar desde marketing el customer journey hacia la compra

Como véis es muchisima información la que queremos identificar, por ese motivo este es solo un post de presentación. A lo que haremos en los siguientes posts es tratar cada uno de estos focos con Google analytics y dar ejemplos de uso comunes.

Seguidamente añado la lista con sus respectivos links que iremos completando en las siguientes semanas, espero que el tema os parezca interesante.



Nos vemos las próximas semanas aquí mismo.

Source: http://feeds.feedburner.com/ikhuerta

Metodologías de Análisis del usuario

Dimensiones personalizadas Tiempo y Temperatura en Tealium

¿Tienes un ecommerce o tienes a tu cargo el análisis de los datos de alguno? Seguro que más de una vez has escuchado algo como que los días de lluvia son una bendición para el comercio electrónico ya que la gente suele quedarse en casa y realizar sus compras a través de la red. Pues bien, el gran Simo Ahava nos daba una idea en este post para poder comprobar si realmente se cumplía dicha teoría mediante una implementación en GTM. Nosotros hemos comprobado que su implementación funciona perfectamente en Google Tag Manager, sin embargo teníamos la duda de cómo realizar esta misma implementación en Tealium. ¿Qué es Tealium? Para los que no sepáis qué es Tealium os diré de manera rápida que se trata de otro gestor de etiquetas, similar a GTM pero con diferentes características. Tealium utiliza el objeto utag_data para proporcionar información desde el site, además una de sus mayores fuerzas es la integración con un gran número de herramientas de terceros, lo que facilita mucho el trabajo con este gestor de etiquetas. Otra característica destacable de Tealium que no tiene GTM es que proporciona 3 entornos preconfigurados (DEV, QA y PRO) y la posibilidad de añadir […]

The post Dimensiones personalizadas Tiempo y Temperatura en Tealium appeared first on Blog de Analítica Web, Optimización y Conversión – Doctor Metrics.


Source: http://feeds.feedburner.com/DoctorMetrics

Dimensiones personalizadas Tiempo y Temperatura en Tealium

GAUPET Release: Google Analytics User Permissions Explorer Tool

Some months ago I asked some friends to test a new tool I was working on and past week I released something close to an open alpha, today after pulling some details, a new UI redesign 100% mobile compatible. I’m announcing the GAUPET release.

At first I named it as GA Governance Tool, but after some interesting chat with the “osom” Yehoshua Coren . I(we)’ve decided to change the tool’s name to something that it’s closer to what it is and here is it: GAUPET , which stands for Google Analytics User Permissions Explorer Tool. (yep, you’re right I didn’t rack my brain on this one)

You can find It the the following link : GAUPET

This will allow you to easily manage and pivot all your Google Analytics users and permissions in order to have a clear view of your current accounts User Governance status.

GAUPET will allow you to gather all your account user emails and permissions and draw them into an interactive pivot table. Even will allow you to merge different accounts users within the same report (thanks goes to Peter O’neill for this and another nice suggestions that will come in a future).

The tool comes with some predefined reports, but you will be able to pivot any data in the way you need. Just drag and drop the fields that’s it!.

The included fields are:

  • Email Address
  • Email Domain
  • Access Level
  • Account ID
  • Account Name
  • Account Access Rights
  • Account Permissions
  • Property ID
  • Property Name
  • Property Access Rights
  • Property Permissions
  • View ID
  • View Name
  • View Access Rights
  • View PermissionsLet’s take a look to a sample the report for user’s with view access:

    I’m offering this tool for free, and I’m hosting it for free, and this means that it’s offered “as it is”. Still you’ll have a feedback section on the page to report bugs, or ask for new features and I’ll try to make updates in my free time.

    Extra thanks fly to Damion Brown , Ani Lopez , Simo Ahava , Natzir Turrado , Doug Hall and Brian Clifton for their comments and testing. #tip Each of them worth a follow 🙂

#Tip – How to quickly debug/qa data attributes

With the years I learned that using CSS selectors to track user actions is really great but sadly I learned too that it’s really dangerous too.

It’s true that we won’t need to ask the IT team to add some dataLayer or ga pushes into the page, and therefore saving a lot of precious time, but in the other side, any single page update or testing will break our tracking.

Now I try to use data attributes whereas is possible, since those are more likely going to be kept for layout updates.

Checking elements for data attributes can be a tedious task, so I’m going to show you a little piece of code that I hope will make your life easier if you based some of your implementations on data attributes.

On this little snippet is where the magic happens:

(function() {
    
    var elements = [].slice.call(document.querySelectorAll('*')).filter(function(el) {
        if (typeof (el.dataset) != "undefined")
            return Object.keys(el.dataset).length != 0;
    });
    
    var data = [];
    var i = elements.length;
    
    while (i--) {
        var el = JSON.parse(JSON.stringify(elements[i].dataset));
        data.push(el);
        el["_element_type"] = elements[i].nodeName;
    }
    console.table(data);

})();

As an example I’m going to show you the output for Google Tag Manager‘s Homepage.

This has been a great time saver for me. Hope you find it useful too 🙂

Google Analytics 360 Suite: un mundo alrededor

Se lee en 3 minutos

An enterprise-class solution for a multi-screen  world”. Así titulaba Google el post donde presentaba su nueva suite de analítica e integración de datos diseñada para negocios de clase Enterprise: Google Analytics 360 Suite. El gigante de Mountain View pretende con ella aportar la ansiada visión customer centric, partiendo de la base de que el customer journey está formado por micromomentos de decisión, y de que es en ellos donde realmente es crucial llegar al usuario con el mensaje adecuado. Y es que todo pasa por entender el momento, aunque cada vez sea más difícil tener una visión completa de un usuario que tiende a ser más multidispositivo.

ga-suite

De acuerdo al mismo post, Google Analytics 360 Suite se ha creado con la intención de dar respuesta a las necesidades de los marketers, como son:

 – Tener la visión del customer journey al completo. Para tomar las decisiones adecuadas se necesita completa visibilidad de lo que está pasando en todos los puntos en los que se interacciona con el cliente, esto es, tanto en el mundo offline como en el online, incluyendo todos los canales y dispositivos.

 – Proporcionar las experiencias adecuadas a las personas adecuadas. Busca posibilitar el accionamiento inmediato del  dato a través de la integración de las herramientas de la suite no solo entre sí, sino con el resto de productos de Google (AdWords, DoubleClick, etc.).

 – Proporcionar insights útiles, no solo datos. En lugar de dejar la responsabilidad del procesado del big data al usuario final, trata de hacer el análisis del lado de la herramienta y así lograr que los insights sean fáciles de obtener.

 – Facilitar la compartición de la información.

Un vistazo a la suite

Actualmente, Google Analytics 360 Suite está formado por seis herramientas, cuatro de las cuales son nuevas. Aunque estas últimas aún están en Beta limitada, es interesante echarle un vistazo a los aspectos más interesantes de lo que la suite nos va a ofrecer.

 

Google Analytics 360

Lo que antes se denominaba Google Analytics Premium, actualizado. Su objetivo es permitir analizar el comportamiento de usuario mediante la combinación de dato online y offline. Así, se podrá entender el customer journey a través de los diferentes activos digitales y físicos.

Además, está diseñado para ser integrado con AdWords, DoubleClick Bid Manager y otros productos de Google, facilitando interpretar el funcionamiento de las acciones de marketing (conversiones post-impresión, post-click, etc), así como accionar el dato (por ejemplo mediante listas de remarketing).

Google Audience Center 360 (beta)

El DMP de Google. Si hablar del futuro de lo digital es hablar de DMPs, Google no se podía quedar atrás. Google Audience Center 360 combina todos los datos en un único punto. Además, gracias a la integración nativa con DoubleClick, se obtiene acceso a datos propiedad de Google y a datos de más de 50 proveedores. De esta forma, se podrá tener una visión customer centric que ayudará a conocer el comportamiento de los usuarios a través de dispositivos, canales y campañas. Una vez conocidas las audiencias, activarlas mediante las integraciones con AdWords y DoubleClick puede convertir a esta herramienta en una pieza fundamental de la estrategia de medios.

Google Optimize 360 (beta)

La herramienta de testing y personalización de la suite. Busca mejorar la experiencia de usuario en el site a partir de la creación de experimentos basados en hipótesis derivadas del análisis del dato recogido. Permite realizar test A/B, multivariantes o de redirección.

Google Attribution 360

Lo que antes se denominaba Adometry se ha vuelto a hacer desde cero para integrar los datos de medios offline y online, y así ayudar a los anunciantes a entender cómo está funcionando, realmente, su inversión en medios. Unifica y analiza todos los flujos de datos (incluyendo data-driven attribution, modelado del mix de medios y atribución de TV) para crear un modelo real del funcionamiento de las campañas.

Además, su integración con otros productos de Google potencian el valor de esta herramienta, permitiendo por ejemplo enviar datos a DSPs y RTBs para mejorar la compra programática.

Google Tag Manager 360

Esta herramienta proporciona agilidad en las implementaciones mediante la posibilidad de añadir, modificar o eliminar tags sin necesidad de alterar el código de la página.

Google Data Studio 360 (beta)

Una nueva herramienta de representación del dato. Permite crear informes con tablas y gráficos muy visuales de una forma sencilla a partir de datos de Google Analytics 360 Suite, Google BigQuery, Google Sheets, CSVs,etc.

 

Si os estáis preguntando cuándo será la release de la suite al completo, no hay más noticias salvo que se hará de forma progresiva, aunque si eres usuario de Google Analytics Premium o Adometry, quizá ya puedas ver los productos renombrados. Ahora solo queda esperar para poder probar la nueva suite de Google 🙂

 

Fuentes imágenes: Google, brianclifton.com


Source: http://www.analiticaweb.es/feed/

Google Analytics 360 Suite: un mundo alrededor

La Suite Analytics 360 por fin para todos los Premiums

Para los que aún no se hayan enterado, hoy 24 de mayo se hace oficial el lanzamiento de la nueva suite de analítica digital de Google. Con el nombre de Analytics 360 esta nueva suite incluye 6 productos, algunos nuevos y otros ya conocidos, que deberían servirnos entre otras cosas para entender a nuestros usuarios, mejorar el rendimiento de las campañas, visualizar la información de manera gráfica o realizar pruebas de contenido para mejorar la experiencia de uso. Todas las empresas que actualmente tienen una licencia de Google Analytics Premium, pasarán automáticamente a partir de hoy (es posible que el proceso se demore unos días)  a tener una licencia de Analytics 360 y TagManager 360,  siendo opcional el uso del resto de productos (opcionalmente puede contratarlos ? El esquema o papel que cada uno de los productos tiene dentro de la suite queda explicado en esta imagen, que nos servirá además para ir introduciendo los diferentes productos: Google Tag Manager 360 Como podemos ver en la imagen, el Tag manager 360 se encuentra en la “base” de la suite. Este producto, al igual que ocurre con el actual Google Tag Manager, nos servirá para “desplegar” o implementar el resto de […]

The post La Suite Analytics 360 por fin para todos los Premiums appeared first on Blog de Analítica Web, Optimización y Conversión – Doctor Metrics.


Source: http://feeds.feedburner.com/DoctorMetrics

La Suite Analytics 360 por fin para todos los Premiums

Universal Analytics Plugin Online Hackathon – Dual tracking

I’ve been thinking about doing a Google Analytics related hackaton for a long time. Some months ago, I started to take a look about how Universal Analytics Plugins work and I decided that coding a plugin to all the data to a secondary property using just a plugin would be a real nice example.

For years now, I’ve sharing a lot of code that I’ve worked on, some tracking ideas too, but still I don’t consider myself a developer, if i must say it, I really think that I really suck at programming even if I can do some stuff myself.

So here I am trying to organize an online Universal Analytics Hackaton. I hope this can turn on a great change to learn from other people, and understand how plugins work!!!

Of course you may be asking what’s a “Hackathon” (don’t be shy about asking). Let’s quote the Wikipedia:

A hackathon (also known as a hack day, hackfest or codefest) is an event in which computer programmers and others involved in software development and hardware development, including graphic designers, interface designers and project managers, collaborate intensively on software projects. Occasionally, there is a hardware component as well. Hackathons typically last between a day and a week. Some hackathons are intended simply for educational or social purposes, although in many cases the goal is to create usable software. Hackathons tend to have a specific focus, which can include the programming language used, the operating system, an application, an API, or the subject and the demographic group of the programmers. In other cases, there is no restriction on the type of software being created.

GitHub Repository:

https://github.com/thyngster/universal-analytics-dual-tracking-plugin

For now I’ve pushed to the repository  with some “core” code, that “already” works.

How to load the plugin:

ga('create', 'UA-286304-123', 'auto');
ga('require', 'dualtracking', 'http://www.yourdomain.com/js/dualtracking.js', {
    property: 'UA-123123123213-11',
    debug: true,
    transport: 'image'
});
ga('dualtracking:doDualTracking');
ga('send', 'pageview');

Some stuff you need to take in mind when loading a plugin in Google Analytics:

  • The plugin needs to be hosted within your domain
  • It needs to be “initialized” AFTER the “create” method call and BEFORE the “pageview” method.
  • If for some reason the plugin crashes it may affect your data collection, please don’t use this in production before it has been fully tested.

Still it needs to be improved, for example:

  1. We don’t want to use global variables
  2. Payload size check, and based on the results send a POST or GET request
  3. Add XHR transport method
  4. Code cleanup/Best practises
  5. Plugin option to send a local copy for the hits
  6. Better debug messages
  7. Name convention improvement
  8. Any other idea?

Anyone is welcome to push code, add ideas, give testing feedback, through the Github repository or the comments on this blog post.

 

 

 

 

Getting super clean content reports in Google Analytics using GTM

In Google Analytics the urls are case sensitive, therefore in our content reports /index.html will be different to /Index.html, and querystring values will make Google Analytics to think that even if it’s the same page it will recorded as a new one, /index.html?cache=off and /index.html?cache=on will be recorded as 2 different pageviews for example.

The first problem its easily fixable with a lowercase filter within the views, but the querystring parameters it’s going to be a problem … I bet you’re saying that you can just add them to the Exclude URL Query Parameters list within your view configuration page and Yes! that’s right, but I’m pretty sure that you’re likely going to end having some marketing campaigns adding new parameters, or IT adding some parameters to get some funcionality switched on (like enabling some caching feature or whatever).

So today, we’ll be using Google Tag Manager to solve this problem of having all our content reports fragmented due the unexpected querystring parameters in our pages. So let’s think about it, wouldnt be easier to identify the real parameters and getting ride of the rest that are not expected for the page functionality?, If you think about it, it’s likely a better way to do it, we can know which parameters will be used in our site, but we cannot think on unexpected ones.

To achive this, we’re going to make use of just one single variable in Google Tag Manager, yeah that’s it, just one single Custom Javascript variable.

We’ll just need to configure the paramList array on the code top, and add there all the querystring parameters that we want to keep. Any other parameter that is not listed in our array will be removed from the querystring value that is going to be recorded by Google Analytics

function(){
  try{
    
        // We'll need to defined the QS values we want to keep in our reports         
        var paramsList = ["two","one","three"];

        // CrossBrowser inArray polyfill 
        if (!Array.prototype.indexOf) {  
            Array.prototype.indexOf = function (searchElement /*, fromIndex */ ) {  
                "use strict";  
                if (this == null) {  
                    throw new TypeError();  
                }  
                var t = Object(this);  
                var len = t.length >>> 0;  
                if (len === 0) {  
                    return -1;  
                }  
                var n = 0;  
                if (arguments.length > 0) {  
                    n = Number(arguments[1]);  
                    if (n != n) { // shortcut for verifying if it's NaN  
                        n = 0;  
                    } else if (n != 0 && n != Infinity && n != -Infinity) {  
                        n = (n > 0 || -1) * Math.floor(Math.abs(n));  
                    }  
                }  
                if (n >= len) {  
                    return -1;  
                }  
                var k = n >= 0 ? n : Math.max(len - Math.abs(n), 0);  
                for (; k < len; k++) {  
                    if (k in t && t[k] === searchElement) {  
                        return k;  
                    }  
                }  
                return -1;  
            }  
        }  
        var qsParamsSanitizer= function(qs,permitted_parameters){
        var pairs = qs.slice(1).split('&');
        var result = {};
        pairs.forEach(function(pair) {
            pair = pair.split('=');
            result[pair[0]] = decodeURIComponent(pair[1] || '');
        });

        var qsParamsObject = JSON.parse(JSON.stringify(result));
        for (var p in qsParamsObject){
            if(permitted_parameters.indexOf(p)==-1)
                delete qsParamsObject[p];
        }
        var rw_qs = '?' + 
                Object.keys(qsParamsObject).map(function(key) {
                    return encodeURIComponent(key) + '=' +
                        encodeURIComponent(qsParamsObject[key]);
                }).join('&');
        if(rw_qs=="?") rw_qs="";
        return rw_qs;
     }        
     return qsParamsSanitizer(document.location.search,paramsList);
    }catch(e){
       // let's let GA to use the current location.href if
       // for some reason our code fails.
       return undefined;
    }
}

Now, we only need to set our pageview tag “page” parameter so Google Analytics uses the new sanitized array instead of the one that it’s on the url.

We’re done!. Let’s see how it works with a screenshot

Now you just need to sit down, and wait some hours to start seeing your reports in a clean way and with no fragmentation. Happy analyzing!