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

Escucha activa (o cuando Internet lo cambió todo)

02/02/2016 a las 10:30
escucha activa

Rick&Brenda Beerhorst | Flickr (cc)

Monitorización, escucha activa o social listening son algunos términos con los que las empresas conviven desde hace algún tiempo, más concretamente desde que Internet cambió las reglas del juego. La aparición, expansión y evolución de la red de redes supuso el nacimiento de los prosumidores, personas que consumen lo que ellos mismos producen: noticias en blogs, comentarios en redes sociales, contribución en wikis, desarrollo de software libre, etc.

Esta nueva realidad ha democratizado todo, de manera que cualquiera dispone de un altavoz con el que hacerse oír y tiene a su alcance un hueco público en el que tener visibilidad para compartir sus creaciones, opiniones e inquietudes.  La universalización no ha hecho más que equilibrar, al menos en apariencia, un sistema que durante décadas ha estado dominado por los medios y la industria tradicional.

La información y el conocimiento ya no son exclusivos de los mismos y limitados emisores. Hoy podemos hablar de una relación sin jerarquías, de un trato de igual a igual.  La interactividad y la autonomía propias de la web 2.0 hace de cada uno de nosotros un prosumidor, ese término que Toffler acuñó en 1980 y que tan bien encaja para describir la situación actual.

Ahora es esta figura quien elige el qué, el cómo y el cuándo, por lo que las empresas deben cambiar sus enfoques para adaptarse a la convivencia en el entorno digital. Estés o no en la web la gente va a hablar de ti, es inevitable, así que lo más práctico es aceptar las transformadas normas, construir tu identidad digital y poner los medios necesarios para ser uno más.

Dentro esa masa ingente de información que se genera en Internet hay un enorme valor que las marcas no deben dejar escapar. Es más, supone una fantástica oportunidad para conocer el mercado.

Si gracias a los recursos existentes y la actitud de los usuarios se ha modificado el ciclo de vida del marketing, ¿por qué no aprovechar esos mismos mecanismos para conocerles mejor? 

Query plan explanation: el nuevo informe de BigQuery para optimizar consultas

22/12/2015 a las 11:45

Como hemos comentado en ocasiones anteriores en doctormetrics, Google Bigquery nos permite realizar consultas muy rápidas sobre grandes conjuntos de datos.

No es raro el caso en el que el resultado de nuestra consulta tiene millones de filas y se han necesitado complejas operaciones intermedias para obtener cada una de sus columnas. A pesar de su potencia, en estos casos nuestras consultas suelen tardar más tiempo del que nos tiene acostumbrados BigQuery, e incluso podemos alcanzar los límites internos de la herramienta y obtener errores a la hora de ejecutar la query, especialmente si la consulta no está optimizada.

Y precisamente una cosa que echábamos en falta los que usamos Google BigQuery con frecuencia era tener la posibilidad de saber qué partes u operaciones de nuestras consultas se podían optimizar para poder sacar el máximo rendimiento de la herramienta. Pero esto ya es pasado, Google BigQuery acaba de sacar un nuevo report llamado query plan explanation. En este post explicaremos dónde podemos encontrarlo, qué información nos proporciona y cómo podemos utilizarlo para optimizar nuestras consultas.

Dicho esto, empecemos!

¿Qué es?

Es un nuevo informe que nos ofrece información detallada sobre el query plan:  los tiempos invertidos, las transformaciones/operaciones realizadas y el número de filas con las que ha trabajado BigQuery en cada una de las etapas que han compuesto el procesamiento de nuestra consulta. Tiene el aspecto siguiente:

BQexplanation4

 

¿Dónde podemos encontrarlo?

Cuando obtenemos los resultados de una consulta en la interficie web de BigQuery, actualmente nos aparece una nueva pestaña llamada Explanation con este informe (antes únicamente teníamos la opción de ver los Results). También se puede conocer el detalle del query plan directamente desde la API.

BQexplanation1

 

¿Qué información nos ofrece?

La información que nos proporciona este nuevo report se puede separar en tres partes:

 

BQexplanation5.2

  1. Stage timing

Cada query se divide en varias etapas y cada una de ellas consiste en una serie de pasos que se pueden agrupar en cuatro categorías: Wait, Read, Compute, Write. Cada barra de color nos da una idea del tiempo medio que han necesitado los subprocesos de cada paso y, además, del tiempo máximo.

BQexplanation2.2

Sin embargo, estas barras no representan el tiempo propiamente dicho, sino que representan el ratio entre el tiempo de ese paso y el tiempo máximo de todos los subprocesos. Por ejemplo, en la imagen anterior, como el subproceso que ha necesitado el tiempo más grande (barra más larga) pertenecía al paso de leer (Read) de la etapa 1 (Stage 1), todos los demás tiempos se han dividido respecto a este valor para obtener el ratio que se muestra. Por lo tanto, cualquier otra barra representa qué proporción de ese tiempo máximo ha necesitado el paso concreto. Así pues, una barra que llena la mitad de la barra significa que ha necesitado la mitad del tiempo que se ha necesitado para leer en la etapa 1.

Aun así, la interpretación del gráfico no cambia: una barra más larga significa que se ha invertido más tiempo en ese paso mientras que una barra más corta significa que el proceso ha sido más rápido.

  1. Rows

Al hacer una query, consultamos los datos de una tabla inicial (input) y acabamos obteniendo una tabla con resultados (output). Sin embargo, en el proceso de pasar de input a ouput, es probable que BigQuery haya tenido que crear tablas intermedias para ir haciendo los distintos cálculos que le hemos pedido. Por este motivo, la consulta se divide en varias etapas (stages). Con la query plan explanation, además de los tiempos relativos que hemos visto en el punto anterior, tenemos el número de filas de la tabla input y de la tabla output correspondiente a cada etapa.

  1. Steps metadata

Por si fuera poco todo lo que hemos comentado hasta ahora, podemos desplegar cada etapa para obtener información completa sobre los pasos que se han hecho en ella: las columnas que se han leído y su correspondiente tabla de origen, las funciones agregadas y condiciones aplicadas, la tabla donde se han almacenado los resultados de ese paso intermedio, etc.

Los posibles pasos son: READ, WRITE, COMPUTE, FILTER, SORT, AGGREGATE, LIMIT, JOIN, ANALYTIC_FUNCTION, USER_DEFINED_FUNCTION.

¿Por qué es útil?

Este informe nos puede servir para optimizar nuestras consultas si combinamos la información que nos proporciona el gráfico de tiempos relativos (stage timing) con la de steps metadata. Con el primero, podemos detectar las partes críticas de nuestra consulta (las que tengan la barra más larga) que podrían estar ralentizando su ejecución, mientras que con el segundo podemos conocer los pasos concretos que se realizan en esa parte y así saber para qué operaciones de la query necesitamos pensar alternativas más eficientes que nos permitan obtener la misma tabla de resultados final.

Únicamente hay que tener en cuenta un pequeño pero importante detalle: siempre habrá un tiempo máximo de todos los subprocesos, que es el que se utilizará para calcular los demás ratios. Por lo tanto, siempre habrá algún paso que llenará toda la barra. Sin embargo, eso no significa que ese paso no sea eficiente! Incluso en las consultas perfectamente optimizadas veremos barras más largas que otras… Es importante tenerlo en cuenta para no sacar conclusiones erróneas.

 

Esto es todo por hoy! Espero que este post os haya sido útil para aprender a interpretar este nuevo informe y también ver la importancia que puede llegar a tener a la hora de optimizar consultas, algo imprescindible y que hasta ahora no era posible en la interficie de BQ. Como siempre, si tenéis alguna duda relacionada con el post o no encontráis la forma de optimizar una consulta, podéis dejar vuestro comentario y os intentaré ayudar en la medida de lo posible. Por último, si os interesa saber más sobre cómo hacer consultas en BigQuery, os invito a que leáis este post que escribí hace un tiempo sobre el tema, explicando su estructura básica y las funciones más importantes que se suelen utilizar.

Hasta la próxima! :)

 

 

Cuadro de mando social (II)

22/12/2015 a las 11:25
redes sociales cuadro de mando social

mkhmarketing (cc) Flickr

Como ya indicamos en la primera parte de este tema, para todas aquellas empresas que invierten en redes sociales para tener una relación más estrecha y de mayor interés con sus clientes es indispensable que introduzcan en sus protocolos de actuación la medición, tanto en las redes propias como en las de la industria de la formen parte. La recopilación de datos y el establecimiento de KPIs es el mejor sistema para mejorar la interacción con los usuarios.

Preocuparse en escuchar implica esforzarse en indagar qué significamos para nuestros seguidores y los ajenos, sintonizar con sus expectativas, determinar qué presencia tenemos en su vida, entender qué dicen, escrutar cuáles son los temas más relevantes dentro de la comunidad para poder formar parte de ella.

Sobre el engagement y cómo calcularlo a medida del cliente

21/12/2015 a las 10:23
como calcular engagement facebook twitter redes sociales

Charis Tsevis (cc) Flickr

¿Cómo calcular el engagement que generan las Redes Sociales de un cliente? ¿Cómo medir el impacto de sus acciones en dichas Redes? ¿Qué herramientas utilizar para medir la efectividad de sus iniciativas? Estas y otras muchas preguntas de índole similar son muy habituales a la hora de tratar con las marcas, especialmente aquellas que más invierten en medios sociales. Como es evidente no solo quieren conocer de qué y cómo hablan de ellos sus clientes para ser más eficaces a la hora de comunicar, sino que quieren obtener referencias para poder valorar el funcionamiento las propuestas que ejecutan.

En las formaciones de community manager siempre se citan diferentes cualidades muy a tener en cuenta para desarrollar correctamente el trabajo: paciencia, madurez, corrección, precisión, originalidad, empatía y, especialmente, sentido común. Es precisamente ese sentido común el que también hay que aplicar a la hora de medir.

Basta consultar Internet para conseguir centenares de referencias a herramientas de medición de redes sociales, fórmulas y procedimientos para tener datos sobre el alcance de los mensajes, la expansión de los mismos, el nivel de conversación generado, etc. Todo esto es importante, no cabe duda, pero antes de ponerse manos a la obra lo fundamental es definir cuáles son los objetivos del cliente y los conceptos que los rodean.

Efectivamente, puede parecer una perogrullada, pero pongamos por caso un cliente que quiere medir el engagement de sus redes sociales. Imaginemos que en una de las reuniones previas al inicio del trabajo están en la misma mesa el marketing manager, el digital manager, el content manager, el communication manager, el digital manager y toda la lista de manager que queramos agregar. Les pedimos que escriban qué es para ellos el engagement. Posteriormente leemos las respuestas. Así es, 5 personas, 5 percepciones distintas, 5 maneras de medir.

Insistimos, si no hay consenso en la definición del objetivo es, imposible medirlo. Al hablar de términos sociales no es difícil encontrarnos en esta situación. Estamos ante etiquetas recientemente acuñadas que se forman y deforman tan rápido como actúan los propios medios sociales, así que actuar en un primer momento en busca de un acuerdo lingüístico, por así decirlo, no solo nos ayudará a contextualizar sino que también nos ahorrará futuras rectificaciones.

La importancia del modelo de datos en una implementación de Google Analytics

15/12/2015 a las 17:31

En el ámbito de la analítica digital  es importante seguir una metodología de trabajo que permita crear sistemas de medición estables, completos y relevantes al negocio. Por este motivo, cada modelo será único y personalizado.

Esta metodología consiste en trabajar distintas fases:

  1. Conocer e interiorizar los objetivos de negocio. Es decir, entender la estrategia y plan de acción que va a realizar la organización, sus hitos y metas; además de definir cuáles van a ser los indicadores clave de rendimiento.
  2. Definir el modelo de datos. Consiste en definir la estructura lógica de los datos y determina el modo de almacenar, organizar y manipular los datos:
    1. Por un lado, se trata de elaborar una lista de todos los elementos que se quieren recoger i especificar la información asociada a dichos elementos, como sus nomenclaturas y conceptos relacionados.
    2. Por otro, se trata de mapear cada uno de estos conceptos y/o elementos con su variable dentro del sistema de medición. En el supuesto caso que nuestra herramienta de medición sea Google Analyics, habrá que mapearlo con su correspondiente Google Analytics Tracking Code (GATC). Por ejemplo, mediremos el buscador con una etiqueta de ‘evento’, y especificaremos dicha acción en la dimensión ‘categoría’ del evento.

 

  1. Implementación. Consiste en la inclusión de los códigos necesarios en el sitio que queremos monitorizar. Los cuales nos servirán para conseguir la estructura diseñada en la fase anterior.
  2. Depuración y validación. Consiste en la validación de los datos recibidos, depuración y refinamiento hasta conseguir el resultado definido en el modelo de datos.

1

 

En este post nos vamos a centrar en la fase del modelo de datos, ya que se trata de la fase más importante a la hora de crear un sistema de medición robusto.

Vamos a imaginarnos que queremos monitorizar la navegación de un portal de turismo rural. En la imagen vemos la ficha de una casa con la opción de clickar a distintos tabs (general, opiniones, fechas libres, fotos y vídeos, mapa). En este caso, se está enviando para cada tab seleccionado una etiqueta de evento de Google Analytics:

 

Variable Valor Tipo
Category New pdp Valor fijo
Action tabs Valor fijo
Label {{nombre de la pestaña clickada}} Valor dinámico

2

¿Creemos de verdad que esta es la información que más aporta al negocio? Dicha acción se está produciendo en una ficha de producto que:

  1. Se llama Maria Ca l’Agustinet
  2. Pertenece a la población de Vallcebre
  3. Pertenece a la provincia de Barcelona
  4. Pertenece a la comunidad autónoma de Cataluña
  5. Pertenece al país España
  6. Tiene un precio de 30,71€ por persona
  7. ….entre otras características más

¿No sería más rico si enviáramos información sobre categoría del producto en vez de enviar por duplicado la acción que realiza el usuario? Este tipo de tracking muestra una ausencia clara de un modelo de datos que articule nuestro sistema de medición.

 

Vamos a ver otro ejemplo de un sector totalmente distinto. Se trata de un ecommerce, en este caso el usuario está añadiendo un producto a la cesta. Para recoger esta acción se envía un hit de página vista con la siguiente información:

 

Variable Valor Tipo
url física Ecommerce/checkout/basket.cfm Valor predeterminado
dp – reescritura Cesta/validar Valor fijo

3

¿No sería más rico si enviáramos información adicional sobre el tipo de producto que se está añadiendo a la cesta para poder calcular luego el porcentaje de conversión de cada categoría, subcategoría y producto, en vez de tener únicamente el dato agregado?

Siguiendo en el mismo sitio, en este caso vamos a realizar un filtro por marca en el listado de productos. La información que se recoge es la siguiente

Variable Valor Tipo
Category {{categoría}}/{{Subcategoría}} Valor dinámico
Action Filtros Valor fijo
Label {{tipo de filtro}} Valor dinámico

4

¿No sería más rico recoger también la selección que ha hecho el usuario? Por ejemplo, podríamos definir la acción así:

Variable Valor Tipo
Category {{categoría}}/{{Subcategoría}} Valor dinámico
Action Filtros – {{tipo de filtro}} Valor dinámico
Label {{selección}} Valor dinámico

No es que el caso anterior esté mal resuelto, es probable que no interese recoger un nivel de detalle tan alto. En cualquier caso es importante plantearse si queremos prescindir de esta información o no.

 

Vamos a ver otro ejemplo, en este caso se trata de pedir una cita por teléfono. Esta acción solo está disponible en la página de formulario de ‘Pedir cita’. La información que se envía es la siguiente:

Variable Valor Tipo
Category Cita telefónica Valor fijo
Action Click/touch Valor fijo
Label formulario Valor fijo

5

¿No creéis que la información enviada es redundante? Simplemente con el uso de una sola variable es suficiente para definir la acción, podemos utilizar las otras dos para añadir información adicional sobre el usuario o el tipo de producto sobre el que se está solicitando más información.

Como estos ejemplos hay millones, espero que estos ejemplos os hayan hecho reflexionar sobre la importancia de definir un buen modelo de datos que permita recoger aquella información clave y pueda garantizar un sistema de medición completo que responda a los requerimientos del negocio.

Usando el Tag Assistant Recording para depurar una implementación de Analytics

10/12/2015 a las 11:24

Google Tag Assistant es una de las herramientas que más uso en mi día a día como analista web. Esta extensión de Google Chrome funciona perfectamente para detectar de manera rápida si una implementación de Google Analytics con Google Tag Manager está hecha adecuadamente.

 

Si lo instalamos nos encontraríamos el botón de Tag Assistant al lado de la barra de direcciones de Chrome , haciendo click en el nos permite ver de manera rápida los tags de Google implementados en la web (Google Analytics, Adwords conversion, remarketing, Foodlight…), y si hubiera alguno mal implementado o hubiera algún problema nos indicaría que puede ser y como solucionarlo.

 

Lo primero que veríamos sería algo así:

Tag Assistant

Además si hacemos click dentro del tag de Analytics podemos ver que tags hay relacionados con GA, como pageviews o eventos.

Tag Assistant

Por lo que nos sirve para ver de forma clara y rápida que la implementación está ok, ahora a través de otra herramienta podríamos ver ya si se está lanzando cuando toca o si se están enviando los datos que queremos, pero para una visión rápida nos sirve.

Tag Assistant

Ahora, hace relativamente poco, se anunciaron nuevas funcionalidades para el Tag Assistant, por lo que ya no solamente nos servirá como ayuda para ver si la base de la implementación es correcta, si no que podremos sacarle mucho más partido a esta herramienta con la nueva funcionalidad de “recordings” o grabaciones.

 

Esta nueva funcionalidad nos sirve para validar implementaciones de Google Analytics en real time con más detalle, encontrar diferentes tipos de problemas con ayudas para solucionarlos y volverlos a revisar.

 

Las grabaciones a través de Tag Assistant funcionan con todo tipo de hits de analytics: pageviews, events, enhanced ecommerce … así que podemos analizar los datos de un proceso de compra y si se están recogiendo correctamente. Es especialmente útil para validar implementaciones, cuando se han hecho cambios en analytics, datalayer, updates en la web, etc

 

Pero no solo sirve para Analytics, también te indica posibles errores con otros tags como los de Adwords, por ejemplo nos puede mostrar si hay posibles errores a la hora de pasar el gclid a Analytics (dato que atribuye el tráfico a la campaña de Adwords que toca), entre otros.

 

Pero vamos a ver como funciona, especialmente para una implementación de GA. Lo primero es descargarnos el plugin de Google Tag Assistant Chrome Extension. Una vez instalada el uso es sencillo, abre la extensión (tal como hemos indicado anteriormente) y dale al botón “Record”, graba el user flow que te interese y una vez hecho esto simplemente visualiza el “full report”. Veríamos algo como esto:

 

Informe de Google Tag Manager

Nos muestra de cada página que hemos visto en la sesión grabada las URLs de estas,  los tag que han saltado, los errores o alertas, el tiempo de carga…  En este caso el tag de GTM y el de Google Analytics:

tag assistant recording

 

Aquí vemos los datos que nos muestra sobre GA

Tag Assistant

Y aquí los datos sobre GTM

Donde podemos ver hasta el dataLayer.

Tag Assistant

 

Informe de Google Analytics

El segundo informe que encontramos es el de Google Analytics, que nos va a ayudar a ver como se estén enviando los datos y los errores que hay o incluso que pudiera haber.

 

Cosas que nos muestra la página principal:

Tag Assistant

  • Alerts: Cualquier tipo de alerta de que algo no está funcionando como debiera. En este caso nos indica que el código de GA se está lanzando bastante tarde y que puede que el usuario se haya ido o cambiado de página antes de haber recogido esta pageview.
  • Audience: Aquí nos muestra el navegador con el que hemos entrado, el sistema operativo, idioma y número de sesiones.
  • Location: Localización
  • Acquisition: Este es interesante para mi, ya que en Universal Analytics no podemos ver la fuente de tráfico cuando hacemos la depuración, lo que hace muy incómodas algunas validaciones.  Pero a través del Tag Assistant Recording si que podemos ver las fuentes de tráfico y podemos ver si se pierden en algún momento de la navegación, lo que es de gran utilidad.

Tag Assistant

  • Behavior: En este mini informe vemos la página por la que hemos entrado, por la que hemos salido, las que hemos visitado y los eventos que se han lanzado.
  • Conversions: En el caso que se hubiera completado algún tipo de conversión nos aparecería en este informe.

Tag Assistant

  • Flow:  flujo de hits en cada página. Aquí también vemos las alertas en cualquiera de los pasos, y sus posibles causas y recomendaciones para solucionarlas, así como las dimensiones personalizadas de cada una de las páginas.

Tag Assistant

Hay que decir que estos datos los podemos ver siempre que hagamos el recording “logueados” con la cuenta de Google que tenga acceso a la cuenta de analytics de la web de la cual estamos haciendo la grabación, no podemos hacerlo tal cual con cualquier web, bueno, si se puede hacer, pero no daría este detalle de información.

 

Dashboard de Google Analytics en Gdrive

09/12/2015 a las 15:32

En este blog ya hemos hablado otras veces sobre dashboarding y herramientas especializadas como Klipfolio, hablando de las ventajas de la herramienta o de usos específicos de la misma, por ejemplo. Una de las pocas desventajas de este tipo de herramientas es que no son de uso gratuito. En la mayoría de casos su coste queda justificado por las numerosas ventajas y virtudes de la herramienta (por ejemplo las de Klipfolio ya las comentamos en su día y no me voy a repetir en exceso, las podéis encontrar aquí), pero no en todos los casos estamos dispuestos a pagar una mensualidad por tener un dashboard, por pequeña que esta sea.

Si os encontráis en una situación de este estilo, una muy buena solución para no renunciar a tener un dashboard automático es Google Drive; más concretamente Google SpreadSheets. Tal como la mayoría de vosotros ya sabéis, Google SpreadSheets es un servicio web de hojas de cálculo dentro de la plataforma de Google para usuarios registrados, con el que podemos realizar la mayoría de acciones que se pueden hacer en aplicaciones de hojas de cálculos de los programas ofimáticos (por ejemplo en Excel); como aplicar funciones matemáticas a datos ubicados en distintas celdas, ordenar y combinar datos, entre otras.

Así pues, si tenéis una cuenta de Google (gmail, analytics, etc.) tenéis acceso a la creación y uso de hojas de cálculo mediante SpreadSheets de Gdrive, que a su vez nos permite la importación de datos de Google Analytics a las mismas de una forma muy cómoda y sencilla, de configuración intuitiva y fácilmente automatizable. ¡Veamos cómo hacerlo! :)

Para tener acceso a nuestros datos de Google Analytics en SpreadSheets debemos realizar unas consultas (queries). Pero que la palabra “query” no os asuste, en este caso no nos liaremos con código ni mucho menos, tenemos una herramienta que nos ayuda a realizar dichas queries mediante simples selectores. Para ello debemos crear un nuevo documento de Google SpreadSheets e instalar un Add-ons. Los Adds-ons son como plugins o extensiones que añadimos a Google SpreadSheets que ponen a nuestra disposición nuevas funciones y/o acciones dentro de la herramienta.

dashboard1

En concreto optaremos por instalar el Add-on original de GA dado que funciona a la perfección para lo que queremos, es cómodo de usar y además de esta forma nos ahorramos compartir los datos con algún tercero (o cuarto); lo cual siempre es una buena idea 😉

dashboard2

Una vez instalado, cuando vayamos al menú de Ads-ons nos aparecerá la pestaña “Google Analytics” y dentro de ella 3 opciones además de la pertinente ayuda. La primera de las 3 opciones que debemos usar es la de “Create new report”, la cual nos va a permitir configurar en gran medida nuestras queries.

dashboard3

Al acceder a “Create new report” se nos abrirá una interface a la derecha de nuestra pantalla, donde podremos seleccionar cuenta, propiedad y vista;  así como métricas y dimensiones para nuestras queries.

dashboard4

Una vez seleccionada toda esta información, clicamos en el botón “Create Report” (en azul). Esto generará una nueva pestaña en el documento de Google SpreadSheets parecida a lo que podéis ver en la siguiente imagen:

dashboard5

En este ejemplo hemos seleccionado como dimensiones la fecha y como métricas los usuarios, las sesiones, el rebote y las transacciones.

En este punto tenemos la query casi lista (pero no del todo), solo nos queda añadir los filtros y/o segmentos que queramos (para hacerlo os podéis ayudar de la herramienta query explorer) y seleccionar el periodo de tiempo que queramos de una forma dinámica.

Por defecto, las queries aparecen elaboradas sobre los últimos 7 días (Last N Days = 7) pero esto lo podemos modificar directamente en las celdas del documento seleccionando los últimos N días (siendo N el número que queramos) o dejando esa casilla en blanco y utilizando las de Start Date y End Date. Esta última opción será la más habitual, ya que normalmente nos interesa realizar dashboards sobre periodos de tiempo dinámicos; como, por ejemplo, la última semana cerrada o el último mes cerrado.

 

En este punto es donde debemos usar las funciones de DS que nos permiten seleccionar períodos de tiempo dinámicos. Por ejemplo, si quisiera seleccionar los datos de la última semana cerrada una opción sería esta (como acostumbra a suceder no se trata de una solución única, puede haber distintas formas de llegar al mismo resultado):

 

Start Date = TODAY()-WEEKDAY(TODAY(),3)-7

End Date  = TODAY()-WEEKDAY(TODAY(),3)-1

 

Por poner otro ejemplo, si estuviéramos haciendo un dashboard mensual y quisiéramos obtener el último mes cerrado, esta podría ser una opción:

 

Start Date =  DATE(YEAR(EOMONTH(TODAY(),-1)),MONTH(EOMONTH(TODAY(),-1)),1)

End Date  = EOMONTH(TODAY(),-1)

 

Lo importante es garantizar que dichas selecciones serán dinámicas y que de forma automática harán que la query obtenga los datos para el periodo deseado.

 

Una vez tengamos lista la query, ya solo queda proceder con el Run de la misma. Para ello iremos al menú de Add-ons/Google Analytics y clicaremos sobre “Run Reports”; lanzando así un primer Run manual para comprobar que todo funciona correctamente y que los datos obtenidos son los deseados.

dashboard6

El resultado del run será una pestaña para cada query (columna) donde encontraremos los datos de la siguiente manera:

dashboard7

Una vez terminadas las comprobaciones, nos dirigiremos al mismo menú Add-ons/Google Analytics pero esta vez accedemos a “Schedule reports”; donde podremos programar nuestras actualizaciones automáticas muy fácilmente con tan solo dos clics.

dashboard8

Llegados a este punto ya hemos conseguido tener los datos de Google Analytics para nuestro dashboard en GS con actualizaciones automáticas. Ahora quedará por hacer todo el trabajo de cálculo de métricas calculadas (en caso de querer utilizarlas), diseño del dashboard, presentación del mismo y demás. Esto de momento os lo dejamos a vosotros, tal vez otro día abordemos estos aspectos juntos en otro post. Hasta ese momento podéis disfrutar de la genialidad de poder tener datos de actualización automática en una herramienta gratuita y accesible para todos de una forma tan simple como esta ^.^

¿Por qué las instalaciones en iTunes no coinciden con las de Google Analytics?

25/11/2015 a las 10:30

Hace poco escribí sobre las posibles discrepancias entre los datos de instalaciones en Google Play y Google Analytics pero ¿qué pasa con las apps iOS? ¿Se ven influidas de alguna forma por lo que pasa en Google Play? ¿Por qué hay tal cantidad de discrepancias entre unos datos y otros?
Bueno, voy a intentar explicarlo todo de la forma más clara y resumida posible. Primero, tenemos que ver qué datos comparar y dónde encontrarlos:

En iTunes Connect
Una vez logueado en iTunes Connect, en “Análisis de las Apps”, seleccionamos nuestra App a analizar y pulsamos sobre la pestaña “Indicadores”. Acto seguido, elegimos la métrica “instalaciones”, ya que será la más parecida a los “nuevos usuarios” que muestra GA (luego explicaré mejor esto último).
Esta métrica se define, según Apple, como:

  • Instalaciones: Número total de instalaciones y descargas repetidas de apps. Las instalaciones no incluyen actualizaciones de la app.
Instalaciones de la App en iTunes Connect

Instalaciones de la App en iTunes Connect

En Google Analytics

Podremos ver los datos sobre nuevos usuarios en Adquisición -> Fuentes -> iTunes. Actualmente está en Beta, aunque no por esto debería de funcionar mal :)

Instalaciones de la App desde iTunnes en GA

Instalaciones de la App desde iTunnes en GA

Nos quedaremos con la versión oficial de “nuevo usuario” de Google:

  • Usuarios Nuevos: indica el número de usuarios que han iniciado la aplicación por primera vez en un determinado intervalo de fechas. Un usuario debe descargar, instalar y LANZAR una app para que los datos de fuente de referencia aparezcan en el Informe de Adquisición.

Como se puede observar, las diferencias entre un indicador y otro son bastante grandes (en mi caso, he segmentado por país en iTunes ya que la vista con la que comparo tiene un filtro para incluir sólo los datos de España).

Pues bien, una vez situados, lo primero que nos debería llamar la atención es que los datos de iTunes no son confiables al 100%. Sí, ya sé que ninguna fuente de datos es confiable al 100%, pero es que Apple sólo recolecta datos de una muestra de la población real. Concretamente, sólo los de aquellos usuarios que decidieron enviar su información de uso a Apple (algo que es configurable en cada dispositivo vía Settings -> Privacy).

Puedes ver qué porcentaje de usuarios de tu app han decidido compartir esta información pulsando sobre el símbolo de interrogación de arriba a la derecha. En mi caso, sólo el 29% de los usuarios han dado permiso a Apple para recolectar sus datos. Es necesario tener en cuenta también que este % se calcula para los últimos 30 días, con lo que si estás analizando datos de meses anteriores, puede ser que este ratio fuera diferente entonces.

Información sobre datos de uso

Información sobre datos de uso

Si el obtener sólo el 30% de los datos reales te parece poco, añádele que Apple sólo recoge datos de dispositivos con iOS 8 o superior, lo que deja fuera a un gran número de dispositivos con versiones anteriores.

Bueno, teniendo todo esto en cuenta (más los posibles filtros que pueda tener la vista de GA donde estéis comparando los datos) tenemos unos ratios de coincidencia entre el 80-90%, aunque como era de esperar, aún seguimos teniendo discrepancias. ¿A qué son debidas?

  1. De nuevo la palabra “lanzar” mencionada arriba es clave. Puede haber usuarios que lancen la aplicación en el rango de fechas seleccionado pero que se la hayan instalado tiempo atrás. En este caso, tendríamos un “nuevo usuario” en GA pero no una “nueva instalación” en iTunnes, ya que este sólo considera instalaciones.
  2. El ratio de los usuarios que dan su consentimiento puede ser diferente al que Apple te muestra para el rango de fechas que has seleccionado dado que este ratio está basado en los últimos 30 días. Con lo cual, has de saber que este % será una estimación y no un % real.
  3. Ten en cuenta los filtros de tu vista de GA, ya que dichos filtros pueden no estar disponibles en iTunes Connect.

Mi conclusión en este caso es que los datos de iTunes Connect nos vendrán bien para ver tendencias pero no deberíamos basarnos en ellos para tomar decisiones, dado que el % de muestra será, por lo general, demasiado bajo cómo para basarnos en él. Sin embargo, los datos de adquisición de “nuevos usuarios” de GA estarán muy próximos a la realidad, teniendo en cuenta siempre las peculiaridades en la definición de esta métrica.

Cuadro de mando social

24/11/2015 a las 11:18

En este mundo, en el que la estrategia de comunicación de las marcas pasa por estar presentes en el mayor número posible de redes sociales, uno de los retos al que nos enfrentamos es el de la medición del desempeño en dichas redes.

La medición es esencial para determinar si las acciones están dando el fruto esperado, y para conocer nuestra situación frente a la competencia.

Ante esta realidad, el número de clientes que necesitan tener acceso centralizado a los KPIs que permiten medir el resultado de su presencia en Facebook, Twitter, Youtube, Instagram, etc… no hace más que crecer.

En Metriplica hemos desarrollado Cuadros de Mando Sociales, en los que se engloba toda la información necesaria.

El primer requisito para desarrollar estos cuadros de mando es contar con toda la información de las interacciones de la marca del cliente en las diferentes redes sociales y de su competencia.

Es decir, necesitaremos menciones, comentarios, tuits, me gustas, retuits, favoritos, shares, etc. Propias y externas.

Dos posibles formas de conseguir esto son:

  1. Obtener la información de cada red social mediante la API de la que disponen, lo que supondría un arduo trabajo.
    redes_cuadro
  2. Echar mano de herramientas existentes en el mercado y que recogen esos datos por nosotros, como por ejemplo:  Engagor, Attentio, Pirendo, trueSocialMetrics, Hootsuito SocialMetrix.
    redes -> tool -> cuadro

Sea cual sea la herramienta seleccionada, debe contar con API para poder extraer los datos de ella de forma automática.

De cara a presentar los datos, contamos con varias alternativas. Una de ellas es KlipFolio.

Otra opción, con la que nos sentimos especialmente cómodos son las hojas de cálculo de Google.

Las hojas de cálculo de Google permiten realizar complejas operaciones, e incluso la gestión de las propias hojas, desde el editor de secuencia de comandos, utilizando Google Apps Script (que es un lenguaje basado en JavaScript).

editor de secuencia de comandos

De esta manera, mediante scripts, y sin utilizar programación externa, podemos acceder a las APIsde las redes o de las herramientas que hemos seleccionado previamente, para recoger nuestros datos y darles forma, adaptándolos y volcándolos a nuestras hojas de cálculo.

datos Facebook

datos Twitter

datos Instagram

Antes de proceder con la selección de los elementos y del diseño que utilizaremos para la presentación de los datos, algo para lo que podemos dejarnos aconsejar por el post de Felipe Maggi sobre diseño de cuadros de mando, debemos acordar con el cliente los KPIs necesarios, en función de su estrategia de negocio.

Los KPI’s más extendidos para conocer el impacto del social media son los propuestos por Avinash Kaushik (simplificando y teniendo en cuenta que algunos nombres pueden variar según la red):

  • Ratio de conversación: Comentarios por actualización en la red.
  • Ratio de amplificación: Veces que se comparte una actualización.
  • Ratio de aplauso: “Me gustas” recibidos por actualización.

En las hojas de cálculo de Google dispondremos de una pestaña donde recogeremos los datos de las redes sociales de la marca del cliente y de aquellas marcas de competencia que quiera monitorizar, para un periodo de tiempo acordado previamente: semanal, quincenal o mensual.

Estos datos se vuelcan al finalizar cada periodo y se almacenan en otra pestaña auxiliar, junto a los datos calculados, que necesitaremos para formar los KPIs comentados, permitiendo así que el cliente pueda cambiar el periodo seleccionado y acceder al histórico de sus datos.

Estás hojas o pestañas, a las que hemos convenido en llamar “las tripas del cuadro”, se ocultan convenientemente para no ensuciar el frontend.

hojas ocultas

De esta forma, dejamos visibles solo aquellas pestañas del Cuadro de Mando propiamente dicho:

cuadro visible

Una de las desventajas de las hojas de cálculo son los límites. Las hojas de Google tienen un límite que ronda las 400.000 celdas (y nos hemos topado con él más de una vez). La solución que hemos adoptado ha sido dividir los datos en diferentes hojas.

Dejando de lado el tema de los límites que, como hemos visto, tiene solución, las Google Sheets tienen varias ventajas que las convierten en una opción más que válida para la creación de Cuadros de Mando:

  • Son gratuitas.
  • Permiten trabajar con Google Apps Scripts.
  • Permiten compartir ficheros fácilmente mediante Google Drive.

Es posible programar actualizaciones automáticas (algo esencial en cualquier Cuadro de Mando).

activadores

Visualización de datos de Google Analytics con R

18/11/2015 a las 11:33

Ya sea para buscar patrones, ayudar a plantear hipótesis para futuros análisis o para hacer reporting de una forma más elegante, la visualización de datos es esencial en el mundo de la analítica. Con el gráfico adecuado, podemos extraer la información más importante de una tabla de datos de una forma mucho más efectiva. Pero no siempre es tarea fácil: hay que elegir las métricas y dimensiones adecuadas y el tipo de gráfico que mejor exprese el mensaje que queremos transmitir.

Google Analytics ya nos ofrece en su interfície la posibilidad de visualizar nuestros datos en forma de tablas, de gráficos de líneas o de barras, con diagramas de sectores e incluso con bubble charts animados. Sin embargo, el principal problema a la hora de hacer análisis avanzados es su falta de flexibilidad. En ese caso, la solución suele ser recurrir a la API de Google Analytics para descargar los datos que necesitamos para su posterior visualización y análisis en otra herramienta como por ejemplo Excel, Google Sheets o R. Hace un tiempo en doctormetrics ya os explicamos cómo podemos conectar R con la API de Google Analytics y hacer consultas para poder analizar los datos de nuestro site en esta herramienta.

Entre las distintas formas con que se pueden visualizar datos en R, destaca por su flexibilidad y la “belleza” de los gráficos resultantes un package llamado ggplot2. En este post mostraremos algunos gráficos creados mediante este package y algunas situaciones en las que cada uno de estos gráficos podrían ser útiles para analizar nuestros datos de GA. Los gráficos que mostraremos no son ni mucho menos todos los que se pueden crear mediante ggplot2 por lo que si consideráis que otro tipo de gráfico sería más útil para uno de vuestros análisis, solo tenéis que buscar un poco de información por internet para encontrar la forma de crearlo con ggplot2. Por último, y antes de ponernos manos a la obra, quería comentar para los menos familiarizados con R que para poder utilizar las funciones de cualquier package de R, primero teneis que instalarlo, lo cual es muy sencillo (en internet podéis encontrar información sobre cómo hacerlo).

  1. Gráficos de barras

Uno de los tipos de gráficos más conocidos y utilizados por todos son los gráficos de barras. Evidentemente, ggplot2 permite crear este tipo de gráficos de forma muy sencilla. Pero, además, con este package se puede crear casi con la misma facilidad una cuadrícula de gráficos de barras teniendo en cuenta varias dimensiones al mismo tiempo. De este modo, podemos comparar el valor de una métrica entre distintas categorías de una o varias dimensiones.

Por ejemplo, imaginemos que queremos analizar la conversión de nuestros productos; en este caso, podríamos analizar la métrica buy-to-detail rate. Si, además, aprovechando el enhanced ecommerce estamos recogiendo dos categorizaciones distintas mediante la Categoría de producto, nos podría interesar estudiar las diferencias de conversión de los productos en función de sus categorías. En este caso, con ggplot2 nos podríamos un gráfico como el siguiente:

ggplot1.2

Con una sencilla línea de código:

ggplot(df, aes(x=productName, y=buyToDetailRate, fill=productName)) + geom_bar(stat=”identity”) + facet_grid(productCategoryLevel1~productCategoryLevel2)

Veamos con más detalle cada componente:

  • ggplot(df, aes(x=productName, y=buyToDetailRate, fill=productName)):

df es el nombre del data frame de R en el que hemos guardado nuestros datos al hacer la consulta a la API de Google Analytics (tranquilos si no tenéis muy claro de lo que hablo, las tablas se guardan como data.frame por defecto al hacer una consulta a la API desde R). Es decir, df es la tabla con los datos que queremos visualizar. En este caso, es una tabla con 4 columnas: productName, productCategoryLevel1, productCategoryLevel2, buyToDetailRate.

En aes indicaremos el papel de cada variable en nuestro gráfico. En este ejemplo, como eje X utilizaremos el nombre del producto, como eje Y el buy-to-detail rate y, finalmente, “rellenaremos” (en inglés, fill) con un color diferente para cada nombre de producto.

  • geom_bar(stat=”identity”):

Indicamos que queremos un gráfico de barras (geom_bar) en el que la altura de las barras sea el valor de la variable Y en los datos (stat=“identity”). Para que la altura de la barra sea el número total de casos de cada grupo, no se tiene que asignar ninguna variable a y en aes y usar stat=“bin”.

  • facet_grid(productCategoryLevel1~productCategoryLevel2):

Las variables que cruzaremos en la cuadrícula. En este caso, cada categoría de productCategoryLevel1 será una fila distinta (A1, A2, A3), y cada categoría de productCategoryLevel2 será una columna distinta (B1, B2). Esta opción no es exclusiva de los gráficos de barras, de modo que también se puede utilizar con otros tipos de gráficos.

  1. Gráficos de áreas

Otro gráfico muy interesante que se puede crear fácilmente con ggplot es un gráfico de áreas, con el que por ejemplo podemos evaluar unas proporciones a lo largo del tiempo. De esta manera, se puede observar cómo ha evolucionado cada categoría asociada a una dimensión a lo largo de un periodo o, incluso, evaluar de forma visual si alguna acción que se emprendió ha tenido el efecto esperado o no.

Por ejemplo, supongamos que se decidió dar el paso a web responsive porque se observó que, al no estar la web optimizada para móviles y tablets, estos dispositivos no estaban convirtiendo como se esperaba que podrían. En una situación como ésta, podríamos crear un gráfico en el que se viera la evolución de la proporción de transacciones hechas desde cada tipo de dispositivo (desktop, mobile, tablet) en un periodo de tiempo que incluyera el lanzamiento de la web responsive. Con ggplot es muy sencillo:

ggplot2.2

ggplot(df, aes(x=date, y=transactions, fill=deviceCategory)) + geom_area(colour=”black”, position=”fill”, size=.2, alpha=.4)

*donde previamente se han convertido las fechas a números del 1 hasta el número de días totales.

  • ggplot(df, aes(x=date, y=transactions, fill=deviceCategory)):

df es el nombre del data frame de R en el que hemos guardado nuestros datos al hacer la consulta a la API de Google Analytics. En este caso, es una tabla con 3 columnas: date (convertida a número), deviceCategory, transactions.

En aes indicaremos el papel de cada variable en nuestro gráfico. En este ejemplo, como eje X utilizaremos la fecha, como eje Y el número de transacciones y, finalmente, “rellenaremos” con un color diferente cada tipo de dispositivo.

  • geom_area(colour=”black”, position=”fill”, size=.2, alpha=.4):

Indicamos que queremos un gráfico de áreas (geom_area) y añadimos algunos parámetros para que acabe luciendo como en la imagen (son opcionales). Importante destacar que el parámetro position=“fill” es el que permite visualizar las proporciones sin tener en cuenta el valor absoluto.

En el caso en que no se incluyera position=“fill”, es decir, utilizaramos geom_area(colour=”black”, size=.2, alpha=.4) , obtendríamos el gráfico:

ggplot3.2

ggplot(df, aes(x=date, y=transactions, fill=deviceCategory)) + geom_area(colour=”black”, size=.2, alpha=.4)

En el cual se ven las proporciones en valores absolutos, lo cual dificulta el análisis de las proporciones pero nos da información sobre el contexto, que también es importante. Por ejemplo, combinando estos dos gráficos vemos que el hecho de que esté disminuyendo la proporción de transacciones hechas con desktop desde el día 13 del periodo (primer gráfico) no ha sido debido a una disminución en el número de transacciones de desktop (segundo gráfico). De hecho, en este segundo gráfico podemos comprobar que el cambio a web responsive no afectó a las transacciones de desktop, cuya curva se mantiene estable, sino que aumentaron el número de transacciones hechas desde tablets y móviles (como esperábamos al hacer el cambio), aumentando su contribución al volumen total de transacciones.

  1. Boxplots

En doctormetrics también hablamos hace tiempo de la importancia de tener en cuenta la variabilidad de las métricas al hacer un análisis.

Una de las herramientas más interesantes para visualizar la variabilidad de las métricas es un gráfico que se conoce como boxplot o diagrama de caja. Este tipo de gráfico nos permite entender cómo se distribuye una métrica mediante su mínimo, su máximo y sus cuartiles.

Por ejemplo, supongamos que tenemos un negocio estacional, es decir, nuestros usuarios se comportan de forma muy distinta según la época del año. En este caso, si analizamos el número de transacciones que se producen cada mes, es evidente que encontraremos que en algunos meses se produce un volumen de transacciones mucho mayor que en otros. ¿Pero eso significa que en todos los días de un mes con un mayor volumen de transacciones se producen más transacciones que en los de un mes con un total de transacciones total menor? La respuesta normalmente será que no, y la manera de visualizarlo de forma efectiva es utilizando un boxplot. Con este tipo de gráfico, tendremos una visión mucho más completa de la influencia del mes a nuestro volumen de transacciones.

ggplot4.2

ggplot(df, aes(x=factor(month),y=transactions)) + geom_boxplot()

  • ggplot(df, aes(x=factor(month),y=transactions)):

df es el nombre del data frame de R en el que tenemos que guardar nuestros datos al hacer la consulta a la API de Google Analytics. En este caso, es una tabla con 3 columnas: date (para conseguir variabilidad, cada día será una observación), month, transactions.

En aes indicaremos el papel de cada variable en nuestro gráfico. En este ejemplo, como eje X utilizaremos el mes y como eje Y el número de transacciones.

  • geom_boxplot():

Indicamos que queremos crear un boxplot.

  1. Gráficos de puntos / líneas

Finalmente, el último tipo de gráfico del que vamos a hablar es el más que conocido gráfico de líneas. Como no podía ser de otra manera, este tipo de gráficos también se pueden crear con ggplot2.

Además, podemos aprovechar la flexibilidad de R para hacer operaciones sobre las métricas que queramos analizar. Es decir, podemos representar gráficamente métricas calculadas con la misma facilidad que una métrica predefinida. Así, por ejemplo, podríamos visualizar los ingresos de nuestro ecommerce después de descontarle las devoluciones ya que, como muchos sabréis, en Google Analytics se recogen en métricas distintas.

ggplot9.2

ggplot(df, aes(x=factor(date), y=transactionRevenue-refundAmount, group=1)) + geom_line() + geom_point() + theme(axis.text.x = element_text(angle = 35, hjust = 1))

  • ggplot(df, aes(x=factor(date), y=transactionRevenue-refundAmount, group=1)):

df es una tabla con 3 columnas: date, transactionRevenue, refundAmount.

En aes indicaremos el papel de cada variable en nuestro gráfico. En este ejemplo, como eje X utilizaremos la fecha (convertida a factor) y como eje Y la métrica calculada ingresos menos devoluciones. Por último, el parámetro group=1 nos permitirá poder crear la línea que unirá los puntos (sino obtendremos un error y solo podremos crear los puntos).

  • geom_line():

Indicamos que queremos crear un gráfico de líneas.

  • geom_point():

Añadimos puntos al gráfico de líneas.

  • theme(axis.text.x = element_text(angle = 35, hjust = 1)):

Opcional. Modifica el aspecto del texto del eje X para que se puedan leer las fechas correctamente.

 

Esto sólo son cuatro ejemplos muy sencillos de gráficos, pero que sepáis que ggplot2 nos permite modificar casi todo el layout de sus gráficos: cambiar los colores, añadir y personalizar títulos y leyendas, hacer cambios sobre los ejes, etc. Aun así, espero que los ejemplos del post os hayan servido para familiarizaros un poco con la forma en la que se crean mediante ggplot2 y que a partir de aquí os animéis a crear los vuestros. Como siempre, si tenéis alguna duda relacionada con el post o no conseguís crear el gráfico que necesitáis, podéis dejar vuestro comentario y os intentaré ayudar en la medida de lo posible. Hasta la próxima! :)

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