Aunque no es un documento técnico este artículo requiere ciertos conocimientos de la problemática y entender por qué es necesario aportar transparencia en los procesos que ejecutamos los proveedores de servicios de CDN y streaming.
Como es largo y concienzudo lo divido en partes con el fin de no perder la atención del potencial lector.
En este primer post vamos a ver qué métricas se usan, qué metadatos se incorporan de forma externa y cómo se presentan para que se puedan analizar éstas estadísticas y extraer conclusiones de negocio, más allá de las cifras en bruto.
Confianza en el proveedor: Transpariencia
Al no existir ninguna guía de recomendaciones ni organización que estandarize este proceso, lo primordial es que el proveedor de servicios ofrezca la información suficiente y demostrable que permita a los clientes confiar en las métricas y estadísticas que ofrece sobre el consumo de datos.
No olvidemos que muchas veces, el pago de los servicios es por uso y según se cuenten las visualizaciones, como clientes, estaremos más o menos contentos, pero deberemos pagar más por un servicio que realmente no se ha ofrecido.
Si un proveedor ofrece la posibilidad de descargar datos de conexiones y tráfico en formato RAW (en bruto) probablemente no tenga nada que esconder.
Recopilación de datos de usuario
Es el principal punto de entrada al sistema, aunque no el único como se verá después.
Cuando un usuario solicita acceder a un vídeo o un audio alojado en una red de distribución de contenidos o CDN, el proceso es más complejo que cuando los usuarios acceden a una web. Esta red balancea la carga entre servidores alojados en datacenters distribuidos en todo el mundo, como ya explicamos en un anterior post.
Se guardan los datos iniciales de la conexión y se "vincula" al flujo de datos que deben de enviar otros servidores, de forma que se conozca el origen de la petición del usuario, y cuantos bytes a consumido de qué servidores y en qué condiciones. Este proceso es transparente al usuario, pero queda perfectamente registrado en la red.
Diferenciación de origen: necesaria la reescritura de URL's
En ARANOVA usamos la reescritura para identificar si el consumo proviene de una app, de una web, de una marca concreta de móvil y en general de cualquier origen que nuestro cliente quiera etiquetar, porque sólo él sabe qué métricas son diferenciales para su negocio.
Lo importante es tener esa posibilidad y segmentar adecuadamente la audiencia.
Un contenido puede distribuirse en múltiples plataformas y webs y a través de distintos dispositivos y apps. Por ejemplo, un podcast puede escucharse desde una app o desde la web con un terminal Android o Apple, en plataformas como iVoox, Apple Podcast, etc.
¿Cómo conocer el origen?
La petición HTTP al contenido no es suficiente, porque se pierde mucha información. Es preciso que la CDN permita reescribir URL's para que al enlazar los contenidos se conozca desde dónde se ha enlazado.
Algunos proveedores ofrecen un etiquetado mediante parámetros GET en la URL (?origin="app"), pero no es lo óptimo porque muchas veces esos parámetros "se pierden" antes de llegar a la CDN.
Bloqueo de orígenes no lícitos: Robots, arañas y otros bots
En la distribución de contenidos audiovisuales hay mucho "pirata" que se aprovecha de los contenidos creados legítimamente. La CDN debe diferenciar y ser capaz de gestionar las conexiones de sistemas automáticos como robots, arañas y otros bots que sólo buscan encontrar contenidos para ofrecerlos en otras plataformas.
Pero muchas veces también se quiere que los contenidos aparezcan en buscadores. Los trucos que usan los bots son muchos, pero el más común es usar un UserAgent (identificación) de servicios legítimos como Google por ejemplo.
Para luchar contra este problema, se analizan las cabeceras de las peticiones, el tráfico generado, la frecuencia de las conexiones, las IP's de origen y se generan alertas automáticas para notificar a los clientes cuando es necesario.
Como indica el documento "Podcast Measurement Technical" que establece las buenas practicas en medidas de estadísticas de podcast en las estadísticas de cliente no hay que contar el trafico generado por estos bots.
De nuevo lo importante es que el proveedor ofrezca información sobre si computa ese tráfico, si dispone de reglas automáticas y/o manuales para getsionar ese tráfico no deseado, etc.
Gestión de tokens: Siguiendo al usuario
La gran dificultad para la recogida de información y la identificación el usuario son las nuevas conexiones móviles y/o compartidas. Es mucho más complejo que lo se puede imaginar: reconexiones, cambios de calidad de flujos, consumo de móviles, proxys, CG-NAT, etc... entornos en los que no se identifica al usuario por la IP de conexión, el UserAgent o las cookies.
Un caso típico de un móvil en movimiento, puede crear múltiples conexiones con distintas IP's y no por eso las estadísticas deben mostrar que en 30 minutos hubo 20 conexiones, sino que había un usuario conectado durante 30 minutos.
La forma de solucionarlo es ofrecer un sistema de seguimiento del usuario desde la primera conexión y lo más común es hacerlo con una variable tipo GET o token.
Para estos casos ARANOVA.cloud, nuestra plataforma de CDN ofrece es sistema de seguimiento via token que identifica de principio a fin la sesión del usuario, use proxys, CG-NAT, en mobilidad, etc.
El uso de tokens no es exclusivo para este fin sino que añade funcionalidades al servicio: geobloqueo, tiempo de vida de las sesiones o hotlinking (que usen tu streaming desde otro pagina agregadora), pago por visión, conexiones simultáneas, caducidad de contenidos y/o flujos...
Hasta aquí se han visto cómo se recopila la información, pero: ¿qué información se recopila? ¿cómo se ofrece al cliente del servicio?
Atentos a próximos post de este tema donde comentaré algún caso particular de algún cliente como Aragón TV, Aragón Radio o teoricaonline.com