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

Categorías
comercio electrónico Dimensiones Personalizadas Doctor Analytics Doctor Conversión enhanced ecommerce. ecommerce producto

Analiza tus productos con todo lujo de detalle

https://m4p.es/analiza-tus-productos-con-todo-lujo-de-detalle/ Analiza tus productos con todo lujo de detalle 2016-03-29 09:06:25 admin Blog post comercio electrónico Dimensiones Personalizadas Doctor Analytics Doctor Conversión enhanced ecommerce. ecommerce producto accont

  Google Analytics, y especialmente con el comercio electrónico mejorado que ya os ayudamos a saber implementar,  nos permite medir el desempeño de los productos o servicios individuales que ofrecemos en nuestra web. En los informes estándar, podremos analizar cuánto hemos vendido de cada uno de ellos, por ejemplo. Y con el comercio electrónico mejorado, incluso el porcentaje de veces que un producto visto fue añadido al carrito o comprado.     Pero en muchas ocasiones, los análisis los haremos agrupando dichos productos en categorías u otra clase de agrupaciones con algo en común. Podemos segmentar o filtrar en base a la información que recogemos de los productos: Nombre Identificador Precio (usando como criterio que estén en una franja u otra, por ejemplo) Marca Categoría (en el comercio electrónico, la categoría puede estar compuesta de hasta 5 niveles). Variante (colores, tallas, etc.) Cantidad Cupón (para cuantificar la influencia de ofrecer o no descuentos) Pero, ¿y si esta información se nos quedara corta? ¿Y si nuestro producto es muy complejo y está definido por una gran cantidad de variables por las que podría interesarnos analizar su desempeño? Imaginemos que nuestro negocio es una inmobiliaria, y nuestra transacción, la solicitud de visita […]

The post Analiza tus productos con todo lujo de detalle appeared first on Blog de Analítica Web, Optimización y Conversión – Doctor Metrics.


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

Analiza tus productos con todo lujo de detalle

Categorías
Analítica Web Google Tag Manager

Tips for working with Custom HTML & Custom JavaScript tags in Google Tag Manager

https://m4p.es/tips-for-working-with-custom-html-custom-javascript-tags-in-google-tag-manager/ Tips for working with Custom HTML & Custom JavaScript tags in Google Tag Manager 2016-03-21 19:19:40 admin Blog post Analítica Web Google Tag Manager accont

This time I’m writting down some tips for when you guys are playing around with the custom HTML tags or custom JavaScript variables not only for Google Tag Manager, but for any other TMS or website.

Most times due the projects deadlines or maybe just lazyness, the code we use (I include myself here), is not fail proof, and we need to think that we may broke some page functionality or even some page load. So using customHTML/custom JavaScript is a serious thing. Even a lot of companies are forbidden to use them in Google Tag Manager.

  1. Don’t use lazy/generic variable names

    As you all know (right) all the scripts share the same window object. So if you declare a variable

    myVariable = "myValue";

    you will then be able to get that variable value from the main window object

    console.log(window.myVariable)

    and this means that if we using some variable like “counter”, and another script uses it, it’s going to be overrided. D’oh, our loop just became a neverending loop (indeed, that’s not good).

  2. Always use “var” for declaring your variables if you are not planning to use them as a global data

    Usually you may think that declaring a variable inside a function will make it just available inside that function, but that’s not right, if you declare a variable without using “var”, it’s gonna became a global variable, if you want to try it, create a new tag an put this code on it:

    <script>
        (function(){ 
           myVariable = "myValuetest";
        })();
    </script>

    Now if you go to your console you will notice that windows.myVariable is there. Even if it was inside anonymous function, it became a global variable.

    This is the right way to do it:

    <script>
        (function(){ 
           var myVariable = "myValuetest";
        })();
    </script>
  3. Always check for the variable value before doing something with it

    Usually being a lazy programmer will lead to problems, I know that it takes a lot of time to get everything checked as it should, and our code may be working for us in our tests, but we need to think that there will be thousands of users, with different browsers, browser versions, internet connections (some things may load slow, or not even load) , pluggins installed, and that’s why we need to perform the checks in the right way, we’re interacting with a client-side tracking, so we just CAN’T cover all the possible situations.

    Take this simple screenshot as an example:

    Let’s see how should we had code the previous snippet:

    Instead of printing an error, we could have send an error event, in order to track on which pages that errors is happening, for which browsers, or at which time 🙂

  4. Be careful with the loops, always set a break in the case the condition is never met

    We may need to loop around some array, for example, we want to grab all the product SKU for our transactions to pass that data into a marketing pixel. For that we’ll need to loop thru all the ecommerce.purchase.products . but we need to be sure that our loop will end at some point. For the previous example it’s easy, as we’ll easily know when it needs to end (when there’re no mor products in the array).
    But let’s think on another example. We want to wait for some object to be available to fire something, and for that we use a setInterval to check for the variable availability each 100 milliseconds.

    Let’s see some code for this:

    (function(){
    var checkExist = setInterval(function() {
      if(typeof(window.myObject)!="undefined") {
      dataLayer.push({
        "event":"myObject-is-available-notify-gtm-with-a-push"
      });
       clearInterval(checkExist); 
       }
    
      }, 100);
      })();

    Hey, it works, it sets an interval each 100 milliseconds and get our object is already available it clears the interval. We tested it, and it works, we’re so proud of ourselves. But this time we didn’t consider what will happen IF that object NEVER gets available… yep, you’re right that code will be running forever, and depending on the code that it’s ran inside it, it may kill the user’s browser.

    If using loops in Variable you may need to take in mind that variables are being ran several times (not just once), so the problem is going to be even bigger.

    In this case we could have an incremental counter, so we could exit the interval execution, after 20 tries (20×100 = 2seconds).

      (function(){
      var counter = 0;
      var checkExist = setInterval(function() {
            if(counter > 20)
                clearInterval(checkExist); 
    
      if(typeof(window.myObject)!="undefined") {
        dataLayer.push({
          "event":"myObject-is-available-notify-gtm-with-a-push"
        });
      clearInterval(checkExist); 
      }
      counter++; 
        }, 100);
    })();

    So always think on a way for our loops to end in the case the condition is never met.

Categorías
Analítica Web Enlaces programacion

10 cosas brutales que puedes hacer con Google Tag Manager – User Web Analytics & eShow BCN 2016

https://m4p.es/10-cosas-brutales-que-puedes-hacer-con-google-tag-manager-user-web-analytics-eshow-bcn-2016/ 10 cosas brutales que puedes hacer con Google Tag Manager – User Web Analytics & eShow BCN 2016 2016-03-21 09:27:31 admin Blog post Analítica Web Enlaces programacion accont

El jueves pasado, tras la charla dentro del clinic SEO vivimos un día completo de charlas de analítica: «User Web Analytics: Analítica y más allá». Hubo un poco de todo, Aplicaciones y validaciones de datos con Google analytics, R, Big data, automatización de informes, etc. Yo por una vez me centré en Google Tag Manager. Una herramienta que usamos continualmente en nuestro día a día y a la que aun no le había dedicado nunca una charla.

Al final la charla resulto en distintas aplicaciones que podemos conseguir a la que vamos rascando en la herramienta. Entre ellas explique la forma de crear un repositorio que nos permite importar pequeños añadidos uno a uno en 2 o 3 clicks lo que me permitió durante el resto de la charla ofrecer links de descarga de muchas de las aplicaciones que se comentaron.

Aqui os dejo la presentación, llena de trucos y consejos, espero que a muchos algunos os sean de utilidad.


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

10 cosas brutales que puedes hacer con Google Tag Manager – User Web Analytics & eShow BCN 2016

Categorías
Enlaces SEO

Saca partido a Screaming Frog – Sin indexación no hay SEO – Clinic SEO & eShow BCN 2016

https://m4p.es/saca-partido-a-screaming-frog-sin-indexacion-no-hay-seo-clinic-seo-eshow-bcn-2016/ Saca partido a Screaming Frog – Sin indexación no hay SEO – Clinic SEO & eShow BCN 2016 2016-03-21 09:18:25 admin Blog post Enlaces SEO accont

La semana se celebró una vez más el eShow de barcelona. Un evento que a mi me gusta especialmente por las actividades paralelas que desarrolla en su interior. En particular el miércoles se celebra un día completo de Clinic SEO y el Jueves otro tanto con el User Web Analytics. En esta ocasión me toco dar un charla en ambos. En el Clinic el día se centró en herramientas y yo abordé la indexación desde la famosa Screaming Frog.

Vimos sus vitudes y como aprovecharnos de sus rastreos en 4 situaciones distintas:

  • Auditoría Técnica
  • Auditoría OnPage
  • Estructura y Crawl Budget
  • Y migraciones y control de cambios en la web

La charla creo que fue bastante bien, juzgalo tu mismo con los slides que te dejo a continuación:

También puedes leer el post resumen que hizo Fernando Macia en el blog de Human Level.

Screaming Frog – Iñaki Huerta en eShow Barcelona 2016

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

Saca partido a Screaming Frog – Sin indexación no hay SEO – Clinic SEO & eShow BCN 2016

Categorías
analytics 360 suite Doctor Analytics Doctor Conversión Doctor Intelligence Doctor Optimizer google analytics suite 360

Google Analytics 360 Suite hoy su gran lanzamiento

https://m4p.es/google-analytics-360-suite-hoy-su-gran-lanzamiento/ Google Analytics 360 Suite hoy su gran lanzamiento 2016-03-15 18:28:13 admin Blog post analytics 360 suite Doctor Analytics Doctor Conversión Doctor Intelligence Doctor Optimizer google analytics suite 360 accont

Os adjunto la carta que Paul Muret, responsable  y creador de Google Analytics, nos ha enviado para presentarnos la evolución de la herramienta en su Suite 360. Hola, Hoy estoy encantado de compartir la próxima evolución de Google Analytics: Google Analytics 360 suite. Una revolución en el marketing está en marcha – las empresas se enfrentan a una explosión de nuevos dispositivos, canales, audiencias fragmentadas y compra programática – que lleva a un aumento exponencial en el volumen de datos. Con un creciente número de señales a monitorizar, es más difícil que nunca manejar todo, encontrar información útil, y convertir esas ideas en acción. Es por eso que hemos construido el Analytics 360 Suite. Un sistema que integra sus datos con herramientas de marketing análisis, diseñadas específicamente para cubrir las necesidades de responsables del marketing o análisis dentro de una empresa y ayudarles a: Visibilidad completa de la conducta del consumidor. Los responsables de marketing necesitan la visión completa de los datos de forma inmediata para ver lo que está sucediendo con sus usuarios en todos los puntos de contacto, canales y dispositivos. Comprender el contexto completo del viaje de un usuario en lugar de medir solamente una sesión, un […]

The post Google Analytics 360 Suite hoy su gran lanzamiento appeared first on Blog de Analítica Web, Optimización y Conversión – Doctor Metrics.


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

Google Analytics 360 Suite hoy su gran lanzamiento

Categorías
Doctor Analytics Redes Sociales

Analítica en redes sociales para cumplir objetivos

https://m4p.es/analitica-en-redes-sociales-para-cumplir-objetivos/ Analítica en redes sociales para cumplir objetivos 2016-03-01 15:11:33 admin Blog post Doctor Analytics Redes Sociales accont

Al margen de la escucha activa, la monitorización y el sentimiento del que hablamos recientemente, como analistas del social media también debemos prestar una exquisita atención a las métricas que ofrecen las redes sociales de nuestros clientes (y las de la competencia), pues es el único modo de comprobar si la marca está cumpliendo con sus expectativas. Y ese es precisamente el camino que hay que seguir: definir objetivos, medirlos, analizarlos, actuar en consecuencia para mejorarlos y vuelta a empezar para transformar los resultados. Así una y otra vez. Toda empresa con presencia en redes sociales debería tener una estrategia y un cuadro de mando con los indicadores que determinen su estado de salud. De no ser así, si no hay ninguna finalidad explícita ni intención de dar valor a la comunidad y crecer con ella, conviene no estar. Mejorar la relación con los usuarios y consumidores no es una tarea sencilla, y el único modo para conseguirlo es medir. Medir, medir y después seguir midiendo. Creemos que no se nos ha olvidado citar la importancia de medir. No nos importa repetir: hay que medir el trabajo de los gestores online de las marcas para identificar sus carencias (para superarlas) […]

The post Analítica en redes sociales para cumplir objetivos appeared first on Blog de Analítica Web, Optimización y Conversión – Doctor Metrics.


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

Analítica en redes sociales para cumplir objetivos