Analytics: Criterios
Dario Castro avatar
Escrito por Dario Castro
Actualizado hace más de una semana

Origen del consumo

Las métricas se obtienen de diferentes plataformas, las cuales se comportan e informan de formas diferentes:

  • Players Full, aquellos que se encuentran completamente implementados o de mediastream, estos informan los eventos del usuario, tales como play, pause, seek, playing, content_end, entre otros.

  • Player Externo Audio, los cuales informan la solicitud del contenido y se obtiene de ellos la data transferida y el consumo a través de los logs, como Itunes, Tunein, etc.

  • Player Externo Video, los cuales solo informan la solicitud del contenido, como Chromecast, Roku. (no es posible obtener información sobre el consumo)

  • Player Externo con caché, algunas plataformas como Spotify, generan la descarga del contenido previamente y el consumo lo realizan a partir de sus servidores, lo que no permite obtener una métrica real del consumo por usuario, solo se obtiene la métrica de cuando la plataforma realizó la descarga para su almacenamiento. Se están revisando otras aplicaciones con comportamientos similares, tales como Google Podcast.

Start:

Corresponde a una solicitud de contenido.

  1. Players Full, se contabilizan aquellos registros donde el usuario realizó efectivamente una acción sobre el player (play o autoplay), se excluyen bots.

  2. Players Externos Audio, se contabilizan todas las solicitudes y se validan contra los logs.

  3. Players Externos Video, se obtienen las solicitudes de contenido, pero no es posible obtener el consumo del usuario.

  4. Download, las descargas no se contabilizan como un start.

Audio Logs:

*Se excluyen los bots.

*Se excluyen solicitudes de validación de las plataformas. (registros inferiores a 70000 bytes)

*Se excluyen solicitudes con status 40X y HEAD.

*Lo bots poseen un user agent, que son reconocidos como bots, estos registros son los que se filtran.

Stream:

Corresponde a un Start con algunos segundos de reproducción posterior.

  1. Player Full, se considera un start como válido luego de 5 segundos de reproducción.

  2. Player Externos Audio, se considera un start como válido luego de 25 segundos de reproducción.

  3. Player Externos Video, no es posible identificar un start como stream, ya que no es posible obtener información del contenido.

  4. Download, las descargas no se consideran como un stream.

Time:

Corresponde al tiempo consumido.

  1. Player Full, es la suma de los tiempos informados en todos los eventos playing.

  2. Player Externos Audio, es la suma de los tiempos calculados a partir de la data transferida, información que es obtenida desde los logs.

  3. Player Externos Video, no es posible obtener el consumo.

  4. Download, no se consideran en los tiempos de consumo.

Download:

Corresponde a una descarga o suscripción de una lista o contenido. (Solo contenido audio Ondemand)

  1. Aplicaciones Mediastream, se considera como un download aquellos registros marcados con el evento “file_downloaded”.

  2. Player Externos Audio, se considera un download cuando el contenido solicitado informa un 200 en los servidores.

  3. Player Externo Video, nunca se considera como un download.

Audio Logs:

*Se excluyen los bots

*Se excluyen las solicitudes de validación. (registros inferiores a 70000 bytes)

*Se excluyen las solicitudes HEAD y status distintos a 200.

Device:

Corresponde a un dispositivo único,

  1. Se utiliza el estándar entregado por la IAB, donde un device es el conjunto del user_agent + ip del usuario que realizó el consumo.

  2. Se consideran tanto los Start como los Download en el recuento de devices.

  3. Los usuarios que cuenten con registro al ingresar a las OTT, usaran la cookie del dispositivos con identificador.

Start/Download ventana de tiempo:

Los conceptos de start y download poseen una ventana de tiempo de 24 horas, esto significa, que luego de este tiempo, si el mismo identificador de reproducción (playback_id) vuelve a ser consumido será contabilizado nuevamente.

Información obtenida desde los consumos: (Players Implementados)

Eventos Registrados:

  1. session_start: Se genera cuando se inicia la sesión de dispositivo, en caso que no tenga una activa actualmente. Esta puede ser generada por el balancer u otra entidad de Mediastream que responda contenido HTTP sobre mdstrm.com.

  2. player_loaded: Se genera cuando el player (web o sdk) ha terminado de cargar todos sus elementos para el correcto funcionamiento en una propiedad (página web, app, otro).

  3. playback_start: Se genera cuando se inicia la descarga de un contenido y se le asocia un ID único que identificará todo el resto de la reproducción de ese contenido particular.

  4. Content_end: Se genera cuando el player llegó al final del contenido. Se deben enviar los eventos generados hasta este momento.

  5. Playing: Se genera cuando el player se encuentra reproduciendo contenido.

  6. Play: Se genera cuando 1) el usuario da click en play 2) el player hace autoplay 3) se utiliza el método de play a través de API.

  7. Pause: Se genera al detener la reproducción. Se deben enviar los eventos generados hasta este momento.

  8. Buffering: Se genera cuando el player que se encuentra reproduciendo el contenido está en proceso de buffering.

  9. Seek: Se genera cuando el player ya sea por acción del usuario o por acción programática (API), el player, adelanta o retrocede el contenido.

  10. File_downloaded: Se informa cuando el usuario hace request de descarga del asset completo (mp4, m4a, etc).

Unificación de registros

Para evitar la duplicidad de solicitudes de contenido, Stream-Metrics trabaja con un algoritmo de unificación que permite distinguir consumos de un mismo usuario donde se agrupan según los criterios de contenido, user agent, ip y otros factores como la ventana de tiempo, para generar un start o download único.

Utilización de logs de CDN - Audio:

Los logs permiten validar y obtener información de los orígenes externos tal como la data transferida y el estado de la solicitud,

  1. Data Transferida: Se utiliza para obtener el tiempo de consumo.

  2. Status: Se utiliza para determinar si una solicitud corresponde a un Start o a un Download.

  • Ondemand: Status 206, HLS Status 200

  • Live y Dar: Status 200

Identificación de orígenes:

Stream-Metrics utiliza el concepto de “Property”, el cual puede ser asignado en cada implementación, la finalidad es para la identificación de donde es consumido el contenido.

Cualquier plataforma que no informe este atributo, será identificada como Others. Los player de Mediastream, por defecto, son identificados como “Mediastream-player” (audio y video son distinguidos de forma separada). En los player web, el property-name, puede ser configurado directamente en la plataforma en la sección de Players.

Criterios CDN:

Conceptos:

  1. Traffic: Corresponde a la data transferida total.

  2. Hits: Corresponde a los request que encontraron el contenido en caché

  3. Misses: Corresponde a los request que no encontraron el contenido en caché.

  4. Hit Ratio: Relación entre los que hicieron los request que hicieron hit y el total de request.

  5. Request: Todos los requests que solicitan contenido, indistintamente de su estado..

  6. Error: Todos los requests que respondieron con 5xx.

  7. Global pop Traffic: Tráfico (GB) por puntos de presencia.

  8. Cache Status: Gráfica que despliega los estados del caché del edge vs el tiempo.

  9. Response Status: Gráfica que despliega las respuestas de los request, agrupados por 2xx, 3xx, 4xx y 5xx.

Códigos de estado de respuesta HTTP:

  1. Respuestas informativas (100–199),

  2. Respuestas satisfactorias (200–299),

  3. Redirecciones (300–399),

  4. Errores de los clientes (400–499),

  5. y errores de los servidores (500–599).

Filtros:

  1. Fecha.

  2. Filtro por zona de distribución.

Ejemplos (Audio):

Plataformas completamente implementadas:

Contabilización:

Plataformas externas (Audio):

Contabilización:

Consideraciones casos players externos:

  1. Algunas plataformas de terceros, descargan el contenido antes de consumirlo, marcando estos como un download y no como un start.

  2. Los tiempos contabilizados se obtienen a partir de la data transferida informada por los servidores, este valor suele ser mayor al consumo real, ya que las plataformas solicitan los contenidos a futuro que el usuario puede o no consumir.

Glosario:

  1. Content id: Identificador del contenido

  2. Referrer: dominio desde el cual se está realizando el consumo. (solo web)

  3. User agent: Identificador que corresponde al conjunto del dispositivo, versión del dispositivo, browser y su versión o aplicación que está utilizando el usuario al momento de realizar el consumo.

  4. Playback: Una solicitud de consumo generada por un usuario, a un contenido en un tiempo determinado. Esta solicitud se identifica con el atributo playback_id que es único durante toda la reproducción. Este identificador puede cambiar si el usuario cierra el player o refresca el sitio donde se encuentra el player.

  5. Dar: Tipo de contenido que corresponde a la grabación de un live, permitiendo avanzar o retroceder en su línea de tiempo.

  6. Live/Ondemand: Tipos de contenidos.

  7. Category: Sistema de categorización de contenido.

  8. Property: Identificador del player.

  9. Referrer: Dominio donde fue realizado el consumo.

  10. Retention: Secciones del contenido vistos.

  11. Engagement: De las secciones del contenido vistos, esta gráfica representa los más vistos.

  12. Distributor: Ente configurado en platform como distribuidor del contenido. Al filtrar por este campo, se desplegarán todos los registros consumidos desde las plataformas del distribuidor seleccionado.

  13. Producer: Ente configurado en platform como generador del contenido.

  14. Show: Estructura de contenido que representa un programa, tiene asociado temporadas, episodios, producer y emisor.

  15. Pre-Load: Carga inicial que se realiza antes de que el usuario solicite el contenido.

Estándares IAB Audio Podcast:

  • Autoplay: no se recomienda el uso de autoplay.

  • Solicitud de archivo: Para una descarga completa, te recomendamos solicitar el archivo completo de una sola vez. Para una descarga progresiva, te sugerimos pedir el archivo en fragmentos (rango de bytes). De esta manera, podrás distinguir una descarga completa de una descarga progresiva.

  • No modifiques la URL del archivo adjunto al solicitar medios; te aconsejamos que no agregues parámetros adicionales.

  • No almacenes en caché los episodios de podcast en tus servidores. Siempre es recomendable descargar el episodio más reciente desde la URL del archivo adjunto para cada usuario de la aplicación que desee escuchar.

  • Utiliza el GUID, en lugar de la URL del episodio, el título, la fecha de publicación, etc., para identificar nuevos episodios en la fuente RSS que deben descargarse automáticamente al dispositivo del usuario. El GUID está diseñado para ser persistente a través de cambios en el entorno de alojamiento, títulos, etc.

  • Emplea un comportamiento de "cancelación automática de descargas" (por ejemplo, detén las descargas automáticas después de 5 episodios no escuchados).

  • No descargues automáticamente todos los episodios (por ejemplo, episodios del catálogo anterior) por defecto. Esto crea una carga innecesaria en los servidores de los editores y consume el ancho de banda de los usuarios. Es recomendable evitar esta práctica.

Los player y SDK de mediastream, ya cuentan con estos estándares.


Si tienes alguna duda adicional, no olvides en contactarnos a través del chat.

Att: El equipo de Mediastream

¿Ha quedado contestada tu pregunta?