Tags populares:

¿Por qué debo creerme una métrica calculada a partir de una muestra si cambiando la muestra cambiaría el valor?

25/09/2014 a las 15:10

Esta es una pregunta que, como estadística, me han hecho incontables veces y muchas de ellas en el entorno del samplig (injustamente tratado de forma habitual como el demonio) de Google Analytics.

Dado este fenómeno reiterado he creído que era un buen tema a tratar en un post.

muestreo

La respuesta constituye la esencia de la teoría del muestreo estadístico y para responderla vamos a focalizarnos en el tiempo medio en el site. La clave reside en las buenas propiedades de los estimadores utilizados habitualmente, entre ellos por supuesto la media, que son las siguientes:

1. El valor medio de la media muestral coincide con la media poblacional.

Es evidente que la media varía de una muestra a otra (si de un total de 1000 visitas cojo una muestra de 100 el tiempo medio será uno, si cojo otra muestra de 100 el tiempo medio será distinto seguro). Sin embargo, si repitiéramos este proceso de substraer muestras (cosa que no hacemos en la práctica), todos estos valores distintos de la media muestral estarían agrupados (con mayor o menor dispersión) entorno a la media poblacional. Cuando un estimador tiene esta propiedad se dice que es un estimador insesgado.

Esto nos deja algo más tranquilos pero no del todo ya que, como hemos apuntado antes y seguro que está retumbando en vuestra mente, nosotros solo tenemos una de esas estimaciones y por tanto desconocemos si está cerca o lejos de la media poblacional también desconocida que queremos estimar.

Para quedarnos más tranquilos sobre este aspecto tenemos la segunda propiedad.

2. La variabilidad del estimador (media muestral) disminuye al aumentar el tamaño de muestra.

Los datos en sí tienen una variabilidad que a menudo olvidamos pero que siempre está allí y conviene tener presente como comentamos en anteriores posts. Conocer dicha variabilidad ya presente en los datos poblacionales (todas las visitas de mi site no están el mismo tiempo en él) nos permite calcular el tamaño necesario de muestra para que, por ejemplo, el 99.7% de las medias muestrales estén a una distancia de menos de dos unidades de la media poblacional.

De esta forma, mediante cálculos estadísticos, se puede determinar cuál es el tamaño de muestra necesario para garantizar esta precisión en nuestra estimación (para vuestra tranquilidad diré que el tamaño de muestra no crece proporcionalmente al tamaño de la población, tema que trataremos en otro post si queréis). Este es un trabajo que, en el caso del sampling en los reports de Google Analytics, desempeña Google sin dar demasiadas explicaciones al respecto. Se trata una vez más de un acto de fe por nuestra parte (no mayor a los que hacemos habitualmente) que consiste en creer que el equipo de Google tiene conocimientos básicos de muestreo estadístico. Preguntarse por qué no dan detalles sobre ello es natural en el caso de personas curiosas y os aseguro que a mí me ha pasado reiteradas veces, pero reflexionando en frío debemos pensar que tampoco nos dan detalle de muchos otros aspectos técnicos ni creo que puedan hacerlo dado que estarían haciendo público su producto. En el caso del muestreo resulta tan claro y evidente cómo se debe hacer que es impensable que Google no lo gestione de la forma adecuada.

Así que, a pesar de conocer una única estimación del valor que queremos conocer, sabemos que “casi” en todos los casos va a estar muy cerca del valor poblacional. Cuando haces una estimación de este tipo no puedes asegurar que tu estimación no sea una de esas tres de cada mil que caen más lejos de la media poblacional, pero este es un riesgo que debemos estar dispuestos a asumir SIEMPRE que trabajemos con estimaciones estadísticas (encuestas, tests de calidad en procesos industriales, estudios de mercado, etc.). Trabajando con el umbral del 99.7% tenemos que pensar que, el hecho de que nuestra media quede a una distancia superior a la de dos puntos es como si compráramos 997 boletos en una rifa con 1.000 boletos a la venta y no nos toca el premio (hay que ser muy gafe para que esto pase).

Resumiendo: que siempre que queremos hacer cálculos en base a una muestra corremos el riesgo de equivocarnos, pero este riesgo se puede controlar :)

El tiempo es oro: tiempos de página y tiempos de usuario en Google Analytics

04/09/2014 a las 12:35

 

Vivimos con prisa y el dicho de que el tiempo es oro es más cierto que nunca.

Sin embargo, en el terreno de la analítica web, los análisis de tiempos parecen unos segundones (cuando no se olvidan por completo). Al  hablar de tiempo, nos referimos a dos tipos de métricas diferentes: los tiempos de página (site speed) y los tiempos de usuario (user timings), ambos, localizados dentro de la sección “Comportamiento” de Google Analytics.

 

Tiempos de página

No vamos a decir nada que no sepamos todos ya, pero nunca está de más un recordatorio para no perder de vista aquello que es importante. Los tiempos de carga de nuestra web son críticos. Y no solo porque, como todo iniciado en SEO sabe, los buscadores favorecen en su posicionamiento a las webs más  optimizadas, sino porque no todo el mundo tiene el mismo ancho de banda. Esto último es especialmente importante si parte de nuestra audiencia potencial procede de zonas rurales o de países en vías de desarrollo.

 

mapa_t

tabla_t

 

¿Tendrán los internautas de las zonas con peores anchos de banda  la paciencia suficiente para moverse por nuestro sitio web si éste no está bien optimizado en cuanto a velocidad de carga?

t_rebote

 

En este ejemplo, se aprecia una tasa de rebote claramente superior a la media para las regiones con tiempos medios de carga más altos. Y en mayor o menor medida, la pauta se repite para otros muchos sitios revisados. Hay más factores, desde luego, pero un tiempo de carga de la página de más de medio minuto,  no ayuda.

Hay que tener en cuenta que para la obtención de estos tiempos se mide, por defecto, un 1% de las sesiones. Este porcentaje se puede modificar introduciendo la siguiente línea en el código de seguimiento, antes de enviar la página vista.

Por ejemplo, en Classic, podríamos cambiar el 1% de muestra por un 5% mediante

_gaq.push(['_setSiteSpeedSampleRate', 5]);

situado antes de _gaq.push(['_trackPageview']);

En Universal Analytics, ese parámetro lo cambiaríamos en

ga(‘create’, ‘UA-XXXXX-Y’, {
‘cookieDomain’: ‘xxxxxx.com’,
‘siteSpeedSampleRate’: 5
});

 

Antes de lanzarnos a poner un 100%, hay que saber que hay límites en función del volumen de tráfico del site. A partir del millón de hits diarios, Google Analytics no recogerá más del 1%, no importa que hayamos especificado un porcentaje mayor.

 

Si los resultados obtenidos no son todo lo buenos que quisiéramos,  podemos detectar puntos de mejora concretos en este terreno,  mediante herramientas como la extensión del navegador Firebug con su plugin Yslow.

 

p_yslow

Fuente: Yslow.org

Otra herramienta gratuita similar es Google PageSpeed, cuya API nos permite personalizar la manera en la que se muestran los resultados de la evaluación que hace de nuestra página, encolar la evaluación de múltiples páginas sin tener que hacerlo una a una a mano, etc.

pagespeed_API

Google Analytics, para estos informes, calcula los tiempos de carga  de la misma  manera que dichas herramientas, aunque no entre en detalle sobre recomendaciones, ya que no es su fin.

 

Tiempos de usuario

Este tipo de métricas no son tan conocidas, ni su utilidad tan  evidente, pero la tienen. Se trataría de mediciones personalizadas sobre elementos determinados. Aclararemos lo que significa ésto un poco más adelante.

Por defecto, este informe está en blanco, ya que se requiere cierta implementación por nuestra parte. El comando a utilizar es:

ga('send','timing','timingCategory','timingVar', timingValue);  // para Universal Analytics

o

_gaq.push([‘_trackTiming’, category, variable, time, opt_label, opt_sample]); // para Classic

En él,  indicamos la categoría del tiempo medido, su nombre y su valor para esta medición en concreto (esos son los parámetros obligatorios). Podríamos tener una categoría para los tiempos de carga de imágenes, otra para medir los tiempos de reproducción de los videos que tengamos en él, otra para recoger el tiempo empleado en interactuar con formularios u otros elementos, etc.

Como se puede ver en los ejemplos de categorías que damos, este tipo de métricas  nos pueden servir para analizar los tiempos de carga  de elementos específicos de la web, el grado de interés que despiertan nuestros contenidos y posibles problemas de usabilidad (correlación entre tiempos altos a la hora de rellenar un formulario, por ejemplo, y la tasa de abandono). Para este último uso, no serviría recurrir a la métrica “promedio de tiempo en página” cuando en una página hay más de un elemento al que pueda dedicar su tiempo el usuario.

cronometro

 

El tiempo a enviar mediante ese comando se calculará restando el tiempo (newDate().getTime()) del momento en el que termina el hecho que queremos medir (click en el botón “stop” de un video,  cuando se ha terminado de cargar una librería, cuando enviamos el formulario…) al momento inicial (click en el botón “play”, comienza la carga del script, comenzamos a rellenar el primer campo del formulario, etc.).

Es interesante incluir código que descarte tiempos menores que cero o anormalmente altos, para eliminar irregularidades (como el que el usuario cambie la hora del ordenador durante el proceso) que puedan afectar a los valores total y medio.

A la hora de mostrar los resultados de nuestras mediciones, disponemos de tres tipos de informe:

-Explorador: una tabla que nos mostrará por categoría de medición o en más detalle, para elementos concretos,  los tiempos medios y el número de muestras con las que se han calculado.

user_timing_1

user_timing_2

 

-Distribución: englobará las diferentes muestras en rangos de tiempo, para que podamos ver la distribución y descartar los extremos, si fuera necesario.

ut_distr

-Gráfico de visitas por ubicación: aquí volvemos a relacionar tiempos y ubicaciones geográficas, mediante un mapa como el que mostrábamos para los tiempos de página.

 

Resumiendo

Si le damos a la eficiencia de nuestra web la importancia que merece, tenemos a nuestro alcance las herramientas que nos permitirán optimizarla en ese sentido y en base a un análisis todo lo pormenorizado que queramos.

 

Nueva aplicación de Google Analytics para IOS

30/07/2014 a las 08:00

Hasta ahora, para los que tenemos  un dispositivo de la compañia de la manzana, solo había 2 maneras de ver los datos de Google Analytics en un iphone o ipad. Acceder directamente a la web de Google Anlalytics, con los problemas con el scroll y ciertos gráficos, o bien utilizar alguna de las aplicaciones no “oficiales” que existe para poder ver los datos de nuestras cuentas.

La aplicación oficial de Google Analytics, solo estaba disponible de momento para sistemas Android… y digo de momento porque este mes, Google ha lanzado por fin la aplicación para sistemas IOS de Google Analytics.

La he estado usando en las últimas semanas y si bien echo en falta algunas de las características de aplicaciones como Quicklytics, merece la pena ser probada y será probablemente mi segunda aplicación para visualizar los datos de mis cuentas.

Qué vas a encontrar en las nueva aplicación:

  • Gráficos optimizados para dispositivos móviles
  • Navegación lateral como la de Google Analytics
  • Posibilidad de usar la segmentación (solo los que trae Analytics por defecto)
  • Ver lo que sucede en tiempo real en tu sitio en la pantalla de tu móvil (cuidado que engancha)

Y más características que prefiero que vays descubriendo tú y nos las comentes en los comentarios.

Descárgate la aplicación y empieza a “trastear” con ella y para que vayas abriendo boca, aquí tienes algunas capturas de cómo es

 

Informe de adquisición Informe de tiempo realInforme de comportamiento

 

Empieza la batalla por convertirse en el estándar de la medición offline

30/06/2014 a las 08:00

Parece que se ha puesto de moda poner como excusa la privacidad de los usuarios para justificar ciertos movimientos estratégicos.

Si en Octubre del 2011 lo hizo Google al introducir el concepto “not provided” dentro de Google Analytics, para esconder las búsquedas orgánicas en modo logeado, esta vez lo ha hecho Apple al anunciar su nuevo sistema operativo iOS 8.

Una de las novedades que ofrece el nuevo iOS 8, no representa un gran impacto para el usuario de a pie, pero sí marca una clara estrategia en pro de su sistema de seguimiento de personas iBeacon.

Básicamente si la medición tradicional de Wifi analytics se basa en las MAC address para identificar a los dispositivos, la novedad del sistema operativo de Apple es que convierte a esta MAC en un número aleatorio.

mac address

(Continua en el Blog de investigación de la escuela de negocios online OBS)

Guía para implementar el Ecommerce Mejorado (Enhanced Ecommerce)

25/06/2014 a las 14:29

Consigue la guía de ecommerce mejoradoHace unos días, escribimos un post sobre el nuevo Ecommerce Mejorado de Google Analytics. Como creemos que es uno de los cambios más importantes que ha hecho Google desde que sacó el Universal Analytics, hemos preparado una guía en la que encontrarás toda la información sobre el nuevo ecommerce mejorado y qué aporta a nivel de análisis así como una explicación paso a paso de cómo instalarlo utilizando el Google Tag Manager.

Y para los que crean que utilizar el Google Tag Manager es muy complicado, dentro de la guía encontrarás un cupón de descuento para nuestro curso de instalación y configuración de Google Analytics con Google Tag Manager.

Ya no tienes excusa para descubrir qué pasa con tus usuarios cuando realizan una compra en tu sitio  y, descubrir qué puedes mejorar para que tengan una experiencia de uso más satisfactoria y obtengas más ingresos.

Quiero la guía Metriplica del Ecommerce Mejorado (Enhanced Ecommerce)

 

Google Analytics y el problema de las atribuciones

25/06/2014 a las 08:04

 

Informe de Rutas de Conversión de Google Analytics

Informe de Rutas de Conversión de Google Analytics

Google Analytics lleva bastante tiempo intentando dar una solución adecuada al problema de las atribuciones. Este problema se puede resumir de la siguiente manera: ¿cómo determinar de manera justa la contribución de un jugador, al resultado final del juego?

La primera incursión en este terreno, realmente tímida, fue la adopción desde el principio de los tiempos del criterio de última interacción, para asignar a los canales de tráfico el crédito de una conversión. Este criterio sigue vigente en los informes estándar de la herramienta.

Cuando vemos que el canal “orgánico” nos ha aportado 1.234 ventas por valor de 74.323 €, lo que nos está diciendo Analytics es que la sesiones en la que se verificaron esas conversiones, en este caso la venta, fueron originadas por un motor de búsqueda, y desde los resultados gratuitos (tráfico orgánico).

Esto es así para todas las fuentes de tráfico, salvo para “directo”. Las visitas directas por defecto no “machacan” a otras fuentes de tráfico que hayan originado visitas previas por parte de un usuario. Por lo que si accedo a un site por Adwords, y no convierto, y luego entro por directo, y convierto, la conversión se le adjudicará a Adwords (por defecto).

El criterio es bastante injusto. En primer lugar no nos dice nada del trabajo efectuado por las otras fuentes de tráfico con las que hayan podido interactuar los usuarios, antes de que la conversión se efectuara. Y, por otro, le resta peso al tráfico directo.

Consciente de esto, la gente de Google desarrolló los informes de Embudos Multicanal, que llevan activos por lo menos un par de años, y que son la base de lo que veremos a continuación.

Google-Analytics-MCF

Agrupaciones de canales en los informes de MCF.

Diseñar cuadros de mando a medida ahora es más fácil

18/06/2014 a las 08:07

La última actualización de Klipfolio permite fácilmente crear Klips con múltiples componentes y ubicarlos en distintas posiciones (horizontal, vertical, etc…) mediante un layout. La experiencia de creación es mucho más agradable y las posibilidades más amplias.  Tal como vemos en la siguiente imagen, hay varios elementos en un mismo Klip, dos en horizontal y uno en la parte inferior ocupando el mismo espacio horizontal que los dos superiores. Esta disposición de elementos no era posible con la versión anterior que solo permitía combinar distintos elementos en vertical (siempre uno debajo de otro), siendo además necesario la edición del código fuente.

1

Klip que contiene tres componentes distribuidos de forma muy flexible según los requerimientos del diseñador. 

 

Paleta de componentes

La paleta de componentes contiene una lista con todos los componentes que puedes utilizar en el Klip y se aplica tan fácil cómo arrastrándolo de la paleta al Klip.

2

 Configuración de un Klip  que incluye varios componentes.

 

Diseño del layout

Se pueden organizar los components en un diseño vertical arrastrándolos a un klip, pero si deseamos hacer una distribución horizontal o darles un ancho específico, podemos usar el Layout Grid

3

Layout que permite la distribución de los distintos componentes. Se ha seleccionado una celda.

Panel del layout

Cada celda de la cuadrícula del layout tiene sus propiedades que pueden ser ajustadas en el panel. Se puede ajustar el ancho, la altura, el relleno y la alineación.

4

 Panel de configuración de una celda  de layout.

Paleta de control

Todo control que se le pueda aplicar al componente seleccionado aparecerá en la paleta de control. Normalmente son botones para añadir o eliminar series de datos, columnas, filas o rangos.

5

Panel de control para el componente de gráfico

El componente etiquetas

Este componente es nuevo y es ideal para crear encabezados de sección y añadir descripciones de Klips.

6

Un Klip con dos componentes de etiqueta

 

El separador de componentes

El nuevo separador de components es útil para crear una separción visual entre los componentes dentro de un Klip. El separador puede ser vertical u horizontal, de trazos o sólido e incluye opciones para ajustar el grosor y el color.

7

El panel de propiedades para configurar el nuevo separador. 

Bordes en la tabla del componente.

Por defecto, los componentes de la tabla tendrán ahora un borde y un relleno alrededor de ellos. Esto hace que su tratamiento de posición sea consistente con otros componentes.

8

Un Pie Chart en la parte superior y una tabla de datos en la parte inferior. Dos componentes distribuidos en vertical.   

Componente de imagen

El componente de imagen mejorada incluye muchas nuevas opciones de escala y posición.

9

Tres componentes de imagen en un mismo Klip distribuidos en horizontal. 

Para más información consultar la documentación de Klipfolio

Mirar offline pero comprar online. Medir para aprovechar este comportamiento

10/06/2014 a las 08:00

Aunque parezca mentira, el e-commerce dista de ser perfecto y es por eso que parece difícil que las tiendas físicas vayan a desaparecer, más bien tienden a complementarse. Incluso las grandes marcas del online están aterrizando en forma de tiendas físicas.

Tres son los hándicaps de la venta online en comparación a las tiendas tradicionales:

  1. No poder interactuar con el producto
  2. No poder obtenerlo al instante
  3. No recibir el asesoramiento de un experto (o por lo menos ser casi imposible dar con quién te “ayudó” online cuando las cosas van mal…)

Precisamente, éstas son tres de las ventajas que tiene el mundo offline y que muchos retailers han entendido para, desde el online, invitar hacia sus tiendas físicas con el objeto de recoger su producto, devolverlo, probarlo, etc.

Lamentablemente, el proceso se está dando también a la inversa. El consumidor visita las tiendas físicas para interactuar con el producto, para más tarde comprarlo por Internet  en el confort de su casa, y quizás con la posibilidad de obtener un mejor precio. A este proceso se le denomina “Showcasing” o “Showrooming”.

Evidentemente la solución no consiste en evitar la tecnología, sino en utilizarla para proveer de una mejor experiencia al usuario, construir ofertas personalizadas según sea el entorno en el que esté y, en definitiva, vincular la información que tenemos de esa persona para ofrecerle el mejor trato multicanal u omni-channel. Una vez más la medición es la clave, veamos cómo.

La experiencia omnicanal que el comprador anhela

(Continua en el Blog de investigación de la escuela de negocios online OBS)

 

Nuevo Ecommerce de Google Analytics

05/06/2014 a las 08:00

Recuperándome todavía del jet lag de San Francisco, la noticia más importante que traigo del summit de este año de Google Analytics es el lanzamiento del nuevo ecommerce (¡por fin!). Y digo la más importante porque desde hace varios años se venía pidiendo a Google que mejorase el apartado de Ecommerce de su herramienta de analítica web y parece que finalmente se han puesto las pilas y lo han hecho.

El equipo de Google Analytics

El equipo responsable de Google Analytics

Vamos a ver las novedades que trae el nuevo ecommerce de Google Analytics.

1. Nueva visualización de embudo.

Con el nuevo ecommerce, tendremos acceso a una nueva visualización de embudo, que nos permitirá conocer si nuestros usuarios lo están teniendo fácil o difícil para conseguir comprar en nuestro sitio.

Esta nueva visualización, realmente son 2 embudos. El primero nos mostrará cómo lo estamos haciendo en nuestro sitio a la hora de conseguir que el usuario realice una compra. Podemos hablar de un embudo general que nos permitirá identificar en qué punto del sitio se nos están marchando los usuarios (¿en nuestro catálogo?, ¿la ficha de producto?, ¿el checkout?).

Embudo de comportamiento de compra

Nuevo embudo de comportamiento de compra

El segundo embudo que podremos ver nos mostrará el rendimiento del proceso de compra o checkout, de forma que podamos conocer en qué paso concreto estamos teniendo problemas.

Embudo del proceso de compra

Embudo del proceso de compra

2. Nuevos informes de rendimiento de producto

Además de estos 2 nuevos embudos, también disponemos de una serie de nuevos informes que nos ayudarán entre otras cosas a:

    • Conocer el rendimiento de nuestros productos, no solo indicando cuál es el más vendido, sino también cuál es el más añadido al carrito o cuál es el que tiene mejor relación vista/compra de forma que podamos determinar cuáles son los mejores para destacar en la home o en una newsletter.
Rendimiento de productos

Informe de rendimiento de productos

    • Identificar qué categoría de productos están funcionando mejor (pe. mujer, hombre etc…)
    • Conocer si agrupaciones que empleamos en nuestro sitio como “los más vendidos”, “productos destacados”, o “productos relacionados” en las fichas de producto realmente generan un mayor volumen de ventas y por tanto conviene mantener estas agrupaciones, potenciarlas o directamente eliminarlas

3. Soporte para devoluciones

Sí, finalmente Google a decidido permitir que se pueda informar a Google Analytics de cuándo se produce una devolución de un producto. De esta forma, tendremos una visión más exacta del rendimiento a nivel económico de nuestro sitio.

4. Seguimiento de promociones internas

Hasta ahora en analytics no existía una metodología “estandar” de seguimiento de promociones internas, usándose generalmente los eventos para este fin. Ahora con el nuevo ecommerce se habilita una manera de realizar un seguimiento de nuestros banners y promociones internas de forma que sea muy sencillo conocer su rendimiento a la hora de generar ventas.

5. Productos relacionados

Otra de las novedades más interesantes es el poder obtener (vía API) los productos que se compran de manera conjunta, de forma que podamos conocer que productos se deben relacionar y por tanto se abren nuevas posibilidades para añadir componentes del estilo “los usuarios que compraron este producto también compraron…” a tu sitio.

Estas son algunas de las novedades que trae el nuevo ecommerce, a lo largo de próximos post iremos desvelando en detalle las características concretas del nuevo ecommerce así que asegúrate de volver a menudo para enterarte de cómo sacarle más partido a tu sitio de ecommerce.

Control de errores en formularios sin intervención de IT gracias a GTM

02/06/2014 a las 13:22

Es fácil que nuestra propia web nos parezca elegante, intuitiva y que los formularios que la pueblan son bonitos, concisos y fáciles de usar, hasta que descubrimos que los clientes no terminan un proceso de compra, una suscripción o no se ponen en contacto con nosotros tanto como cabría esperar.

Hacer el seguimiento de los errores de un formulario suele ser el método más eficiente para comprobar si nuestros formularios presentan alguna complejidad a la hora de ser rellenados por los usuarios.

En ocasiones desarrollar este seguimiento de errores para el site de un cliente puede ser una tarea algo tediosa, normalmente hay que ponerse en contacto con el departamento de IT para que añadan la programación necesaria dentro del proceso de control de errores de un formulario y así conseguir que Google Analytics reciba esa información.
Como esto no siempre ocurre con la celeridad que nos gustaría, ahora contamos con el GTM y sus etiquetas de procesamiento de eventos o “event listener”.

Os proponemos una solución para implementar el seguimiento de errores utilizando GTM sin que tengáis que recurrir al departamento IT del cliente.

Por supuesto, para poder seguir estos pasos es necesario tener una cuenta de Google Tag Manager asociada a tu Google Analytics y con el código del contenedor incluido en las páginas del site.
Si necesitas alguna información para empezar a usar GTM puedes echar un vistazo a este post http://www.doctormetrics.com/2013/02/13/google-tag-manager-analytics/
Y
 si quieres formarte y tener una visión más amplia de lo que permite Google Tag Manager, seguro que este curso te parecerá interesante
http://www.metriplica.com/es/formacion/c-curso-online-google-tag-manager-gtm

Primer paso, acceder a nuestra cuenta de Google Tag Manager y crear la etiqueta que estará escuchando a que se pulse sobre el botón de submit del formulario.

Tendremos que completar los siguientes datos:

Nombre de etiqueta, por ejemplo “submit formulario”
Tipo de etiqueta, debemos seleccionar, dentro de “procesador de eventos”, la opción “Procesador de envío de formularios”.

Etiqueta procesador de formularios

 

A continuación marcaremos el “check” de esperar  por las etiquetas

Esperar por las etiquetas

 

Necesitamos que esta etiqueta esté escuchando en todas las páginas del site, por lo que seleccionaremos la regla “todas las páginas”, y pulsaremos en guardar la etiqueta.

Segundo paso, crearemos una regla que permitirá que las etiquetas se lancen cuando se cumpla el anterior evento, es decir, cuando el evento sea gtm.formSubmit.

Creación de regla

 

Tercer paso, crearemos una etiqueta HTML personalizada con un código javascript que compruebe que campos de nuestro formulario no se han rellenado y genere un dataLayer en ese caso, informando del nombre del campo.

Etiqueta HTML que gestiona los errores del formulario

 

El código que deberemos insertar en el campo HTML de la etiqueta es el siguiente:

<script src=”http://code.jquery.com/jquery.js”></script>
<script>
$(document).ready(function(){
$(“form :input”).each(function(){ //recorremos todos los elementos del formulario
if($(this).attr(“type”)!=”hidden” && $(this).attr(“type”)!=”submit” && $(this).attr(“type”)!=”radio” && $(this).attr(“type”)!=”checkbox”){
//controlamos que el elemento no es un campo oculto, el botón de submit, un radiobutton o un checkbox
if($(this).val()==””){
dataLayer.push({‘event’:’errorForm’ , ‘virtual_page’:’/virtualpage/form_’+$(“form”).attr(“id”)+’/campo_’+$(this).attr(“name”)+’/enblanco’});
//lanzamos el dataLayer con el evento y la información de la página
}
}
});
});
</script>

Vamos a explicar un poco lo que hace este código.
En primer lugar cargamos la librería jquery, esto no será necesario si ya existe en la página.

Con $(“form :input”).each recorremos los elementos del formulario.
Con el primer if excluimos los elementos que no sean campos de texto, listas desplegables o textarea.
El segundo if comprueba que el valor del elemento esté vacío, en ese caso se lanza el dataLayer con el dato del evento que utilizaremos para la siguiente etiqueta y el dato de la página virtual con la información del campo que ha dado error.
Con form_’+$(“form”).attr(“id”)  estamos indicando el identificador del formulario, podemos utilizar también el atributo “name”. En el caso de que no existan estos atributos en la definición del formulario podemos utilizar la macro {{url path}}, en este caso el valor para virtual_page quedaría así:
‘/virtualpage’+{{url path}}+’/campo_’+$(this).attr(“name”)+’/enblanco’
Con campo_’+$(this).attr(“name”) cargamos el nombre del elemento de formulario que se dejó en blanco.

Cuarto paso, crearemos una etiqueta que se encargará de transferir a Analytics la información con los errores del formulario.
Antes crearemos dos macros y una regla que vamos a necesitar para nuestra última etiqueta.

- Macro que recoge el valor de la página virtual que mandamos en el dataLayer

Macro para página virtual

 

Seleccionamos como tipo de macro variable de capa de datos e indicamos el nombre de la macro y el nombre de la variable de la capa de datos, este último coincide con el campo que hemos utilizado en el dataLayer.

- Macro con una cadena constante con nuestro ID de seguimiento, esta macro no es obligatoria, ya que podemos cargar la ID directamente, pero simplifica las cosas cuando vamos a tener varias etiquetas

Macro Propiedad - cadena constante

 

 

- Regla para el evento “errorForm”, que permitirá que nuestra etiqueta se lance cuando se cargue el dataLayer con este evento.

Regla para lanzar etiqueta con errorForm

 

Por último crearemos la etiqueta, tendremos que completar los siguientes datos:

Nombre de etiqueta, por ejemplo “virtuales error formulario”
Tipo de etiqueta, aquí debemos seleccionar según el tipo de cuenta que tengamos (Analytics Clásico o Universal Analytics).
ID de seguimiento, incluiremos la macro que tiene la información de nuestra ID {{Property-ID}}
Tipo de seguimiento, Seleccionaremos vista de página.
En Más configuraciones, Configuración básica, Ruta del documento seleccionaremos nuestra macro con la información de la página virtual {{virtual_page}}

Ruta de documento - virtualpage

 

Y como regla de activación seleccionamos la regla, antes creada, evento_error_form

Eso es todo, a partir del momento que creemos una versión del contenedor y lo publiquemos, cada vez que se ejecute el submit de un formulario de nuestra web estaremos recogiendo la información de los posibles campos que se han quedado en blanco.