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

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. 🙂

Midiendo conversiones que ocurren fuera de nuestro sitio

29/06/2016 a las 16:57

Seguramente, muchas veces han querido contabilizar conversiones que ocurren fuera de nuestro sitio como por ejemplo, en una web de generación de lead donde la venta ocurre por teléfono y no en el propio sitio.

Hace poco, trabajando para un cliente, me encontré precisamente en esta situación y quiero contarles en este post cómo lo resolví por si les puede ayudar o servir de ejemplo.

No significa por supuesto que sea la única manera de hacerlo, pero los resultados han quedado bastante bien y escribir un post siempre sirve para que otras personas aporten ideas de mejora o diferentes puntos de vista.

El sitio

Llamaré de manera ficticia a mi cliente como ACME FX. Esta empresa ofrece a sus clientes realizar pagos a empresas en el extranjero que impliquen cambio de moneda con unas comisiones sensiblemente inferiores a las que ofrecen los bancos o brokers.

Para convertirse en cliente de ACME FX, una persona debe pasar una serie de “pasos” , el primero de estos es dejar sus datos a través de la web y posteriormente responder a un cuestionario que lo clasifica como Qualified para seguir en el proceso de “conversión” a cliente o no.

 

El reto

Era precisamente este objetivo el que ACME FX quería tener en Analytics es decir, las conversiones serían cuántos de los usuarios que llegan al sitio y envían un contacto, acaban siendo marcados como Qualified. El reto de este proyecto por tanto, era el de conseguir que una acción que ocurre fuera de la sesión del usuario (un check en una casilla por parte del evaluador) acabase en Analytics como una conversión de objetivo asignado al usuario.

Y por si esto fuese poco, queríamos también que las conversiones se asignase al origen, medio y campañas de la sesión online.

 

El proceso para medir las conversiones

En esencia, los pasos que necesitamos seguir para poder realizar este proyecto o cualquier otro que requiera medir conversiones offline/online pero fuera de la sesión del usuario es:

  1. Necesitamos capturar el client id del usuario, el client id es un identificador único que le da Google Analytics a cada usuario que entra en el sitio y recomendamos recogerlo y guardarlo en una custom dimensión (aunque para este caso, guardarlo en una custom dimension no es estrictamente necesario)
  2. Una vez capturado, necesitamos enviar ese client id junto con los datos que envía el usuario en el formulario
  3. Una vez enviado, necesitamos almacenarlo, normalmente en nuestro CRM (o BBDD)
  4. Cuando el usuario realiza la conversión, enviamos un hit de evento mediante el measurement protocol indicando la acción de conversión, en ese hit incluiremos el client id que teníamos almacenado para que pueda ser asignado a ese usuario concreto.
  5. En Google Analytics, damos de alta un objetivo que se cumpla cuando llega un evento del tipo definido en el punto 4.

Eso es todo ;), realmente es tan fácil como parece.  Vamos a ver en detalle cada punto tal y como lo apliqué con mi cliente.

Punto 1

Dado que mi cliente tenía Google Tag Manager instalado, capturar su client id fue realmente sencillo, basta con definir una variable como “custom javascript” (podemos llamarla UA client ID por ejemplo) con el siguiente código:

function() {
 try {
 var cookie = {{ga cookie}}.split(".");
 return cookie[2] + "." + cookie[3];
 } catch(e) {
 console.log("No Universal Analytics cookie found");
 return "n/a";
 }
}

Realmente lo interesante es el JavaScript, esta función devolverá el valor del client id almacenado en la cookie de Google Analytics (el mérito es de Simo Ahava y su excelente post sobre 4 custom dimensión que debes capturar para mejorar tu implementación)

Una vez lo tengas, lo puedes almacenar en una variable para mandarlo junto a los datos del usuario. Adicionalmente nosotros solemos guardarlo en una custom dimension. Hacerlo en  GTM es tan sencillo como modificar la etiqueta de seguimiento de página para que la variable sea enviada como custom dimension.

custom-dimension-userid

Envío del client id como custom dimension

 

Punto 2 y 3:

Una vez capturado el client ID, lo siguiente es mandarlo a la herramienta que gestiona nuestros leads junto con los datos del cliente, dado que hay muchas formas de mandarlo,  me centraré en mi cliente. En su caso su CRM es SalesForce y lo que hicimos fue enviar el client id como campo oculto en el formulario de contacto (o cuando se pedía una demo del producto o se dejaban los datos para solicitar un informe)

Realmente enviar el client id como campo oculto es la manera más común de mandar el dato para almacenarlo.

En SalesForce (o nuestro CRM o BBDD), creamos un campo para guardar el client id y almacenamos este valor junto con el resto de información del usuario.

proceso de guardado

Proceso de guardado del cliend ID en SalesForce

Punto 4:

Ahora viene la parte entretenida. Cuando un usuario ha enviado sus datos, interviene un evaluador que decide si este usuario pasa de Lead a Lead Qualified. Es en este punto cuando queremos considerar en Analytics una conversión . Hasta hace poco, solo podíamos mandar información a Google Analytics si nos encontrábamos en una página web. Esto ha cambiado con el measurement protocol. Este protocolo, nos ofrece una vía para mandar información a Google Analytics desde cualquier dispositivo que disponga conexión a internet, en este caso nuestro CRM.

Cuando el evaluador marca la casilla de Lead Qualified lanzamos un “hit” de Google Analytics de tipo evento, en nuestro caso este hit tiene la siguiente forma:

www.google-analytics.com?v=1&t=event&tid=UA-XXXXXX-X&cid=884b4995-dd01-45c1-9dd8-f7ef158abdc3&dp=%2FsalesForce&ec=Offline%20interaction&ea=Lead%20status&el=qualified&ni=1&cd3=884b4995-dd01-45c1-9dd8-f7ef158abdc3

La explicación de los parámetros sería la siguiente:

 

Parámetro Valor Descripción
v 1 Versión de measurement protocol
t event Tipo de hit
tid <cuenta> Cuenta a la que se manda los datos
cid <Client ID> Client ID, permite relacionar los datos del CRM con los de Google Analytics
dp /salesForce Página asociada al evento, permite que filtrando la página salesForce se eliminen todos los eventos
ec Offline interaction Categoría del evento que se manda
ea Lead Status En el event action indicaremos la acción que se realiza sobre el usuario en sales force.
el Qualified Indica que el lead tiene el status de Qualified (objetivo)
ni 1 Se pone a 1 para indicar que el evento es siempre “no interactivo” con lo cual no generamos sesión con los hits del measurement protocol y no engordamos las estadísticas (dado además que los usuarios son existentes porque uso el client ID, no creo tampoco usuarios nuevos)
cd3 <Client ID> Almacena el client ID como custom dimensión

Un detalle importante es que no debemos indicar nunca ni el source ni el medium (parámetros cs y cm) en el hit de evento.

Al no indicarlos, este hit se considerará como tráfico directo con lo cual, a efectos de la conversión, aplicará el funcionamiento normal de Google Analytics que es el de tomar como fuente y medio aquellos que tenía el usuario en su última sesión online (es decir, la sesión en la que el usuario envió el lead) .

Un problema que puede aparecer es que el usuario entre de nuevo al sitio en el intervalo de tiempo que pasa desde que manda el formulario y se le clasifica como Lead Qualified, en ese caso, la fuente/medio que se asignaría a la conversión sería esta última (siempre que no sea directa) y no aquella que generó el envío del contacto.

Punto 5:

Lo que nos queda ahora es dar de alta en Analytics un nuevo objetivo, este objetivo se “disparará” cuando en Analytics se reciba un hit con el evento definido para clasificación de lead.

Objetivo

Definición del objetivo de generación de lead válido

Resultado

El resultado de todo este proceso es el que pueden ver a continuación.

Fuente y medios que generan la conversión

Informe de resultado de conversiones en Sales Force

Como podemos ver, se contabilizan las conversiones del objetivo y estas se asigna a la fuente y medio de la sesión previa online que es lo que queríamos.

Espero que el post es haya resultado útil y se animen a medir todo aquello que el usuario hace “fuera” de la sesión online.

Si tienen cualquier duda o sugerencia no duden en plantearla en los comentarios

Fernando

Como empezar a usar R statistics

15/06/2016 a las 10:51

Muchos ya habréis notado, por anteriores posts, que nosotros estamos acostumbrados a usar R. Pero ello no hace que nos olvidemos de nuestros inicios y de la notable curva de aprendizaje que conlleva empezar a usar R de cero.

Pero si os encontráis en vuestros inicios con R no os preocupéis, la comunidad de usuarios/desarrolladores de packages de R ha pensado una buena ayuda para empezar a usar R haciendo más amena la primera toma de contacto con la herramienta, y nosotros estamos aquí para contároslo.

La solución que os queremos presentar hoy es el package/tutorial Swirl. Se trata de un package del mismo R que consta de un tutorial interactivo de dicha herramienta.

Para acceder al tutorial debemos:

  1. Tener R instalado y abrirlo.
  2. Instalar y cargar el package “Swilr” usando los siguientes comandos:
                          install.packages(“swirl”)
                          library(swirl)
  3. Llamar la función correspondiente para iniciar el tutorial:
                           swirl()

Llegados a este punto, ya habremos empezado.

img R swirl 1

A partir de aquí, las diferentes explicaciones y actividades nos irán apareciendo en la consola de R mediante texto en inglés. En cada bloque explicativo o ejercicio se esperará nuestra interacción mediante la respuesta de dicho ejercicio propuesto, pulsando “enter” para saltar a la siguiente explicación o utilizando comandos específicos para guardar la progresión o abandonar el tutorial, por ejemplo.

El programa consta de los siguientes puntos:

img R swirl 2

Se pueden seguir los diferentes steps uno a uno en orden, realizar solo aquel que nos interese, ir haciendo poco a poco guardando el progreso y recuperándolo en otro momento… vamos, toda la flexibilidad que tanto nos gusta que tengan este tipo de tutoriales.

Además, cada uno de estos bloques consta de diferentes apartados. Por ejemplo, este es el contenido correspondiente al bloque de análisis exploratorio de datos (bloque 4):

img R swirl 3

Como podéis ver se trata de un completo tutorial interactivo que os animamos a probar y a compartir vuestra experiencia con todos en los comentarios.

Good luck and Statistics 😉

El algorítmico y absorbente mundo de Facebook

09/06/2016 a las 13:29

Algoritmo de Facebook como funciona que es EdgeRank

El tiempo de media, según The New York Times, que se invierte entre Facebook, Messenger e Instagram es de 50 minutos al día. Las plataformas de Zuckerberg (no tiene en cuenta WhatsApp pese a ser de su propiedad) superan con creces las cifras de YouTube (17 minutos), LinkedIn (2 minutos) o Twitter (1 minuto).

Más allá de su precisión, suban o bajen, los números marcan una explícita tendencia que sonríe claramente a Facebook. Aún así, la empresa quiere más. Más tiempo entre sus algodones implica obtener más datos sobre el comportamiento de los usuarios, más control y al mismo tiempo más engagement y por tanto más alicientes para atraer a la publicidad.

Estamos hablando que de 24 horas que tiene el día, si descartamos el promedio de 8,8 horas que se consumen durmiendo, invertimos un dieciseisavo en Facebook y sus aliados, prácticamente lo mismo que a comer (1 hora). De la lectura o practicar deporte mejor ni hablar. Nadie nos obliga a ello, estar en Facebook es una elección libre que si se realiza es porque nos satisface. Y Zuckerberg lo sabe, por lo que no duda en ofrecer más y más opciones para atraparnos con sus hechizos (y los que podrían están por llegar, como un nuevo navegador dentro de la app, las imágenes en 360º o la categorización del feed).

Dimensiones personalizadas Tiempo y Temperatura en Tealium

09/06/2016 a las 12:35

¿Tienes un ecommerce o tienes a tu cargo el análisis de los datos de alguno?

Seguro que más de una vez has escuchado algo como que los días de lluvia son una bendición para el comercio electrónico ya que la gente suele quedarse en casa y realizar sus compras a través de la red.
Pues bien, el gran Simo Ahava nos daba una idea en este post para poder comprobar si realmente se cumplía dicha teoría mediante una implementación en GTM.

Nosotros hemos comprobado que su implementación funciona perfectamente en Google Tag Manager, sin embargo teníamos la duda de cómo realizar esta misma implementación en Tealium.

¿Qué es Tealium?

Para los que no sepáis qué es Tealium os diré de manera rápida que se trata de otro gestor de etiquetas, similar a GTM pero con diferentes características. Tealium utiliza el objeto utag_data para proporcionar información desde el site, además una de sus mayores fuerzas es la integración con un gran número de herramientas de terceros, lo que facilita mucho el trabajo con este gestor de etiquetas.

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