Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
Los datos de nivel de registro por lotes (LLD) permiten recuperar y realizar un seguimiento de fuentes de datos de eventos de nivel de registro que incluyen dimensiones no disponibles en la interfaz de usuario de Xandr o a través del servicio de informes de API de una manera procesada por lotes. Las fuentes se generan cada hora y se dividen en uno o más archivos (consulta Formatos de archivo a continuación). El formato del archivo que recibas dependerá de lo que hayas especificado al suscribirte (por ejemplo, Avro, Protobuf, delimitado por Protobuf).
Para obtener información general acerca de los datos de nivel de registro, consulte [Fuentes de datos de nivel de registro](level-data-feeds.md de registro).
Formatos de archivo & esquemas
Puede especificar uno o varios de los siguientes formatos al suscribirse al servicio.
Utilice las descargas que se proporcionan a continuación para los archivos de ejemplo empaquetados y el código para consumir archivos de datos de nivel de registro.
Nota:
Los archivos de ejemplo se crean para ayudarle a probar la implementación que utilizará para usar archivos de datos de nivel de registro. Para facilitar las pruebas, los archivos de ejemplo son algo más simples que los archivos generados que recuperará en producción:
- Los archivos de ejemplo para el formato protobuf no están comprimidos (en producción, están comprimidos con Snappy)
- Los datos de ejemplo no contienen valores típicos de una columna determinada. En su lugar, las columnas se rellenan con el número de índice de la columna convertido al tipo de columna.
| Versión | Fecha de lanzamiento | Esquema Zip | Ejemplo de Files Zip | Código de ejemplo Zip (incluye esquemas + archivos de ejemplo) | Notas |
|---|---|---|---|---|---|
| 0.5.47 | 29 de mayo de 2026 | Descargar | Descargar | Descargar | Agregado curator_member_id a la fuente Standard |
| 0.5.46 | 21 de mayo de 2024 | Descargar | Descargar | Descargar | Se agregó private_auction private_auction_eligible chrome_traffic_label a Standard Feed. |
| 0.5.44 | 21 de febrero de 2024 | Descargar | Descargar | Descargar | Se agregó split_id external_campaign_id external_bidrequest_id external_bidrequest_imp_id postal_code_ext_id Se agregarán los siguientes valores al campo existente event_type : click served started skipped error 25_pct 50_pct 75_pct 100_pct |
| 0.5.43 | 2 de enero de 2024 | Descargar | Descargar | Descargar | Se agrega vg_id a la fuente de eventos de vídeo |
| 0.5.42 | 10 de noviembre de 2023 | Descargar | Descargar | Descargar | Agregado curated_deal_code a la fuente del Conservador |
| 0.5.41 | 30 de octubre de 2023 | Descargar | Descargar | Descargar | agregado external_bidrequest_id y external_bidrequest_imp_id a la fuente de transparencia de marca/comprador. |
| 0.5.37 | 22 de junio de 2023 | Descargar | Descargar | Descargar | Se agrega region_id a la fuente Standard. |
| 0.5.36 | 2 de mayo de 2023 | Descargar | Descargar | Descargar | En desuso data_costs de la fuente Standard. |
| 0.5.35 | 8 de marzo de 2023 | Descargar | Descargar | Descargar | Se agrega fallback_ad_index a la fuente Standard. |
| 0.5.31 | 1 de febrero de 2023 | Descargar | Descargar | Descargar | agregado segment_data_costs y feature_costs a la fuente Standard. |
| 0.5.27 | 1 de noviembre de 2021 | Descargar | Descargar | Descargar | Se ha agregado un nuevo campo, extended_ids, a la fuente Standard y a la fuente Curator. |
| 0.5.26 | 14 de octubre de 2021 | Descargar | Descargar | Descargar | La fuente de transparencia del comprador (brand_transparency_feed) es ahora una fuente de nivel de registro totalmente compatible (anteriormente era una versión alfa). |
| 0.5.25 | 8 de septiembre de 2021 | Descargar | Descargar | Descargar | Se han agregado dos nuevos campos device_unique_id al ip_addressfeed de incrementalidad. |
| 0.5.24 | 22 de julio de 2021 | Descargar | Descargar | Descargar | Se ha agregado un nuevo campo, postal_code_ext, a la fuente Standard. |
| 0.5.22 | 21 de julio de 2021 | Descargar | Descargar | Descargar | Campo agregado device_id al Canal de Conservadores. Estos valores de identificador se pueden buscar mediante el servicio de modelo de dispositivo de la API de Xandr. |
| 0.5.21 | 18 de junio de 2021 | Descargar | Descargar | Descargar | Se han agregado 3 nuevos campos, operating_system, browsery language al contenido del curador. Estos valores se pueden buscar mediante el servicio del sistema operativo, el servicio de explorador y el servicio de idioma de la API de Xandr, respectivamente. |
| 0.5.20 | 20 de mayo de 2021 | Descargar | Descargar | Descargar | Se ha agregado un nuevo campo, device_make_id, a la fuente Standard. El campo contiene el identificador de la marca del dispositivo, que suele ser el fabricante del dispositivo (por ejemplo, Samsung). Para asignar identificadores de marcas de dispositivos a nombres, use el servicio Device make. |
| 0.5.18 | 19 de abril de 2021 | Descargar | Descargar | Descargar | Se han agregado mejoras a la fuente del Conservador (curator_feed). |
| 0.5.15 | 31 de marzo de 2021 | Descargar | Descargar | Descargar | - Se ha agregado un nuevo campo, personal_identifiers, al Standard Feed. Este campo de tipo "repetido" aparece tanto para compradores como para vendedores para impresiones realizadas, no realizadas y vistas. - Se agregó la versión inicial del Curator Feed ( curator_feed). |
| 0.5.10 | 4 de febrero de 2021 | Descargar | Descargar | Descargar | - Se han realizado los siguientes cambios en el feed de transparencia del comprador: Los siguientes campos se agregaron bajo el bid message (índice 9): external_campaign_id insertion_order_id bidder_seat_id bidder_seat_name El sasc_cap_savings campo se agregó debajo del result message (índice 10). - El custom_parameters campo (índice 17) en Universal Pixel Feed se ha cambiado de un campo opcional a uno repetido. Consulta la documentación de las fuentes individuales para obtener más información sobre los campos que se han agregado. |
| 0.5.7 | 6 de abril de 2020 | Descargar | Descargar | Descargar | Se han añadido 4 nuevos campos al Universal Pixel Feed. Los nuevos campos son: - traffic_type - La fuente del tráfico que rastrea el píxel. Los valores posibles son WEB o APP - application_id - El ID de la aplicación (en la tienda de aplicaciones) en la que se ha colocado el píxel. Este valor puede ser numérico o alfanumérico (por ejemplo, com.xandr.application_name) - device_unique_id - El identificador único que representa el dispositivo móvil (El valor de este campo será null excepto para integraciones específicas). El prefijo numérico indica el tipo de identificador de dispositivo único: 0 = IDFA (ID de Apple para publicidad) 1 = SHA1 2 = MD5 3 = ODIN 4 = OPENUDID 5 = AAID (id. de publicidad de Android) 6 = WINDOWSADID (Id. de Microsoft Advertising). - custom_parameters - Contiene todos los parámetros personalizados que se enviaron con el disparo de píxeles. |
| 0.5.4 | 27 de enero de 2020 | Descargar | Descargar | Descargar | Corrección del esquema utilizado para lanzar el nuevo Universal Pixel Feed. |
| 0.5.2 | 7 de noviembre de 2019 | Descargar | Descargar | Descargar | Se ha agregado un nuevo external_campaign_id campo a la fuente Standard en LLD. Este nuevo campo opcional solo debería aparecer para los vendedores en las filas de impresiones de reventa. El valor de este campo se pasa a través del campo en la cid oferta de un DSP. Dado que el cid campo es opcional, el nuevo external_campaign_id campo solo tendrá datos cuando los DSP externos lo rellenen en su(s) oferta(s). Consulte la especificación Open RTB para obtener más información sobre el cid campo. |
| 0.5.1 | 10 de septiembre de 2019 | Descargar | Descargar | Descargar | - Añadido partner_fees a Standard Feed. - Se ha añadido partition_time_millis un campo a todos los feeds para simplificar la carga y la partición de datos en las bases de datos. - Se ha añadido hashed_user_id_64 un campo a los feeds depíxeles y segmentos de conversión para los clientes que sólo quieren datos personales anónimos. |
| 0.4.4 | 29 de mayo de 2019 | Descargar | Descargar | Descargar | Añadido tc_string a la alimentación estándar. |
| 0.3.4 | 10 de abril de 2019 | Descargar | Descargar | Descargar | Añadido split_id a la alimentación estándar. |
| 0.3.3 | 5 de abril de 2019 | Descargar | Descargar | Descargar | - Agregado hashed_user_id_64 a la fuente de segmentos. - Se agregó hashed_user_id_64, latitude_trunc, longitude_trunc a la alimentación estándar sin transacciones. |
| 0.3.0 | 4 de octubre de 2018 | Descargar | Descargar | Descargar | - Se agregaron esquemas de Avro y archivos de ejemplo - Se agregó partition_time_millis una columna a todas las fuentes para filtrar particiones por registro |
| 0.2.4 | miércoles, 22 de agosto de 2018 | Descargar | Descargar | Descargar | - Eliminado hashed_device_unique_id del esquema de alimentación estándar (ya no se usa) - Se ha añadido un esquema para el feed estándar sin transacciones |
| 0.1.9 | 12 de abril de 2018 | Descargar | Descargar | Descargar | - Permitir especificar la versión del protobuf, por ejemplo, -Dprotobuf.version="2.5.0" - Buscador de clases de esquema parcheado para trabajar con código generado por proto3 |
| 0.1.8 | 16 de marzo de 2018 | Descargar | Descargar | Descargar | Añadida la sugerencia de sintaxis proto2 para hacer que los archivos proto sean compilables con proto3 |
| 0.1.7 | 12 de marzo de 2018 | Descargar | Descargar | Descargar | Protobuf-delimited ahora está comprimido con GZIP, código de ejemplo actualizado en consecuencia |
| 0.1.6 | 7 de marzo de 2018 | Descargar | Descargar | Descargar | Se han agregado campos de datos personales anónimos a varios esquemas de LLD relevantes |
| 0.1.4 | 8 de diciembre de 2017 | Descargar | Descargar | Descargar | Columna agregada imps_for_budget_caps_pacing a standard_feed |
| 0.1.3 | lunes, 16 de octubre de 2017 | Descargar | Descargar | Descargar | Versión inicial |
Protobuf (búferes de protocolo ajustados en archivo de secuencia)
Importante
Actualmente solo se admite la versión 2.5.0 de protobuf.
Los Files son archivos de secuencia Hadoop comprimidos Snappy donde el valor de cada registro es BytesWriteable, cuya carga útil es un mensaje de búfer de protocolo codificado.
Todos los esquemas especifican que los campos son opcionales y null los valores son campos no establecidos en el mensaje de protobuf. Consulte las fuentes individuales en Fuentes de datos de nivel de registro para conocer las condiciones que hacen que el valor de un campo esté null disponible y para obtener más detalles sobre la disponibilidad de columnas.
Consulte Instalación y configuración de Protobuf para obtener instrucciones sobre cómo instalar y configurar el compilador de protobuf y descargar un proyecto que incluye los esquemas y el código de ejemplo.
Delimitado por Protobufs (búferes de protocolo)
Importante
Actualmente solo se admite la versión 2.5.0 de protobuf.
Los Files son archivos comprimidos GZIP que contienen mensajes de búfer de protocolo de longitud delimitada. Cada registro es una variable que especifica la longitud del mensaje, seguido del mensaje protobuf en sí. Una razón para usar nuestro formato delimitado por protobufs en lugar de nuestro formato protobuf es que la lectura de archivos delimitados por protobuf no requiere Hadoop o Hadoop con soporte nativo de Snappy.
Todos los esquemas especifican que los campos son opcionales y null los valores son campos no establecidos en el mensaje de protobuf. Consulte las páginas de servicio de fuentes individuales para conocer las condiciones que hacen que se establezca null el valor de un campo y para obtener más detalles sobre la disponibilidad de columnas.
Consulte Instalación y configuración de Protobuf para obtener instrucciones sobre cómo instalar y configurar el compilador de protobuf y descargar un proyecto que incluye los esquemas y el código de ejemplo.
Avro
Avro es un marco de serialización de datos que agrupa esquemas con datos. Para la compresión, se utiliza el códec DEFLATE (nivel = 1). Para obtener más información, consulte la documentación de Avro.
Nota:
A diferencia de nuestros formatos de protobuf, null los valores nunca se usan. Los campos que falten o que no se establezcan se codifican con sus valores predeterminados, tal como se especifica en el esquema de fuente.
Avro se ofrece para una integración más sencilla con los sistemas en la nube de terceros existentes. Debido a las incompatibilidades encontradas al probar las integraciones, un campo que está "enum" en protobuf se envía como Avro "int".