Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Batch Log Level Data (LLD) vous permet de récupérer et de suivre les flux de données d’événement au niveau du journal qui incluent des dimensions non disponibles dans l’interface utilisateur Xandr ou via le service de rapports d’API de manière traitée par lots. Les flux sont générés toutes les heures et sont divisés en un ou plusieurs fichiers (voir Formats de fichier ci-dessous). Le format du fichier que vous recevez dépend de ce que vous avez spécifié lorsque vous vous êtes abonné (par exemple, Avro, Protobuf, Protobuf-delimited).
Pour obtenir des informations générales sur les données de niveau journal, consultez [Flux de données au niveau du journal](log level-data-feeds.md).
Formats de fichier & schémas
Vous pouvez spécifier un ou plusieurs des formats suivants lors de l’abonnement au service.
Utilisez les téléchargements fournis ci-dessous pour obtenir des exemples de fichiers empaquetés et du code pour la consommation de fichiers de données au niveau du journal.
Remarque
Des exemples de fichiers sont créés pour vous aider à tester l’implémentation que vous utiliserez pour consommer des fichiers de données au niveau du journal. Pour faciliter les tests, les exemples de fichiers sont un peu plus simples que les fichiers générés que vous allez récupérer en production :
- Les exemples de fichiers pour le format protobuf ne sont pas compressés (en production, ils sont compressés Snappy)
- Les exemples de données ne contiennent pas de valeurs typiques pour une colonne donnée. Au lieu de cela, les colonnes sont remplies avec le numéro d’index de la colonne converti en type de colonne.
| Version | Date de publication | Schémas Zip | Exemples de fichiers zip | Exemple de code postal (inclut des schémas + des exemples de fichiers) | Remarques |
|---|---|---|---|---|---|
| 0.5.46 | 21 mai 2024 | Télécharger | Télécharger | Télécharger | Ajoutéprivate_auction private_auction_eligible chrome_traffic_label au flux standard. |
| 0.5.44 | 21 février 2024 | Télécharger | Télécharger | Télécharger | Ajoutésplit_id external_campaign_id external_bidrequest_id external_bidrequest_imp_id postal_code_ext_id Les valeurs suivantes seront ajoutées au champ existant event_type :click served started skipped error 25_pct 50_pct 75_pct 100_pct |
| 0.5.43 | 2 janvier 2024 | Télécharger | Télécharger | Télécharger | Ajouté vg_id au flux d’événements vidéo |
| 0.5.42 | 10 novembre 2023 | Télécharger | Télécharger | Télécharger | Ajouté curated_deal_code au flux de curateur |
| 0.5.41 | 30 octobre 2023 | Télécharger | Télécharger | Télécharger | Ajout external_bidrequest_id de et external_bidrequest_imp_id au flux de transparence marque/acheteur. |
| 0.5.37 | 22 juin 2023 | Télécharger | Télécharger | Télécharger | Ajouté region_id au flux standard. |
| 0.5.36 | 2 mai 2023 | Télécharger | Télécharger | Télécharger |
data_costs Déconseillé du flux standard. |
| 0.5.35 | 8 mars 2023 | Télécharger | Télécharger | Télécharger | Ajouté fallback_ad_index au flux standard. |
| 0.5.31 | 1er février 2023 | Télécharger | Télécharger | Télécharger | Ajout segment_data_costs de et feature_costs au flux standard. |
| 0.5.27 | 1er novembre 2021 | Télécharger | Télécharger | Télécharger | Un nouveau champ, extended_ids, a été ajouté au flux standard et au flux de conservateur. |
| 0.5.26 | 14 octobre 2021 | Télécharger | Télécharger | Télécharger | Le flux de transparence de l’acheteur (brand_transparency_feed) est désormais un flux au niveau du journal entièrement pris en charge (il s’agissait auparavant d’une version alpha). |
| 0.5.25 | 8 septembre 2021 | Télécharger | Télécharger | Télécharger | Deux nouveaux champs et device_unique_idip_address ont été ajoutés au flux d’incrémenticité. |
| 0.5.24 | 22 juillet 2021 | Télécharger | Télécharger | Télécharger | Un nouveau champ, postal_code_ext, a été ajouté au flux standard. |
| 0.5.22 | 21 juillet 2021 | Télécharger | Télécharger | Télécharger | Champ ajouté device_id au flux de conservateur. Ces valeurs d’ID peuvent être recherchées à l’aide du service de modèle d’appareil de l’API Xandr. |
| 0.5.21 | 18 juin 2021 | Télécharger | Télécharger | Télécharger | Ajout de 3 nouveaux champs, operating_system, browseret language au flux de conservateur. Ces valeurs peuvent être recherchées à l’aide du service de système d’exploitation de l’API Xandr, du service de navigateur et du service de langage , respectivement. |
| 0.5.20 | 20 mai 2021 | Télécharger | Télécharger | Télécharger | Ajout d’un nouveau champ, device_make_id, au flux standard. Le champ contient l’ID de la marque de l’appareil, qui est généralement le fabricant de l’appareil (par exemple, Samsung). Pour mapper les ID de fabrique d’appareil aux noms, utilisez le service Device Make. |
| 0.5.18 | 19 avril 2021 | Télécharger | Télécharger | Télécharger | Ajout d’améliorations au flux de conservateur (curator_feed). |
| 0.5.15 | 31 mars 2021 | Télécharger | Télécharger | Télécharger | - Ajout d’un nouveau champ, personal_identifiers, au flux standard. Ce champ de type « répété » apparaît aux acheteurs et aux vendeurs pour les impressions traitées, non traitées et consultées. - Ajout de la version initiale du flux curator ( curator_feed). |
| 0.5.10 | 4 février 2021 | Télécharger | Télécharger | Télécharger | - Les modifications suivantes ont été apportées au flux de transparence de l’acheteur : Les champs suivants ont été ajoutés sous ( bid message index 9) :external_campaign_id insertion_order_id bidder_seat_id bidder_seat_name Le sasc_cap_savings champ a été ajouté sous ( result message index 10). - Le custom_parameters champ (index 17) dans le flux de pixels universels a été modifié d’un champ facultatif à un champ répété. Pour plus d’informations sur les champs qui ont été ajoutés, consultez la documentation relative aux flux individuels. |
| 0.5.7 | 6 avril 2020 | Télécharger | Télécharger | Télécharger | Ajout de 4 nouveaux champs au flux de pixels universels. Les nouveaux champs sont les suivants : - traffic_type - Source du trafic suivi par le pixel. Les valeurs possibles sont WEB ou APP - application_id - ID de l’application (dans l’App Store) sur laquelle le pixel a été placé. Cette valeur peut être numérique ou alphanumérique (par exemple, com.xandr.application_name)- device_unique_id - Identificateur unique représentant l’appareil mobile (la valeur de ce champ est null à l’exception des intégrations spécifiques). Le préfixe numérique indique le type d’identificateur d’appareil unique :0 = IDFA (IDENTIFIANT Apple pour la publicité)1 = SHA12 = MD53 = ODIN4 = OPENUDID5 = AAID (Android Advertising ID)6 = WINDOWSADID (MICROSOFT Advertising ID). - custom_parameters - Contient tous les paramètres personnalisés qui ont été envoyés avec le feu de pixels. |
| 0.5.4 | 27 janvier 2020 | Télécharger | Télécharger | Télécharger | Correction du schéma utilisé pour libérer le nouveau flux de pixels universels. |
| 0.5.2 | 7 novembre 2019 | Télécharger | Télécharger | Télécharger | Ajout d’un nouveau external_campaign_id champ au flux standard dans LLD. Ce nouveau champ facultatif doit uniquement apparaître pour les vendeurs sur les lignes d’impression revendues. La valeur de ce champ est transmise via le champ sur l’enchère cid d’un DSP. Étant donné que le cid champ est facultatif, le nouveau external_campaign_id champ contient uniquement des données lorsque les fournisseurs de services de sécurité réseau externes le renseignent sur leurs offres. Pour plus d’informations sur le champ, consultez la cidspécification Open RTB. |
| 0.5.1 | 10 septembre 2019 | Télécharger | Télécharger | Télécharger | - Ajouté partner_fees au flux standard. - Ajout d’un partition_time_millis champ à tous les flux pour simplifier le chargement et le partitionnement des données dans les bases de données. - Ajout d’un hashed_user_id_64 champ aux flux de pixels et de segments de conversion pour les clients qui souhaitent uniquement des données personnelles anonymisées. |
| 0.4.4 | 29 mai 2019 | Télécharger | Télécharger | Télécharger | Ajouté tc_string au flux standard. |
| 0.3.4 | 10 avril 2019 | Télécharger | Télécharger | Télécharger | Ajouté split_id au flux standard. |
| 0.3.3 | 5 avril 2019 | Télécharger | Télécharger | Télécharger | - Ajouté hashed_user_id_64 au flux de segment. - Ajout de hashed_user_id_64, latitude_truncau longitude_trunc flux non traduit standard. |
| 0.3.0 | 4 octobre 2018 | Télécharger | Télécharger | Télécharger | - Ajout de schémas Avro et d’exemples de fichiers - Ajout de partition_time_millis la colonne à tous les flux pour le filtrage de partition par enregistrement |
| 0.2.4 | mercredi 22 août 2018 | Télécharger | Télécharger | Télécharger | - Supprimé hashed_device_unique_id du schéma de flux standard (plus utilisé)- Ajout du schéma pour le flux standard non traduit |
| 0.1.9 | 12 avril 2018 | Télécharger | Télécharger | Télécharger | - Autoriser la spécification de la version de protobuf, par exemple -Dprotobuf.version="2.5.0" - Recherche de classes de schéma corrigée pour utiliser le code généré par proto3 |
| 0.1.8 | 16 mars 2018 | Télécharger | Télécharger | Télécharger | Ajout de l’indicateur de syntaxe proto2 pour rendre les fichiers proto compilables avec proto3 |
| 0.1.7 | 12 mars 2018 | Télécharger | Télécharger | Télécharger | Protobuf-delimited est désormais compressé par GZIP et l’exemple de code mis à jour en conséquence |
| 0.1.6 | 7 mars 2018 | Télécharger | Télécharger | Télécharger | Ajout de champs de données personnelles anonymes à différents schémas LLD pertinents |
| 0.1.4 | 8 décembre 2017 | Télécharger | Télécharger | Télécharger | Ajout de imps_for_budget_caps_pacing la colonne à standard_feed |
| 0.1.3 | lundi 16 octobre 2017 | Télécharger | Télécharger | Télécharger | Version initiale |
Protobuf (Mémoires tampons de protocole encapsulées dans un fichier séquence)
Importante
Seule la version 2.5.0 de protobuf est actuellement prise en charge.
Les fichiers sont des fichiers de séquence Hadoop compressés snappy où la valeur de chaque enregistrement est BytesWriteable, dont la charge utile est un message de mémoire tampon de protocole encodé.
Tous les schémas spécifient que les champs sont facultatifs et null que les valeurs sont des champs non défini dans le message protobuf. Consultez les flux individuels sous Flux de données au niveau du journal pour connaître les conditions qui entraînent la valeur null d’un champ et pour plus d’informations sur la disponibilité des colonnes.
Consultez Installation et configuration de Protobuf pour obtenir des instructions sur l’installation et la configuration du compilateur protobuf et sur le téléchargement d’un projet qui inclut les schémas et l’exemple de code.
Protobuf-delimited (mémoires tampons de protocole)
Importante
Seule la version 2.5.0 de protobuf est actuellement prise en charge.
Les fichiers sont des fichiers compressés GZIP qui contiennent des messages de mémoire tampon de protocole délimité par la longueur. Chaque enregistrement est un varint spécifiant la longueur du message, suivi du message protobuf lui-même. L’une des raisons d’utiliser notre format délimité par protobuf au lieu de notre format protobuf est que la lecture de fichiers délimités par protobuf ne nécessite pas Hadoop ou Hadoop avec prise en charge snappy native.
Tous les schémas spécifient que les champs sont facultatifs et null que les valeurs sont des champs non défini dans le message protobuf. Pour plus d’informations sur la disponibilité des colonnes, consultez les pages de service de flux individuelles pour connaître les conditions qui entraînent la valeur null d’un champ.
Consultez Installation et configuration de Protobuf pour obtenir des instructions sur l’installation et la configuration du compilateur protobuf et sur le téléchargement d’un projet qui inclut les schémas et l’exemple de code.
Avro
Avro est une infrastructure de sérialisation des données qui regroupe des schémas avec des données. Pour la compression, le codec DEFLATE (niveau = 1) est utilisé. Pour plus d’informations, consultez la documentation Avro.
Remarque
Contrairement à nos formats protobuf, null les valeurs ne sont jamais utilisées. Les champs manquants ou non définis sont encodés avec leurs valeurs par défaut, comme spécifié dans le schéma de flux.
Avro est proposé pour une intégration plus simple avec des systèmes cloud tiers existants. En raison d’incompatibilités détectées lors du test des intégrations, un champ qui est «enum » dans protobuf est envoyé en tant que Avro «int ».