Analytics Premium ComScore ClickTale Analytics Certified Partner Klipfolio Coremetrics
Tags populares:

Presentación de la Suite Google Analytics 360

28/09/2016 a las 11:09

Torre Picasso - Madrid

Torre Picasso

El pasado jueves 22 de septiembre estuvimos en la presentación oficial de la nueva Suite Google Analytics 360 en Madrid. Esta herramienta es la evolución de Google Analytics Premium, versión de pago para grandes clientes presentada  por Google en 2011.

Si te interesa,  aquí tienes un interesante artículo sobre la historia de Google Analytics que se remonta al siglo pasado.

 

Si tuviera que sacar conclusiones de lo que vimos en la presentación, destacaría la solidez que aporta la integración de los diferentes módulos de la herramienta, pensada para sacar el máximo partido de las cookies propias, en combinación con la potente plataforma publicitaria de Google. Esto supone que si compramos todo el “kit” (que no es barato y cuyo precio varía según volumen y módulo) tendremos una herramienta sin discrepancia en los datos a nivel de cookies, ya que todos los módulos se sincronizan con la integración en este aspecto.

El objetivo, según Google, es conseguir un “círculo virtuoso”. Dan Florin, Global Product Lead fue el encargado de presentar la Suite y destacó sus puntos clave: Identificar a nuestros usuarios de valor, entendiendo su ciclo de vida. Personalizar y optimizar su experiencia con la marca. Hacer campañas consistentes en diferentes canales y dispositivos, poder medirlas correctamente a través de su integración compartiendo los resultados con los distintos equipos y evitar los silos.

 

Presentación Google Analytics 360 -Madrid

Presentación Google Analytics 360 -Madrid

No es el propósito de esta entrada hacer un repaso en profundidad de sus componentes, tan sólo pretendo destacar los aspectos que, desde mi punto de vista, mejoran la versión Premium.

Cada uno de los módulos se centra en un área concreta:

Attribution 360

Attribution es, en pocas palabras, la encargada de ayudarnos a decidir quién se lleva la comisión por la venta. Nos invita a encontrar cual es el Marketing Mix adecuado para nuestra marca. Ofrece una visión global, holística, gracias a su integración nativa con Analytics 360, lo que permite analizar los datos de nuestras campañas de marketing, con la máxima granularidad,  y confrontarlos con el resto de nuestros canales (online y ahora también offline). Dave Barney, Product Manager, fue el encargado de contarnos las novedades:

¿Qué nos permite hacer?

  • Marketing Modeling: Orientado a mejorar la distribución del presupuesto de marketing y su impacto en los resultados y ayudarnos a definir la estrategia en este área. Como novedad, su modelo de atribución basado en datos tiene en cuenta todos los puntos de contacto del usuario. Este modelo, en Analytics 360 seguirá teniendo el límite de cuatro puntos si no se ha comprado este módulo.
    • Informe de rendimiento de campañas
    • Simulador: Para saber qué hubiera ocurrido si hubiéramos actuado de otro modo.
    • Análisis predictivo para un rango de fechas (cuya precisión mejora en corto plazo, p.e. tres meses) y que tiene en cuenta diversos factores (estacionales, de clima..) y se puede segmentar por canal.
    • Optimizador de presupuesto: permite la asignación de prespuestos por canal a distintos escenarios para hacer previsiones.
  • TV Attribution: Análisis de impacto de nuestros anuncios en Radio y Televisión. La evolución de Adometry. Utiliza patrones observados en el histórico de datos. Si incorporamos los datos de campañas (p.e. semanalmente) a través de Data Import, superpone el plan de medios off line (TV y radio) sobre nuestros datos online para conocer su impacto.
    • Informe de rendimiento: se puede segmentar por canal televisivo, por coste o por audiencia.
    • TV Insights: Consiste en un gráfico de bolas (tipo DAFO), que muestra en un eje el volumen y en el otro su efectividad, con cuadrantes, lo que ofrece una imagen clara, en un vistazo del rendimiento, evitando la confusión que nos puede provocar pensar que más tráfico es siempre mejor.
    • Nos permite contrastar la emisión de nuestras campañas con datos de búsqueda de palabras clave en tiempo real (con su buscador).

Optimize 360

Es el módulo de testing y personalización. Facilita la publicación de otras versiones de nuestras páginas, contenidos, llamadas a la acción.. etc para medir si éstas rinden mejor que lo que ya teníamos, manejando una única fuente de datos, la propia. Utiliza el análisis estadístico Bayesiano (basándose en la consistencia de nuestra tasa de conversión), se integra con Big Query y aplica la corrección Bonferroni (que tiene en cuenta aquellas circunstancias que se producen debido al azar)

¿Qué nos permite hacer?

  • Utilizar objetivos, métricas o nuestros segmentos de audiencia creados en Google Analytics para enriquecer los tests.
  • Dirigir los tests a usuarios que hayan realizado (o no) determinadas acciones en el nuestro site
  • Segmentar los resultados con nuestros segmentos avanzados de Google Analytics.
  • Seleccionar manualmente las métricas que creamos convenientes en los informes.

Parece que pronto se podrá probar la versión gratuita de esta herramienta, de momento se puede solicitar la prueba a esta versión de Google Optimize según anuncian en el blog de Google

Audience Center 360

Carl Fernandes, Product Lead, fue el encargado de introducir el módulo. Audience Center realiza las funciones de un DMP (Data Management Platform), recopilando y organizando los datos de nuestros usuarios. Desde aquí podremos, en la misma plataforma tecnológica, integrar nuestra publicidad en Search, RTB, Display, adserving etc. con consistencia e integración con los data sets de Google (demográficos, geográficos, de intereses.. etc.).. Esto quiere decir que no tendremos que exportar nuestras audiencias a otros proveedores.

¿Qué nos permite hacer?

  • Utilizar las audiencias de cookies de primera parte en el ecosistema publicitario de Google (DBM, Adwords, red de Display, Adsense..)
  • La novedad. Podremos contectar nuestras audiencias con proveedores fuera del ecosistema de Google, con cookies de tercera parte. Ofrece un informe de “similitud”, en donde podemos buscar aquellas audiencias que trabajan con 3ª parte y que sean similares a nuestras audiencias de 1ª parte.
  • Incluir o excluir nuestros segmentos de Analytics para construir las audiencias (por ejemplo, excluir un segmento que no convierte nunca en cualquiera de las inserciones, o apuntar a audiencias que presentan ciertos atributos en todos los canales)
  • Dispone de un informe de frecuencia de impactos y otro con el número de impresiones idóneo para una mejor conversión
  • Podemos definir paquetes y sub-paquetes de cookies para lanzar en diferentes DSPs con el objetivo de testear su rendimiento
  • Prometen una activación en 24 horas y la publicación en un click en otras plataformas publicitarias no-google.

Data Studio 360

Alicia Escribá nos contó cómo funciona el módulo de reporting de la Suite. Ofrece integraciones nativas con Analytics, diversos CRM y algunos servicios de Google.

¿Qué nos permite hacer?

  • Trabajar de manera cómoda si se está habituado a utilizar spreadsheets, con una interfaz muy parecida
  • Widgets con métricas contrastadas
  • Construcción de campos personalizados en base a fórmulas
  • Manejar tablas con datos importados de nuestro CRM construyendo gráficos que funcionan en tiempo real.

Habrá una versión gratuita de esta herramienta, que permite la creación de cinco informes, pero de momento está disponible sólo para los Estados Unidos.

 

Vistas Google Torre Picasso

Vistas Google Torre Picasso

Otras novedades, de las que ya teníamos noticia como partners:

  • Objetivos inteligentes en Google Analytics (basados en nuevos atributos de la visita),.
  • Integración con Firebase para aplicaciones móviles.
  • Nuevos workspaces o entornos de trabajo en Google Tag Manager.
  • Simplificación de los procesos de integración de los módulos.

 

 

La sesión terminó con un caso de uso que contó con la presencia de Marcos Ortega, Director de Marketing de PSA (Peugeot, Citrôen, DS), pionero en el uso de los datos para tomar decisiones, a pesar de formar parte de una marca que no tiene su core en la venta online. Fue una intervención amena sobre el proceso de integración con la plataforma Doubleclick llevado a cabo por PSA en los últimos meses.

Muchas novedades, queda mucho camino por recorrer hasta que en nuestro país veamos todo esto funcionando a tope, hay que ser optimista. Lo que está claro es que hará falta mucha masa gris para sacar rendimiento a tanta funcionalidad.

¿Te apuntas al reto?

El Report “Resumen de Navegación”

26/09/2016 a las 18:23

Hoy, en mi estreno en DoctorMetrics, voy a hablaros de uno de los reports más desconocidos que podemos encontrar dentro de Google Analytics, pero no por ello menos útil…Para empezar, veamos donde encontrarlo, que no es inmediato…

Navigation Summary 1

 

Como vemos, lo encontraremos dentro del Menú Comportamiento –> Todas las páginas, y luego pestaña “Resumen de Navegación”.

Una vez clickamos en la pestaña “Resumen de navegación” nos encontraremos con la siguiente información:

post_de_ns_3

 

Comentemos los campos que podemos configurar en este Report:

1 – En este desplegable, que por defecto viene con la opción de “Número de visitas a páginas” podemos seleccionar también estas otras métricas:

post_de_ns_4

 

2 – Lo mismo en el caso que queramos comparar métricas:

post_de_ns_5

 

3 – Podemos agrupar las páginas por Contenido (previamente definido en la sección de “Agrupación de Contenido”) si estamos más interesados en el tipo de contenido que en el contenido individual.

post_de_ns_6

 

4 – Podemos seleccionar la página que queramos analizar (por defecto nos aparecerá la que tiene más páginas vistas del site)

post_de_ns_7

 

5. En este report podemos segmentar, lo cual es algo realmente muy potente, ya que, por ejemplo, nos podría interesar comparar distintos tipos de tráfico. Imaginad que queremos evaluar el comportamiento de un usuario que entra por la página x en el site en función de si viene por tráfico orgánico o de pago….mola, no? 🙂

Bueno, hasta ahora sólo hemos visto como encontrar el Report y qué posibilidades de configuración nos ofrece. Pero, ¿qué podemos hacer con él realmente? ¿Para qué sirve?

Veámoslo con un ejemplo:

post_de_ns_9

 

Vamos a comentar toda la información que nos está dando el Report. Recordemos que estamos analizando la página “index” en el periodo 1 al 15 de Septiembre de 2016.

Si nos fijamos en los datos, de izquierda a derecha y de arriba a bajo, vemos que nuestra página es el 70.91% de las entradas al site, es decir, de todas las entradas al site, el 70.91% de las veces entran por nuestra página. En este caso, tiene cierta coherencia al ser la homepage….

El 29.09% de las entradas a nuestra página vienen de páginas de nuestro site, las cuales se detallan a continuación, en la columna “Ruta de la Página Anterior”. Vemos por ejemplo, que la página que lleva más tráfico a nuestra página es “/Google+Redesign/Apparel/Men++s/Men++s+T+Shirts” con 560 visitas a página, el 9.23%.

Si miramos la parte derecha del Report, vemos que el 49.08% de las visitas a la página se van del site. Y el resto, es decir el 50.92% van a las páginas que se detallan en “Rutas de la página siguiente”.

Como acabamos de ver, el Resumen de Navegación nos proporciona una información muy interesante, simple y visual al mismo tiempo. Si queremos optimizar una página en particular de nuestro site, por ejemplo una landing, una página de producto, etc., la información que nos proporciona este report nos facilita una mayor comprensión de como nuestros usuarios están interactuando con nuestra página.

Espero que os haya gustado….y si compartes, pues mejor! 🙂 Nos seguimos leyendo!

 

 

 

 

 

 

 

 

Nos hemos certificado en Optimize 360

19/09/2016 a las 15:33

Uno de los productos que más atención ha creado de la nueva suite 360 es el Optimize 360, este producto nos permite probar cambios en nuestro sitio y personalizar sus contenidos para segmentos de usuarios con el fin de maximizar el rendimiento del mismo.

360-certified-logo

Metriplica optiene la certificación de Optimize 360

Desde el principio tuvimos claro que queríamos usar esta herramienta como parte de nuestra estrategia de mejora continua que ofrecemos a nuestros clientes y el primer paso que teníamos que hacer era certificarnos en la misma.

La certificación consiste en un examen,  y un caso de estudio que demuestre que sabemos usar la herramienta. Buscar un caso de estudio puede parece sencillo pero ¿saben lo difícil que es encontrar un cliente que quiera testear su sitio en verano?

Por coincidencias del destino, justo en Julio Metriplica lanzó su nueva web y había un elemento que no nos acaba de convencer a varios en la empresa. Se trataba del nuevo menú de navegación en formato “hamburguesa”, si bien en móvil este formato es común en ordenadores de escritorio pensábamos que penalizaba la navegación más que la mejoraba. Y aquí teníamos nuestro caso de estudio 🙂

El proceso de certificación para Optimize 360

Para certificarnos en Optimize 360, planteamos como caso de estudio un test en el que, “enfrentamos” el menú de navegación en formato hamburguesa con el menú de navegación en formato clásico.

Los resultados, como pueden ver en la imagen, reflejan que el hecho de poner el menú en formato clásico mejora en casi un 50% la navegación a través del mismo, es decir provoca un consumo de contenido mayor y por tanto mayores probabilidades de contacto y de visualizar nuestros servicios como empresa.

Mejora del 50% en navegación del menú clásico vs hamburguesa

Con un menú clásico, la navegación aumenta un 50% sobre el menú hamburguesa

Y ahora ¿qué?…

Pues los siguientes pasos que vamos a tomar obviamente  es cambiar nuestro menú por un formato clásico visible y comenzar a ofrecer Optimize 360 a todos nuestros clientes 🙂

Agradecer a todos los miembros del equipo que han hecho posible la certificación en Optimize 360  y espero que podamos sacarle partido lo antes posibles

Tasas de abandono de carrito en eCommerce: ¿he de preocuparme?

07/09/2016 a las 10:07

Si tienes a tu cargo un ecommerce seguramente te preocupará la tasa de abandono del carrito de compra. Lo más probable es que te parezca una tasa muy elevada y probablemente pienses que algo no estás haciendo bien.

Lo primero: no te preocupes demasiado, a día de hoy el porcentaje de abandono de los carritos de compra en ecommerce ronda entre el 60-80%.

Tasa de abandono = 1-(número de compras finalizadas/número de carritos de compra creados).

En vez de verlo como algo negativo tienes que enfocarlo de manera positiva, ya que tienes a un 60-80% del público interesado en tu producto, pero por la razón que sea no acabó convirtiendo.

Ave, Python, los analistas de datos te saludan

25/08/2016 a las 11:24

Como usuarios de R, alguna vez hemos hecho llamadas a la librería rPython.

En anteriores posts se ha hecho una introducción a R y llega el turno de Python, un lenguaje de programación en código abierto que, entre otros, dispone de paquetes específicos para almacenar, manipular y analizar datos.

Hoy instalaremos numpy, un paquete que permite el uso de funciones estadísticas y el cálculo matricial.

Hay dos maneras de trabajar:

  • De forma interactiva: tecleamos código e inmediatamente vemos los resultados. Para ello usamos el intérprete IPython:

    https://www.python.org/shell/

0_python shell
  • Ejecutando scripts: son archivos de texto (.py) con comandos Python línea a línea. Permite realizar cambios y volver a ejecutar. En este caso no se muestran los resultados de forma automática, para ello usamos la función print().

Haremos una demo de instalación en Windows, para otros sistemas operativos encontramos la ayuda en cada uno de los links que se citan a continuación.

 

1. Instalando Python.

Podemos descargar la última versión en el siguiente enlace y ejecutar el .exe.

https://www.python.org/downloads/

1_python download
 

2. Instalando pip.

El paso siguiente es instalar el paquete pip, encargado de la instalación de otros paquetes y el mantenimiento del sistema en Python. Lo podemos descargar en:

http://pip.readthedocs.org/en/stable/installing/

2_pip

2.1. Abrir línea de comandos de Windows.

Inicio > Buscar > teclear cmd

3_cmd

2.2. Cambiar al directorio en que tenemos el get-pip.py que acabamos de descargar:

> cd C:\Users\metriplica\Downloads

2.3. Ejecutar:
> get-pip.py

Sale un mensaje ‘Requirement already up-to-date:…’ que pide la actualización si nuestra versión es Python 2 >=2.7.9 or Python 3 >=3.4.

2.4. Buscar en el directorio donde se ha instalado Python el archivo pip.py, que suele colgar de \Scripts\ y arrastrarlo a la línea de comandos.

4_instalar pip

Aparecerá un listado con los comandos y opciones que admite pip.
Con esto ya podemos usar pip para instalar paquetes de Python.

 

3. Instalando numpy.

3.1. Cambiar al directorio \Scripts\ (asegurarnos de que pip.exe se encuentra en esta carpeta y en caso contrario modificar la ruta a la que lo contenga):

> cd C:\Users\metriplica\AppData\Local\Programs\Python\Python35-32\Scripts

3.2. Instalar paquete:

> pip3 install numpy

3.3. Cambiar al directorio en que está instalado Python:
> cd C:\Users\metriplica\AppData\Local\Programs\Python\Python35-32
o

> cd.. (sube un nivel en el path)

3.4. Ejecutar Python. Con esto pasamos de la línea de comandos del sistema al intérprete de Python:
> python
>>>

 

4. Importando numpy.

4.1. Para poder hacer uso de los objetos y funciones de un paquete es preciso importarlo una vez instalado:

>>> import numpy

5_instalar numpy

4.2.En la ayuda encontramos una descripción detallada:

>>> help(numpy)

6_help numpy
 

5. Saliendo del intérprete de Python.

>>> quit()

 

Hasta aquí la instalación del paquete numpy. Disponemos de otros como matplotlib (gráficos) y scikit-learn (machine learning) que le complementan en la apasionante aventura del análisis de datos 

Basket Market Analysis

17/08/2016 a las 14:18

Probablemente os habréis preguntado muchas veces qué combinación ganadora de productos genera más ventas en su tienda física o en el catálogo de su tienda online.

1

Esta información puede ser aprovechada para numerosos fines. Entre otros:

  • Cross-selling de productos.
  • Redistribución del catálogo o del escaparate (en caso de tratarse de una tienda física): colocar los artículos que puedan co-ocurrir juntos uno cerca del otro.
  • Campañas de email marketing: ofrecer promociones/descuentos/sugerencias de productos relacionados con el que ya sabemos que han comprado.

Pero, ¿y si además pudiéramos conocer la probabilidad de que, habiendo comprado cierto(s) producto(s), el cliente termine comprando otro(s)?

Existe una metodología llamada Market Basket Analysis que nos ayudará en la búsqueda de estos insights.

Market Basket Analysis

En el mundo online acumulamos una enorme base de datos de las transacciones de compra. Cada transacción consiste en una serie de productos que se han comprado de manera conjunta.

Pero, ¿qué productos se compran conjuntamente con más frecuencia? Mediante la metodología del Basket Market Analysis podemos responder preguntas tales como: ¿Existen relaciones entre ciertos productos, que al comprarlos influyen significativamente en la compra de otros productos? Esto lo entendemos como reglas de asociación entre productos.

Podemos entender estas reglas de asociación como “Si compras A y B, entonces es probable que compres C”.

Una medida de la bondad de estas relaciones son los estadísticos Support, Confidence y Lift:

  • Support: proporción del total de compras en las que X e Y se han comprado conjuntamente.

4

  • Confidence: proporción de compras con X donde también se compró Y. En términos estadísticos, se trata de una probabilidad condicional.

5

  • Lift: Un valor de Lift > 1 indica que los productos X e Y se compran conjuntamente más veces de lo esperado. Por tanto, estamos interesados en aquellas relaciones con un valor de Lift>1.

6

Un ejemplo ficticio de los resultados que podríamos obtener de un análisis de este tipo nos lo proporciona la siguiente tabla:

3

La manera de leer la tabla anterior es, por ejemplo, para la primera entrada: “Los productos A y B se han comprado conjuntamente en el 0.23% del total de las transacciones, y además, en el 95% de las transacciones que contienen el producto B también se ha comprado A”. A priori, puede parecer poco un valor para Support del 0.23%: ¡Solamente esta proporción del total de las transacciones contienen A y B!. Pero suponed que tenemos registradas 12K transacciones, ¡se darían 2760 con los productos A y B!

Implementación en R

Utilizamos el algoritmo apriori para encontrar las reglas de asociación que comentábamos anteriormente. Únicamente se ha de instalar en R el paquete arules y ¡manos a la obra!

Todas las funciones necesarias para el análisis las podemos encontrar cargando dicha librería. En caso de obtener numerosas reglas de asociación (todo depende del tipo de estudio que se realice y de la cantidad de transacciones con las que se trabaje), es de gran ayuda el paquete arulesViz. Este añade características adicionales al paquete arules: se apoya en gráficos muy curiosos de las reglas de asociación, permitiéndonos estudiarlas de una manera más cómoda.

Como curiosidad, y para hacernos una ligera idea de cómo trabaja el algoritmo apriori, primero encuentra las transacciones unitarias (es decir, transacciones que contienen un único producto) más frecuentes. A continuación, estudia todas las combinaciones posibles (dos a dos) de las transacciones unitarias, y se queda con las transacciones que contengan dichas combinaciones y que se dan con más frecuencia. Así, iterativamente, el algoritmo continúa hasta que hallan sido generados todos los conjuntos de ítems más frecuentes con k productos y no se obtengan más conjuntos frecuentes dentro de las transacciones.

Si os encontráis en vuestros inicios con R, que no cunda el pánico. Se ha desarrollado un package interactivo de R que os enseñará a sacarle partido a la herramienta. Para más información: Como empezar a usar R statistics, de mi compañera Anna Fernández.

Los pasos a seguir para llevar a cabo el Basket Market Analysis en R son:

    1. Leemos el Dataset. Únicamente necesitamos una tabla en la que cada fila contenga el ID de transacción y el nombre del producto.7
    2. Agregar por ID de transacción todos los productos comprados. Existe una función de la librería data.table (llamada del mismo modo) que hace las agregaciones de manera muy eficaz:8Otra alternativa para hacer la agregación, mediante la función split:9
    3. Convertir los datos agregados en tipo de objeto “transacción”:10
    4.  Arrancamos el algoritmo mediante la función a priori de la librería arules.11Notad que los campos de los parámetros para Support y Confidence están vacíos. La definición de estos umbrales mínimos depende de la cantidad de transacciones que manejemos. Para definir el umbral mínimo para Support nos podemos apoyar en el siguiente gráfico: frecuencia del producto en las transacciones.13El código de R para obtener el gráfico anterior:

      12

      Nótese como aparece el artículo más frecuente en menos del 0.3% de las transacciones. La línea roja indica donde hemos decidido fijar el umbral mínimo para Support. Este umbral debe ser lo suficientemente pequeño para que entren en juego varios productos en el análisis (en caso de proporcionar un valor muy grande para Support, es posible que el algoritmo no sea capaz de encontrar association rules).

    5.  Finalmente, visualizaremos las reglas de asociación de productos mediante el siguiente código: inspect(rules).  Así, obtendremos una tabla análoga a la del ejemplo. En el caso de no disponer de reglas de asociación, siempre se puede jugar “relajando” los umbrales mínimos de los parámetros Support y Confidence.

Consideraciones

Resulta muy interesante también estudiar las relaciones entre productos más débiles.

Si el análisis muestra que dos artículos no están relacionados fuertemente, y sin embargo, se encuentran muy próximos en el catálogo online (porque puedan pertenecer a la misma categoría de producto, por ejemplo) cabría replantearse una re-estructuración del catálogo.


¡Y listo!

Indagando en estos resultados, ¡podríamos llevarnos muchas sorpresas analizando únicamente las transacciones!.

¿No has probado este tipo de análisis? ¡Anímate!

Y cualquier pregunta que se os presente, no dudéis en comentar 🙂

 

Extraer y trabajar con datos de Facebook

10/08/2016 a las 13:45

exportar y trabajar con datos de Facebook

Actualmente existen multitud de herramientas de analítica social que nos ayudan a medir lo que ocurre en las redes y nos facilitan la construcción del cuadro de mando. Podemos encontrar soluciones gratuitas y de pago que ofrecen desde métricas sencillas a las más complejas, pasando por análisis predictivos,  algoritmos propios y hasta conejos dentro de una chistera.

Todo dependerá de nuestro presupuesto, pero es común encontrarse con métricas tan variopintas como:

  • Likes, comentarios y shares en un periodo
  • Alcance por post
  • Impresiones vs alcance
  • Efectividad según día
  • Efectividad según horario
  • Post por hora o semana
  • Personas que están hablando de esto
  • Total Fans
  • Fans por país
  • ROI
  • Crecimiento/decrecimiento de fans
  • Nº publicaciones
  • Tasa de interacción
  • Engagement

La lista podría continuar y continuar, pero lo importante es no dejarnos deslumbrar por sus opciones y ser conscientes de que todo se construye a partir de unos datos básicos que también están a nuestro alcance.

En caso de que no tengamos acceso al software adecuado no habrá más remedio que extraer los datos de Facebook y realizar las gráficas y tablas con las métricas que nos interesen de forma manual.

Una vez determinemos qué queremos medir, cómo y para qué es hora de ponernos manos a la obra para tenerlo todo a nuestro gusto.

¿Tus formularios no van bien?, 2 ideas para descubrir qué les pasa

08/08/2016 a las 10:55

Es difícil pensar en un sitio que no tenga uno o varios formularios entre sus contenidos,  ya sea de contacto, como parte del proceso de checkout o simplemente de registro.

Dado que normalmente los formularios forman parte de un proceso, es común configurar nuestra herramienta de métricas para medir cómo una visita evoluciona en dicho proceso y por tanto el rendimiento de estos formularios a nivel de conversión (ej. % de paso de datos de entrega a datos de pago)

Lo que no es tan común es que configuremos nuestra herramienta para medir cómo funciona el formulario en sí, qué campos dan error, en qué campos invierte más tiempo el usuario, por cuál abandona etc.

En este artículo les voy a dar 2 ideas para medir si tenemos o no problemas en nuestros formularios. Como no quiero asustar con contenido técnico me centraré en dar la idea de lo que se persigue y los resultados más que explicar la implementación en sí. Sobre esto, haré un vídeo u otro post posterior que explique cómo montarlo.

Idea 1: Convertir las interacciones con los campos de los formularios en eventos

La primera idea es bastante sencilla, se trata de convertir las interacciones que realiza un usuario con los diferentes campos del formulario en hits de eventos.

Por ejemplo, dado el siguiente formulario, vemos que el usuario puede realizar las siguientes acciones:

  • Ver el formulario
  • Indicar su nombre
  • Indicar sus apellidos
  • Indicar su código postal
  • etc.

formulario

Lo primero que tenemos que hacer por tanto es convertir estas acciones en eventos, una propuesta de nombrado podría ser la siguiente:

Qué hacemos Categoría Acción Etiqueta
Ver formulario Formulario <nombre formulario> <nombre formulario>.nombre
Introducir nombre Formulario <nombre formulario> <nombre formulario>.nombre
Introducir apellidos Formulario <nombre formulario>  <nombre formulario>.apellidos
Introducir código postal Formulario <nombre formulario>  <nombre formulario>.codpostal

Se repite el nombre del formulario en la etiqueta para facilitar la interpretación de los datos desde un informe personalizado pero no sería realmente necesario.

Una vez que hemos definidas las acciones que vamos a considerar, lo siguiente es configurar el Analytics para recogerlas, como he indicado la parte técnica la dejare para un post posterior.

El resultado, una vez configurado, será parecido a este:

eventos interacciones formulario

Listado de eventos con las interacciones en el formulario

 

Donde el primer evento “formulario”, indica las visualizaciones.

La métrica clave en este informe es el número de eventos por sesión, si es 1 o cercano a 1 suele indicar que el usuario no ha tenido problemas con el mismo, cuanto más alejado esté de 1 (pe. formulario.rfc) indicaría que es posible que el usuario haya tenido problemas viéndose obligado a interactuar varias veces con el mismo.

De esta manera fácil y sencilla podemos hacernos una idea precisa de lo que pasa con cada uno de los campos…

Mejora a la idea 1

Podemos mejorar la recogida de datos si además de recoger las interacciones en el formulario recogemos los errores que se produzcan en el mismo, de forma que obtendremos otro informe parecido a este:

Errores en un formulario

Errores en un formulario

 

Aquí podemos ver que hay un problema con el formato de entrada del teléfono, tal vez se exige un formato muy específico y el campo es poco flexible.

Recuerda que:

Los eventos, en especial aquellos que se lancen de manera automática (visión del formulario) deberían ser no interactivos para evitar que afecten a las tasas de rebote. Para el resto de eventos, dependerá de si se quiere considerar el hecho de interactuar con el formulario como razón suficiente para “eliminar” el rebote.

Idea 2: Convertir las interacciones con los campos de los formularios en páginas virtuales

La segunda idea que quiero comentar es el tratar los campos del formulario como si fuesen páginas virtuales, esto tiene algunas ventajas interesantes como:

  1. Te permite construir un embudo con los campos del formularios.
    – ¿De verdad?, un embudo como el de los objetivos
    – Igualito, igualito
  2. Además puedes saber el campo que usa una visita para abandonar el mismo  mirando el exit rate de las páginas falsas
  3. Y si  lo anterior fuera poco, puedes saber el tiempo medio que pasa una visita en cada campo mirando el tiempo medio en página

Créeme yo también estoy alucinando con la cantidad de datos que podemos ver :), el inconveniente  que tiene esta técnica es que añadimos páginas falsas a la vista con lo cual alguna métricas se verán afectadas (páginas vistas por sesión, nº de páginas vistas etc.).

Por ello una buena práctica es crear una vista que contenga estos datos y filtrar estas páginas falsas del resto de vistas.

Les muestro un ejemplo de cómo podría crear un embudo utilizando esta técnica:

embudo

Embudo de campos de un formulario

Obviamente faltarían datos en el mismo pero ya pueden hacerse una idea de lo útil que puede ser.

Mejora a la idea 2:

Con un poco de trabajo y si nuestro sitio solo tiene un formulario y no es un ecommerce se podría adaptar el enhanced ecommerce para que los campos del formulario sean los pasos de un proceso de checkout con lo cual tendríamos un embudo con la posibilidad de segmentarlo….

Para acabar

Espero que las ideas que les he puesto les ayuden a entender mejor qué pasa con esos formularios por los cuales “pierden” visitas. Realizar los cambios necesarios en la implementación para obtener estos datos no es demasiado complicado y los beneficios que se obtienen merecen la pena.

El próximo mes, veremos la parte técnica del artículo en el que pondré un ejemplo de cómo capturar estos datos.

Feliz análisis

Entornos en Google Tag Manager

01/08/2016 a las 15:17

A la hora de iniciar o dar evolución a un proyecto que incluye GTM, una muy buena práctica es utilizar un entorno de pruebas donde insertar los tags, y realizar las modificaciones correspondientes en el código, para extraer finalmente los datos que sean de utilidad. Tanto, o más importante que usar un entorno de test, es enviar los datos a una propiedad de prueba mientras se verifica la veracidad de los propios datos.

La utilización de “Entornos” en GTM nos permite realizar las buenas prácticas nombradas anteriormente sin tener que crear duplicidades de un mismo contenedor de GTM, evitando el trabajo de tener que ir duplicando cada nuevo elemento que se cree.

Breve introducción al cambio

Antes de entrar en materia, os explicaré un poco porque se ha introducido este cambio GTM. Anteriormente, podíamos revisar y hacer testing de los nuevos tags que íbamos añadiendo a nuestro contenedor de GTM mediante el modo preview & debug. El modo preview nos permite probar el estado actual del contenedor en el navegador antes de publicarlo, incluso podemos compartirlo para que otro usuario que no tenga abierto el propio GTM en su navegador, también pueda ver el modo preview del contenedor (esto se hace mediante una token asociada a la cookie del dominio googletagmanager.com).

share previewEl problema de este método es que tratamos con una cookie de sesión, lo cual implica que expirará si se cierra el navegador y por lo tanto se deberá clicar en el enlace de nuevo para poder entrar en el modo preview. También existe el problema de que la cookie está vinculada a una versión del contenedor, con lo cual siempre que se genere una nueva versión se deberá generar una nueva token para la cookie, esto implica crear un nuevo enlace. En definitiva, trabajar con el modo preview en un entorno donde se ven involucradas varias personas, no es flexible y es bastante molesto.

Los Entornos de GTM viene a resolver todas estas problemáticas relacionadas con las pruebas y los entornos de test, en la implementación de GTM.

A continuación, explicaré como crear un único contenedor el cual tenga una versión (Entorno) para test y la versión normal de GTM y que a su vez, en función de la versión a la que se esté accediendo desde el site, enviar los datos a una propiedad u otra.

Crear un Entorno en GTM

Dentro del apartado ADMIN en la lista del contenedor, abajo del todo tenemos Entornos. Hay que hacer lo siguiente para crear un entorno:

  1. Hacer clic en el apartado de Entornos
  2. Dentro de entornos, pulsamos en “New” para crear uno nuevo
  3. Agregamos los detalles del nuevo Entorno con un nombre, una descripción y una URL del destino donde se hará uso de este Entorno
  4. Finalmente, publicamos para poder tener el Entorno activo y así poder usarlo (será necesario revisar si hay alguna otra modificación del contenedor, ya que al publicar publicaremos todas las nuevas modificaciones del contenedor).

crear entorno

Una vez tenemos el entorno de test creado, queremos que dicho entorno se ejecute en el entorno de prueba del site. Para ello debemos cargar un nuevo script que irá en el código del site de prueba tal y como se hace para cualquier contenedor de GTM. Para obtener dicho script hacemos lo siguiente:

  1. Dentro de Entornos, desplegamos “Actions” para el Entorno que hemos creado y clicamos en “Get Snippet”.
  2. El código que nos aparece será el que deberemos introducir en la página/as de test.

getSnipper

Una vez hayamos introducido el script anterior en la página de pruebas, ya estaremos ejecutando el Entorno de GTM que queremos.

Envío a GA según el Entorno

A continuación, os mostraré como enviar los datos desde GTM a una propiedad de GA en función del Entorno ( en este caso: Real o Test), de forma sencilla.

Dentro del apartado Variables (anteriormente “Macros”), tenemos una nueva variable llamada Nombre del entorno:

variables_nombreEntorno

Creamos una variable que determinará el ID (también llamado UA) de la propiedad a la que enviaremos los datos.

Esta nueva variable tendrá las siguientes características:

  • Tipo de variable: lookup table
  • En la configuración de la variable tendremos:
    • Input Value: {{Environment Name}}
    • Lookup Table:
      • Input: “Nombre del nuevo Entorno”
      • Output: UA de la propiedad de test
    • Seleccionamos “Set Default Value”:
      • Default Value: UA de la propiedad real

variable_Entorno-UA

Siempre que creemos un nuevo tag que envíe información a GA, deberemos especificar como propiedad de destino esta nueva variable. Una vez hayamos hecho lo anterior, no deberemos preocuparnos por el envió de datos según sean del tipo test o sean datos reales.

Me gustaría recordar que las posibilidades que nos ofrecen los Entornos, en GTM, son muy amplias y aquí solo se recoge una de esas posibilidades

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

20/07/2016 a las 10:25

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 la fecha de inicio (start.date) y de fin (end.date) de la función Init del package RGoogleAnalytics, que es mediante la cual creamos la consulta a hacer a la API de Google Analytics. Sin embargo, para poder hacerlo necesitaremos:

1) Tener instaladas y cargadas las librerías RGoogleAnalytics y lubridate. Esta segunda la necesitamos para usar ciertas funciones de tiempo que nos ayudarán a obtener las fechas relativas que queremos. En principio se carga automáticamente al cargar la librería RGoogleAnalytics, pero si no fuera el caso también habría que cargarla para utilizar el código.

install.packages("RGoogleAnalytics")
install.packages("lubridate")
library(RGoogleAnalytics)

2) Autenticarse con nuestras credenciales para poder hacer la conexión entre R y Google Analytics. Para más detalles, seguir los pasos del post mencionado anteriormente.

#Credenciales para la cuenta de Google Analytics seleccionada
client.id<-"xxxxxxxxxxxxxxxxxxxxxxxx"
client.secret<-"xxxxxxxxxxxxxxxxxxxx"

#Creación y llamada del token (la conexión en sí)
token<-Auth(client.id,client.secret)
ValidateToken(token)

3) Comprobar que tenemos configurados el día y la hora correctos. Para hacerlo se puede ejecutar el comando Sys.time(), que devuelve la fecha y la hora del momento en que se ejecuta.

Últimos N días

query.list<-Init(
 start.date=as.character(Sys.Date()-N), #Sustituir N por un número
 end.date=as.character(Sys.Date()-1)
 dimension="<dimensiones>",
  metrics="<métricas>",
  max.results=10000,
  table.id="ga:XXXXXXX"
)
ga.query<-QueryBuilder(query.list)
ga.data<-GetReportData(ga.query,token)
La fecha inicial tiene que ser la de hace N días. Como Sys.Date() devuelve la fecha actual, simplemente le restamos el número de días que queremos.
La fecha final tiene que ser ayer, así que usamos la misma idea y le restamos 1 día a hoy.
Finalmente, con as.character() convertimos los valores obtenidos en un string o cadena de caracteres, que es el formato que necesitan los parámetros start.date y end.date.

Últimas N semanas (de lunes a domingo)

query.list<-Init(
  start.date=as.character(seq(Sys.Date()-wday(Sys.Date())+2,
               by="-1 week",length.out = N+1)[N+1]), #Sustituir N por un número
  end.date=as.character(Sys.Date()-wday(Sys.Date())+1),
  dimension="<dimensiones>",
  metrics="<métricas>",
  max.results=10000,
  table.id="ga:XXXXXXX"
)
ga.query<-QueryBuilder(query.list)
ga.data<-GetReportData(ga.query,token)
La fecha inicial tiene que ser el lunes de hace N semanas. Para ello, primero recuperamos el lunes de la semana actual mediante Sys.Date()-wday(Sys.Date())+2 y luego retrocedemos N* semanas para obtener el lunes que necesitamos con seq(…,by=”-1 week”,length.out = N+1)[N+1]).
La fecha final, considerando que queremos semanas cerradas, es el domingo de la semana anterior a la actual. Lo obtenemos mediante Sys.Date()-wday(Sys.Date())+1 (no es más que el mismo código con el que obtenemos el lunes de la semana actual pero restando un día para que sea el domingo anterior).
Finalmente, usamos as.character() como en el caso anterior.
*Se utiliza N+1 porque la primera fecha que considera es la de la semana actual.

Últimos N meses

query.list<-Init(
  start.date=as.character(seq(Sys.Date()-day(Sys.Date())+1,
               by="-1 month",length.out = N+1)[N+1]), #Sustituir N por un número
 
  end.date=as.character(Sys.Date()-day(Sys.Date())),
  dimension="<dimensiones>",
  metrics="<métricas>",
  max.results=10000,
  table.id="ga:XXXXXXX"
)
ga.query<-QueryBuilder(query.list)
ga.data<-GetReportData(ga.query,token)
La fecha inicial tiene que ser el primer día del mes correspondiente. Para obtenerlo, primero recuperamos el día 1 del mes actual con Sys.Date()-day(Sys.Date())+1 y después retrocedemos N* meses para tener el día 1 que necesitamos con seq(…,by=”-1 month”,length.out = N+1)[N+1])
La fecha final del periodo, considerando que queremos meses cerrados, es el último día del mes anterior al actual. Lo podemos obtener con Sys.Date()-day(Sys.Date()), que no es más que el mismo código con el que obtenemos el día 1 del mes actual pero restando un día para que sea el último del mes anterior (independientemente de si tiene 30, 31 o 28 días).
Finalmente, como en los casos anteriores, usamos as.character() para convertir los valores en un string o cadena de caracteres, que es el formato que necesitan los parámetros start.date y end.date.
*Se utiliza N+1 porque el primer mes que considera es el actual.
Y ya está! Poniendo nuestro id de la vista de Google Analytics correspondiente más las dimensiones y métricas que se quieren extraer, ya podríamos tener una consulta que siempre devuelva los datos de los últimos N días, de las últimas N semanas o de los últimos N meses. Además, podríamos combinar estos códigos para automatizar consultas con fechas relativas personalizadas, como por ejemplo “los últimos 2 meses hasta el domingo pasado” o cosas por el estilo. De esta forma, podremos repetir nuestros análisis y/o visualizaciones hechos con R periódicamente para generar informes sin tener que modificar ni una línea del código inicial, así que ya tienes una razón más para animarte a usar R para analizar tus datos de Google Analytics. 😉
Espero que este post os pueda facilitar un poco la vida y de cara a próximos análisis sólo tengáis que centraros en la explotación de los datos, que es lo realmente importante. Y si tenéis alguna duda relacionada con el tema o tenéis algún problema al automatizar algunas fechas, no dudéis en dejar vuestro comentario. 🙂

Se advierte al usuario del uso de cookies propias y de terceros de personalización y de análisis al navegar por esta página web para mejorar nuestros servicios y recopilar información estrictamente estadística de la navegación en nuestro sitio web. Política de cookies Acepto