Campañas en Universal Analytics. Todo lo que necesitas saber: Solapamientos, referrals, etiquetados y expedientes X


Este tenía que haber sido un post de los pequeños. Juro que esa era mi intención. Solo quería explicar ciertos detalles sobre la gestión de campañas de Universal Analytics que sobretodo al ser un poco distintos a como se venían gestionando en Classic Analytics traen de cráneo a más de uno. Sin embargo la realidad y mi manía de llegar al detalle de cada caso se han impuesto y ha terminado saliendo más una guía compleja sobre gestión de campañas avanzadas en analytics que un post con pocos detalles.

La historia comienza con el cambio de Google Analytics Classic a Universal Analytics. Un cambio realmente importante al que aún nos estamos terminando de acostumbrar. Había tantas cosas parecidas (entre ellas la propia interfaz web de Google Analytics) que siempre tendemos a pensar que todo prácticamente igual entre los dos sistemas. Pero la realidad no es así. Muchas cosas han cambiado en el nuevo código de analytics.js y entre ellas de lo más notable es la gestión y asignación de campañas que ahora no es que sea mejor ni peor, sino que tiene otras peculiaridades distintas a como eran antes.

Tabla resumen de campañas de analytics

Antes de nada aviso de que partiré de lo básico, con explicaciones que casi todo el mundo conoce, pero entre ellas es posible que encontréis algunos detalles que o bien no son muy conocidos o no están muy bien explicados en la documentación de Analytics ni en otros blogs de analítica web (al menos los que yo he visto). Lo comento por los que solo leen titulares y no el contenido, que quizás se pierdan alguna cosilla 😉

Primero un repaso: Qué son las Campañas de Google Analytics

Para los más novatos recordaros el sistema de campañas que usa Google Analytics. Este se fundamenta en 5 dimensiones distintas en las que de una forma u otra se adquieren distintos valores cada una de estas dimensiones:

  • medium o medio: Es donde se almacena el tipo de medio de que ha traído la visita. De pago, orgánica, referencias, banners, emails, etc.
  • source o fuente: Es donde se almacena el proveedor o negocio que nos ha enviado la visita. La web que la trajo, el motor de búsqueda, el sistema de publicidad, etc.
  • campaign o Campaña: Es donde podemos poner el nombre exacto a nuestra campaña. Descuentos, Invierno 2014, etc.
  • term o keyword: En Motores de búsqueda es donde se almacenan las keywords que usaron los usuarios para encontrarnos.
  • content o contenido: Es una variable comodín, que nos permite segmentar a un nivel superior, ya sea especificando el contenido del anuncio, su formato o zonas de click de un mail

Cómo se informan los 5 valores de las campañas de Analytics

Estos 5 valores son los 5 clasificadores de adquisición más importantes que ofrece Google Analytics y por lo tanto comprender a la perfección tanto como se informan por si solos como qué podemos hacer para rellenarlos es vital para cualquier analista.

He clasificado las formas en las que se toman valores en estas 5 variables en 4 grupos dependiendo de donde se extraiga la información:

1. Autocumplementación de campañas

Por un lado, algunos valores se autorellenan solos cuando las visitas llegan de forma «natural al site». Para eso no tenemos que hacer nada, esto es lo que sudece de forma automática con todas las visitas que van llegando al site.

  • medium o medio:
    – Coge el valor de «organic» si la visita viene de un dominio de un motor de busqueda,
    -«referral» si viene de un click en una página cualqueira
    – y «(not set)» (o Direct) si no viene de ningún click y por tanto no sabe de donde llega.
  • source o fuente:
    – Coge el valor del motor de búsqueda en motores de búsqueda
    – y el dominio de donde viene el usaurio en visitas «referral».
  • campaign o Campaña: No coge ningún valor por defecto.
  • term o keyword:
    – Coge la keyword del motor de búsqueda (si es que no nos la ocultan con el not-provided)
    – o se queda vacío en el resto de los casos.
  • content o contenido: No coge ningún valor por defecto

2. Etiquetado de campañas

Por otro nosotros, si hemos pagado o llegado a un acuerdo para conseguir esa visita y por lo tanto controlamos el link exacto con el que llegan estas visitas a nuestra web, podemos generar enlaces hacia nuestro site con variables que cambien estas dimensiones por lo que más nos convenga.

  • medium o medio: Se define añadiendo la variable utm_medium a la url.
  • source o fuente: Se define añadiendo la variable utm_source a la url.
  • campaign o Campaña: Se define añadiendo la variable utm_campaign a la url.
  • term o keyword: Se define añadiendo la variable utm_term a la url.
  • content o contenido: Se define añadiendo la variable utm_content a la url.

Donde al menos «medium» y «source» son obligatorios.

Asi si yo etiqueto un link como: «blog.ikhuerta.com?utm_medium=blog-link&utm_source=ikhuerta&utm_campaign=prueba_post»

En analytics para las visistas que lleguen desde ese link se guardará en analytics:

  • medium o medio: blog-link
  • source o fuente: ikhuerta
  • campaign o Campaña: prueba-post
  • term o keyword: (not set)
  • content o contenido: (not set)

Aqui es importante notar que con definir solo source o medium, la campaña completa se reescribirá y si por ejemplo mi link fuese solo: «blog.ikhuerta.com?utm_medium=blog-link»

En analytics yo vería:

  • medium o medio: blog-link
  • source o fuente: (not set)
  • campaign o Campaña: (not set)
  • term o keyword: (not set)
  • content o contenido: (not set)

Y no…

  • medium o medio: blog-link
  • source o fuente: blog.ikhuerta.com
  • campaign o Campaña: (not set)
  • term o keyword: (not set)
  • content o contenido: (not set)

Como piensan muchos. Es decir, al indicar variables de campaña se elimina el comportamiento por defecto de analytics; no es que se aplique primero uno y luego otro.

3. Campañas por ID

Algunos sistemas pueden usar ID’s de campaña en los cuales con un solo ID se consigue el etiquetado de las 5 variables.

El mayor ejemplo de esto es Adwords, que nos permite autoetiquetar los links. Una vez activada la función de Adwords de autoetiquetado todos los links de adwords pasan a contener la variable «gclid» que es un ID del que analytics extrae las 5 variables de campaña (y algún dato más). Podéis comprobarlo clickando en casi cualquier link de Adwords y veréis como la URL muchas veces lleva ese gclid que sirve de referencia para sincronizar las campañas.

Otros sistemas que usan id’s los podemos definir nosotros con la carga de datos de Analytics.

Accedemos a nuestra cuenta de analytics, entramos en el «Administrador» >> a nivel de propiedad (columna central) >> y entramos en «importación de datos» (una opción que solo esta disponible en cuentas Universal Analytics). Ahí podremos crear una nueva importación del tipo «Datos de Campaña» donde subamos nosotros tablas a Analytics que asocien por un id (que se informará con utm_id) los valores correspondientes de medium, source, capaign, term y/o content.

importacion-datos-admin-analytics

Un ejemplo:

Imaginemos que mi web no puede o quiere usar campañas de analytics declarando cada variable suelta.

En lugar de eso tengo unas codificaciones propias que son algo parecido a esto:

  • C12-005: Campaña de adwords con keywords genéricas
  • C12-006: Campaña de adwords con keywords de producto
  • C13-001: Campaña display banners de marca, provedor google display
  • C13-002: Campaña display banners de marca, provedor himedia
  • C13-004: Campaña display banners de marca, otros proveedores
  • C13-011: Campaña display banners de producto, provedor google display
  • C13-012: Campaña display banners de producto, provedor himedia
  • C13-014: Campaña display banners de producto, otros proveedores
  • Etc…

Todo esto puede ser muy acorde al sistema interno de campañas de la empresa y el CRM pero muy poco practico de gestionar en analytics.

Lo que hacemos es cargarle a Analytics una tabla como esta:

ga:campaignId ga:medium ga:source ga:campaign
C12-005 cpc google genericas
C12-006 cpc google producto
C13-001 display google marca
C13-002 display himedia marca
C13-003 display otros marca
C13-004 display google producto
C13-005 display himedia producto
C13-006 display otros producto

E informar en cada visita solo el Id de campaña: blog.ikhuerta.com?utm_id=C13-006

Y a partir de entonces nuestros valores de campaña se rellenarán con tan solo tener el utm_id informado.

importacion-campañas

(Esta claro que para ello hay que entender el sistema de carga de datos de analytics, pero eso vendrá en otro post… algún día)

4. Informadas en el código

Gracias a Universal Analytics, las campañas ya pueden informarse directamente en el código de la web. Esto es mucho más potente que en en Google Analytics Classic donde solo podíamos redefinir las variables de captura.

Para informar las campañas en código debemos cumplir varios requisitos:

  • 1. Hacerlo solo en la primera página vista de la visita, de otra forma generaremos visitas nuevas
  • 2. Hacerlo antes de enviar la página vista pero después de crear el tracker
  • 3. Informar como mínimo Medium, Source y Campaign. Si falta alguna el sistema puede fallar

Asi si yo quiero que por el motivo que sea una visita se etiquete con medio=auto, source=ikhuerta, campaign=in-code deberé definir un código de Analytics como el que sigue:

ga('create','UA-xxxxxx','midominio.com');

ga('set', 'campaignMedium', 'auto');
ga('set', 'campaignSource', 'ikhuerta');
ga('set', 'campaignName', 'in-code');

ga('send','pageview');

Este sistema como decía es realmente versátil, pero si hecháis de menos redefinir simplemente los nombres de variable tenéis un plugin de universal Analytics con el que añadir esa funcionalidad.

Tabla resumen

Seguidamente añado una pequeña tabla resumen de los detalles más importantes vistos sobre las campañas. Más que nada para que los que empiecen la tengan como chuleta. En esta faltaría contemplar las campañas por ID, pero como esas se configuran a medida no tenían sentido en una tabla resumen.

Tabla resumen de campañas de analytics

¿Cómo gestiona Google Analytics las campañas Internamente?

Aquí es donde Universal Analytics ha supuesto un gran cambio con respecto a las campañas de Google Analytics Classic.

La gestión de campañas en Google Analytics Classic

En Google Analytics Classic las campañas se gestionaban con Cookies. Estas cookies guardaban tal cual les llegaba el valor de cada una de estas dimensiones y los enviaba en cada página vista tal cual venían en las cookies.

Eso originó varias consecuencias, algunas beneficiosas y otras no tanto:

  • A nivel de hacking de analytics o de configuraciones al detalle, nos permitía conocer y manipular las campañas de analytics en todo momento. Solo había que acceder a la cookie para conocerlas y solo había que cambiar la cookie para falsearlas.
  • A nivel de gestión interna de analytics, una vista podía alterar su campaña a mitad de visita de forma que los datos que nos llegaban a analytics no eral del todo cierto. Si por ejemplo una visita venía de Adwords pero a mita de visita se cargaba una página con utm_medium=loqueyoquiera, analytics guardaba toda la visita como procedente del medio «loqueyoquiera.
  • Además existían ciertos problemas de gestión de cookies en algunos navegadores que podían hacer perder la campaña a Analytics.

    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

    flujo-cambio-de-visita-por-referral

    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»

    explusion-referencia-admin-analytics

    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.


  • 4 respuestas a “Campañas en Universal Analytics. Todo lo que necesitas saber: Solapamientos, referrals, etiquetados y expedientes X”

    1. Como es habitual, un post perfecto para conocer el funcionamiento al detalle de Analytics con información clara y precisa.
      ¿En que caso práctico sería apropiado informar las campañas en el código como indicas en el punto 4? No acabo de entender la aplicación.

      Gracias Iñaki y un saludo.

      • Buenas Juanfra!

        Gracias por tus comentarios. He añadido un pequeño bloque de texto intentando explicar lo que preguntas. Lo localizarás como «Para qué nos sirve saber la campaña». Espero que así quede todo más claro!

    2. Gracias Iker, excelente artículo, como de costumbre! Ahora entiendo porque las discrepancias con Universal a nivel de campañas están creciendo. Pero tengo una duda ¿La solución que planteas al final, remplaza al etiquetado manual clásico(utm)?

      • Gracias david por el comentario.

        El código del final mas que para reemplazar es para emular lo que Analytics guarda. Es decir, es para saber nosotros que es lo que va a recoger Analytics pues al quitarnos la cookie no lo sabemos y durante la visita ocurre estamos ciegos. Solo al ver los datos al dia siguiente en los informes podemos averiguarla y en consecuencia no podemos hacer ninguna acción basada en la campaña actúal del usuario. Con ese código ya si que podremos conocer la campaña mientras el usuario aún visita el site.

    Deja una respuesta

    Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *