Business Intelligence acaba siendo una herramienta para tomar decisiones de negocio rápidas, fiables y que tengan impacto en el rendimiento de nuestra compañía. Tradicionalmente, y por nuestra experiencia, los datos objeto del análisis provienen de procesos de negocio internos: ventas, stocks, logística, producción… Estos datos, seguro, nos permitirán generar información valiosa para la optimización de procesos y toma de decisiones, pero estamos dejando fuera un componente fundamental de la ecuación, si no el más importante: el cliente. Para ello, utilizando Power BI, hemos creado la herramienta definitiva para analizar tus redes sociales: SolidQ Social Analyzer, pero antes vamos a ver qué nos ofrecen las redes sociales para conocer más información de nuestro público objetivo.
En análisis tradicionales, al cliente se le conoce por dos vías: o bien por los datos que voluntariamente otorga al realizar una venta o indirectamente a través de la propia venta. Al final, nos quedamos con una visión centrada en el producto y no en el cliente, de quien no se sabe más una vez paga su compra.
Usually, BI is product focused
Las redes sociales nos ofrecen, en cambio, información sobre nuestros clientes en parámetros “humanos”: satisfacción, interés… Esta información puede servir para generar indicadores de negocio de un valor altísimo. Además, también tiene interés por sí mismo el estudio de la propia información sobre el desempeño de la misma red social: ¿Qué publicaciones resultan más interesantes? ¿Hay algún tipo de publicación que genere cierto rechazo? Por ello, serán de gran utilidad los informes generados por el SolidQ Social Analyzer.
Social Network data analysis allow a customer based strategy
¿Qué información nos ofrecen las API de las redes sociales?
Cada red social ofrece una serie de métodos para obtener distintos datos. A menudo, en el análisis cruzado de información de redes sociales, se encuentran problemas de homologación entre las medidas de cada una, que obligan a buscar la equivalencia entre redes sociales. Pero como norma general, las redes sociales ofrecen primariamente tres tipos de análisis.
En primer lugar, el análisis de la línea de tiempo (timeline) de un usuario. Aquí pueden estudiarse las publicaciones que tienen su origen en el usuario objeto del análisis. En general, este usuario será una cuenta corporativa: una página en Facebook o una Business Account en Instagram (Twitter no distingue en principio entre cuentas corporativas o personales). Obteniendo la línea de tiempo del usuario podemos “ver” las cosas como las vería alguien navegando la página principal de dicha cuenta: qué hemos publicado, qué contestaciones ha habido, número de favoritos (o equivalente) de nuestras publicaciones…
Facebook Feed as viewed in the API Explorer Tool
El segundo tipo de análisis es el de Insights. Llamamos Insights, siguiendo la nomenclatura de Facebook, a datos agregados que proporcionan las API de las redes sociales, en general, relativos al rendimiento de las publicaciones. Estos datos incluyen cosas como el alcance de las publicaciones o las reacciones a las mismas. La API aquí nos ofrece el número global para cierto periodo de tiempo (por ejemplo, likes de una publicación en las últimas 24h) pero no tenemos más información derivada: no podemos relacionar un like con un usuario. Es información muy útil para tener un vistazo rápido del rendimiento de nuestra red social.
Facebook Insights as viewed in the API Explorer Tool
Por último, las redes sociales suelen ofrecer herramientas de búsqueda que permiten monitorizar palabras clave o usuarios. Por ejemplo, en Twitter, podemos monitorizar hashtags o nuestro nombre de usuario, permitiendo así reconstruir conversaciones o seguir el impacto de nuestras etiquetas. Particularmente, Instagram permite buscar información sobre otras páginas corporativas, lo que nos permitiría estudiar estrategias de competidores en dicha red social.
Principales dificultades
La primera de las dificultades con la que nos encontramos es la variabilidad de las APIs. Desde el famoso escándalo de Cambridge Analítica (en el que, en resumen, se hizo un uso ilícito de datos que eran públicos o semipúblicos en la API de Facebook) las distintas redes sociales se han aplicado a limitar el acceso a los datos, generando nuevas versiones en los últimos 18 meses que han comprometido muchas de las soluciones de análisis que había disponible.
Una de las soluciones que han propuesto ha sido el incremento en la perspectivización de los datos, es decir, se han incrementado los límites debidos a qué usuario es el autenticado, permitiendo obtener datos de “mí” pero ofuscando o directamente ocultando los datos de terceros (por ejemplo, ofuscando los ids de los usuarios que comentan). En cierto punto fue posible obtener alguna información de los usuarios que comentaban o daban like a una página siguiendo su ID y pidiendo a la API la información que estuviese disponible. Este tipo de cosas ya no son posibles de manera explícita, ya no se puede pedir la información de un usuario que no haya dado permiso específico para que la aplicación obtenga su información, aunque los datos relevantes de público agregados sí están disponibles (p.ej. Número de personas que dieron like a mi página por país), pero nunca se pueden relacionar estos datos con usuarios reales.
Con el aumento de la perspectivización se hace indispensable disponer de una gestión de la autenticación en la API eficiente, ya que, si queremos, por ejemplo, obtener información de dos páginas de facebook, necesitaremos en muchos casos autenticarnos como dos usuarios distintos. Las redes sociales acostumbran a usar el protocolo de autenticación Oauth2, un protocolo pensado para la autenticación de seres humanos y que plantea algunas dificultades a los servicios automatizados (principalmente la renovación de los permisos).
Por último, el mayor celo de las redes sociales sobre sus datos ha desembocado en un proceso de revisión de aplicaciones para controlar qué hacen las apps que se conectan a la API. En el ejemplo de Facebook, el más significativo, la información disponible en la API ha sido fragmentada en distintos “paquetes” de permisos. Este concepto no es nuevo, pero el número de paquetes se ha incrementado sensiblemente. Además, una aplicación que quiera obtener un permiso concreto debe postularse para ello, rellenando una serie de formularios, firmando en algunos casos un contrato con Facebook e incluso enviando un vídeo mostrando cómo los usuarios interaccionan con la información; un vídeo que, al parecer, es revisado manualmente por un humano, incrementando el tiempo que se tarda en obtener respuesta para una petición. Este vídeo, además, es un problema para los servicios de extracción de datos, que no interaccionan a penas con el usuario.
Estrategias básicas
Herramientas como Power BI o Microsoft Flow nos proporcionan conectores directos a las redes sociales que nos permiten extraer datos de las mismas y operar con ellos. En el caso de Power BI, podemos agregar los datos al modelo existente en el informe; con Flow podríamos insertarlos en nuestras tablas de STG para análisis posteriores.
Este tipo de servicios presenta dos ventajas fundamentales: proveen el sistema de autenticación y de la app para la conexión a la API y además son extremadamente rápidos a la hora de ponerlos en funcionamiento.
Sin embargo, adolecen de lentitud (cuando no estatismo total) a la hora de adaptarse a los cambios que se puedan producir en las APIs, tienen graves dificultades para la gestión multicuenta, están limitados a los métodos de las APIs que su desarrollador haya implementado (no se pueden ampliar) y son imposibles de implantar on premises si se quisiese.
Conector de Power BI
El conector de Power BI parece una buena alternativa para un análisis rápido de la información: seleccionarlo, introducir usuario y contraseña de la red social y utilizar los datos.
PowerBI Facebook Connector interface
El conector nos ofrece una serie de elementos que podemos traer de la API y nos permite, a priori, seleccionar de qué usuario o página queremos extraer los datos:
PowerBI Facebook Connector configuration
Sin embargo, el conector (en el momento de escribir estas líneas) se encuentra desactualizado sólo se puede obtener la parte de Posts, de la que se pueden ver las publicaciones, y dentro de ellas, algunas de sus propiedades, como por ejemplo los comentarios. Peor aún, la estructura que ofrece la API es recursiva, es decir, para una publicación podemos obtener, como un registro dentro de la misma, los comentarios, pero los comentarios de los comentarios estarán anidados dentro de un registro del comentario, y así se va completando el árbol. Esto provoca una complejidad enorme a la hora de realizar el procesado del resultado de las publicaciones.
PowerBI Facebook Connector obtained data
En la imagen se ve el registro dentro de la publicación, que dentro tiene un campo “connections” que a su vez tiene un registro:
PowerBI Facebook Connector object_link Record
Que dentro tiene el listado de los comentarios y los likes:
PowerBI Facebook Connector connections Record
Comentarios, que, si expandimos, podemos ver, pero tienen, también, un registro
PowerBI Facebook Connector comments Record
Dentro del cual podremos ver los comentarios y los likes, y dentro de los comentarios…
La gestión de este árbol no es sencilla, y aunque el conector puede servir para realizar estadísticas sencillas sobre las publicaciones, mucha información será difícil de obtener.
Además, hay partes del api que quedan literalmente sin opción para cubrir, como por ejemplo son los datos de rendimiento de las publicaciones (los llamados insights), a los que no se ofrece acceso.
Conector de Flow
El conector de Flow es un poco más avanzado que el de Power BI. De hecho, Flow permite generar conectores propios utilizando el lenguaje de definición de APIs Swagger, lo cual es un avance. Microsoft Flow es un producto bastante interesante, que permite, usando el conector, obtener información de las APIs y, mediante su sistema de programación de bloques, aplicar lógicas a los datos obtenidos, convirtiéndose en una herramienta particularmente interesante.
MS Flow connector
Sin embargo, esta flexibilidad en la definición de APIs y en la gestión de la información no soluciona todos los problemas.
En primer lugar, los métodos de autenticación están limitados en la definición de las APIs por medio de swagger, de manera que sólo se pueden usar ciertos métodos. Esto impidió, en cierto punto, que pudiésemos mapear la API de Google Analytics que en cierto momento se nos requirió, lo que obligó a utilizar otra solución para esta red social.
Además, la gestión multicuenta es inexistente: cada instancia de flow lleva incorporada su autenticación y para poder realizar la misma extracción, pero con otra autenticación necesitamos otra instancia distinta de flow. Si cada página de facebook de cada sucursal de nuestra compañía tiene un administrador, necesitaremos un flow para autenticar como cada uno de ellos, y cuando haya que realizar un cambio en la lógica habrá que replicarlo en cada instancia.
Flow complexity
Finalmente, aunque flow es bastante poderoso aplicando lógicas a la información, con relativamente poca complejidad el esquema de bloques crece demasiado, haciendo de nuevo el mantenimiento todo un sufrimiento.
Power BI templates
Las templates de Power BI permiten replicar toda una arquitectura en Azure y aplicarla a nuestro negocio con un menú, indicando, por ejemplo, nuestras cuentas en redes sociales, nuestra suscripción de azure, etcétera.
El resultado es toda una infraestructura de análisis prácticamente plug & play que desemboca en un modelo de Power BI. Es una opción interesante, pero Microsoft la descontinuó.
Aun así, todavía hay disponibles algunas de estas plantillas, pero son de terceros y no cabe esperar actualizaciones ni soporte. Además, presentan otro problema fundamental y es que el análisis que hacen de la información está hecho de cierta manera, siendo imposible personalizarlo o saber exactamente qué cálculos se hacen.
Estrategia avanzada
Ante las limitaciones que presentan las soluciones más sencillas y rápidas, siempre cabe desarrollar algún pequeño programa que realice la extracción de datos y los inserte en algún SQL de nuestra infraestructura. Podríamos, por ejemplo, realizar un script de Python que realizase algunas queries contra la API y depositase los json resultado en algún lugar; luego con SSIS podemos incluir esos json en nuestras tablas de STG.
Esta estrategia es adecuada para algunas partes de algunas API, como por ejemplo los insights: datos agregados que no requieren una gran lógica para ser cargados. El dato extraído podría ser “número de visitas a nuestra página en el día de ayer”, y esto se representa con un número y una fecha, por lo que no tiene más complicación gestionarlo. Además, como el desarrollo es propio, disponemos de toda la API a nuestro alcance, y las actualizaciones corren de nuestra cuenta, con lo que podemos estar atentos en nuestras extracciones a los posibles cambios que las APIs estén planeando.
Python extractor arquitecture
Sin embargo, una vez entramos en los timelines, los usuarios, las relaciones muchos a muchos y las llamadas recursivas a la API buscando los comentarios de los comentarios de los comentarios (véase el ejemplo del conector de PowerBI) nos encontramos con que el pequeño script crece de forma exponencial y se hace difícil de mantener (véase Conector de Flow).
Además, estos desarrollos nos dejan “solo ante el peligro”. En primer lugar, tendremos que solicitar a la red social permiso para los datos que queramos obtener, pasando por el proceso de revisión de aplicaciones. Además, tendremos que mapear a mano los distintos métodos de la API (a menudo, en Python, por ejemplo, podemos encontrar librerías que realicen esta tarea por nosotros), y gestionar los posibles errores. Finalmente, nos quedamos solos también autenticando usuarios, y la implementación de un flujo de autenticación Oauth2 sin interfaz de usuario plantea grandes retos por sí misma.
Nuestra solución: SolidQ Social Analyzer SQSA
Tras pasar por la experiencia de todos los escenarios anteriores, y constatar que muchos de nuestros clientes están interesados en la obtención de datos de redes sociales, nos pusimos manos a la obra a desarrollar una solución que pudiera satisfacer los requerimientos de nuestros clientes.
La solución, SolidQ Social Analyzer, tiene la forma de una WebApp en .Net que realiza las peticiones a la API, guarda los JSON y luego llama a procedimientos almacenados en un SQL server para insertar la información en un STG.
Soluciones aportadas por Social Analyzer
Después de enfrentarnos a todos los retos que ya se han mencionado, hemos buscado la manera de solucionar cada uno de los inconvenientes del resto de soluciones:
En primer lugar, disponemos de una aplicación de Facebook (con permiso también en Instagram) ya aprobada, aplicación que puede obtener datos de cualquier persona que de su consentimiento expreso: en la primera extracción, se pide la clave de usuario de la persona de la que se quieren extraer datos, y sólo si la da se pueden extraer. Facebook y su sistema de permisos hacen que estas extracciones estén compartimentadas y cada instancia de nuestra aplicación sólo puede ver información de aquellas personas que dieron su consentimiento a una cierta instancia, por lo que los datos están seguros.
Para continuar, y con la experiencia de lo importante que es la gestión multicuenta de la extracción de datos corporativos en las redes sociales, hemos diseñado un mecanismo de gestión de credenciales que nos permite relacionar cada página de Facebook con un usuario y sus credenciales, permitiendo de manera transparente la extracción de múltiples usuarios una vez han dado permisos a nuestra aplicación.
Mantenemos, de la estrategia de los scripts de Python, la versatilidad de estar mapeando nosotros los métodos de la API por lo que cualquier información que la red social ponga a nuestra disposición es potencialmente extraíble. De hecho, la aplicación se configura completamente utilizando unas tablas de metadata en SQL. Esto nos permite describir la extracción que queremos hacer de la red social como filas de una tabla que, además, como la aplicación es una webapp, puede ofrecer una interfaz al usuario para modificar. De esta manera, si los requisitos cambian, la aplicación puede configurarse sola.
Esta configuración, además, determina de qué páginas se extrae la información y contra qué usuarios, permitiendo también un formulario donde se añaden o se quitan páginas y usuarios en funcion de los requerimientos puntuales. Estas tablas de metadata podrían hasta gestionarse mediante una PowerApp que ofreciese una interfaz extremadamente sencilla para cambiar la configuración.
Arquitecturas para Social Analyzer
La solución requiere de un servidor web para desplegar la webapp y un almacenamiento intermedio para almacenar los json. Esta infraestructura puede proveerse on premises o cloud en azure de manera indistinguible.
Además, se requiere un SQL Server para depositar la información, aunque la aplicación está preparada para poder intercambiar este destino pudiendo utilizarse, por ejemplo, un Data Lake.
Serverless:
SQSA Serverless Architecture
Sobre una WebApp de Azure se despliega nuestra aplicación, que comunica con las API de las redes sociales obteniendo la información en formato JSON. Estos archivos se depositan en un Blob Storage que posteriormente se insertan en Azure SQL Server mediante procedimientos almacenados.
SQSA OnPrem Architecture
On premises, la arquitectura es completamente análoga: La webApp “SolidQ Social Analyzer” se despliega sobre un IIS local, los JSON se almacenan en el disco del servidor que aloja también la instancia de SQL Server.
En ambos casos, la información recopilada por el Social Analyzer es luego mostrada con PowerBI.
El informe de Social Analyzer con Power BI
El objetivo principal de toda la extracción es generar un informe en PowerBI con el que mostrar toda la información extraída para el Social Analyzer. Con dicho informe podremos estudiar cómo se relacionan las distintas métricas que obtenemos entre sí y nos ofrezcan un panel de control desde donde podamos dominar, por ejemplo, los eventos en nuestro timeline:
Social Analyzer Report: timeline events
También podemos representar los insights, estas métricas agregadas que representan el rendimiento de nuestras publicaciones:
Social Analyzer Report: Engagement
Además, si los datos se han incorporado a nuestro STG, podemos cruzar la información de las publicaciones con nuestras líneas de negocio, palabras claves, elementos de marketing, etcétera, resultando en el análisis centrado en el cliente que comentábamos al principio:
Social Analyzer Report: Customer Based Analysis
En definitiva, el SolidQ Social Analyzer nos permite incorporar la información de redes sociales a nuestro STG y nos permite hacer un análisis cruzado entre las propias redes sociales y el resto de elementos de negocio, aportando valor analizando información sobre nuestros clientes.
Si quieres seguir al tanto de las últimas novedades en el sector, así como de tutoriales y consejos, desde SolidQ te invitamos a suscribirte a nuestra newsletter para estar al día de todos nuestros posts. 🙂
