De casualidad, mirando los cohortes de analytics me encuentro con una nueva versión de la API de GA que lleva ya unas cuantas semanas con nosotros y que supone una pequeña revolución en cuanto al acceso a datos del que vamos a disponer a partir de ahora. Y me diréis: «¿Nueva versión? ¿Pero eso supone cambiar todos códigos de acceso que usamos ahora?», – Si, ¡claro que si! «¿Que pereza, no?». Pues no se decirte, pero seguro que te dará mucha menos pereza cuando veas el potencial de lo nuevo que nos llega: Nuevos accesos a la información, formas de trabajar las dimensiones y métricas, nuevas vías de filtrado de los datos y sobretodo mucho precálculo de los datos que ahora realiza Google antes de darnos los datos.

Una vez más nos encontramos con que Google Analytics ha conseguido resolver de forma simple procesos por los que hasta ahora teníamos que crear sistemas de proceso alternativos. A nosotros mismos en IKAUE nos desmonta un poco la base del sistema de dashboarding interno que tenemos dado que una de las ventajas que nos daba era precisamente la posibildidad de precalcular datos en una sola consulta. Ahora parece que esta GA API V4 va a hacer eso por nosotros. ¡Bienvenido sea! Pero hay que reconocer que fastidia un poco tirar parte de ese trabajo que te diferenciaba un poco de la competencia «solo» porque ahora Google se lo ofrece a todo el mundo integrado…

Bueno, lloraremos otro día, ¿vale? Hoy vamos a desgranar esta API…

Una API que supone poder montar dashboards y cuadros de mando serios haciendo solo una consulta por cada gráfico o tabla a incorporar

Google Analytics Reporting API V4

Tenéis ya a vuestra disposición la documentación en el site de desarrolladores de Google donde encontraréis una pequeña introducción, una guía para migrar de la anterior versión V3 el código y distintos ejemplos de solicitudes y códigos con distintos sistemas.

Un simple vistazo ya nos empieza a hablar de las novedades que encontraremos:

• Metric Expressions:

  Ahora se nos permite solicitar el calculo de métricas calculadas en el momento.
  ASí que solicitando como métrica cosas como «ga:pageviews/ga:transactions» tendríamos el numero de páginas vistas necesarias para conseguir una transacción. Esto para el calculo de KPIs es una mejora enorme.

• Multiples rangos de fechas:

  En una sola consulta podremos solicitar datos de varios periodos lo que por fin nos permitirá consultar de forma cómoda aspectos relativos a la evolución del negocio a nuestra medida y sin tener que encadenar una solicitud a otra

• Datos sobre cohortes y tiempo de vida del usuario:

  Nuevas dimensiones y métricas tan apetitosas como el medio, fuente o canal de adquisición del usuario (no solo el de conversión)
  El trabajo con Cohortes forma ahora un capitulo completo de la API al mismo nivel por ejemplo que los segmentos o filtros.

• Segmentos múltiples:

  Como con las fechas ahora podemos ir solicitando varios segmentos a la vez, sacando realmetne los datos como los queremos: ya agrupados y procesados y evitando una vez más encadenar una consulta tras otra
  Con este sistema parece que esta costumbre de solicitar varios segmentos para montar una sola tabla de datos nos dice adios.

Y esto es lo que ellos nos resaltan pero la nueva API trae mucho más… Lo que nos ofrecen es una revisión completa de la forma por la que crear las consultas que ahora contienen muchisimos nuevos parámetros y que ya no se indican de forma desordenada sino con dependencias directas. Por ejemplo yo ya no solo pido una dimensión, sino que sobre esta puedo indicar exactamente como quiero que se extraiga el dato añadiendo más y más detalles a la consulta..

El resultado es un mundo de nuevas opciones y practicamente un paradigma de acceso a Google Analytics distinto. Esto para nosotros supone una gran cantidad de mejoras y posibilidades, casi siempre en la capacidad de preprocesar datos antes de servirnoslos, que pasamos a poder usar en nuestro beneficio. Os enumero ventajas que yo he ido encontrando al repasar la API V4 aunque es seguro que me quedaré corto y con el tiempo surgirán muchas más ventajas:

• Número de filas, máximos y mínimos valores de las métricas
  Vienen ahora de serie en las respuestas que da la API de forma más cómoda para que no tengas que calcularlos.
  También tenemos opciones para omitirlos si no queremos usarlos
• Diferenciación entre filtrados de métricas y dimensiones:
  Lo que nos permite más criterios para hacer los filtrados como listas enumeradas, la sensibilidad a mayúsculas o permitir usar filtros numéricos con dimensiones
  Las opciones para métricas en cambio no sufren muchos cambios
• Creación de agrupaciones de valores de dimensión
  Permitiéndonos transformar por ejemplo valores numéricos de una dimensión en grupos (<10,10-20,20-30,etc...) en la propia respuesta de la API Esta funcionalidad como tantas otras nos permite sacar realmente los datos como nos interesará visualizarlos y no siempre en bruto
• Ordenaciones mucho más potentes
  Como por ejemplo si pedimos dos fechas a la consulta, ordenar por la resta entre los 2 valores consultados, o la capacidad de ordenar numéricamente dimensiones o el criterio SMART muy interesante para KPI’s
  Estas ordenaciones cobran especial sentido cuando lo que queremos es ver solo el TOPxx de datos.
• Un control brutal en la forma de segmentar con muchos segmentos a la vez
  Pudiendo cruzar y anidar casi cualquier casuistica de los datos ahora de forma ordenada y no con signos raros para ámbitos y secuencias.

  Además ahora el conjunto de segmentos se trata como una dimensión más llamada «ga:segments» por lo que realmente se integran con nuestro informe como si tuviésemos dimensiones creadas a medida.

• Definición del ámbito (scope) de las métricas
  Pudiendo pedir métricas en un ámbito superior al que tienen por defecto. Podemos demandar para métricas de hit su valores totales si estas fuesen por ejemplo de ámbito sesión o usuario

  Esto debería posibilitar pedir por ejemplo el ansiado número de sesiones que pasan por una página o número de usuarios deduplicados que pasan por un canal.

• La capacidad de consultar directamente los datos como tabla dinámica (pivot table)
  Lo que otra vez supone una gran ventaja sobre la actual en la que sacábamos todos los datos en bruto solo para poder cruzarlos entre dimensiones.
  Ahora definimos no solo dimensiones y métricas para sacar totales de datos, sino que podemos añadir dimensiones con las que pivotarlas y las metricas con las que van a crear su tabla dinámica.
• Creación de Grupos Cohortes con nombre en las propias consultas:
  Lo que nos permitirá analizar qué sucede con usuarios captados con campañas concretas en el tiempo o crear agrupaciones de fechas de captación para examinar sus efectos a nivel de usuario
  El análisis de cohortes se transforma así en una herramienta muy capaz de analizar el tiempo de vida del usuario según fechas de captación. Y presumiblemente en el futuro según otros criterios aún más interesantes.
• Personalización de nombres de dimensión y métricas
  Ya no nos hace falta transformar los nombres de filas, la api nos los servirá con el nombre que queramos darle a cada dato. Esto que es un añadido tonto cobra su sentido al ver que ahora podemos crear informes finales con la API y por lo tanto para redondearlos igual queremos cambiar los nombres de los datos que sacamos.
  Gracias a los campos «alias» de las metricas y a los nombres de cada segmento esto es posible. Aunque si que es cierto que se echa en falta un campo alias para las dimensiones…
• Las respuestas ahora ya no son tablas planas, sino una estrutura con nombres de dimensiones y metricas desglosadas por rangos de fechas Al pasar a ser todo el sistema con información estructurada el campo de los datos («rows») ya no es una tabla de numeros sin referencias, sino que en cada nodo nos dice el valor de las dimensiones que estamos viendo con un resultado para cada rango de fechas demandado y con todas las métricas calculadas solicitadas.

  El formato de cada fila es algo parecido a esto:

  dimensions : [
    "valor de dimensión o nombre de segmento",
    "valor de dimensión o nombre de segmento",
    ...
  ],
  metrics : [
     // un elemento por cada rango de fechas solicitado
    {
      values : [
        "valor metrica calculada",
        "valor metrica calculada",
        ...
      ]
    }
    // otras fechas
  ]
  

  En definitiva, estas respuestas son mucho más fáciles de tratar para hacer cosas con ellas (aunque se parecen mucho menos a tablas de bases de datos)

• La información de error en una consulta es ahora mucho más descriptiva
  Indicándonos por ejemplo que nos falta definir una propiedad o que dos propiedades definidas en la consulta son incompatibles.
  En definitiva el debug de queries es mucho más claro

Ya solo con esto la API a poco que lo pienses merece la pena pues facilita enormemente las tareas de modelado de los datos ya desde su propia extracción. Siempre nos faltará algo y no nos vamos a librar de encadenar consultas una tras otras pero si parece que estos dashboards y exportaciones de datos que requerían de 500 consultas seguidas poco a poco irán bajándolas a niveles mucho más fáciles de mantener.

Esta API básicamente pasa a procesar directamente antes de devolvernos los datos gran parte de lo que antes teníamos que hacer nosotros tras extraerlos.

Los cambios técnicos resumidos

Hablemos claro. Esta V4 no es un update de la API sino una API totalmetne nueva, así que puedo aseguraros que hay trabajo. Google se suele preocupar bastante por la retrocompatibilidad pero en este caso los cambios en las posibilidades de consulta son tales que nuestras peticiones van a cambiar drásticamente. Aún así si que existe la posibilidad de transformar nuestras consultas actuales (llamemoslas básicas) al nuevo sistema…

Por un lado tenemos cambios menores como a que URL hacer las solicitudes o pequeñas variables que cambiando de valor (por ejemplo en muestreo pasamos de FASTER->DEFAULT->HIGGER_PRECISSION a SMALL->DEFAULT->LARGE ). Estas cosas son fáciles de cambiar y depurar en la mayoría de los casos.

Lo complejo está en que debido a la complejidad que ahora tienen las consultas ya no nos vale con una sola linea de datos sueltos para hacer las consultas. Ahora necesitamos objetos JSON para definir todos los parámetros que consultamos. Es decir, antes hacíamos consultas del tipo…

"ids=ga:12345&start-date=2015-11-01&end-date=2015-11-06&metrics=ga:users,ga:sessions"

Y ahora esto pasa a ser algo asi:

{
  "reportRequests":[
  {
    "viewId":"XXXX",
    "dateRanges":[
      {
        "startDate":"2015-11-01",
        "endDate":"2015-11-06"
      }],
    "metrics":[
      {
        "expression":"ga:users"
      },{
        "expression":"ga:sessions"
      }],
      ...
    }]
}

Esto hace mucho más tediosas las consultas simples pero es justamente este cambio de formato el que permite hacer consultas complejas y con tanta riqueza de definición. Ya solo en el ejemplo veis que las métricas son expresiones y que las fechas son rangos múltiples. Lo mismo nos encontraremos con los segmentos y con gran cantidad de las nuevas opciones que ahora nos dan.

Por suerte la mayor parte de las librerías de acceso con los lenguajes de programación más usados ya están actualizadas y usan esta versión. También tenemos una pequeña guía de migraciónque se queda corta pero es un comienzo.

¿Merece la pena cambiar de versión?

Esto de las versiónes de API siempre es lo mismo. Una nueva versión te dará acceso a una serie de posibilidades que ahora no tienes así que cambiar significa mejorar y en este caso mejorar muchísimo. Otro tema es que no quieras mejorar: «Yo ya tengo mis dashboards no quiero mejoras». Y aqui te encontrarás con que no hay ningún problema: la API V3 sigue funcionando perfectamente. Pero ten en cuenta que cierto día Google Anunciará la fecha en la que deja de dar continuidad a la V3 y luego te tocará correr. Aun falta mucho para eso, pero tenlo en cuenta 😉

¿Quieres probar la API V4 ya mismo?

Todo este potencial no parece algo fácil usar de buenas a primeras, ¿verdad? Esto hay que probarlo y ver en real sobre nuestras cuentas sus posibilidades antes de lanzarnos a incorporarlo a nuestros sistemas. Para eso nada mejor que un explorador de consultas que nos ofrecen junto a su docmunentación. Ahi podremos hacer nuestros pinitos y empezar a ver la bestia de proceso que es ahora la API de nuestro querido Analytics.

Probar la Api v4 de Google Analytics

Mi recomendación: Empieza por consultas sencillas y ve complicandolas poco a poco hasta obtener lo que quiers. Seguidamente una captura de como solicitar el las sesiones de lo que llevamos del mes de abril. Más simple imposible.

Luego ya empezaremos a complicarnos la vida y a sacar partido de las nuevas opciones. La siguiente captura responde a una solicitud en la que directamente pedimos el tráfico no rebotado (sesiones – rebotes) del segmento de búsqueda (organic + cpc) de la web:

Este ultimo ejemplo que os paso es usando las nuevas variables para pivot tables (tablas dinámicas). En este caso solicitamos una tabla que nos despliegue las sesiones en 2 ejes, como filas los medios y como columnas las categorías de dispositivos (desktop/tablet/mobile) creando así una visualización más que digna.

Como veis las solicitudes se complican, pero en realidad son más fáciles de leer que con la api vieja y sobretodo son mucho más prácticas para trabajar con los datos.

¿Y cómo la uso en el sistema de visualización de datos que uso ahora?

¿Usas Excel? ¿Google SpreadSheets? ¿Algún sistema de dashboarding de terceros? Aquí el código te lo hacen otros y es probable que de momento no tengas una vía fácil para acceder, pero tiempo al tiempo, poco a poco irán apareciendo soluciones que acerquen esta nueva API a todos. Lo que si que es cierto es que se me escapa como poder conseguir toda esta versatilidad en un entorno facilón de formularios a base de clics… pero bueno, los genios de la UX están ahí para algo y seguro que nos sorprenden con algo chulo, intuitivo y práctico.

Bueno ¿Y todo esto por qué?

La respuesta está clara: Dashboards y cuadros de mando.

La mayor parte de la gente usa la API de GA para crear cuadros de mando y dashboards con lo que era lógico que de avanzar en la API esta lo hiciese facilitando este camino. Lo que se consigue con esta API es que con solo una consulta tengamos accesible la información necesaria para poder crear un gráfico de datos ya procesados. Todas las nuevas funciones complementan carencias que nos obligaban a ir a programación a medida, hojas de cálculo o complejos sistemas de dashboarding con la API V3.

Ahora, con solo un entorno de gráficas conectado a esta API ya se pueden hacer maravillas. En esta situación resulta imposible no echarle un ojo a la «embed api«, esa api JS que pretendía permitirnos sacar directamente consultas de GA en formato gráfico pero que se quedaba coja la hora de modelar los datos. La misma API ahora cobra otro sentido y puede volverse muy practica.

Por nuestra parte a parte de revisar nuestra herramienta interna de dashboards tendríamos que revisar esa solución más simple que liberamos hace unos meses: Bootboard, un cruce entre Bootstrap y la propia Embed API para hacer más potente a esta al tiempo que se simplificaba la carga técnica los desarrollos. Sin duda con esta API se puede hacer mucho más con mucho menos esfuerzo y merece la pena pensar pensar en un bootboard 2.

Que todo esto es genial me parece más que evidente. La duda que personalmente me surge sobre todo esto es qué va a pasar con la interfaz de Google Analytics que todos conocemos. Siempre ha sido un poco más potente consultar con la API que con la interfaz web pero con esta API V4 el cambio en el potencial es radicalmente distinto. Esto no puede quedarse así, el mismo salto cualitativo deberíamos ver como se produce poco a poco en la interfaz que todos conocemos… Hay cosas que de cierta forma ya están usando: ya hacemos 2 consultas de tiempo a la vez y las comparamos, ya consultamos hasta 4 segmentos a la vez, etc… pero con esta API está claro que se puede ir más allá… ¿con qué nos sorprenderán?