Categorías
Analítica Web

10 conceptos clave con los que dominar cualquier negocio – SEonthebeach 2016

https://m4p.es/10-conceptos-clave-con-los-que-dominar-cualquier-negocio-seonthebeach-2016/ 10 conceptos clave con los que dominar cualquier negocio – SEonthebeach 2016 2016-06-27 05:51:22 admin Blog post Analítica Web accont

Buenas, este será un post bastante breve. Acabamos de volver del evento más divertido y cachondo del año, el SEonthebeach. Organizado por Sico de Andrés, este congreso elimina la parte formal y nos lleva directamente a la playa en la manga del mar menor para disfrutar de 2 días de ponencias en camiseta y bañador. Acabo de volver y solo quería dejaros aquí mi presentación.

En esta ocasión hable de aspectos básicos de la analítica web. 10 conceptos que deberíamos asimilar para centrar nuestros análisis y resolver los problemas que realmente tienen nuestras webs. Abordamos desde la propia definición de objetivos de negocio y de medición, hasta distintas formas por las que segmentar o extraer los datos. Una presentación de 115 slides (alguno eliminado antes de subir a slideshare) que en teoría tenía que darse en 40 minutos pero que en la práctica fue inevitable pasar los 50…

No me enredo más, os dejo seguidamente la presentación para que tanto los que vinistéis como los que no podáis ojearla o descargarla.


Source: http://feeds.feedburner.com/ikhuerta

10 conceptos clave con los que dominar cualquier negocio – SEonthebeach 2016

Categorías
análisis del usuario Analítica Web

Analisis de desviación de los datos de sesión ¿Necesito analizar a nivel de usuario?

https://m4p.es/analisis-de-desviacion-de-los-datos-de-sesion-necesito-analizar-a-nivel-de-usuario/ Analisis de desviación de los datos de sesión ¿Necesito analizar a nivel de usuario? 2016-06-14 10:41:00 admin Blog post análisis del usuario Analítica Web accont

Empezamos con el primer post de la serie dedicada a metodologías de análisis del usuario. Empezamos por el principio y en este caso nuestro objetivo será el de responder a un pregunta simple: ¿Merece la pena que realice en mis negocios este tipo de análisis? ¿realmente no me basta con los informes que ya tengo? La respuesta a esta pregunta como siempre es: «Depende», hay muchos negocios y generalizar en analítica es pecado, tabú, estúpido y además está mal.

Lo que vamos a hacer es decribir una metodología sencilla con la que realizar un primer acercamiento a los datos de una web para decidir si tiene sentido o no sentido que nos preocupemos de la parte de los datos que perdemos por analizar a la vieja usanza (a nivel de sesiones). Para ello miraremos varios detalles sobre nuestros datos y conversiones y estimaremos una desviación de la credibildiad de los datos de sesión. Con ella será con la que decidamos que hacer.

En el complejo mundo del usuario solos los frikis quieren meterse

Partamos de una realidad: a nadie le gusta trabajar por que si. Te sientes muy tonto cuando terminas un análisis al detalle cuyas conclusiones no te aportan absolutamente nada que no supieses. Por ese motivo conviene perder un poco de tiempo garantizando que no vamos a perder muchísimo más. Al final probar cosas nuevas mola -al menos a los analistas nos suele molar- y es altamente recomendable hacer un ejercicio de análisis de este tipo solo para interiorizar y saber lo que te puede ofrecer, pero lo dicho, cuando no va a aportarnos nada debemos saberlo de antemano.

Así que vamos a ver una serie de indicadores que nos hablarán de la necesidad real que tiene nuestro negocio de trabajar en este mundo de usuarios. Si vemos que estos indicadores no son favorables tenemos que asumirlo y olvidarnos del análisis de usuarios en nuestro negocio.

Entendiendo la métrica de usuario en Google Analytics

Un detalle que tenemos que entender es cómo se hace el calculo de la métrica de usarios en GA (y en muchos otros sistemas). Estamos acostumbrados a que todas nuestras métricas y mediciones sean absolutas y por lo tanto nos sorprendemos cuando nos encontramos una métrica que dependiendo de cómo la consultemos pueda tener un valor u otro… y este es justo el caso de los usuarios.

¿Por qué pueden variar su valor?

Básicamente porque es una métrica que se calcula en función del periodo de tiempo que seleccionemos. Imaginemos el siguiente caso:

  • Un usuario realiza una sesión el día 1 del mes.
  • Realiza una segunda sesión el día 3.
  • Y una tercera sesión el día 6 en la cual compra.

Tenemos muy claro que se trata de 3 sesiones y una conversión. Pero, ¿cuantos usuarios son? La lógica nos dice que se trata de un solo usuario pero como os decía analítics nos lo presentará según las fechas que le consultemos. ALgunos ejemplos:

  • Si le pido a GA, cuantos usuarios hay desde el día 1 hasta el 6 del mes me dirá que solo hay 1. Genial.
  • Si le pido cuantos había del 1 al 3. Me dirá que también hay solo 1, lo cual tambiés es cierto, pero se trata ahora de un usuario con solo 2 sesiones en vez de tres.
  • Ahora si le pido cuantos usuarios hubo del dia 1 al 5 y cuantos del 6 al 10 para sumarlos, me dirá que hay 1 con 2 sesiones del 1 al 5. Y 1 con 1 sesión del 6 al 10. Cuando yo lo sume veré que son 2 usuarios lo cual no es cierto… Aqui mucha gente comete errores al sacar datos parciales y sumarlos.
  • También si le pido los datos por una dimensión basada en fechas me devolverá por ese criterio cada. Dato. Es decir, si le pido a analytics que me diga los usuarios por día. Me dirá:
    >> Día 1: 1
    >> Día 2: 0
    >> Día 3: 1
    >> Día 4: 0
    >> Día 5: 0
    >> Día 6: 1
    >> Día 7: 0
    >> Total usuarios: 1

Es raro, ¿verdad? Pero es que es cierto, tenemos 1 usuario para esos días pero el total de usuarios suma 1 :)

En consecuencia cuando yo veo gráficas de evolución por días o por semanas en Analytics los datos no coincidirán con los totales que veo al unificar usuarios que aparecen en varios días por separado. y a mayor diferencia entre el tamaño de los grupos de fechas mayor será esta diferencia.

Aqui os dejo una captura donde vemos que el total de usuarios en una consulta de 5 días no coincide con la suma de los usuarios por día:
diferencias-usuarios-por-dia

Por este tipo de pecularidades es preferible trabajar con fechas amplias cuando hablemos de usuarios, pues cuanto menor sea el rango de fechas seleccionados más usuarios parciales estaremos cogiendo.

Primer indicador: Sesiones por usuario

El es el indicador más fácil al que podemos acceder y surge de la simple división entre sesiones y usuarios. Una métrica que nos dirá cuantas sesiones provocan de media los usuarios en nuestro site.

Para muchos la forma más sencilla de acceder a este indicador será ir Google Analytics a sus informes de Público >> Visión general y realizar la división a mano.

Es un cálculo bastante directo y sencillo al alcance de todo el mundo.

Sin embargo hay que saber que en realidad esta es una métrica nativa de Google Analytics llamada «Sesiones por usuario» y por lo tanto podemos usarla en nuestros informes personalizados:

metrica-sesiones-por-usaurio

Esto tiene varias ventajas, a parte de evitarnos hacer una división a mano, claro. Principalmente disponer esta métrica nos aporta dos ventajas:

    1. Nos permite ver cómodamente la evolución de la misma en el tiempo con las típicas gráficas de evolución de GA.
    1. Permite poder cruzarla con distintas dimensiones de analítytics para empezar a intuir como es la revisita según distintos criterios: Países, dispositivos, Canales de captación, etc.

informe-metricas-por-usuario
(nótese que el problema que decíamos que existía con los usuarios al separar por días sigue aquí vigente y por ejemplo en esta captura si miramos la gráfica por días vemos que el valor e sesiones/usurio/dia se mantiene de forma estable en unas 1,3 sesiones)

¿Y para que quiero yo saber este dato?

Las sesiones por usuario nos indican cuantas sesiones hacen los usuarios pero también que ratio de información incompleta tengo en un análisis por sesiones. Por lo general sabemos que el análisis a nivel de usuario en métricas globales de sesiones/usuario que queden por debajo del 1,2 es probable que no mezcan la pena. Estamos hablando de negocios en los que la reincidencia de un usuario es muy baja y casi todas las métricas se conforman a nivel de sesión.

Por encima de estos valores ya entramos en la zona interpretable, valores más altos suponen una desviación mayor en el análisis de sesiones y los más bajos una desviación menor. Así un ratio de de 2,00 sesiones/usuario nos indicaría que la mitad de los datos de conversión y funnels no son del todo correctos, pues esos usuarios que nos aparecen en cierto paso del embudo de conversión en realidad tuvieron otra visita en la que siguieron evolucionando. Nos queda claro, pero es quizas un poco abstracto. Asi que esto nos lleva a nuestro segundo indicador.

Segundo indicador: Desviación directa de los informes de sesión

En base al anterior indicador vamos a crear otro un poco más descriptivo. Decíamos que a mayor número de sesiones por usuario más «incorrectos» son nuestros datos a nivel de sesión. Vamos por lo tanto a calcular el ratio de desviación de la realidad que sufren nuestros informes generales, al menos para conocerlo.

Este ratio tiene que decirnos en que porcentaje la información que vemos puede no ser del todo correcta. Sería algo parecido al muestreo, estadisticamente podemos trabajar sabiendo que esta desviación existe y sacar conclusiones pero no podemos obviar que esta desviación existe y que a niveles muy altos puede hacernos tomar conclusiones erróneas.

Este cálculo es tan simple como

  • ( (sesiones – usuarios) / sesiones ) x 100

Y no, no es una métrica que nos ofrezca analytics de forma nativa. pero si que podríamso si quisiésemos crearla con las métricas calculadas.

Por ejemplo. Tenemos 200 sesiones y 100 usuarios. Esto nos da 2,00 sesiones por usuario y una desviación de los informes de sesión de un 50%…

( (sesiones - usuarios) / sesiones ) x 100
= ( ( 200 - 100 ) / 200 ) x 100
= ( 100 / 200 ) x 100
= 0,5 x 100
= 50 %

Así que en este caso podemos decir que la desviación de nuestros informes es del 50%, es un caso exagerado que permite trabajar a nivel de sesión pero solo si nuestro volumen de visitas es grande y no vamos a sacar informes muy granulares.

¿Existe una desviación de los datos de sesión normal?

Realmente no existe, depende de demasiados factores como el tipo de producto, el precio y los métodos de pago, el tipo de campañas que hagamos, la notoriedad y reputación de la marca, etc. Como extremos puedo hablaros de que las webs de captación de registros (leads) en base a landings suelen estar por de un 20% o incluso 5% de desviación, mientras que webs de productos caros y complejos como pueden ser paquetes vacacionales o excursiones pueden incluso pasar ese 50% del que hablábamos antes prácticamente obligádnote a trabajar a nivel de usuario.

Tercer indicador: tamaño del proceso de decisión del usuario

Y cambiamos de tercio totalmetne de tercio para irnos a los informes de embudos multicanal y centrarnos ahora un poco en nuestras conversiones. Estos informes son de los pocos informes de Google Analytics que se orientan totalmetne al usuario. En ellos podemos ver como los datos de procedencia de las visitas (normalemnte canales de captación) se van sucediendo para terminar consiguiendo las conversiones.

No vamos a abordar aqui todos los informes de este tipo, para eso tenemos otro post dedicado al análisis de conversiones multicanal. Recordemos que solo estamos intentando evaluar la necesidad real que tenemos de hacer análisis a nivel de usuario.

Lo primero al usar estos informes es seleccionar las conversiones que queremos observar. Por defecto (y por desgracia) en estos informes se autoseleccionan todos los objetivos de GA + conversiones de ecommerce + objetivos de dobleclick (si los tenemos integrados con GAP). Esto no nos conviene porque mezclamos churras con merinas y terminamos no viendo nada. Lo suyo es empezar seleccionado el macroobjetivo principal de nuestro negocio para más adelante, si queremos, analizar la conversión de otros objetivos.

MCF-seleccionar-conversion

Una vez tenemos seleccionada la conversión a seguir, es el momento de evaluar la longitud del proceso de decisión del usuario, es decir, cuan largo es este proceso.

Para ello tenemos dos posibles visiones:

1) Medirla en días desde la primera visita.
2) O en Sesiones totales necesarias para convertir.

tamaño-proceso-decisión

Medir en días es quizás más cercano a nuestra realidad. Nos va a ser más facil comunicar que el usuario se toma de media 2 semanas para decidir reservar un apartamento que hablar a alguien no muy metido en el online de sesiones.

Por otro lado, para mi al menos, tiene más sentido hablar de sesiones si las entendemos como distintas aproximaciones que hace el usuario a la web antes de decidirse. Y es que podemos encontrarnos con procesos rapidos pero complejos en los que un usuario visita una oferta 4 veces en solo 2 días y por el contrario procesos de maduración muy lenta pero con poca consulta en los que un usuario necesite varias semanas para decidirse pero apenas acceda 2 o 3 veces a la web en ese tiempo. Son circunstancias distintas asi que en realidad no podemos obviar ninguno de los dos valores (al menos en una primera aproximación).

Aqui nos contraremos con el problema de que los datos vienen muy desglosados, por numero de días o de sesiones (según el informe que miremos) y eso lo dispersa mucho. Así que tenemos que saber que queremos mirar:

Lo primero: porcentaje de conversiones directas.

Es decir, en el día 0 o la sesión 1. este el mejor indicador que tendremos de que porcentaje de nuestros ratios de conversión y funnels a nivel de sesión son exactos. Si tenemos por ejemplo solo un 20% de conversiones en primera sesión, significa que en nuestros funnels solo el 20% de los datos son lo que creemos, el resto de ratios estan llenos de visitas previas que hacen bajar los porcentajes de conversión.

Aquí consideraremos los datos por encima del 50% como entornos donde el análisis de conversión a nivel de sesión sigue teniendo sentido y por debajo del 20% como conversiones con un mix de sesiones demasiado arriesgado como para creernos nuestros funnels.

Una vez hemos hecho este ejercicio con nuestra conversión principal podemos cambiando la selección de conversión analizada ocuparnos de ver cada uno de los objetivos que tenemos configurados. Si hemos sido listos y hemos dado de alta cada uno de los pasos de nuestro embudo como objetivos podremos ver para cada paso en que porcentaje se alcanza este en primera visita.

Otro dato interesante: la mediana del tamaño del proceso de decisión

Es decir, del total de conversiones ordenadas por su distancia cual es la distancia de la conversión que se encuentra en el punto medio.

Esto podemos hacerlo llevando estos datos a excel, o calculandolo a mano, que no es tan dificil. Para hacerlo a mano necesitamos encontrar el punto medio, que será el total de conversiones/2.

En el gráfico que indicabamos antes:
tamaño-proceso-decisión

Tenemos un total de 643 conversiones, asi que la mediana se encuentra en la conversión 322.

Recorremos los datos de menor a mayor hasta encontrarla.

643 conversiones / 2 = 332 conversiones
332 - 235 en primera sesión = 97
97 - 145 en segunda sesión = -48

Asi que la mediana está en 2 sesiones para convertir

Esta mediana es otra referencia que nos dice por lo general cuantas conversiones suelen hacer falta para convertir.

Una vez tenemos esta mediana para nuestro macroobjetivo tambien podemos sacarla para otros objeitvos que tengamos viendo para cada paso del embudo de conversión cuanto hace falta para alcanzarlo.

Y por ultimo, agrupaciones por distancias

Por ultimo si queremos dar una visión más completa podemos dividir porcentajes de conversión por distancias de conversion (en tiempo o sesiones) pero en ese caso es preferible que hagamos nuestros propias agrupaciones.

A mi personalmente me funciona bastante bien crear grupos que con un tamaño que crece exponencialmetne, entendiendo que a mayor distancia de conversión en realidad también las diferencias están mas dialtadas. Asi por lo tanto los grupos de conversiones según sesiones con un sistema así serían:

  • Conversión en 1 visita
  • En 2-3 visitas
  • En 4-7 visitas
  • En 8-15 visitas
    etc…

Con este tipo de datos podemos segmentar un poco mejor los distintos tipos de procesos decisión a sabiendas de que no hay solo un patrón para tomar decisiones.

Conclusiones

Con estos 3 tipos de indicadores la decisión de si lanzarnos a realizar análisis a nivel de usuario o no se vuelve mucho más sencilla.

Las sesiones por usuario son un primer y rapidísimo indicador sobre la necesidad que tenemos de cambiar nuestra perspectiva. El porcentaje de desviación de los informes de sesión terminarán de hacernos comprender la gravedad del problema que tenemos con los informes que estamos consumiendo al tiempo que nos permitirá explicar de forma comprensible que tenemos controlado hasta que punto podemos fiarnos de nuestros datos. Por ultimo un análisis del tamaño del proceso de decisión nos permitirá llevar esta problemática al terreno que más nos interesa: cómo afectan estas desviaciones a mi conversión y por qué. Este último punto será el que nos permita terminar de dibujar nuestro escenario.

¿qué decisión debo tomar? Ahí está nuestro trabajo, saber transmitir si tenemos o no un problema por realizar análisis orientados a sesión. A partir de aquí lo que hay que sopesar es: «cuanto me cuesta resolver la situación» vs «cuanto me afecta no hacerlo» y tomar una decisión.

En el caso de que los datos te lleven a meterte en el mundo del usuario, bienvenido seas. Esta serie de posts es para ti, te invito a seguir leyendo estos distintos capítulos para ir viendo como resolver cada problema:




Source: http://feeds.feedburner.com/ikhuerta

Analisis de desviación de los datos de sesión ¿Necesito analizar a nivel de usuario?

Categorías
análisis del usuario Analítica Web Google Analytics

Metodologías de Análisis del usuario

https://m4p.es/metodologias-de-analisis-del-usuario/ Metodologías de Análisis del usuario 2016-06-14 06:16:47 admin Blog post análisis del usuario Analítica Web Google Analytics accont

Llega el verano y a la gente le aumentan las ganas de leer… O eso se dice, quizás se refiera a novelas y demás literatura para evadirse, pero por si acaso he pensado en prepara una serie post de los chulos para explicaros algunas cosas en las que estamos trabajando actualmente.

En esta serie de posts hablaremos del análisis a nivel de usuario. Es decir, acercándonos lo máximo posible a las personas reales y no quedándonos solo en páginas o sesiones sueltas. Un paso difícil de dar, no vamos a negarlo, pero que hace más reales todas las conclusiones que obtenemos de la analítica.

Todo lo que ya se ha hablado y de lo que se está hablando

Sobre esto y sobre el famoso customer journey veréis mucha información por la red, la mayoría en inglés aunque con grandes artículos también en castellano. El análisis del usuario esta de moda lo que provoca que haya mucha gente hablando de este tipo de enfoque últimamente. Pero creo que tenemos un problema, y según voy viendo es que todo el mundo habla de lo mismo:

  • Por un lado se nos presenta el concepto de customer journey, que es genial y difícil de rebatir, pero la mayoría simplemente lo describe conceptualmente lo cual sirve en la práctica para poco. Al fin y al cabo no nos dedicamos a realizar mapas mentales de los usuarios para poder dar charlas de psicología sino que lo que buscamos es que los negocios mejoren sus resultados.
  • Por otro lado tenemos el tan de moda análisis multicanal: Modelos de atribución, secuencias de campañas, etc. Aquí hay mucha chicha pero que solo podemos aprovechar en entornos de marketing pues no se nos habla de la web en si, sino de que tan solo tocamos la adquisición del tráfico cruzada con las conversiones; a nivel de usuario, eso sí. Es una información genial, pero solo con eso no podemos decir que conozcamos a nuestros usuarios

Siempre parece que nos falten piezas para resolver este puzle. Por un lado sabemos que nuestros análisis a nivel de sesión (visitas, rebotes, funnels, etc.) no son todo lo realistas que cabria esperar, por otro tampoco sabemos como llevar esta riqueza de datos al mundo de los usuarios; al menos con Google Analytics.

Este es el motivo de esta serie de post que vais a ir viendo publicados: Vamos a ver que posibilidades tenemos para hacer este tipo de análisis. Para ello usaremos mucha información y conceptos propios. Es decir, lo que os voy a contar es cosecha propia y difícilmente podréis verlo en algún libro, es el resultado de buscar como resolver distintos problemas que nos hemos ido encontrando en entornos donde sabemos que la orientación a usuario es vital para entender los datos.

El Customer Journey y los problemas del análisis cuantitativo del usuario

Partamos de la base. Sabemos que los usuarios son en realdiad personas y que la mayoría de nosotros necesitamos varios inputs para tomar una sola decisión. En definitiva, no llego a una web por una publicidad, veo un producto y lo compro siguiendo un estricto funnel de compra. Antes de la compra viene la decisión de compra y antes de esta viene una evaluación mental que todos hacemos de los productos y servicios que se nos ofrecen. De esta indiscutible verdad nace el concepto del «customer journey» que nos explica con distintas teorías cómo el usuario va avanzando en su proceso de decisión por distintos estados mentales hasta la compra. Es decir, nos explica el «viaje del cliente».

Entre las distintas formulaciones que nos han hecho los grandes gurús del marketing en la práctica cada uno hace su mix. Hay muchas perspectivas y no te puedes casar con todas. Nosotros trabajamos con un esquema como el que sigue, donde intentamos mezclar las partes de funnel de decisión de compra, con el concepto de lealtad del usuario y con los estadios del usuario heredados del inbound marketing.

Es un esquema. Pero hay otros. De cara a lo que vamos a hablar en este post no tiene mucha importancia, solo lo incluyo para ilustrar que podéis encontrar muchas metodologías para abordar el customer journey.

El problema de este esquema que os planteo (y de tantos otros) es que es que es imposible de medir completamente pues tenemos una gran cantidad de áreas desinformadas (en la fase de conciencia ni siquiera conocemos al usuario y en la de evaluación los inputs externos se escapan de nuestro control). Además aunque consiguiésemos estimar todos los valores posibles nos encontraríamos con tal cantidad de datos cruzados que sería imposible ver nada en ellos. A fin de cuentas estos esquemas son modelos conceptuales que no necesariamente van destinados a poder realizar analítica cuantitativa sobre ellos sino a sentar las bases de lo que estamos estudiando.

La solución

Al final lo que necesitamos es una metodología (o varias) que nos arrojen datos cuantitativos y sencillos de entender a la vez. Y es que los seres humanos, las personas, somos limitados. Muy limitados. No podemos intentar mirar a Matrix y entender lo que sucede, necesitamos que la información se transforme en algo comprensible para nosotros. Esto no es cierto siempre, todos conocemos a maquinas mentales que se se miran una cuadricula de 60×60 filas y son capaces de darte conclusiones al instante. Pero lo común es que esto no sea así y lo cierto es que tan importante es disponer de los datos como que cualquier persona involucrada en un proceso de decisión los entienda. Ahi, en la búsqueda de este modelo, es donde todos llevamos años dándole vueltas a «cómo representar los datos que tenemos sobre el customer journey para poder entenderlos y sacar conclusiones de ellos». Y esto no es fácil… parece casi imposible… siempre falla algo…

Tras darme contra un muro varias veces, el camino que por mi parte he tomado es el de desistir en este intento. Ya esta bien. Es el momento de aceptar nuestras limitaciones y abordar estos problemas de otra forma más sencilla, más plausible. Buscamos sencillez, encontrémosla simplificando el problema: trabajemos por focos.

¿qué es esto de los focos? pues no es otra cosa que NO intentar crear un modelo que lo contenga todo, sino distintos modelos parciales en los que cada uno resuelva una parte vital de la información (un foco) que nos interesa. Así pues nos podemos permitir simplificar la información y obviar agujeros en la misma y sacar los insights que nos interesan uno a uno. El truco está por lo tanto en describir y desarrollar los focos que realmente nos importan del usuario, sabiendo que controlándolos todos el mundo del usuario pasará a estar un poco más a nuestros alcance.

Así que el trabajo que hemos realizado a sido el de detectar y proponer soluciones para esos focos, siempre con la visión puesta en el usuario. Y así, poco a poco hemos resuelto distintos de ellos que os vamos a ir presentando. Los focos que de momento tenemos identificados son los siguientes:

  • La desviación sesión/usuario:
    Que nos tiene que indicar lo importante que es para nuestro negocio hacer análisis a nivel de usuario. Vital sobretodo para no perder el tiempo con estas historias si no va a aportarnos nada que no sepamos ya.
  • Análisis del funnel de touchpoints:
    Análisis de Funnels pero llevados al mundo de los usuarios y por lo tanto con implicaciones distintas en la definición de pasos y en las métricas a observar de estos
  • Evolución de las preferencias de uso de los usuarios:
    Inputs sobre cómo afecta lo que aprende el usuario de nuestra web al uso que hace de la misma
  • Objetivos de avance en el customer journey:
    Que nos tienen que permitir cuantificar el éxito en las primeras visitas del usuario al site, para saber si estas van iniciar un proceso de decisión o un descarte directo
  • Análisis de la fidelización:
    Cómo son las revisitas y las recompras al site. Cómo obtener KPIs de fidelización
  • y por supuesto, el análisis de conversiones multicanal:
    Que nos tiene que ayudar a gestionar desde marketing el customer journey hacia la compra

Como véis es muchisima información la que queremos identificar, por ese motivo este es solo un post de presentación. A lo que haremos en los siguientes posts es tratar cada uno de estos focos con Google analytics y dar ejemplos de uso comunes.

Seguidamente añado la lista con sus respectivos links que iremos completando en las siguientes semanas, espero que el tema os parezca interesante.



Nos vemos las próximas semanas aquí mismo.

Source: http://feeds.feedburner.com/ikhuerta

Metodologías de Análisis del usuario

Categorías
Analítica Web Google Analytics

GAUPET Release: Google Analytics User Permissions Explorer Tool

https://m4p.es/gaupet-release-google-analytics-user-permissions-explorer-tool/ GAUPET Release: Google Analytics User Permissions Explorer Tool 2016-06-07 17:11:05 admin Blog post Analítica Web Google Analytics accont

Some months ago I asked some friends to test a new tool I was working on and past week I released something close to an open alpha, today after pulling some details, a new UI redesign 100% mobile compatible. I’m announcing the GAUPET release.

At first I named it as GA Governance Tool, but after some interesting chat with the “osom” Yehoshua Coren . I(we)’ve decided to change the tool’s name to something that it’s closer to what it is and here is it: GAUPET , which stands for Google Analytics User Permissions Explorer Tool. (yep, you’re right I didn’t rack my brain on this one)

You can find It the the following link : GAUPET

This will allow you to easily manage and pivot all your Google Analytics users and permissions in order to have a clear view of your current accounts User Governance status.

GAUPET will allow you to gather all your account user emails and permissions and draw them into an interactive pivot table. Even will allow you to merge different accounts users within the same report (thanks goes to Peter O’neill for this and another nice suggestions that will come in a future).

The tool comes with some predefined reports, but you will be able to pivot any data in the way you need. Just drag and drop the fields that’s it!.

The included fields are:

  • Email Address
  • Email Domain
  • Access Level
  • Account ID
  • Account Name
  • Account Access Rights
  • Account Permissions
  • Property ID
  • Property Name
  • Property Access Rights
  • Property Permissions
  • View ID
  • View Name
  • View Access Rights
  • View PermissionsLet’s take a look to a sample the report for user’s with view access:

    I’m offering this tool for free, and I’m hosting it for free, and this means that it’s offered “as it is”. Still you’ll have a feedback section on the page to report bugs, or ask for new features and I’ll try to make updates in my free time.

    Extra thanks fly to Damion Brown , Ani Lopez , Simo Ahava , Natzir Turrado , Doug Hall and Brian Clifton for their comments and testing. #tip Each of them worth a follow 🙂

Categorías
Analítica Web Google Analytics Google Tag Manager

#Tip – How to quickly debug/qa data attributes

https://m4p.es/tip-how-to-quickly-debugqa-data-attributes/ #Tip – How to quickly debug/qa data attributes 2016-06-02 16:45:23 admin Blog post Analítica Web Google Analytics Google Tag Manager accont

With the years I learned that using CSS selectors to track user actions is really great but sadly I learned too that it’s really dangerous too.

It’s true that we won’t need to ask the IT team to add some dataLayer or ga pushes into the page, and therefore saving a lot of precious time, but in the other side, any single page update or testing will break our tracking.

Now I try to use data attributes whereas is possible, since those are more likely going to be kept for layout updates.

Checking elements for data attributes can be a tedious task, so I’m going to show you a little piece of code that I hope will make your life easier if you based some of your implementations on data attributes.

On this little snippet is where the magic happens:

(function() {
    
    var elements = [].slice.call(document.querySelectorAll('*')).filter(function(el) {
        if (typeof (el.dataset) != "undefined")
            return Object.keys(el.dataset).length != 0;
    });
    
    var data = [];
    var i = elements.length;
    
    while (i--) {
        var el = JSON.parse(JSON.stringify(elements[i].dataset));
        data.push(el);
        el["_element_type"] = elements[i].nodeName;
    }
    console.table(data);

})();

As an example I’m going to show you the output for Google Tag Manager‘s Homepage.

This has been a great time saver for me. Hope you find it useful too 🙂

Categorías
adobe analytics Analítica Web crm Web Analytics

Analítica web 3.0: Integración del mundo Online y Offline

https://m4p.es/analitica-web-3-0-integracion-del-mundo-online-y-offline/ Analítica web 3.0: Integración del mundo Online y Offline 2016-05-31 10:01:37 admin Blog post adobe analytics Analítica Web crm Web Analytics accont

Se lee en 1 minuto

A día de hoy, son muchas empresas, de diferentes sectores, que la visita de la web ejecuta la transacción vía offline a través de un call- center.

Esto provoca, que perdemos visión de la visita/transacción, por consiguiente, puede causar que al definir una estrategia digital con los datos que nos aporta una herramienta de analítica web, no sean del todo completos y erremos en nuestra estrategia.

Entonces, ¿cómo organizamos todo esto?

POST-IMAGEN
Fuente: Blog Sphenia

En este caso, voy hablar de cómo vincular el mundo online y offline con Adobe Analytics, que es la solución que aplico para solucionar este tipo de problema.

Para poder integrar estos dos mundos, puedes hacerlo de dos maneras:

  1. Integrando a través de los Data Connectors la información de tu CRM, en tu herramienta de analítica web.

  2. Disponer de un CRM y a través de SAS, vincular el ID de usuario de tu herramienta de analítica web y tu CRM.

En este post, voy optar por escribir de la segunda solución. A través de esta, voy a sacar la información de las transacciones tanto online como offline, vinculando cada transacción a las diferentes visitas que entran en tu site por un ID de usuario único.

¿Cómo?

Para ello, lo primero que debemos hacer, es una implementación personalizada en Adobe Analytics, con eventos serializados, vinculados a un ID de usuario. Dicho ID, se puede recoger o bien por pantalla si lo muestra, o también a través de un Data Layer en el cual este definida dicha variable.

Por último, distinguir que este evento puedes definirlo en varios puntos del site, pero los más comunes son:

1º En la pantalla de contratación del producto o servicio.

2º En la primera pantalla del flujo de contratación del producto o servicio.

Desde mi punto de vista, esta última opción es más acertada que la primera.

Una vez tenemos el evento asociado al ID, debemos validar que el ID sea el mismo en ambas plataformas, Adobe Analytics y CRM. En el momento que está vinculado el ID en ambas plataformas, yo utilizo SAS para extraer la información de aquellos ID que han completado la transacción vía call center.

A partir de aquí, y con la información total de la visita, puedo hacer análisis más concretos y provocará que los análisis para nuevas estrategias digitales, sean mucho más certeros.

¿Y tú? ¿cómo te has enfrentado a este tipo de problemas? Cuéntanos las soluciones aplicadas para este tipo de proyectos.


Source: http://www.analiticaweb.es/feed/

Analítica web 3.0: Integración del mundo Online y Offline

Categorías
Analítica Web Google Analytics Universal Analytics

Universal Analytics Plugin Online Hackathon – Dual tracking

https://m4p.es/universal-analytics-plugin-online-hackathon-dual-tracking/ Universal Analytics Plugin Online Hackathon – Dual tracking 2016-04-28 19:59:33 admin Blog post Analítica Web Google Analytics Universal Analytics accont

I’ve been thinking about doing a Google Analytics related hackaton for a long time. Some months ago, I started to take a look about how Universal Analytics Plugins work and I decided that coding a plugin to all the data to a secondary property using just a plugin would be a real nice example.

For years now, I’ve sharing a lot of code that I’ve worked on, some tracking ideas too, but still I don’t consider myself a developer, if i must say it, I really think that I really suck at programming even if I can do some stuff myself.

So here I am trying to organize an online Universal Analytics Hackaton. I hope this can turn on a great change to learn from other people, and understand how plugins work!!!

Of course you may be asking what’s a “Hackathon” (don’t be shy about asking). Let’s quote the Wikipedia:

A hackathon (also known as a hack day, hackfest or codefest) is an event in which computer programmers and others involved in software development and hardware development, including graphic designers, interface designers and project managers, collaborate intensively on software projects. Occasionally, there is a hardware component as well. Hackathons typically last between a day and a week. Some hackathons are intended simply for educational or social purposes, although in many cases the goal is to create usable software. Hackathons tend to have a specific focus, which can include the programming language used, the operating system, an application, an API, or the subject and the demographic group of the programmers. In other cases, there is no restriction on the type of software being created.

GitHub Repository:

https://github.com/thyngster/universal-analytics-dual-tracking-plugin

For now I’ve pushed to the repository  with some “core” code, that “already” works.

How to load the plugin:

ga('create', 'UA-286304-123', 'auto');
ga('require', 'dualtracking', 'http://www.yourdomain.com/js/dualtracking.js', {
    property: 'UA-123123123213-11',
    debug: true,
    transport: 'image'
});
ga('dualtracking:doDualTracking');
ga('send', 'pageview');

Some stuff you need to take in mind when loading a plugin in Google Analytics:

  • The plugin needs to be hosted within your domain
  • It needs to be “initialized” AFTER the “create” method call and BEFORE the “pageview” method.
  • If for some reason the plugin crashes it may affect your data collection, please don’t use this in production before it has been fully tested.

Still it needs to be improved, for example:

  1. We don’t want to use global variables
  2. Payload size check, and based on the results send a POST or GET request
  3. Add XHR transport method
  4. Code cleanup/Best practises
  5. Plugin option to send a local copy for the hits
  6. Better debug messages
  7. Name convention improvement
  8. Any other idea?

Anyone is welcome to push code, add ideas, give testing feedback, through the Github repository or the comments on this blog post.

 

 

 

 

Categorías
Analítica Web api de google analytics

¿Aun no la conoces? ¡La nueva API de Google analytics (V4) es una auténtica pasada!

https://m4p.es/aun-no-la-conoces-la-nueva-api-de-google-analytics-v4-es-una-autentica-pasada/ ¿Aun no la conoces? ¡La nueva API de Google analytics (V4) es una auténtica pasada! 2016-04-27 09:07:03 admin Blog post Analítica Web api de google analytics accont

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.

Google Analytics - API V4

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.

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:

API V4 - con segmentos

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.

API V4 - con tablas dinamicas

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?

Source: http://feeds.feedburner.com/ikhuerta

¿Aun no la conoces? ¡La nueva API de Google analytics (V4) es una auténtica pasada!

Categorías
Analítica Web Google Tag Manager Universal Analytics

Keep your dataLayer integrity safe using Custom JavaScripts in Google Tag Manager

https://m4p.es/keep-your-datalayer-integrity-safe-using-custom-javascripts-in-google-tag-manager/ Keep your dataLayer integrity safe using Custom JavaScripts in Google Tag Manager 2016-04-04 20:19:10 admin Blog post Analítica Web Google Tag Manager Universal Analytics accont

In JavaScript when you want to copy an object into another variable is not an easy as doing var myVar = myObjectVar; and you should be really careful when working with your dataLayer info in your customHtml Tags and your Custom Javascript Variables.

Let’s try to explain this is the best way I can. When  you’re doing that you’re not copying the current object data to a new variable but instead you’re pointing your new variable to the object one.

What does this mean?, that if that you change a value into your new variable that change will be reflected in the original one. Let’s see an example:

var OriginalData = {'a': 1, 'b':2};
var CopiedData = OriginalData;

CopiedData.a = "MEC!";

console.log("Old 'a' Value: ", OriginalData.a);

Before trying it in your browser console, could you please think what will be “mydata.a” value printed into the console?. If you’re thinking on a “1” value I’m sorry to say that you’re wrong:

 

You may be thinking, why “OriginalData.a” has changed if we only modified the value for our “CopiedData” object.

In programming you we can pass the data in 2 ways:

Call-by-value: This means that the data from the original variable will be copied/cloned into the new variable. 

Call-by-reference or Pass-by-reference: This means that the data on the new variable will be a pointer/reference to the original varialbe one. So if we want to print CopiedData.a , instead of returning a value, it will go to get the value to OriginalData.a (where CopiedData.a POINTS TO) .

How the data is passed in the different programming language is specific to each language, but let’s take a look on how JavaScript does it. Basically any variable type but the object will be called by value. If we do the same example as above, but instead of using an object we use a integer, we’ll be getting a different behaviour.

var OriginalData = 1
var CopiedData = OriginalData;

CopiedData = "MEC!";

console.log("Original Object 'a' Value: ", OriginalData);
console.log("Copied Object 'a' Value: ", CopiedData);

 

As you can see if the variable to be “cloned” is not an object, it will be “passed by value“.

So we need to take in mind that we may be overwriting the original object values. When working with GTM variables, this may equal with updating the original dataLayer values.

There’s not any in-built way to do a deep copy of an object in JavaScript. As we’re mostly refering to data, we could just stringify our object and then parse it again ( never use eval() for converting ).

So when trying to make a copy of some object from the dataLayer (for example when working on a Enhanced Ecommerce implementation and using variables to feed our hits). I would recomend doing it this way:

var ecommerce = JSON.parse(JSON.stringify({{ecommerce}}));

This will only work for objects not including functions/date values/etc. Just plain data. But for now it will keep our dataLayer integrity safe.

Just googleing a bit, you’ll find some functions around to make a full deep copy of an object, but we’re just working with data, so we’re not going to cover that at the moment.

Categorías
Analítica Web big data inteligencia de negocio

Proyectos globales de datos, una aproximación a desarrollos Big Data y Data Warehouse

https://m4p.es/proyectos-globales-de-datos-una-aproximacion-a-desarrollos-big-data-y-data-warehouse/ Proyectos globales de datos, una aproximación a desarrollos Big Data y Data Warehouse 2016-03-30 11:15:06 admin Blog post Analítica Web big data inteligencia de negocio accont

Este post surge de unas conversaciones que estoy manteniendo en las ultimas semanas (¿meses quizas?) con Celia de Frutos, donde estamos persiguiendo justo el objetivo de poner orden en los datos de la empresa y disponer de un sistema versátil y potente a la hora de consultar datos. En una de tantos emails me comentó más a modo de broma que otra cosa «¿Y con esto no escribes un post?». Y la verdad es que tenía razón, ¿por qué no hacer un «pequeño» post sobre el tema?.

En este post voy a intentar dar mi visión particular (fuera de libros y teorías varias, que quede claro) sobre como planificar un proyecto de consolidación y centralización de datos. Un paso que a medida que una empresa se adentra en la analítica digital -dejando la web solo como una parte de la misma- resulta lógico y necesario. El proceso, con muchas particularidades de cada caso, suele tener un fondo común. Estamos en una empresa en la que no existe una cultura del dato, muchos departamentos trabajan de forma separada con sus propias herramientas y dejando muchas veces las decisiones más en el buen saber hacer -llamémoslo también intuición- de los seniors. Cierto día, con una chispa que alguien aporta interna o externamente se produce el despertar. Los datos molan. Dan respuestas claras e inequivocas y ayudan a seguir un rumbo positivo en cada aspecto que tocan.

Es hasta divertido ver como a veces son los detalles más insignificantes los que consiguen crear esta consciencia de que los datos hacen falta: un informe bien trabajado, un test a/b, un presupuesto basado en analitica predictiva, una respuesta que nadie había sabido dar hasta ahora o simplemente una formación interna que no se esperaba que cuajase tanto. Eso no es lo importante, lo importante es ese momento en el que la dirección se da cuenta a todos los niveles de que hacen falta datos para tomar decisiones. Y no estoy diciendo que antes no se usasen datos… todo el mundo observa sus ventas y sus gastos, me refiero a todos los datos que explican el camino por el que los macroobjetivos se han conseguido: todo ese conjunto de detalles que permiten crear lo que en analítica llamamos KPI’s y así extraer Insights que expliquen nuestra realidad de negocio.

La necesidad está ahí… ¡Queremos datos! El problema gordo ya está solucionado. Pero ahora tenemos que acercarnos a la realidad y ahí nos daremos cuenta de la gran cantidad de trabajo que tenemos que hacer para disponer de toda la información que queremos. Nos acabamos de meter de lleno en un proyecto de centralización de datos. Será brutal cuando lo acabemos pero el camino no pinta que vaya a ser ni corto ni sencillo… De primeras hay más incognitas que respuestas…

queremos-datos

Las necesidades de análisis de la empresa

El primer concepto que debemos resolver es tener claro las necesidades de análisis que va a tener la empresa realmente. Esto no es algo que pueda decidirse en una sola reunión de trabajo y menos aun puede hacerlo un analista o consultor en solitario. Conocer estas necesidades implica si o si reunirse con los responsables de cada departamento implicado y comprender las necesidades de información que tienen, absorber todas sus demandas y transformarlas en métricas y segmentaciones de los datos más relevantes. Es un trabajo de abstracción, de transformación de necesidades en demandas de datos.

Con todas estas necesidades en conjunto es con lo que podremos seguir trabajando dando pasos en la planificación del entorno de datos de la empresa. Sin tenerlas controladas, en cambio, es cuando te encuentras con que a mitad de proyecto o incluso con el proyecto terminado aparecen demandas nuevas que no esperabas; los costes se descontrolan y los tiempos se alargan… Ese tipo de cosas que hace peligrar y poner en evidencia cualquier proyecto. Así que por lo poco que cuesta hacer bien este primer trabajo es importante que todos los implicados se lo tomen en serio y sepan que estas reuniones son para facilitarles su trabajo.

Mi recomendación sería que dieseis al menos 34 pasos en este proceso para llevarlo a buen puerto:

  • 1) Identificar a los demandantes de información. A veces jefes, analistas o simplemente profesionales serios e implicados. Quienes deciden con qué datos se trabaja y que necesidades tiene la gente para poder sacar adelante su trabajo.
  • 2) Reuniones con recogida de demandas. Si es necesario con cada persona por separado y apuntando cada caso en documentos distintos. Hay que recoger varias perspectivas sobre el negocio y valorar que datos son vitales y cuales prescindibles.
  • 3) Consolidación de demandas. Es decir la unión de las demandas de todos en un único documento que nos aproxime al modelo de datos que queremos tener disponible. Buscamos simplificar y concretar nuestro mundo de datos en zonas e informaciones claras.
  • 4) Comunicación del esquema consolidado. Es decir, comunicar a esos mismos responsables de forma clara e inequívoca cuales son los datos que vamos a trabajar gracias a ellos.

El ultimo paso creo que es especialmente importante. En proyectos en los que vamos a trabajar mucho tiempo es necesario que existan pactos y compromisos y este tipo de documentos son herramientas ideales tanto para que nos puedan alertar de que vamos a dar pasos en falso como para luego esgrimir el clásico «te lo dije y lo aceptaste» cuando alguien cambie de opinión a mitad de proyecto. Por eso creo que hay que ser especialmente claro con esta comunicación y buscar una aprobación implícita de cada responsable. Técnicas como entender un OK por silencio administrativo no parecen las mejores para estos casos…

Bueno, tenemos nuestro esquema claro. Ahora toca abordarlo…

Planificando nuestro entorno de datos

Aunque situaciones hay miles y realmente hay necesidades que podrán resolverse con las herramientas de las que ya disponemos lo cierto es que debemos pararnos a pensar qué es lo que queremos conseguir y desde ahí planificar qué necesito para hacerlo. Esto nos lleva siempre a un escenario en el que tenemos que dibujar nuestro entorno de datos. ¿De qué datos dispongo? ¿cómo accedo a ellos? ¿Cómo debo tratarlos? ¿Cómo deseo visualizarlos? A todo ese mar de detalles tenemos que ponerle un orden y sobretodo comprendedlo en global para saber por donde atacarlo.

Aquí lo que os propongo es realizar una aproximación dividiendo todo este escenario en 3 zonas diferenciadas de trabajo. Esta división por zonas nos tiene que ayudar a atajar cada tipología de problema de forma más clara.
Las tres zonas de trabajo serían las siguientes:

  • Acceso a Fuentes de datos: El sistema por el que accedemos y recogemos los datos de forma sistemática (y preferiblemente automatizada) para poder disponer de ellos.
  • Almacenamiento y gestión de los datos: La solución por la que optemos para almacenar de forma interna a los datos (el famoso Data Wharehouse) y así trabajarlos como deseemos
  • Visualización los datos: El o los sistemas por los que accedemos a los datos almacenados y terminamos transformándolos en cuadros de mando, dashboards o simples alertas automatizadas

esquema-centralizacion-de-datos

¿Por qué esta separación?

Básicamente porque las soluciones a aplicar y los criterios por los que decidiremos como se conforma nuestro sistema en cada una de las 3 zonas de trabajo es totalmente distinto por lo que cada parte conviene resolverla por separado respondiendo a sus propias preguntas.

En el acceso a fuentes nos encontraremos con problemas como identificación de las mismas, acceso a sus API’s o programación de sistemas de carga de datos. En el almacenamiento tendremos que tomar decisiones sobretodo sobre el soporte a escoger y el formato en el que usarlo. Por ultimo la en consulta de los datos tenemos que a partir del análisis de necesidades de la empresa ver la mejor forma de expresar estos datos para que puedan ser entendidos y accionados por los distintos responsables.

Nuestras fuentes de datos

Saber lo que el mundo de los datos tiene que ofrecernos es esencial. Vivimos en la era de la información y parece que todo este informatizado y medido de una u otra forma pero esto ni es del todo cierto ni la información esta siempre alcance de nuestras manos. Crear un mapa de que información es accesible para nosotros nos ayudará a definir de forma concreta cuales serán nuestras fuentes de datos. Algunas fuentes o datos estarán ahí otras no pero tendremos información accesoria con la que aproximarnos y terminar sacando los mismos insights, otra por desgracia no estará a nuestro alcance.

El siguiente gráfico resume las distintas fuentes básicas de las que deberíamos preocuparnos:

fuentes-datos

  • Las herramientas de analítica: Son información de enorme calidad y si nuestro negocio es una web o una App estaremos de suerte, pues podemos acceder a un mundo de experiencias de usuario de forma bastante cómoda y organizada mediante distintas API’s de datos. Una cuidada selección de KPI’s es práctimente obligada.
  • Las herramientas de marketing: Nos suplen de información sobre la atribución e inversión. Nos ayudan a cerrar el círculo y en el caso del online también resultan muy ricas en datos organizados. También es cierto que no toda la información es necesaria para nuestra integración de datos.
  • El mundo del cliente y el posible CRM: Suele ser el corazón de la empresa y no podemos despreciarlo. Todo lo que sabemos de nuestros clientes debe ser accesible y si no lo es significa que tenemos trabajo que hacer en capturar esos datos
  • Por último tememos información corporativa y de la empresa Que es la que termina de ayudar a dar sentido a los datos y a organizarlos. Aspectos que no forman parte de ninguna herramienta pero que definen la actividad de la empresa, sus departamentos, sus responsables, organigramas, costes y significados. Esta suele ser la información menos accesible de todas, lo que pasa es que como suele ser también la más estable no resulta especialmente complejo tabularla a mano en lugar de importarla como datos electrónicos.

El modelado de datos

Sobre este sistema además tendremos que decidir en qué lugar aplicaremos el modelado de datos. Algo que parece en un principio trivial pero que va a condicionar muchísimo como trabajaremos las distintas zonas de trabajo que definíamos antes.

Llamamos modelado de datos a ese proceso por el cual transformamos los datos brutos que hemos captado de nuestras fuentes en información útil que puede ser consumida y comprendida por los responsables. Es uno de los procesos más típicos del Business Intelligence con sus procesos de ELT o el cada vez más común ETL. Con estos procesos son por ejemplo con los que calculamos cosas como unidades de negocio, departamentos, beneficios, ROI y toda la amalgama de KPIs que hayamos definido.

Este proceso que a priori podría parecer muy simple (a fin de cuentas con exel hacemos operaciones parecidas cada dia en segundos) cuando tenemos que aplicarlo a todo nuestro conjunto de datos uno a uno y disponer de este calculo en segundos (de otra forma nuestros dashboards y cuadros de mando serían infumables) ya no es tan sencillo. Necesitamos de automatizaciones que nos trabajen los datos brutos en el modelo deseado y asi poder trabajar la zona del consumo y visualización de datos sobre el modelo ya trabajado.

Para realizar estos modelos hay distintas tecnologias a nuestro alcance cada una especializada en resolvernos el problema por distintas vías. Algunos ejemplos:

  • El famoso Kettle de la suite de Pentaho es al ser open source quizas la herramienta de BI mas extendida. Nos permite dibujar estas transformaciones de forma grafica a base de clicks dibujando flujos de operaciones sobre los datos y exportando el trabajo a realizar hacia archivos java que podamos usar para crear las automatizaciones. Muy bueno para empezar pero muy limitado para grandes operaciones.
  • Lenguajes como R se orientan muy bien hacia este trabajo ocupandose de crear el modelo o incluso su visualización. Os dejo la presentación que Jose Ramon Cajide hizo en el pasado User Web Analytics sobre este.
  • Python es amado por muchos por ser un lenguaje que trabaja muy rapido con ficheros de texto y procesando grandes volumenes de datos a la vez. Ademas al ser un lenguaje completo que puede orientarse a varios cometidos, no pone limites a que hacer luego con los datos pudiendo así hacer aplicaciones de modelado muy complejas.
  • Otros lenguajes. En realidad cualquier lenguaje de programacion es capaz de hacer este trabajo. Lo que pasa es que algunos se comen demasiados recursos del servidor cuando les pides que trabajen con listados de datos muy grandes. Un ejemplo. Nosotros hemos realizado trabajos de importación y modelado de datos con PHP pero dado que en ese lenguaje trabajar con listados de varios miles de datos ya es pesado al final eso te obliga a ir haciendo cada manipulación por fases distintas y no poder hacer todo el modelado del dato bruto en un unico proceso.
  • Los lenguajes de bases de datos. El mismo SQL es capaz de modelar en parte los datos e incluso muchos sistema de bases de datos tienen su sistema de programacion asociado (por ejemplo PLSQL) que permite hacer manipulaciones mayores. Sin embargo como antes puede ser muy pesado hacer según que operaciones con ellos.
  • Etc. si será por opciones… al final este es un tema tan recurrente que encotnramos cientos de soluciones en el mercado

Lo cierto es que al final qué usar suele depender más del perfil de las personas que trabajan en el entorno de la empresa que de la tecnología idónea o con más posibilidades. Dicho en otras palabras yo no puedo pretender montar un modelado en R si nadie en la empresa va a ser capaz de alterarlo o modificarlo en la empresa o no me caso con un proveedor serio capaz de trabajar en R. Lo mismo para cualquier solución propuesta. Conviene más invertir en aquello que se que puedo controlar.

Decisión 1: ¿dónde debería hacer el modelado de datos?

Y llegamos por fin a la primera gran decisión que tenemos que tomar. En mi esquema de 3 zonas. ¿donde debería realizar el modelado?

No hay respuesta buena a esto y distintos proyectos podrían optar por distintos puntos siendo todos ellos correctos. Lo que si puedo explicaros es que implicaciones puede tener hacer el modelado en distintos puntos del esquema.

1. Modelado en la carga de fuentes. El proceso ETL

ETL

Esto implica que el mismo proceso que se encarga de ir a recoger el dato a la fuente es el encargado también de modelar los datos para que ya sean guardados en un esquema fácil de consumir. Es lo que en BI se conoce como ETL (Extraction->Transform->Load)

Implicaciones: De primeras esto supone que la construcción de las cargas de datos de las fuentes se compliquen. Ya no solo tengo que conectarme a una API (por ejemplo analytics, Twitter, etc.) o base de datos (CRM, base de datos interna, etc.) Sino que además tengo que procesar lo que saque de ahí para que los datos sean casi los que quisieramos ver en un cuadro de mandos. Luego esos datos son los que llevo a mi sistema de almacenamiento de datos (alias datawarehouse) para que en este sistema ya tenga directamente el modelo bien clarito.

Ventajas de este sistema: La ventaja es que acumulo la parte de inteligencia de negocio en el acceso a los datos provocando que solo la zona de carga de datos sea compleja. Esto en algunos sistemas con una explotación no tan al detalle de los datos es una ventaja pues reduce sensiblemente los costes del proyecto. Así sólo necesito un equipo de trabajo o un proveedor que me cree las automatizaciones de la carga y modelado de fuentes, a partir de ahí los datos ya están disponibles de una forma que cualquiera del equipo interno de IT o cualquier software de visualización de datos va a poder aprovechar sin demasiadas operaciones.

Problemas de este sistema El problema surge precisamente por esa acumulación de la complejidad en un único punto. Las cargas de datos son realmente potentes pero precisamente por eso cuando alteramos el modelo de datos se vuelve más costoso. Por un lado tengo que revisar mi proceso de carga incluso cuando no necesito datos nuevos y solo quiero procesarlos de otra forma (cambio en el modelo) pero peor aun es que como el dato bruto no lo he guardado sino que solo he almacenado el dato modelado un cambio en el modelo supone siempre rehacer todos mis datos almacenados. Es decir, si llevo un año almacenando datos en un modelo y lo cambio, tendre que volver a generar todo ese año de datos de nuevo.

¿Cúando usarlo? Como decia, es ideal cuando no quiero asumir internamente demasiados procesos y que se genere el proyecto con un coste comedido. Pero más aun es interesante cuando se que mi modelo de datos no va a sufrir demasiadas variaciones en el futuro. Cuando las bases de analisis están suficientemente asentadas y la gente que cosume los datos es suficientemente seria como para no generar una continua recarga de los datos modelados.

2. Modelado en el almacenamiento de datos. El proceso ELT

ELT

Esta es la forma más común en entornos Big Data que son capaces de procesar ingentes cantidades de datos en sus sistemas en tiempos ridículos. Pero también es un sistema más que posible fuera de estos entornos. La base es sencilla. Mi almacen de datos se va a ocupar de mantener dos copias de los datos: por un lado cargará los datos brutos desde las fuentes sin ningún procesado (lo que supone muchos más datos a guardar) y por otro un proceso interno automatizado hará replica de esos datos en la versión modelada (o incluso en algunos sistemas, el modelo será directamente el proceso que calcula los datos desde los brutos en cada petición realizada). En BI hablaríamos de procesos ELT (Extraction->Load->Transform)

Implicaciones: Ni que decir que el sistema crece mucho en complejidad y recursos. Estamos hablando de montar un almacen de datos brutal con todas sus fuentes de datos ahí metidas (WATs, herramientas de marketing, bases de datos de la empresa, etc.) y además queremos autoprocesar esos datos para disponer de ellos ya modelados. Es decir, estamos montando una bestia de proceso. Pero eso sí, una bestia capaz de darnos lo mejor de todos los mundos.

Ventajas Las ventajas son más que evidentes. El entorno es capaz de almacenar todas las fuentes al detalle con lo que evitamos recargas de datos históricos, al mismo tiempo el proceso se automatiza lo que implica que cambiar de modelo es solo cambiar detalles de ese proceso desde el dato bruto al modelado y el automatismo hará el resto. Por ultimo las herramientas de visualización siguen disfrutando del dato modelado y por lo tanto fácil de acceder para todos.

Desventajas Montar estos sistemas suele ser mucho más costoso tanto en recursos (económicos y de personal técnico) como en tiempo. Hablamos de proyectos que se pueden ir a más de uno o dos trimestres si las cosas no están muy acotadas. Es decir, estamos apostando muy en serio por la centralización de datos.

¿Cuando usarlo? La respuesta corta sería: Cuando vamos en serio. La larga tiene muchas implicaciones, ¿Cuantos recursos puedes destinar? ¿Que rentabilidad esperas sacar del proyecto? y más importante aun, realmente ¿cuanta gente va a hacer un uso real de todo lo que estas montando? Aquí mucho cuidado. No seríais los primeros que van a por todo para descubrir que una vez acabado el proyecto solo 2 o tres personas lo usan y sus informes luego no son tenidos en cuenta por la dirección… Lo dicho, lo de gastar recursos de verdad dejemoslo solo para cuando vayamos muy en serio. Eso si, una vez lo tengamos, seremos muy muy felices.

3. Modelado en la consulta de los datos

Por último y de forma más común de lo que la lógica nos podría llevar a pensar esta la posibilidad de almacenar solo el dato bruto y dejar a la herramienta de consulta de datos que sea ella la que cree el modelo necesario para realizar su visualización. Esto viene a ser que tan solo nos tenemos que preocupar de tener el dato limpio y que relegamos a una herramienta el trabajo duro. Es decir, la antítesis de lo que sería procesar en la carga.

Implicaciones Lo primero que nos ponemos en manos de la herramienta de consulta de los datos y por lo tanto tenemos que conocer como trabaja esta. Por lo general estas herramientas se venden por su capa visual con un alto efecto wow en la decisión de compra. Pero la realidad es que importa mucho más que capacidad de tratamiento de los datos van a hacer. Si por ejemplo esperamos que una herramienta sencilla y barata sea capaz de absorver nuestros datos en bruto y procesarlos en tiempo real vamos listos. Lo que suelen hacer las herramientas que posibilitan el modelado en sus propias tripas es copiar nuestros datos en bruto (una copia de nuestro datawarehouse) y realizar el modelado en otra fase (como en el punto anterior) para así darnos la misma velocidad que si hubiésemos trabajado en ese entorno profesionalizado del que hablábamos antes. Esto es genial, pero otra vez no es barato.

Ventajas Por un lado tenemos la ventaja de desplazar a un punto normalmente externo a la empresa la complejidad de los procesos. Nuestra capa de carga de fuentes y de almacenaimiento puede llegar a ser realmente simple. Por otro lado la variabilidad del modelo final usado ya no es problema, a base de clicks y configuraciones reviso mi modelo cuando lo necesite.

Desventajas Tendríamos como desventaja el duo de precio-funcionalidades que suele ir bastante de la mano. A un bajo precio no podemos pretender que la capacidad de modelado de la herramienta sea muy alta lo que significa que le tendremos que dar los datos ya masticados. Para cuando llegamos a funcionalidades realmente interesantes vemos que hemos pasado sin problemas la franja de los 1000€ al mes de coste. Otra de las desventajas evidentes de este sistema es que si dejas en una herramienta la inteligencia de los datos significa que solo puedes usar esa para ver los datos y no puedes apoyarte en distintas herramientas para ver los datos de distintas formas.

¿Cuando usarlo? Personalmente no me acaba de convencer este sistema porque la capa de visualización es una de las más volátiles y que más flexibilidad debería darnos. Si me caso con una herramienta (que no un proceso propio) cuando esta ya no me sirva o no sea suficiente tiraré todo el trabajo que hice con ella. Aun así, es más que recomendable cuando tenemos muy claro que los datos se van a disfrutar mayoritariamente a través de esa herramienta y esa decisión la llevamos arrastrando desde la primera parte del proyecto (las demandas de los responsables).

Decisión 2: ¿De quien son los datos?

Una decisión que a mi personalmente no me importa nada. Soy confiado, que le vamos a hacer. Si firmo que una empresa no va a mirar mis datos, entiendo que no lo va a hacer…

Sin embargo este es un tema que preocupa a muchas empresas y no hay que olvidar que cuando montamos todo esto no esperamos ver ahi dentro solo datos de analítica sino que vamos cargar dentro datos de costes de campaña, ingresos, beneficios e incluso puede que costes de personal y estructuras. Son datos muy sensibles y ya no solo porque lo diga la LOPD sino porque para según que competencia podrían ser muy apetitosos… y ahi lo dejo, del terreno ideal no hace falta que os explique demasiado.

Asi pues en todo este flujo de la información debo tomar una decisión muy importante sobre quien puede acceder a mis datos y que pasa con ellos. Esto afecta sobretodo al datawarehouse y posibles replicas que se hagan del mismo. ¿Tenemos la necesidad de que la información quede controlada? y de ser así ¿Sabemos exactamente quien accede a cada aspecto de nuestro negocio?

Este tipo de decisiones no aportan nada a cómo debo montar mi estructura pero si limitan nuestras posibilidades. Por daros el ejemplo más evidente. Si me niego a meter mi facturación en servicios externos, olvidémonos de cualquier servicio de Big Data en cloud, sencillamente no podemos hacerlo porque no nos vamos a fiar de ellos. Olvidémonos también entonces de esas herramientas que replican nuestros datos y cubrámonos bien por contrato sobre como acceden a la info a las que les damos acceso. Si tampoco lo tenemos claro así eso implicaría comprar licencias de software instalable, o instalar software opensource en nuestros sistemas o crear nuestro propios sistema de reporting… Ninguna decisión es trivial.

Decisión 3: El soporte usado. ¿Entramos en Big data?

Debemos admitir que el Big Data esta de moda. Quizás demasiado de moda… Pero ¿Qué es Big Data? Como sistema, no es más que un conjunto de tecnologías que posibilitan el procesamiento de datos muy granulados en tiempos record. Solo eso. Por asombroso que nos resulte hasta donde estamos llegando en capacidad de generación y proceso de datos en estos días la realidad es que por si solo el Big Data no aporta ninguna inteligencia ni nos va a dar soluciones directas. Al final se trata de bases datos como las que llevan usandose ya muchos años solo que ahora con una capacidad de trabajo bestial.

Y en realidad la linea que separa que algo sea Big Data o simples bases de datos conceptualmente es muy difusa. Todo el mundo se cuelga la etiqueta de Big Data a veces sin aportar ningún valor especial a sus servicios. Encontraremos quien nos diga que todo lo que no quepa en un excel es Big Data. Segun esa definición una base de datos de 500.000 productos sería big data… También quien nos hable de que Analytics es Big Data, y lo es… pero la parte que nosotros usamos de él yo no la veo como Big data real. Para mi tenemos que hablar de servicios capaces de manejar grandiosas cantidades de información, casi sin limitación. No hablamos de 500.000 productos sino de 500 millones, con todo el histórico de stocks de los últimos 10 años, de compras y de incidencias. También debemos hablar de libertad total de consulta de estos datos. Si los datos ya se guardan procesados y solo puedo consultarlos por una API o sistema limitado no creo que debamos hablar de Big Data. Sin estas ventajas incluso usando bases de datos orientadas a big data, no creo que debamos ponerle ese nombre. Al final la formula es clara:

Big Data = Muchísimos datos al detalle + Proceso en tiempo real de los mismos.

Decíamos que Big Data es solo un sistema con ventajas de almacenamiento y proceso pero no debemos olvidar que el trabajo sobre entornos Big Data en cambio si que tiene ciertas ventajas sobre el trabajo tradicional en bases de datos o archivos sueltos. Y es que a un precio no desorbitado (aunque tampoco barato) podemos disponer del dato granulado y procesarlo en tiempo real. Esto tiene ciertas implicaciones positivas y negativas.

  • El big data fuera de entornos en la nube puede hacerse pero es bastante caro y también caro de escalar: Implica que montes una batería de servidores en tu web y que les instales un software de pago para hacer el trabajo. La capacidad de proceso que te de este Big Data dependerá de cuanto quieras invertir en este sistema base. Por otro lado los entornos en la nube suelen ser más rápidos de preparar y económicos pero como hablábamos en el punto anterior no son posibles si no queremos meter en servidores de otra gente datos sensibles.
  • Big data permite procesar todo o parte del modelado de datos en tiempo real. Eso simplifica mucho las variaciones sobre el modelo y por lo tanto es ideal para soluciones donde el modelado se haga en la zona de almacenamiento de los datos. En estos sistemas si podemos aprovechar las ventajas del big data al llevarnos los datos casi desde la fuente a la visualización en el justo momento que los pedidos.
  • Esto último no sucede siempre. Hay veces que incluso el Big Data será demasiado lento o su proceso no sera suficiente como para hacer el trabajo y tendremos que hablar de modelados del dato incluso dentro de entornos big data. Como siempre depende de lo que pidas (o de lo que los depmandantes te hayan pedido).
  • Big data no aporta muchas ventajas sobre datos ya modelados. Por ese motivo no tiene tanto sentido cuando hablamos de modelados en la fuente (salvo que la cantidad de datos a procesar incluso estando modelados sea descomunal). Ahi bases de datos convencionales pueden hacer el trabajo sin problemas
  • Con todo esto deberías decidir si el Big Data es o no para tu proyecto, asumiendo que cuando una tecnología no es necesaria hay que ser serios y quitarla de la ecuación. Tu proyecto no será peor que otro por no usar big data. Es más seguramente será más eficiente solo por el estudio que has hecho para determinar que a ti no te hacía falta usar Big Data.

    Y por último, decisión 4: El caos de herramientas

    Una vez y solo una vez tengo todo lo demás claro es cuando puedo acercarme a la amplia oferta que se está desarrollando sobre este tipo de trabajos. Y ahi vamos a encontrar de todo. Ciertos productos como pueden ser Google Big Query, Qlick o Tableau pueden destacar (en fama y funcionalidades) por encima de otros pero la realidad es que tenemos que buscar los que mejor se adapten a las necesidades que ya hemos detectado y definido en los pasos anteriores.

    Lo que siempre va a ser un error es empiezar un proyecto de este tipo eligiendo antes que nada la tecnología.

    Esta debe ser una consecuencia, no un requisito. Aun así no son pocos los proyectos que nacen con la premisa «vamos a meter un tableau» o «el objetivo es meterse big data». Sin saber ni si lo necesitas estas condicionando tus necesidades y puedes terminar teniendo suerte pero tambien puedes tirar el dinero a la basura y eso en el mejor de los casos…

    El caso ideal sería pasar por ese escenario del que os hablaba antes:

    – Tengo claros los requisitos
    – Entiendo el modelo de datos que quiero comsumir
    – Conozco mis fuentes de datos y se como implementarlas
    – Defino el sistema de almacenamiento de datos
    – Defino los modos y visualizaciones por los que quiero ver los datos
    – Especifico donde y cómo quiero hacer el modelado de datos
    – Y entonces, elijo las herramientas que me faciliten la carga, almacenamiento, proceso y visualización de los datos en las condificiones que he especificado (o en las mas cercanas, siempre algo se nos atascará)

    El problema de ubicar las herramientas en nuestro esquema

    Para terminar de complicar todo esto me voy a encontrar con que las herramientas no se sitúan casi nunca en una de las 3 zonas de trabajo que definiamos (carga de fuentes, almacenamiento y visualización) sino que todas han cogido lo que creen que es más competitivo para su oferta de servicios y cubren mejor o peor varias necesidades. Por lo general muchas te ofrecen ocuparse del almacenamiento y procesado con algunos extras.

    Algunos comentarios sueltos sobre algunas herramientas. No porque sean las mejores sino por que son las primeras que me vienen a la mente:

    Google Big query: se ocupa del almacenamiento de datos, como herramienta big data es capaz de crear el modelo en tipo real o procesandolo. Ademas integra directamente en Google Analytics Premium los datos (haciendo innecesaria la carga de la fuente). En este caso nos han hecho incluso trampa en Google y resulta que Google Big Query es la única forma rápida de sacar sin muestrear grandes periodos de tiempo (la api nos da su famoso muestreo) de GA. Asi que incluso es posible que uses Big Query no como herramienta Big Data de almacenamiento sino como Fuente de datos. Es raro que uses una herramienta en teoria Big Data como fuente, pero pasa más de lo que podrías pensar. Esto es culpa de Google. Si nos diese un acceso API a Google Analytics sin muestrear para cuentas premium esto no pasaría pero obligandonos a pasar por Big Query si o si desplaza la balanza en su favor. Quiern que nos hagamos preguntas del tipo:; «¿Si total, ya estoy en Big Query? porque no usarlo como data wharehouse».

    Google Data Studio 360: la nueva aplicación dentro de Google 360 Suite parece orientada a conseguir la visualización también desde el propio Google Big Query absorviendo 2 zonas ella sola. No solo eso sino que parece que podrá acceder directamente a fuentes y hacer los modelados de datos por si sola. A ver al final si es verdad…

    Qlik y Tableau: se pueden ocupar cada uno por su lado de almacenar los datos, procesarlos (en la medida de lo posible) y mostrar la representación gráfica. Ambos tienen varias opciones entre las que la diferencia principal radica entre escoger un sofware personal de escritorio, una solución desde tus datos o una versión totalmente cloud con los datos también almacenados por ellos. Pueden usarse por lo tanto solo para visualización o también como datawarehouse vitaminado. Además tiene funcionalidades para hacer visualización directa de las cargas de fuentes (cargas muy sencillas, eso si, no les pidas gran cosa).

    Pentaho: Es una suite muy completa capaz de dar todos los pasos por si sola, pero también al estar dividida en herramientas independientes nos permite usar solo algunas de sus opciones sueltas para carga modelado o visualizacion de datos.

    Las opciones son interminables…

    Conclusión

    Creo que los que nos dedicamos al marketing online muchas veces no somos ajenos al marketing que hacen otras empresas. El Big Data esta de moda y las herramientas que se ponen el sello del big data no para de proliferar pero en muchas ocasiones se pierde la esencia de por qué requerimos de estas herramientas. Al final todo esto del Big Data no es más que una serie de herramientas más y las herramientas sin un motivo fundamental solo nos hacen perder el tiempo. Pensemos y planifiquemos lo que necesitamos y a partir de ahí las herramientas saldrán solas.

    Source: http://feeds.feedburner.com/ikhuerta

    Proyectos globales de datos, una aproximación a desarrollos Big Data y Data Warehouse