Entrega de archivos de registros y frecuencia
Triton Digital obtiene los archivos de registro del S3, FTP o SFTP (punto de recogida) del cliente. Los publishers deben proporcionar las credenciales de ingreso necesarias para obtener los archivos de registro.
Los archivos de registro deben llegar al punto de recogida al menos a diario, pero la frecuencia puede ser mayor, en especial si los registros son más grandes y se encuentran en múltiples fragmentos. Triton Digital espera recibir la información de sesión dentro de los tres días posteriores al inicio de la sesión. Si el registro de la sesión se recibe después de esta demora, no se tomará en cuenta en las mediciones agregadas.
Nombre del archivo
Los archivos de registro deben tener un nombre único, con la fecha como parte del nombre del archivo. Cada archivo con nombre debería llegar a la ubicación de recogida cuando el archivo está completo (en vez de abrir FTP en la carpeta de registro real donde los archivos se escriben activamente), y cada nombre de archivo único será recuperado/procesado una vez. Un ejemplo de un buen nombre de archivo para este propósito es: MSLT20150830-00.tsv.gz, donde 20150830 es la fecha, y -00 es un sufijo, si es necesario, para la hora, el número de archivo de ese día o algún otro valor de secuenciación / identificación único.
Para mayor eficiencia, cada archivo de registro debe ser comprimido en un archivo único ".gz".
Persistencia
Cree una tarea de limpieza para eliminar los archivos de registro que se crearon hace más de 60 días. Por ejemplo, si utiliza almacenamiento en Amazon S3, puede añadir una regla de ciclo de vida a su bucket para lograrlo.
Formato del archivo
Los archivos de registro deben estar en uno de los siguientes formatos:
- Formateado en la salida estándar del servidor de archivos. La salida del registro de acceso predeterminado de los servicios de streaming de audio más actuales por lo general se usa sin hacer cambios especiales en la configuración.
- Formateado según el formato de archivo extendido W3C (https://www.w3.org/TR/WD-logfile-960221.html). Este formato se usa comúnmente para la salida de servidor de streaming. Básicamente, es una pestaña o un archivo delimitado por espacio con un encabezado que identifica los nombres de campo de cada columna en los datos.
- Formateado como valores separados por tabuladores (tsv). Detalles: Carácter de tabulación (As \t o 0x09). Terminación de línea (\n o 0x0A). El carácter # de la línea comentada. La línea de encabezado es ideal, pero opcional. Si se usa este formato, contáctese con su gestor de cuenta de Triton Digital e infórmele el formato/los campos de salida que piensa utilizar para que podamos asegurarnos de que coincida con su plan de análisis de registros.
- Quienes usan la CDN de Akamai deben utilizar este formato de archivo Luna:
Formato de registro Flag Log extendido + terminación:
date_YYYY-MM-DD \t time_HH:MM:SS \t client_ip \t http_method \t arl_stem \t status_code \t total_bytes \t transfer_time \t "referrer" \t "user_agent" \t "cookie" \t total_object_size \t byte_range \t last_byte_served_flag
Campos obligatorios y opcionales en las líneas de registro
| Campos obligatorios (registros) | Descripción |
|---|---|
IP | Dirección IP pública remota del dispositivo del cliente. Puede ser IPv4 o IPv6. Puede ser la dirección IP completa (por ejemplo, 200.150.100.111) o una parcial (truncada) con el último dígito en 0 (por ejemplo, 200.150.100.0). Si se trata de una dirección parcial, también debemos recibir la dirección IP cifrada en un campo adicional. La IP cifrada mediante hash es necesaria para mantener un recuento único y de descargas adecuado. |
Hashed-IP | Dirección IP cifrada mediante hash con cualquier algoritmo estándar de función de hash (p. ej., MD5). El método de cifrado hash debería reducir al mínimo el riesgo de colisiones y no debería compartirse. La IP cifrada mediante hash se utiliza para contar correctamente las descargas únicas y los oyentes únicos cuando la dirección IP está truncada. (Consulte el campo IP). |
agente de usuario | Contenido de la cabecera HTTP de "agente de usuario". Esta cabecera HTTP de agente de usuario contiene una secuencia característica que permite a los pares de protocolo de red identificar el tipo de aplicación, el sistema operativo, el distribuidor del software o la versión del software del agente de usuario solicitante del software. Ejemplo: Mozilla/5.0 (Windows NT 10.0; Win64; x64) |
fecha | Fecha en que se completa la transacción. El formato es AAAA-MM-DD. |
tiempo de inicio | La marca de tiempo del inicio de la sesión. El formato es HH:MM: SS |
Método | Método HTTP. Por ejemplo: GET |
estado | Código de estado HTTP. Ej.: 200 |
url | URI completo de hasta 2048 caracteres (o URL). Este valor debería completarse automáticamente con un punto de publicación (URI) único, de modo que el registro pueda aplicarse a esa estación en nuestro sistema. En otras palabras, una parte de este campo se usará como la clave para coincidir con una estación en la base de datos de Triton Digital. Ejemplo: /FolderABC/2018/02/20180209_pine0823.mp3?siteplayer=true&episode=588472 |
bytes | Bytes transferidos o tamaño de respuesta, servidor a cliente. Ej.: 766967 |
object-size | Tamaño total del archivo de podcast a descargar. |
Intervalo de bytes | Debe tener datos si el código de respuesta es 206. Por ejemplo: 2008-19568 |
Campos opcionales | Descripción |
cabecera | La dirección de la página web anterior desde la cual se siguió un enlace hacia la página actualmente solicitada. |
tiempo transcurrido (duración) | Numérico, hasta nueve dígitos. Esta es la duración de la sesión, en segundos enteros. |
episode-guid | Identificador de episodio GUID como se lo representa en el contenido RSS. Si este valor está presente, puede sustituir el URI como la clave que debe coincidir con un episodio en el contenido RSS. |
podcast-id | Identificador de podcast (programa) en el que el oyente ha iniciado una sesión. |
vid | Una ID única de registro/visitante que puede usarse para identificar a un oyente y debe provenir de un mecanismo de registro de oyentes. |
lsid | The Triton Digital LSID (también conocido como UUID). Esta es la ID de aplicación/cookie/publicidad tal como se presenta en el tema Gestión de ID del oyente en la Especificación técnica de publicidad. Por lo general, en un dispositivo móvil, debe ser una "gaid" de Google o "idfa" de Apple, o si no está disponible, una ID generada por la aplicación. En una computadora de escritorio, debería ser una ID de cookie. |
género | Género del oyente (M o F o U). "U" puede usarse para otro género o género desconocido. |
yob | Año de nacimiento del oyente, en formato AAAA . |
edad | La edad del oyente. |
código postal | El código postal del oyente (5 dígitos); también puede ser alfanumérico, sin espacios. |
hasads | Macador que indica si la sesión de escucha puede recibir publicidad. Los valores posibles son 0 y 1. Enviar 0 indica que la sesión no puede recibir publicidad. |
dev | Propiedad adicional que se usa para especificar en qué dispositivo se inició la sesión. Triton Digital puede proporcionar una lista no exhaustiva de los dispositivos disponibles, pero los clientes pueden ampliar esa lista para su propio uso. |
dist | Propiedad adicional que puede usarse para producir una agregación que muestre en qué distribuidor/socio se ha iniciado la sesión. Por ejemplo, el Publisher A comparte su stream en el distribuidor/socio B, de modo que la propiedad Distribuidor es "B". Triton Digital puede proporcionar una lista no exhaustiva de los distribuidores disponibles, pero los clientes pueden ampliar esa lista para su propio uso. |
ss | Propiedad adicional que puede usarse para producir una agregación que muestre el publisher del stream. Por ejemplo, el Publisher A comparte su stream en el Socio B, por lo que la propiedad ss es "A". Esto rara vez se usa, ya que los registros generalmente son producidos por el editor. |
ps | Propiedad adicional que se usa para especificar en qué reproductor se inició la sesión. Triton Digital puede proporcionar una lista no exhaustiva de todos los reproductores disponibles, pero los clientes pueden ampliar esa lista para su propio uso. |
Query Params | Es posible que se proporcione cualquiera o todas las secuencias de parámetros de búsqueda URI para un posible uso futuro. Por ejemplo, podría haber ID que se utilicen para vincular correctamente episodios o podcasts. |
X-Forwarded-For | Se usa para identificar la dirección IP de origen de un cliente que se conecta a un servidor web a través de un equilibrador de carga o proxy HTTP. |
Personalizado/otros | Cualquier otro parámetro enviado será ignorado por nuestros sistemas. |