Por este y por otros motivos más técnicos, Google Analytics decidió sacar de las cookies las campañas en Universal Analytics y pasar a gestionar esta en su servidor.

La gestión de campañas en Universal analytics

Ahora, las campañas no son javascript, sino un proceso que se hace en los servidores de Analytics a partir de las URLs cargadas de las visitas. Analytics al procesar los datos mira la primera de las páginas vistas y de esa saca la campaña para toda la visita.

Este sistema en un principio es más seguro y evita que el navegador se responsabilice de datos que perfectamente pueden sacarse a posteriori de las propias páginas visitadas. Sin embargo, como veremos a continuación, provoca ciertos cambios en el comportamiento de las campañas que debemos conocer.

¿Que pasa si cambia la campaña a mitad de visita?

Esto Universal Analytics lo ha resuelto reseteando la visita siempre que perciba un cambio de campaña. Es decir, que si existe un cambio de campaña a mitad de visita Analytics no le cambia la campaña sino que cierra la visita anterior y empieza una nueva visita con la nueva campaña. En definitiva, para mejorar los datos de campaña duplicamos visitas.

¿Cuando sucede esto? Pues en varios casos:

• 1. Cuando etiquetamos las paginas de destino con utm’s (de campaña o de id’s). En ese momento esa nueva página ya es de la nueva visita. Esto es algo clásico cuando se usan incorrectamente campañas de analytics para seguimiento de campañas internas
• 2. Cuando La visita llega a una página con un referral distintos al de la propia web. Es decir, cuando el usuario sale de nuestra web y luego vuelve a entrar. Ahí también se genera una nueva visita que aplica las normas de autocumplimentación de campañas para averiguar sus 5 nuevos valores de campaña

El primer caso es del todo lógico, solo tenemos que saber que ahora ya no sobreescribimos campañas, sino que partimos las visitas en varias al cambiar de campaña. En cambio el segundo caso es el que suele dar más problemas a la gente, porque es un comportamiento totalmente nuevo y, para muchos, inesperado.

Pongamos varios casos que van a afectarnos con el segundo caso de creación de nueva visita con nueva campaña:

• 1. Una visita para poder hacer el pago va a la web del banco, y al volver con el pago ya hecho Analytics se encuentra con que el viene de una referencia externa y por lo tanto resetea la visita. Nos encontramos con que todos los pagos de ese banco nos aparecen de visitas con una sola página vista (la de gracias) y con medium=referral y source=el dominio del banco.
• 2. El mismo caso aplicado a paypal
• 3. Una visita para poder hacer una búsqueda lanza al usuario a una página externa. Este usuario luego vuelve al dominio principal. Nos encontramos con que cuando vuelve siempre genera nueva visita con medium=referral y source=esa web.
• 4. Una web lanza las búsquedas sobre google, con el comando «site:» para que google le haga el trabajo. Al volver el usuario cuenta como nueva visita con medium=organic y soruce=google y parece que ese buscador no lo use nadie
• Y así casos y más casos

Cómo solucionar este problema

Para estos casos, la función de Google Analytics de exclusión de Referencias se convierte en una herramienta vital si queremos garantizar la integridad de nuestras campañas.

Esta herramienta en cuentas de Universal Analytics la encontramos en «Adminsitrador» >> a nivel de propiedad (columna de en medio) >> Información de Seguimiento (icono .js) >> «Lista de Exclusión de Referencia»

Ahí Google nos permite ir añadiendo dominios con los cuales, si detecta que la visita viene de ese referral no tiene que aplicar sus normas por defecto de campaña. Por lo tanto al incluir un dominio en esa lista pasarán dos cosas:

• 1. Las visitas marchen a ese dominio y luego vuelvan no resetearán la visita ni cambiarán su campaña
• 2. Si la visita es nueva, llegará como medio=(not set) y contará como visita directa

Es decir, que le decimos a analytics que ignore que el usuario viene de ahí.

Con esta herramienta decíamos que se solucionan la mayor parte de estos problemas puesto que si controlamos a donde enviamos los usuarios va a bastar con añadir esos dominios a la lista para que no nos reseteen visitas.

Por ejemplo, uno de los trabajos más comunes a la hora de realizar implementaciones serias de Analytics en eCommerces y demás webs transaccionales es añadir a la lista de exclusión todos los métodos de pago que utilice el site: paypal, sermepa, 4b, etc. Asi cuando el usuario vuelva de pagar en el banco seguirá contando como la misma visita que era.

Pero y si no quiero anular siempre esa referencia como campaña

El problema del sistema de exclusión de referencias es que es totalitario. Si yo incluyo ahí un dominio, siempre sera excluido lo cual puede complicar la situación si de un dominio recibimos tanto visitas a excluir como naturales que si que deberían generar campaña.

Os pongo un ejemplo reciente, una web que en su sistema de creación de usuarios envía un email al usuario recién creado para que valide que su cuenta existe y le tiene esperando hasta que haga dicho paso.

Cuando el usuario abre el mail desde un webmail (gmail, outlook-online, etc.) la visita llega con una referencia desde las webs de email donde estaba leyendo y por lo tanto analytics hace de las suyas reseteando la visita y cambiando la campaña…

El problema está en que no podemos aplicar una exclusión de referencia a todo gmail, outlook, yahoo, etc. Primero porque nunca cubriríamos todos los dominios posibles y segundo porque seguramente si que recibiremos visitas desde esas direcciones como nuevas visitas y no queremos que Analytics nos las cuente como directas (que es lo que haría de encontrar esa visita procedente de un dominio en exclusión de referencia). Asi que ese método de la lista de exclusión de referencia no nos vale.

Solución: Creando una variable de «nooverride»

Analytics Classic tenía una variable especial para estos casos que nos permitía no cambiar la campaña cuando esta viniese indicada. Sin embargo en el código analytics.js de Universal analytics esta variable no está contemplada, no existe y no podemos por lo tanto forzar ese comportamiento… ¿No? Bueno, no podemos hacerlo por defecto, pero si podemos engañar un poco a Analytics para que se comporte como queremos con esta variable.

En Universal Analytics se nos permite definir los valores de campaña a mano (lo hemos visto antes). Esto es con funciones del tipo «ga(‘set’, {VariableDeCampaña}, {valor});». Este envío de variables además tiene una peculiaridad: si lo hacemos mal, provocan que Analytics no realice su gestión de campañas acostumbrada quedándose con los valores que ya tenía. Esta peculiaridad es la de la que vamos a sacar provecho para no resetear las campañas:

• Vamos a crear un pequeño código, que cuando detecte la variable «nooverride» en la URL provoque este pequeño fallo, enviando el source de la campaña vacío e impidiendo así que se resetee la visita.

El codigo es tan simple como el siguiente:

if (location.toString().match(/[\?&]nooverride=1/i)) ga('set', 'campaignSource', '');

Este debemos incluirlo en nuestra configuración de analytics:

– DESPUÉS de crear el tracker con ga(‘create’, UA-…
– y ANTES de lanzar la página vista con ga(‘send’, ‘pageview’);

Es decir que en una configuración normal de Analytics quedaría algo así:

ga('create','UA-xxxxxxxx', 'midominio.com');
if (location.toString().match(/[\?&]nooverride=1/i)) ga('set', 'campaignSource', '');
ga('send', 'pageview');

Con eso, cuando llegue una visita con «?nooverride=1» o «&nooverride=1», la campaña no se reseteará.

Volviendo al caso anterior, ahora bastará con que etiquete los links de los emails de registros con ese nooverride=1 como variable para solucionar el problema y que mis confirmaciones de registro mantengan la campaña que tenían al principio.

Cómo hacemos esto en Google Tag Manager

Este mismo ejercicio podemos querer realizarlo en GTM. Sin embargo en GTM no existen los envios de datos condicionales (no puedo meter un IF en una etiqueta). Asi que para conseguirlo tendremos que dar varios pasos:

• 1. Creamos una regla: {{url}} >> Coincide con la Regex (no diferenciar may y min) >> «[\?&]nooverride=1»
• 2. La aplicamos en negativo a nuestra etiqueta de página vista actual.
• 3. Creamos una Macro, tipo Javascript Personalizada que nos permita enviar valores vacios:
  Nombre: void
  Valor: function () { return »; }
• 4. Duplicamos la etiqueta de página vista, le cambios a la misma regla pero ahora en positivo y le añadimos la configuración un «Campo a Configurar»:
  Nombre del Campo: campaignSource
  Valor: {{void}}

Con esto conseguiremos el mismo comportamiento que con código, pero ahora dentro de GTM.

¿Cómo saber y/o guardar que campaña es la que usa el usuario?

Como decíamos antes, una de las cosas que hemos perdido con el nuevo sistema de campañas es esa maravillosa cookie tan accesible que nos permitía saber en todo momento en que campañas estábamos. Esta cookie tenía un sin fin de usos en implementaciones avanzandas ya fuese en CRO, A/B testing o simplemente mejorando la información de nuestro CRM a base de Para qué nos sirve saber la campaña

No nos engañemos, por defecto y si dedicamos nuestros esfuerzos en analítica solo al reporting, este dato no nos va a servir de mucho. Al final, para hacer reporting podré ir a Google Analytics donde las campañas están más que claras por lo que no las necesito en javascript. Cuando saber la campaña se vuelve útil es en dos casos:

Cuando queremos dotar a nuestra web de inteligencia según la campaña que llega:

Esto puede ser desde adaptar la apariencia a la publcidad que se ha visto hasta cambiar totalmente las llamadas a la acción o los mensajes enviados al usaurio dependiendo de lo que ya sabemos de el.

En el primer caso tendríamos ejemplo a un emailing que usar la variable de camapaña content para saber que imagen mostrar en las landings, así el usuario percibe una continuidad en la comunicación y por lo general la conversión sube. También podríamos adecuar cada medio según como sabemos que convierte mejor: más presencia del contenido en organic y directo, más transaccionalidad en adwords, más garántias y sellos de confianza en tráfico de afilaidos, etc. En definitiva ténicas de CRO aplicadas solo a un canal concreto de la web. (Nota para los SEOs: tened en cuenta las implicaciones de estos cambios y como si no se usan canonicals o se abusa de manipulación para el medio organic podemos caer en «cloaking»).

En el segundo caso simplemente nos aprovecharíamos del conocimiento del flujo de campañas, sabiendo por ejemplo en una campaña de Inbound Marketing los usuarios procedentes de email ya son usuarios por lo que no debo ofrecerles registro simple de solo email y puedo aprovechar esos espacios para obligarles a logarse o para técnicas de lead nurturing.

Cuando queremos ligar la información del CRM o base de datos interna con la de Analytics

En muchas ocasiones la base de datos que importa es la propia. Esto es correcto, analytics tiene que servirnos para analizar estadisticamente la web pero no para llevar la contabilidad real de objetivos cumplidos (llevar la contabilidad de compras y más aun de ingresos, con analytics es un gran error). Por lo tanto, cuando ofrecemos resultados exactos de conversiones muchas la información de campaña no nos sobra.

Lo que solía hacerse antes era cualificar la base de datos de conversiones reales con datos de analytics. Sacabamos los datos de campaña de analytics y los metiamos como información extra de la compra. Pero ahora eso ya no puede hacerse pues esa cookie no existe.

Todo esto con Universal Analytics y analytics.js lo hemos perdido…

¿Cómo podemos recuperarlo?

Pues os ofrezco dos vías, una más sencilla (pero más cutre) si no sois muy diestros con javascript y otra más seria.

Usando el código del viejo Analytics Classic a la vez, solo para seguir disponiendo de esa cookie

Una forma fácil de conseguir esa información es dejando instalado en el site una copia del viejo Classic Analytics. Este aunque envíe datos a una cuenta que no usamos nos permitirá ver esa cookie y seguir trabajando como hacíamos hasta ahora.

Los problemas de este sistema son obvios:

• Por un lado cargamos las la página con multitud de funciones que no necesitamos
• Por otro llenamos google de basura con datos de visitas que no vamos a mirar
• Además usamos un sistema de campañas que no es exactamente igual que el de Universal Analytics, pues este sabemos que resetea las visitas con más facilidad que el viejo analytics
• Y por ultimo estamos usando un método que sabemos que cualquier día quedará obsoleto cuando Google deje de darnos el código de ga.js

Sin embargo no hay que negar que por cantidad de trabajo a muchos puede salirles rentable usar este sistema.

Creando un nuevo código javacsript que emule el comportamiento de campañas que va a hacer universal analytics

El segundo sistema pasa por crear nuestro propio código que se parezca lo máximo posible a la gestión que hace Universal Analytics de las campañas y las almacene en cookie permitiéndonos así acceder a ellas cuando queramos.

Esto nos brindará datos a bajo coste de recursos (pues no cargamos todo Analytics, solo un fragmento para averiguar sus campañas) pero al ser código propio (en este caso mio, desarrollado con mis manitas :P) y no de Google no tenemos garantías de que siempre funcione correctamente (que uno es humano y a veces se puede equivocar).

Cada uno puede hacer su código para emular campañas de Universal Analytics pero yo os dejo el mío, espero que os sirva o para usarlo directamente o como base para vuestros pequeños añadidos.

Este código debe incluirse:

– ANTES de la llamada a Analytics y básicametne nos brindará estas funciones:

gaEmulator.exec() :

Es la función que lanza las campañas. Debe lanzarse siempre en cada página vista, al final del código de gaEmulator.

gaEmulator.get( Dimension ) :

nos permitirá conocer la dimensión que queremos extraer.

Por ejemplo:

var medium = gaEmulator.get('medium'); 

Nos dará el medio de la campaña y así para «medium», «source», «campaign», «content», «term», «referral» y «landing».

Esta función es la que podemos usar para por ejemplo añadir a nuestros

gaEmulator.addIgnoredRef( Referral ) :

Nos permitirá indicarle que dominios no deben resetear la visita (como si lo hiciesemos en la lista de exclusiones de referencias de Analytics).

Ahi si por ejemplo pongo:

gaEmulator.addIgnoredRef('paypal.com'); 
gaEmulator.addIgnoredRef('misuperbanco.com'); 

Al volver el usuario desde paypal o desde tu banco, después de pagar, no se me reseteará la visita ni se recogerá nueva campaña.

gaEmulator.setCookieTime( seconds ) :

Nos permite cambiar el tiempo por defecto de la cookie de campaña (que por defecto son 6 meses)

Así, por ejemplo:

gaEmulator.setCookieTime( 30*24*60*60 ); 

Pasará las cookies a 30 días.

El resto del proceso es transaparente, hace muchas cosas (averigua el referral, mira si es un buscador, asigna campañas automaticas, recoge las que haya en los utm’s, etc.) pero no nos interesan apenas salvo que queramos hacer cosas raras.

Nota: Lo que este código no gestiona es:
– Ni la carga de campañas por ID’s (por lo que de visitas Adwords autoetiquetadas solo se averigua su medium y source y del utm_id no se gestiona nada).
– Ni la definición en el propio código de las campañas (pueden definirse con gaEmulator.vals[{nombreVariable}] = {valor};)

Ejemplo de implementación de gaEmulator:

Para acabar con este apartado dejaros solo un ejemplo de implementación de este código:

Luego, cuando quiera saber la campaña del usuario usare gaEmulator.get().

El siguiente ejemplo nos muestra como, tras haber usado el bloque de arriba, podemos añadir el medio y el source con jQuery a un formulario para que cuando este se envíe nos llegue también esa información:

$(function () {
  $('form#envio').append('');
});

Luego solo nos resta, desde el servidor capturar esos valores:

$medium = $_GET['medium'];
$source = $_GET['source'];

Emulador de campañas en Google Tag Manager

Hoy en día, cualquier cosa que hagas debes poder llevarla a GTM. En este caso llevar este codigo a tag manager es tan sencillo como dar dos pasos:

1) Creamos una etiqueta html personalizado en nuestro GTM que se active en todas las páginas y en ella copiamo el código base con su configuración y acabado en gaEmulator.exec():

2) Creamos una macro javascript personalizada que nos permita acceder a esos valores de campaña cuando lo necesitemos:

function () {
  return (gaEmulator) ? gaEmulator.get('medium') : '';
}

Y ya podemos usar esa macro para los scripts o etiquetas que queramos…

Conclusión

El mundo de las campañas de Analytics es bastante curioso, en un principio todo parece funcionar de forma automática y nos permite despreocuparnos pero poco a poco empiezan a aparecer los Expedientes X que nos muestran datos raros y erróneos. Los analistas (o las personas que usan Analytics) acaban pasando varias fases según su conocimiento de las campañas:

• Las dejamos actuar solas
• Luego empezamos con los etiquetados de utm’s brutos, sin pensarnoslo mucho
• Seguimos tomándonoslos un poco más en serio y aplicando agrupaciones de canales para mejorar la lectura de sus datos
• Luego llegamos a los detalles, a entender cuando una visita cambia de campaña y a leer los datos enteniendo estas peculariedades.
• A partir de ahí es cuando empezamos a configurar bien las campañas: a añadir referencias excluidas, a personalizar el tiempo de campaña, etc.
• Y cuando se nos quedan cortas, pasamos al mundo de los embudos multicanal (o multiCampaña-más bien)

Las campañas son en definitiva un tema complejo que si no dominamos nos puede llevar a más de un error. ¿Cuantas veces se han tomado decisiones basadas en problemas al leer las campañas? ¿Cuantas cuentas saben que tienen datos de asignación de campañas incorrectos y no los arreglan por desidia o desconocimiento? Pero lo que más me preocupa es ¿Como puede una empresa permitirse irregularidades en un tema tan vital como la asignación de resultados por proveedores de tráfico? Pues porque la Analítica web sigue siendo una disciplina poco madura en muchas empresas, pero todo llegará.

Espero haber puesto mi granito de arena y que este post sirva a más de uno para resolver sus problemas de campañas. ¿Sigues con dudas? No te preocupes, déjalas en los comentarios y veremos que podemos hacer 😉 ¿Y si el problema es grave? Pues ya sabes donde encontrarme, podemos hablar de tu problema y ver un presupuesto adecuado a tus necesidades.