Skip to main content
Consultez nos guides de comparaison :

​
X API : Dictionnaire de données Enterprise

​
Introduction

Enterprise Les Publications sont les éléments de base de tout ce qui se passe sur X. Toutes les X API qui renvoient des Publications fournissent ces données encodées en JavaScript Object Notation (JSON). JSON est fondé sur des paires clé-valeur, avec des attributs nommés et des valeurs associées. Les objets Publication récupérés via l’API incluent la « mise à jour de statut » d’un utilisateur X, mais les Retweets, les réponses et les Tweets cités sont également tous des objets Publication. Si une Publication est liée à une autre Publication, en tant que Retweet, réponse ou Tweet cité, chacune sera identifiée ou intégrée dans l’objet Publication. Même la Publication la plus simple, dans le format de données natif de X, contiendra des objets JSON imbriqués pour représenter les autres attributs d’une Publication, tels que l’auteur, les utilisateurs mentionnés, le lieu balisé, les hashtags, les symboles de cashtag, les médias ou les liens URL. Lorsque vous travaillez avec les données de X, il s’agit d’un concept important à comprendre. Le format des données de Publication que vous recevrez à partir de la X API dépend du type de Publication reçu, de la X API que vous utilisez et des paramètres de format. Les endpoints Enterprise qui renvoient des objets Publication ont été mis à jour pour fournir les métadonnées nécessaires à la compréhension de l’historique des modifications de la Publication. Pour en savoir plus sur ces métadonnées, consultez la page Principes de base sur la modification des Publications.
Dans le format natif de X, le payload JSON comprend des attributs au niveau racine et des objets JSON imbriqués (représentés ici par la notation {}) :

​
Formats de données disponibles

Veuillez noter : il est fortement recommandé d’utiliser le format Enriched Native pour les API de données Enterprise. 
  • Le format Enriched Native inclut toutes les nouvelles métadonnées depuis 2017, comme les métadonnées de sondage, ainsi que des métriques supplémentaires comme reply_count et quote_count.
  • Le format Activity Streams n’a pas été mis à jour avec de nouvelles métadonnées ou de nouveaux enrichissements depuis la mise à jour du nombre de caractères en 2017.
Les API de données Enterprise fournissent des données dans deux formats différents. Le format Enterprise le plus proche du format natif standard v1.1 est Native Enriched. Le format de données Enterprise historique est Activity Streams, initialement mis en œuvre et utilisé par Gnip comme format normalisé pour X et d’autres fournisseurs de données de médias sociaux à l’époque. Bien que ce format soit toujours disponible, X n’a investi dans de nouvelles fonctionnalités et évolutions que pour le format Native Enriched depuis 2017. Le format Enriched Native est exactement ce que son nom suggère : il inclut les objets natifs X ainsi que des enrichissements supplémentaires disponibles pour les produits de données Enterprise, comme les métadonnées de déroulement d’URL, la géolocalisation de profil, les métadonnées de sondage et des métriques d’engagement supplémentaires.  

​
Comparaison d’objets par format de données

Quel que soit votre cas d’usage de X, comprendre ce que ces objets et attributs de Publication encodés en JSON représentent est essentiel pour réussir à trouver les signaux de données qui vous intéressent. Pour vous aider dans cette tâche, un ensemble de pages est dédié à chaque objet, dans chaque format de données. En reflétant la hiérarchie JSON ci-dessus, voici des liens vers chacun de ces objets :

​
Bonnes pratiques d’analyse

  • Le JSON de X est encodé en UTF-8.
  • Les analyseurs doivent pouvoir gérer sans difficulté la variation de l’ordre des champs. Il faut partir du principe que le JSON de Publication est renvoyé sous forme de table de hachage de données non ordonnée.
  • Les analyseurs doivent tolérer l’ajout de « nouveaux » champs. 
  • Les parseurs JSON doivent tolérer les champs « manquants », car tous les champs n’apparaissent pas dans tous les contextes.
  • Il est généralement acceptable de considérer qu’un champ nul, un ensemble vide et l’absence d’un champ sont équivalents.

​
Objets de données Enterprise Native Enriched

​
Objet Tweet Native Enriched

Vous souhaitez en savoir plus sur la façon dont le format de données Native Enriched correspond au format X API v2 ? Consultez notre guide de comparaison : Native Enriched comparé à X API v2

​
Objet Publication

Lorsque vous utilisez des produits de données Enterprise, vous constaterez que la majeure partie du dictionnaire de données est similaire au format natif des données de Publication, avec quelques métadonnées enrichies supplémentaires. Le niveau de base du format natif enrichi reprend en grande partie les mêmes noms d’objets que le format des données X API v1.1. L’objet Publication possède une longue liste d’attributs au niveau racine (« root-level »), y compris des attributs fondamentaux tels que id, created_at et text. Les objets Publication contiennent également des objets imbriqués tels que user, entities et extended_entities. Les objets Publication comportent aussi d’autres objets Publication imbriqués tels que retweeted_status, quoted_status et extended_tweet. Le format natif enrichi inclut en outre un objet matching_rules.
Dictionnaire de données X
Vous trouverez ci-dessous le dictionnaire de données pour ces attributs racine, ainsi que des liens vers les dictionnaires de données des objets enfants.
Attributs supplémentaires de Publication
Les X API qui fournissent des Publications (par exemple l’endpoint GET statuses/lookup) peuvent inclure ces attributs de Publication supplémentaires :
Attributs obsolètes

​
Objets Publication imbriqués

Dans plusieurs cas, un objet Publication inclura d’autres objets imbriqués. Si vous travaillez avec des objets imbriqués, alors cette charge utile JSON contiendra plusieurs objets Publication, et chaque objet Publication pourra contenir ses propres objets. L’objet de niveau racine contient des informations sur le type d’action effectuée, c’est‑à‑dire s’il s’agit d’un Retweet ou d’un Quote Tweet, et peut également contenir un objet décrivant la Publication « originale » qui est partagée. Les Publications étendues incluront un objet étendu imbriqué qui dépasse les 140 caractères, utilisé pour éviter les changements disruptifs lors de la mise à jour effectuée en 2017. Chaque dictionnaire d’objet imbriqué est décrit ci‑dessous. Retweets Les Retweets contiennent toujours deux objets Publication. La Publication « originale » faisant l’objet du Retweet est fournie dans un objet « retweeted_status ». L’objet de niveau racine encapsule le Retweet lui‑même, y compris un objet User pour le compte qui effectue l’action de Retweet et l’heure du Retweet. Le Retweet est une action permettant de partager une Publication avec vos abonnés, sans possibilité d’ajouter de nouveau contenu. De plus, une (nouvelle) localisation ne peut pas être fournie avec un Retweet. Même si la Publication « originale » a été géolocalisée, les objets « geo » et « place » du Retweet seront toujours null. Même avant l’introduction des Publications étendues, l’objet « entities » de niveau racine était dans certains cas tronqué et incomplet en raison de la chaîne « RT @username » ajoutée au message de la Publication faisant l’objet du Retweet. Notez que si un Retweet est à son tour retweeté, le champ « retweet_status » pointera toujours vers la Publication originale, ce qui signifie que le Retweet intermédiaire n’est pas inclus. Un comportement similaire est observé lors de l’utilisation de x.com pour « afficher » un Retweet. Si vous copiez l’ID unique de Publication attribué à l’« action » de Retweet, la Publication originale est affichée.  Vous trouverez ci‑dessous un exemple de structure pour un Retweet. Là encore, lors de l’analyse des Retweets, il est essentiel d’analyser l’objet « retweeted_status » pour obtenir le message complet de la Publication (originale) et les métadonnées d’entités.
Tweets cités
Les Tweets cités sont très similaires aux Retweets, à ceci près qu’ils incluent une nouvelle Publication. Ces nouvelles Publications peuvent contenir leur propre ensemble de hashtags, de liens et d’autres métadonnées d’“entities”. Les Tweets cités peuvent également inclure des informations de localisation partagées par l’utilisateur qui publie le Tweet cité, ainsi que des médias tels que des GIF, des vidéos et des photos. Les Tweets cités contiennent au minimum deux objets Publication et, dans certains cas, trois. La Publication citée, qui peut elle‑même être un Tweet cité, est fournie dans un objet “quoted_status”. L’objet au niveau racine encapsule le Tweet cité lui‑même, y compris un objet User pour le compte effectuant l’action de partage et l’heure du Tweet cité. Notez que les Tweets cités peuvent désormais avoir des photos, des GIF ou des vidéos, ajoutés via l’interface utilisateur ‘Post’. Lorsque des liens vers des médias hébergés en externe sont inclus dans le message du Tweet cité, le “entities.urls” au niveau racine les décrit. Les médias associés aux Tweets cités apparaissent dans les métadonnées “extended_entities” au niveau racine. Lorsque les Tweets cités ont été lancés pour la première fois, un lien raccourci (URL t.co) était ajouté au message de la Publication “originale” et fourni dans le champ “text” au niveau racine. De plus, les métadonnées de cette URL t.co étaient incluses dans le tableau ‘entities.urls’ au niveau racine. En mai 2018, nous avons modifié ce comportement afin que l’URL t.co raccourcie vers le Tweet cité ne soit plus incluse dans le champ “text” au niveau racine. Deuxièmement, les métadonnées du Tweet cité ne seront plus incluses dans les métadonnées “entities.urls”. À la place, les métadonnées d’URL pour le Tweet cité se trouvent dans un nouvel objet “quoted_status_permalink” au niveau racine (ou niveau supérieur), donc au même niveau que l’objet “quoted_status”. Voici ci‑dessous un exemple de structure pour un Tweet cité utilisant cette mise en forme d’origine.
Publications étendues
Le JSON qui décrit les Extended Posts a été introduit lorsque les Publications de 280 caractères ont été lancées en novembre 2017. Le JSON des Publications a été étendu pour encapsuler ces messages plus longs, sans rompre la compatibilité avec les milliers d’applications qui analysent ces objets X fondamentaux. Pour assurer une rétrocompatibilité totale, le champ ‘text’ d’origine, limité à 140 caractères, ainsi que les objets d’entités extraits à partir de celui‑ci, ont été conservés. Dans le cas de Publications dépassant 140 caractères, ce champ ‘text’ au niveau racine est tronqué et donc incomplet. Étant donné que les objets ‘entities’ de niveau racine contiennent des tableaux de métadonnées clés extraites du message ‘text’, comme les hashtags et les liens inclus, ces collections seraient incomplètes. Par exemple, si le message d’une Publication faisait 200 caractères, avec un hashtag à la fin, le tableau hérité ‘entities.hashtags’ au niveau racine ne le contiendrait pas.  Un nouveau champ ‘extended_tweet’ a été introduit pour contenir les messages de Publications plus longs ainsi que les métadonnées d’entités complètes. L’objet “extended_tweet” fournit le champ “full_text” qui contient le message de Publication complet, non tronqué, lorsqu’il dépasse 140 caractères. L’objet “extended_tweet” contient également un objet “entities” avec des tableaux complets de hashtags, liens, mentions, etc. Les Publications étendues sont identifiées par un booléen “truncated” au niveau racine. Lorsque sa valeur est true (“truncated”: true), les champs “extended_tweet” doivent être analysés à la place des champs de niveau racine. Dans l’exemple JSON ci‑dessous, notez que le champ “text” de niveau racine est tronqué et que le tableau “entities.hashtags” de niveau racine est vide, même si le message de la Publication contient trois hashtags. Étant donné qu’il s’agit d’une Publication étendue, le champ “truncated” est défini sur true, et l’objet “extended_tweet” fournit des métadonnées complètes de Publication “full_text” et “entities”.

​
Objet User natif enrichi

L’objet User contient les métadonnées du compte utilisateur X décrivant l’utilisateur X référencé. 

​
Dictionnaire des données utilisateur

​
Attributs obsolètes (non pris en charge)

​
Exemple d’objet utilisateur :

​
Objets de géolocalisation natifs enrichis

Les Publications peuvent être associées à un lieu, générant une Publication « géolocalisée ». Les lieux d’une Publication peuvent être associés à l’aide de l’interface utilisateur X ou lors de la publication d’une Publication à l’aide de l’API. Les lieux d’une Publication peuvent correspondre à un « point » géographique exact ou à un X Place avec une « boîte englobante » décrivant une zone plus vaste, allant d’un lieu donné à une région entière. Il existe trois objets JSON de « premier niveau » utilisés pour décrire le lieu associé à une Publication : place, geo et coordinates.  De plus, le format natif enrichi inclut, dans l’objet utilisateur, la localisation dérivée de l’enrichissement de géolocalisation de profil. L’objet place est toujours présent lorsqu’une Publication est géolocalisée avec un lieu. Les lieux sont des emplacements spécifiques et nommés, avec des coordonnées géographiques associées. Lorsque les utilisateurs décident d’attribuer un lieu à leur Publication, une liste de X Places candidates leur est présentée. Lors de l’utilisation de l’API pour publier, un X Place peut être associé en spécifiant un place_id au moment de la publication. Les Publications associées à des Places ne proviennent pas nécessairement de ce lieu, mais peuvent aussi potentiellement porter sur ce lieu. Les objets geo et coordinates ne sont présents (non nuls) que lorsque la Publication se voit attribuer un lieu exact. Si un lieu exact est fourni, l’objet coordinates fournira un tableau [long, lat] avec les coordonnées géographiques, et un X Place correspondant à ce lieu sera attribué.

​
Dictionnaire de données Place

​
Bounding box

​
Dictionnaire de données de l’objet Geo

Dictionnaire de données de l’objet Coordinates

​
Emplacements dérivés

​
Exemples :

Dictionnaire de données : Enterprise

​
Entités X

Aller à une section de cette page Introduction Objet entities   - Objet hashtag   - Objet media   - Objet media size   - Objet URL   - Objet user mention   - Objet symbol   - Objet poll Détails sur les Retweets et les Quote Tweets Entities dans les objets user Entities dans les Direct Messages Étapes suivantes

​
Introduction

Les entités fournissent des métadonnées et des informations contextuelles supplémentaires sur le contenu publié sur X. La section entities fournit des tableaux d’éléments courants inclus dans les Publications : hashtags, mentions d’utilisateurs, liens, codes mnémoniques boursiers (symboles), sondages X et médias associés. Ces tableaux sont pratiques pour les développeurs lors de l’ingestion de Publications, puisque X a en pratique prétraité, ou pré-analysé, le corps du texte. Au lieu d’avoir à rechercher et trouver explicitement ces entités dans le corps de la Publication, votre parseur peut aller directement à cette section JSON, où elles se trouvent déjà. Au-delà de ces facilités d’analyse, la section entities fournit également des métadonnées utiles à forte valeur ajoutée. Par exemple, si vous utilisez l’Enhanced URLs enrichment, les métadonnées d’URL incluent des URL entièrement développées, ainsi que les titres et descriptions des sites Web associés. Autre exemple : lorsqu’il y a des mentions d’utilisateurs, les métadonnées des entités incluent l’identifiant utilisateur numérique, ce qui est utile lorsque vous effectuez des requêtes vers de nombreuses X API. Chaque charge utile JSON de Publication inclut une section entities, avec l’ensemble minimal d’attributs hashtags, urls, user_mentions et symbols, même si aucune de ces entités ne fait partie du message de la Publication. Par exemple, si vous examinez le JSON d’une Publication dont le corps est « Hello World! » et sans média associé, le JSON de la Publication inclura le contenu suivant, avec des tableaux d’entités contenant zéro élément :
Remarques :
  • les entités media et polls n’apparaîtront que lorsque ce type de contenu fera partie de la Publication.
  • si vous travaillez avec des médias natifs (photos, vidéos ou GIFs), l’Extended Entities object est la solution recommandée.

​
Objet entities

Les sections entities et extended_entities sont toutes deux constituées de tableaux d’objets d’entité. Vous trouverez ci-dessous des descriptions pour chacun de ces objets d’entité, ainsi que des dictionnaires de données qui décrivent les noms d’attributs de l’objet, leurs types et une brève description. Nous indiquerons également quels opérateurs PowerTrack s’appliquent à ces attributs et fournirons quelques exemples de charges utiles JSON. Une collection d’entités courantes présentes dans les Publications, notamment les hashtags, les liens et les mentions d’utilisateurs. Cet objet entities inclut bien un attribut media, mais son implémentation dans la section entiites n’est entièrement exacte que pour les Publications contenant une seule photo. Pour toutes les Publications comportant plus d’une photo, une vidéo ou un GIF animé, le lecteur est renvoyé à la section extended_entities.

​
Dictionnaire de données des entités

L’objet entities est un conteneur de tableaux d’autres sous‑objets d’entité. Après avoir présenté la structure de entities, des dictionnaires de données pour ces sous‑objets, ainsi que les opérateurs qui permettent de les faire correspondre, seront fournis.

​
Objet Hashtag

La section entities contiendra un tableau hashtags contenant un objet pour chaque hashtag inclus dans le corps de la Publication, et un tableau vide si aucun hashtag n’est présent. L’opérateur PowerTrack # est utilisé pour faire correspondre l’attribut text. L’opérateur has:hashtags correspondra s’il y a au moins un élément dans le tableau.

​
Objet média

La section entities contiendra un tableau media contenant un seul objet média si un objet média a été « associé » à la Publication. Si aucun média natif n’a été associé, il n’y aura pas de tableau media dans entities. Pour les raisons suivantes, la section extended_entities doit être utilisée pour traiter les médias natifs de la Publication :
  • Le type de média indiquera toujours « photo », même lorsqu’une vidéo ou un GIF est associé à la Publication.
  • Même si jusqu’à quatre photos peuvent être associées, seule la première sera répertoriée dans la section entities.
L’opérateur has:media donnera une correspondance si ce tableau contient au moins un élément.

​
Objets de taille des médias

Toutes les Publications avec des médias natifs (photos, vidéos et GIF) incluront un ensemble de tailles « thumb », « small », « medium » et « large » avec une hauteur et une largeur en pixels. Pour les photos et les URL de médias d’image d’aperçu, la section Photo Media URL formatting décrit comment construire différentes URL pour charger des médias photo de tailles différentes.

​
Objet sizes

​
Objet size

​
Formatage des URL de média photo

Les médias photo sur X peuvent être chargés en différentes tailles. Il est préférable de charger l’image de plus petite taille dont les dimensions sont suffisamment grandes pour s’adapter à une zone d’affichage (viewport) donnée. Pour charger différentes tailles, l’objet Size et le media_url (ou media_url_https) doivent être combinés selon un format particulier. Nous utiliserons l’objet d’exemple media entity déjà fourni pour illustrer la construction d’une URL de média photo. Les valeurs media_url ou media_url_https peuvent être chargées telles quelles, ce qui aura pour effet de charger par défaut la variante medium. Il est toutefois préférable de fournir, lorsque c’est possible, une URL de média photo entièrement formatée. Une URL de média photo comporte trois parties : Nous prenons ces trois parties (base URL, format et nom) et les combinons dans l’URL de média photo à charger. Il existe deux formats pour charger des images de cette manière, legacy et modern. Tous les chargements d’images doivent cesser d’utiliser le format legacy et utiliser le format modern. Utiliser le format modern améliore le taux de succès de mise en cache sur le CDN pour le client, ce qui réduit les latences de chargement en limitant les cas où le média doit être généré et chargé depuis le centre de données.

​
Objet URL

La section entities contiendra un tableau urls incluant un objet pour chaque lien présent dans le corps de la Publication, et inclura un tableau vide si aucun lien n’est présent. L’opérateur has:links correspondra s’il y a au moins un élément dans le tableau. L’opérateur url: est utilisé pour faire correspondre l’attribut expanded_url. Si vous utilisez l’enrichissement Expanded URL, l’opérateur url: est utilisé pour faire correspondre l’attribut unwound.url (URL complètement déroulée). Si vous utilisez l’enrichissement Enhanced URL, les opérateurs url_title: et url_decription: sont utilisés pour faire correspondre les attributs unwound.title et unwound.description. Si vous utilisez les enrichissements Expanded et/ou Enhanced URL, les métadonnées suivantes sont disponibles sous l’attribut unwound :

​
Objet de mention d’utilisateur

La section entities contient un tableau user_mentions qui comprend un objet pour chaque mention d’utilisateur incluse dans le corps de la Publication, et un tableau vide si aucune mention d’utilisateur n’est présente. L’opérateur PowerTrack @ est utilisé pour faire correspondre l’attribut screen_name. L’opérateur has:mentions correspond si le tableau contient au moins un élément.

​
Objet Symbol

La section entities contient un tableau symbols qui comporte un objet pour chaque $cashtag inclus dans le corps de la Publication, et inclut un tableau vide si aucun symbole n’est présent. L’opérateur PowerTrack $ est utilisé pour faire correspondre la valeur de l’attribut text. L’opérateur has:symbols correspondra s’il y a au moins un élément dans le tableau.

​
Objet de sondage

La section entities contient un tableau polls contenant un seul objet poll si la Publication contient un sondage. Si aucun sondage n’est inclus, il n’y aura pas de tableau polls dans la section entities. Notez que ces métadonnées de sondage ne sont disponibles qu’avec les API Entreprise suivantes :

​
Détails sur les Retweets et les Quote Tweets

Du point de vue de la X API, les Retweets et les Quote Tweets sont des types particuliers de Publications qui contiennent la Publication originale sous forme d’objet imbriqué. Les objets Retweets et Quote Tweet sont donc les parents d’une Publication enfant « originale » (et sont donc deux fois plus volumineux). Les Retweets ont un objet de premier niveau “retweeted_status”, et les Quote Tweets ont un objet “quoted_status”. Pour des raisons de cohérence, ces objets de premier niveau Retweet et Quote Tweet disposent également d’une propriété text et d’entities associées. Cependant, les entities au niveau supérieur peuvent différer des entities fournies par les entities « originales » imbriquées. Dans le cas des Retweets, un nouveau texte est ajouté au début du corps de la Publication originale. Pour les Publications citées, un nouveau texte est ajouté à la fin du corps de la Publication. De manière générale, la meilleure pratique consiste à récupérer le texte, les entities, l’auteur original et la date à partir de la Publication originale dans retweeted_status dès lors que celui-ci existe. Une exception concerne la récupération des entities X qui font partie du texte additionnel de la citation. Voir ci-dessous pour plus de détails et de conseils.

​
Retweets

Un point important concernant les Retweets est qu’aucune autre entité X ne peut être ajoutée à la Publication. Les utilisateurs ne peuvent pas ajouter de hashtags, d’URL ou d’autres éléments lorsqu’ils Retweetent. Cependant, l’attribut de texte du Retweet (au niveau supérieur) est composé du texte de la Publication originale avec « RT @username: » ajouté en préfixe.   Dans certains cas, en particulier pour les comptes avec des noms d’utilisateur longs, la combinaison de ces nouveaux caractères et du corps de la Publication originale peut facilement dépasser la limite de longueur de 140 caractères du texte de la Publication originale. Afin de conserver la prise en charge de l’affichage et du stockage basés sur 140 caractères, le corps de niveau supérieur tronque la fin du corps de la Publication et ajoute des points de suspension (« … »). Par conséquent, certaines entités de niveau supérieur placées à la fin de la Publication originale peuvent être incorrectes ou manquantes, par exemple dans le cas d’un hashtag ou d’une entrée d’URL tronqués. Cette Publication, https://x.com/FloodSocial/status/907974220298125312, contient le texte de Publication suivant :                Just another test Post that needs to be exactly 140 characters with trailing URL and hashtag http://wapo.st/2w8iwPQ #Testing Dans l’exemple ci-dessus, l’URL et le hashtag ont tous deux été affectés. Étant donné que le hashtag a été complètement tronqué et l’URL partiellement tronquée, ceux-ci sont absents des entités de niveau supérieur. Vous remarquerez également l’entité de niveau supérieur user_mentions supplémentaire provenant du préfixe « RT @floodsocial: » dans le champ text. Cependant, le texte de la Publication et les entités dans retweeted_status reflètent parfaitement la Publication originale, sans troncation ni entités incorrectes, d’où notre recommandation de se fier à l’objet imbriqué retweeted_status pour les Retweets.

​
Tweets cités

Les Tweets cités ont été introduits en 2016 et diffèrent des Retweets en ceci que lorsque vous « citez » une Publication, vous ajoutez un nouveau contenu « par-dessus » une Publication partagée. Ce nouveau contenu peut inclure quasiment tout ce qu’une Publication originale peut contenir, notamment du nouveau texte, des hashtags, des mentions et des URL. Les Tweets cités peuvent contenir des médias natifs (photos, vidéos et GIF) et apparaissent dans l’objet entities. Étant donné que des entités X peuvent être ajoutées, les entités du Tweet cité sont probablement différentes des entités d’origine. Dans cet exemple, une nouvelle URL et un nouveau hashtag ont été placés à la fin du Tweet cité. Cette Publication, https://x.com/FloodSocial/status/907983973225160704, contient le texte de Publication suivant :                   étrange et tout aussi tragique lorsque des îles sont inondées… test transatlantique des Tweets cités | @thisuser @thatuserhttp://bit.ly/2vMMDuu #testing Dans ce cas, les entités de niveau supérieur ne reflètent pas les détails du Tweet cité.  En revanche, le texte de la Publication et les entities dans extended_tweet reflètent parfaitement le Tweet cité, sans troncature ni entités incorrectes, d’où notre recommandation de vous appuyer sur l’objet _extended_tweet _object imbriqué pour les Tweets cités.

​
Entités pour l’objet utilisateur

Les entités pour les objets utilisateur décrivent les URL qui apparaissent dans les champs d’URL de profil et de description définis par l’utilisateur. Elles ne décrivent pas les hashtags ni les user_mentions. Contrairement aux entités de Publication, les entités utilisateur peuvent s’appliquer à plusieurs champs au sein de leur objet parent — pour lever toute ambiguïté, vous trouverez des nœuds parents appelés url et description qui indiquent quel champ contient l’URL convertie en entité. Dans cet exemple, le champ url de l’utilisateur contient un lien t.co qui est entièrement développé dans le nœud entities/url/urls[0] de la réponse. L’utilisateur n’a pas d’URL raccourcie dans sa description.

​
Exemple de JSON

​
Entités étendues de X

Accéder aux sections de cette page Introduction Objet Extended Entities Exemples de Tweets et de payloads JSON   - Tweet avec quatre photos natives   - Tweet avec une vidéo native   - Tweet avec un GIF animé Étapes suivantes

​
Introduction

Si une Publication contient des médias natifs (partagés via l’interface utilisateur de la Publication plutôt que par un lien vers un autre emplacement), il y aura également une section extended_entities. Pour tout média natif (photo, vidéo ou GIF), extended_entities est la source de métadonnées privilégiée pour plusieurs raisons. Actuellement, jusqu’à quatre photos peuvent être jointes à une Publication. Les métadonnées entities ne contiendront que la première photo (jusqu’en 2014, une seule photo pouvait être incluse), tandis que la section extended_entities inclura toutes les photos jointes. Avec les médias natifs, une autre limite des métadonnées entities.media est que le type de média indiquera toujours « photo », même lorsque le média joint est une vidéo ou un GIF animé. Le type réel de média est spécifié dans l’attribut extended_entities.media[].type et prend la valeur photo, video ou animated_gif. Pour ces raisons, si vous travaillez avec des médias natifs, les métadonnées extended_entities sont la source à privilégier. Toutes les Publications avec des photos, vidéos et GIF animés joints incluront un objet JSON extended_entities. L’objet extended_entities contient un unique tableau media d’objets media (voir la section entities pour son dictionnaire de données). Aucun autre type d’entité, comme les hashtags et les liens, n’est inclus dans la section extended_entities. L’objet media dans la section extended_entities est identique, en termes de structure, à celui inclus dans la section entities. Les Publications ne peuvent avoir qu’un seul type de média associé. Pour les photos, jusqu’à quatre photos peuvent être jointes. Pour les vidéos et les GIF, une seule peut être jointe. Comme, dans la section extended_entities, la métadonnée de type de média type indique correctement le type de média (« photo », « video » ou « animated_gif ») et prend en charge jusqu’à quatre photos, il s’agit de la source de métadonnées privilégiée pour les médias natifs.

​
Exemples de Publications et de charges utiles JSON

Vous trouverez ci-dessous quelques exemples de Publications et les métadonnées d’entités qui leur sont associées. Publication avec quatre photos natives Publication avec hashtag, mention d’utilisateur, cashtag, URL et quatre photos natives :
Voici la section entities pour cette Publication :
Vous ne trouverez les quatre photos natives (au maximum) que dans le payload « étendu » ci-dessous. Notez que la première photo du tableau est la même que l’unique photo incluse dans la section X entities non étendue. La structure des métadonnées media pour les photos est identique dans les sections entities et extended_entities. Voici la section extented_entities pour cette Publication :

​
Publication avec vidéo native

Voici les métadonnées des extended entities pour cette Publication vidéo :
Lorsqu’un annonceur choisit de limiter la lecture de la vidéo uniquement aux plateformes détenues et exploitées par X, l’objet video_info est remplacé par un objet additional_media_info. L’objet additional_media_info contient des informations média supplémentaires fournies par l’éditeur, comme title, description et le embeddable flag. Le contenu vidéo n’est disponible que pour les clients officiels de X lorsque embeddable=false. Dans ce cas, toutes les URL vidéo fournies dans la charge utile pointeront vers X, afin que l’utilisateur puisse ouvrir la vidéo dans une propriété appartenant à X en cliquant sur le lien. Voici un exemple de ce à quoi ressemblera l’objet extended entities dans cette situation :
Comme indiqué ci-dessus, voici la section entities où le champ type est incorrectement défini sur « photo ». Là encore, la section extended_entities est à privilégier pour tous les types de médias natifs, y compris « video » et « animated_gif ».

​
Publication avec un GIF animé

Vous trouverez ci-dessous les métadonnées des extended entities pour cette Publication avec un GIF animé :

​
Exemples de charges utiles « Native Enriched »

​
Publication

​
Réponse à une publication

​
Publication étendue

​
Publication avec extended_entities

​
Retweet

​
Tweet cité

​
Retweet d’une citation de Tweet

​
Objets de données Enterprise Activity Streams

Vous souhaitez en savoir plus sur la façon dont le format de données Activity Streams correspond au format X API v2 ?
Consultez notre guide comparatif : Comparaison entre Activity Streams et X API v2
Veuillez noter : il est fortement recommandé d’utiliser le format Enriched Native pour les API de données Enterprise. 
  • Le format Enriched Native inclut toutes les nouvelles métadonnées depuis 2017, telles que les métadonnées de sondage, ainsi que des métriques supplémentaires comme reply_count et quote_count.
  • Le format Activity Streams n’a pas été mis à jour avec de nouvelles métadonnées ou de nouveaux enrichissements depuis la mise à jour du nombre de caractères en 2017.

​
Objet Activity

Activity Streams est un schéma d’objet dérivé du format de données d’origine de X, créé par Gnip pour « normaliser le format » des données de Publications et d’autres données de réseaux sociaux en utilisant le schéma tiers Activity Base Schema décrit ici. Les Publications sont normalisées selon le schéma Activity Streams, notamment au moyen des types d’objet note, person, place et service, utilisés comme objets imbriqués. Les Publications peuvent contenir d’autres objets d’activité de Publication imbriqués pour les Retweets, ou d’autres, notamment twitter_quoted_status, long_object. L’objet de base de type « activity » est similaire à l’objet de base Post du format natif enrichi. Des exemples de charges utiles au format Activity Streams sont disponibles ici.

​
Dictionnaire de données

Vous trouverez ci-dessous le dictionnaire de données pour ces attributs « activity » de niveau racine, ainsi que des liens vers les dictionnaires de données des objets enfants.

​
Attributs supplémentaires de la publication

​
Attributs obsolètes

​
Objets d’activité de Publication imbriqués

Dans certains cas, un objet Publication inclura d’autres Publications imbriquées. Si vous travaillez avec des objets imbriqués, la charge utile JSON contiendra alors plusieurs objets, et chaque objet Publication pourra contenir ses propres objets. L’objet au niveau racine contiendra des informations sur le type d’action effectuée, c’est‑à‑dire s’il s’agit d’un Retweet ou d’un Quote Tweet, et pourra également contenir un objet qui décrit la Publication « originale » partagée. Les Publications étendues incluront un objet étendu imbriqué qui va au‑delà de 140 caractères, ce qui a été utilisé pour éviter des ruptures de compatibilité lorsque la mise à jour a été effectuée en 2017. Chaque dictionnaire d’objet imbriqué est décrit ci‑dessous. Retweets Le format Activity Streams des Retweets inclut un objet imbriqué avec le type “activity” et le verbe “note” pour représenter la Publication originale qui est retweetée.
Statut cité sur X Le format Activity Streams permet d’intégrer des Tweets cités { "id": "tag:search.x.com,2005:222222222222", "objectType": "activity", "verb": "post", "body": "Quoting a Tweet: https://t.co/mxiFJ59FlB", "actor": { "displayName": "TheQuoter2" }, "object": { "objectType": "note", "id": "object:search.x.com,2005:111111111", "summary": "https://t.co/mxiFJ59FlB" }, "twitter_entities": {}, "twitter_extended_entities": {}, "gnip": {}, "twitter_quoted_status": { "id": "tag:search.x.com,2005:111111111", "objectType": "activity", "verb": "post", "body": "console.log('Happy birthday, JavaScript!');", "actor": { "displayName": "TheOriginalTweeter" }, "object": { "objectType": "note", "id": "object:search.x.com,2005:111111111" }, "twitter_entities": {} } } Retweet d’un Tweet cité :

​
Objet long

Format Activity Streams de l’extended_tweet

​
Objet actor

L’objet actor contient les métadonnées du compte utilisateur X qui décrivent l’utilisateur X à l’origine de l’activité.

​
Dictionnaire de données

​
Attributs obsolètes (deprecated)

​
Exemples :

​
Location Object

Les objets Location peuvent exister dans l’objet actor défini au niveau du compte X ou dans l’objet profileLocations de l’objet gnip. Les objets Location ont un type d’objet place et peuvent avoir un nom, une adresse ou des coordonnées géographiques. Les objets Location sont similaires à Geo au format natif enrichi.

​
Dictionnaire de données Location

​
objets dérivés de profileLocations

Exemples

​
Objet X entities

Pour le format Activity Streams, twitter_entities a le même format et utilise le même dictionnaire de données que l’objet entities du format enrichi natif.

​
Exemple :

​
Objet X extended entities

Pour le format Activity Streams, twitter_extended_entities utilise le même format et le même dictionnaire de données que ceux présentés dans le format enrichi natif, voir l’objet X extended_entities ici.

​
Exemple :

​
Objet Gnip

L’objet gnip, dans le format Activity Streams, contient les métadonnées ajoutées par les enrichissements actifs, ainsi que des indications sur les règles de correspondance appliquées à l’activité.

​
Dictionnaire de données

​
Exemple :

​
Exemples de charges utiles pour les flux d’activité

Activité de Publication
Activité de Publication en réponse
Activité de Publication avec long_object
Activité de publication avec twitter_extended_entities
Activité de Retweet
Activité de citation de Tweet
Activité de Retweet d’un Tweet cité

​
Chronologie des métadonnées de Tweet

Aller à une section de cette page Introduction Concepts clés Chronologie X Conseils de filtrage Étapes suivantes

​
Introduction**

Au fond, X est un réseau de communication public, en temps réel et mondial. Depuis 2006, l’évolution de X est guidée à la fois par les modes d’utilisation et les conventions des utilisateurs, ainsi que par de nouvelles fonctionnalités et améliorations produits. Si vous utilisez des données X pour de la recherche historique, comprendre la chronologie de cette évolution est important pour faire émerger, à partir de l’archive de données, les Publications qui vous intéressent. X a été lancé comme une simple application mobile SMS et est devenu une plateforme de communication complète, avec un ensemble complet d’API. Les API ont toujours été un pilier du réseau X. La première API est arrivée très peu de temps après le lancement de X. Lorsque la géolocalisation des Publications a été introduite pour la première fois en 2009, elle a été proposée via une Geo API (et plus tard, la possibilité de « géolocaliser » une Publication a été intégrée à l’interface utilisateur de X.com). Aujourd’hui, les API de X alimentent le réseau de communication bidirectionnel qui est devenu une source d’actualités de dernière minute et de partage d’informations. Les possibilités de développer par‑dessus ce canal de communication mondial et en temps réel sont infinies. X met à disposition deux API historiques qui offrent un accès à chaque Publication rendue publique : Historical PowerTrack et la Full-Archive Search API. Les deux API proposent un ensemble d’opérateurs utilisés pour interroger et collecter les Publications d’intérêt. Ces opérateurs effectuent des correspondances sur une variété d’attributs associés à chaque Publication, des centaines d’attributs tels que le contenu textuel de la Publication, le nom de compte de l’auteur et les liens partagés dans la Publication. Les Publications et leurs attributs sont encodés en JSON, un format d’échange de données textuel courant. Ainsi, à mesure que de nouvelles fonctionnalités ont été introduites, de nouveaux attributs JSON sont apparus et, en général, de nouveaux opérateurs d’API ont été ajoutés pour effectuer des correspondances sur ces attributs. Si votre cas d’usage implique un besoin d’écouter ce que le monde a dit sur X, plus vous comprenez à quel moment les opérateurs ont commencé à disposer de métadonnées JSON auxquelles les faire correspondre, plus vos filtres Historical PowerTrack pourront être efficaces. Ensuite, nous présenterons quelques concepts clés qui posent le cadre pour comprendre comment les mises à jour des métadonnées de Publication influent sur la capacité à trouver le signal de données qui vous intéresse.

​
Concepts clés**

​
Des conventions utilisateurs aux objets de première classe de X

Les utilisateurs de X ont, de façon organique, introduit de nouveaux modes de communication désormais fondamentaux pour le réseau X. Un exemple fondateur est le hashtag, aujourd’hui presque universel sur l’ensemble des réseaux sociaux. Les hashtags ont été introduits comme un moyen d’organiser les conversations et les sujets. Sur un réseau comptant des centaines de millions de messages par jour, les outils permettant de trouver des Publications pertinentes sont essentiels, et les hashtags sont devenus un mécanisme clé. Peu après la montée en puissance des hashtags, ceux-ci ont reçu un statut officiel et une prise en charge native de la part de X. Quand les hashtags sont devenus un objet de « première classe », cela a eu de nombreuses implications. Cela signifiait que les hashtags devenaient cliquables/recherchables dans l’interface utilisateur de X.com. Cela signifiait également que les hashtags devenaient membres de la famille des entités de X, aux côtés des @mentions, des médias joints, des symboles boursiers et des liens partagés. Ces entités sont encodées de manière pratique dans un tableau JSON déjà parsé, ce qui facilite pour les développeurs leur traitement, leur analyse et leur stockage. Les Retweets sont un autre exemple de conventions définies par les utilisateurs devenant des objets officiels. Le Retweet est apparu comme un moyen de « transférer » du contenu à d’autres. Il a commencé comme un processus manuel consistant à copier/coller une Publication et à la faire précéder du motif « RT @ ». Ce processus a finalement été automatisé via un nouveau bouton Retweet, accompagné de nouvelles métadonnées JSON. Le Retweet « officiel » était né. D’autres exemples incluent les « mentions », le partage de médias et de liens web, ainsi que le partage d’une position géographique avec votre Publication. Chacun de ces modes d’utilisation a abouti à de nouvelles fonctionnalités de l’interface utilisateur de x.com, à de nouveaux JSON de support, et donc à de nouvelles façons de faire correspondre des Publications. L’ensemble de ces attributs fondamentaux des Publications a donné lieu à des opérateurs PowerTrack utilisés pour effectuer des correspondances sur ces attributs.

​
Métadonnées de Publication, mutabilité, mises à jour et actualité

Bien que les Publications puissent contenir jusqu’à un nombre fixe de caractères, la description JSON d’une Publication se compose de plus de 100 attributs. Il s’agit d’attributs tels que qui a publié, à quel moment, s’il s’agit d’une Publication originale ou d’un Retweet, ainsi que d’un tableau d’objets de premier niveau tels que les hashtags, les mentions et les liens partagés. Pour le compte qui a publié, il existe un objet User (ou Actor) avec un ensemble d’attributs qui fournissent le profil de l’utilisateur et d’autres métadonnées du compte. Les profils incluent une courte description biographique, un lieu de résidence (texte libre), la langue préférée et un lien de site web facultatif. Certaines métadonnées de compte ne changent jamais (par exemple l’id utilisateur numérique et la date de création), d’autres changent lentement au fil du temps, tandis que d’autres attributs changent plus fréquemment. Les personnes changent d’emploi et déménagent. Les entreprises mettent à jour leurs informations. Lorsque vous collectez des Publications historiques, il est important de comprendre que certaines métadonnées sont telles qu’elles étaient au moment de la Publication, tandis que d’autres métadonnées sont telles qu’elles sont au moment où la requête est soumise.  Avec toutes les API historiques, la description du profil de l’utilisateur, le nom d’affichage et les attributs « home » du profil sont mis à jour avec les valeurs qu’ils ont au moment de la requête.

​
Médias « natifs »

X.com et les applications mobiles X permettent d’ajouter des photos et des vidéos à une Publication en cliquant sur un bouton et en parcourant vos galeries de photos. Maintenant qu’elles sont intégrées comme actions de base, les vidéos et photos partagées de cette façon sont appelées des médias « natifs ». De nombreux opérateurs de requête fonctionnent avec ces ressources « natives », notamment has:videos, has:images et has:media. Ceux-ci ne renvoient que des contenus média qui ont été partagés via les fonctionnalités de X. Pour faire correspondre d’autres médias hébergés en dehors de la plateforme X, vous devrez utiliser des opérateurs qui se basent sur les métadonnées d’URL. Avant donc d’entrer dans les détails produits de Historical PowerTrack et Full-Archive Search, faisons un tour de l’évolution de X, en tant que produit et plateforme, au fil du temps. Chronologie de X Vous trouverez ci-dessous une chronologie sélectionnée de X. La plupart de ces mises à jour de X ont, d’une manière ou d’une autre, fondamentalement affecté le comportement des utilisateurs, le contenu JSON des Publications, les opérateurs de requête, ou les trois à la fois. Si l’on considère X comme une plateforme d’API, les événements suivants ont, d’une manière ou d’une autre, affecté les charges utiles JSON utilisées pour encoder les Publications. En retour, ces détails JSON influencent la façon dont les API historiques de X les font correspondre. Notez que cette liste chronologique est globalement précise mais non exhaustive.

​
2006

  • Octobre
    • @replies devient une convention d’usage.
    • Les cashtagsapparaissentpourlapremieˋrefois,maisleurutilisationpourmentionnerdessymbolesboursiersnedevientcourantequ’audeˊbutde2009.Lescashtags apparaissent pour la première fois, mais leur utilisation pour mentionner des symboles boursiers ne devient courante qu’au début de 2009. Les cashtags deviennent des liens cliquables et recherchables en juin 2012.
  • Novembre - Introduction des favoris.

​
2007

  • janvier - les @replies deviennent un type d’objet à part entière avec un bouton Répondre dans l’interface utilisateur et des métadonnées in_reply_to.
  • avril - les Retweets deviennent une convention.
  • août - les #hashtags apparaissent comme un outil principal pour rechercher et organiser les Publications.

​
2009

  • Février - les $cashtags deviennent d’usage courant pour discuter des symboles boursiers.
  • Mai - la version « bêta » des Retweets est introduite avec « Via @ » ajouté au début du corps de la Publication.
  • Juin - introduction des comptes vérifiés.
  • Août - les Retweets deviennent un objet de première classe avec le motif « RT @ » et les nouvelles métadonnées retweet_status.
  • Octobre - fonctionnalité de Listes lancée.
  • Novembre - l’API de géolocalisation des Publications est lancée, offrant pour la première fois aux utilisateurs un moyen de partager leur position via des applications tierces.

​
2010

  • Juin - X Places est lancé pour géolocaliser les Publications.
  • Août - Le bouton de Publication pour les sites web est lancé. Il simplifie le partage de liens.

​
2011

  • Mai - Lancement du bouton « Follow », qui facilite le suivi des comptes associés à des sites web.
  • Août - Introduction des photos natives.

​
2012

  • Juin - les $Cashtags deviennent des liens cliquables et recherchables.

​
2014

​
2015

  • Avril - Une modification de l’interface utilisateur de publication de X entraîne une diminution du nombre de Publications géolocalisées.
  • Octobre - Lancement de X Polls. Les sondages prenaient initialement en charge deux choix avec une période de vote de 24 heures. En novembre, les sondages ont commencé à prendre en charge quatre choix avec des périodes de vote de 5 minutes à sept jours. Les métadonnées de sondage ont été mises à disposition (format natif enrichi uniquement) en février 2017.

​
2016

​
2017

  • Février - Les métadonnées de sondage X sont incluses dans les métadonnées de Publication (format natif enrichi uniquement).
  • Avril - Introduction de « Simplified Replies », avec les comptes auxquels il est répondu qui ne sont pas comptabilisés dans la limite de 140 caractères (« dmw140, part 2 »).
2018 2022
  • 29 septembre - La possibilité de modifier des Publications est déployée auprès d’un petit groupe de test. Les métadonnées des Publications modifiées sont ajoutées à l’objet Publication lorsque c’est pertinent. Celles-ci incluent les objets edit_history et edit_controls. Ces métadonnées ne seront pas renvoyées pour les Publications créées avant l’ajout de la fonctionnalité d’édition. Aucun opérateur associé pour ces métadonnées. Pour en savoir plus sur le fonctionnement de la modification des Publications, consultez les principes fondamentaux de la modification des Publications
Conseils de filtrage Bien connaître la chronologie X indiquant quand et comment les nouvelles fonctionnalités ont été ajoutées peut vous aider à créer des requêtes plus efficaces. Ici, une requête désigne un filtre ou une règle appliqué par les API historiques X à l’archive de Publications, en utilisant des opérateurs PowerTrack pour faire correspondre le JSON de Publication. Un exemple est l’opérateur lang:, qui est utilisé pour faire correspondre des Publications dans une langue donnée. X fournit un service de classification linguistique (prenant en charge plus de 50 langues), et les API X fournissent ces métadonnées dans le JSON généré pour chaque Publication. Ainsi, si une Publication est écrite en espagnol, l’attribut JSON « lang » est défini sur « es ». Donc, si vous construisez un filtre avec la clause lang:es, il ne correspondra qu’aux messages de Publication classés comme espagnols. Les informations de chronologie peuvent également aider à mieux interpréter les données de Publication reçues. Supposons que vous recherchiez le partage de contenu à propos des Jeux olympiques d’été de 2008 et 2012. Si vous appliquez uniquement l’opérateur is:retweet pour faire correspondre les Retweets, aucune donnée ne correspondra en 2008. Cependant, pour 2012, il y aurait probablement des millions de Retweets. À partir de cela, vous pourriez potentiellement conclure à tort qu’en 2008 les Retweets n’étaient pas une convention d’utilisation, ou que simplement personne n’a fait de Retweet à propos de ces Jeux olympiques. Étant donné que les Retweets sont devenus un objet de première classe en 2009, vous devez ajouter une clause de règle ”RT @” pour aider à les identifier en 2008. Les Retweets et la classification linguistique des Publications sont tous deux des exemples d’attributs de Publication avec une longue histoire et de nombreux détails liés au produit. Ci-dessous, nous aborderons plus en détail ces éléments et d’autres catégories d’attributs importantes pour faire correspondre et comprendre les données de X.

​
Reconnaître les faux négatifs

Lorsqu’il s’agit de créer des filtres, il est important de garder à l’esprit que toutes les métadonnées sur lesquelles les Opérateurs font correspondre les résultats ont des dates de « naissance ». Si vous créez un filtre avec un Opérateur qui agit sur des métadonnées introduites après la Publication d’origine, vous obtiendrez un faux négatif. Par exemple, supposons que vous vous intéressiez à toutes les Publications qui mentionnent « snow » et partagent une vidéo. Si vous créez une règle avec l’Opérateur has:videos, qui fait correspondre les Publications comportant des vidéos natives, cette clause ne renverra aucune Publication antérieure à 2015. Cependant, le partage de vidéos était courant sur X bien avant 2015. Avant cela, les utilisateurs partageaient des liens vers des vidéos hébergées ailleurs, mais en 2015, X a intégré directement à la plateforme de nouvelles fonctionnalités de « partage de vidéo ». Pour trouver ces Publications plus anciennes qui vous intéressent, vous ajouteriez une clause de règle comme url:”youtube.com”. À noter qu’avec les API Search, il existe quelques exemples de métadonnées ayant été renseignées a posteriori lors de la reconstruction de l’index. Un bon exemple est celui des cashtags, qui sont devenus très utilisés pour discuter des symboles boursiers en 2009. Après l'introduction de l'opérateur cashtag en 2015, l’index Search a été reconstruit et, au cours de ce processus, l’entité de symbole a été extraite de tous les corps de Publications, y compris dès 2006, lorsque «  » était utilisé principalement comme argot : « J'espère qu'il neige bientôt$ ! ».

​
Identifier et filtrer les attributs de Publication importants pour votre cas d’utilisation

Certaines métadonnées, comme les id numériques de comptes X, existent depuis le premier jour (et sont un exemple de métadonnées de compte qui ne changent jamais). D’autres métadonnées n’ont été introduites que bien après le lancement de X en 2006. Des exemples de nouvelles métadonnées introduites incluent les métadonnées de Retweets, les emplacements des Publications, les titres et descriptions d’URL, ainsi que les médias « natifs ». Vous trouverez ci-dessous quelques-uns des types d’attributs de Publication les plus courants qui ont été fondamentalement affectés par ces mises à jour de la plateforme X. Le comportement de filtrage et de correspondance pour ces éléments dépend, dans la plupart des cas, de l’API historique des Publications que vous utilisez. Pour vous aider à déterminer quel produit est le mieux adapté à vos recherches et à votre cas d’utilisation, les détails relatifs aux attributs fournis ci-dessous incluent des informations générales sur les produits.

​
Profils X

Puisqu’au cœur de son fonctionnement X est un canal de communication mondial en temps réel, les recherches basées sur les données de Publication mettent souvent l’accent sur qui communique. Il est souvent utile de savoir où un utilisateur X considère être son domicile. Savoir qu’une bio de compte mentionne des centres d’intérêt et des loisirs peut souvent vous conduire à des Publications pertinentes. Il est très courant de vouloir surveiller les Publications émanant de comptes qui vous intéressent. Les attributs de profil sont essentiels pour tous ces cas d’utilisation. Chaque compte sur X possède un profil qui inclut des métadonnées telles que le @handle X, le nom d’affichage, une courte bio, le lieu de résidence (texte libre saisi par l’utilisateur), le nombre d’abonnés et bien d’autres encore. Certains attributs ne changent jamais, comme l’identifiant numérique de l’utilisateur et la date de création du compte. D’autres changent généralement au jour le jour, de semaine en semaine ou de mois en mois, comme le nombre de Publications publiées et le nombre de comptes suivis et d’abonnés. D’autres attributs de compte peuvent également changer à tout moment, mais ont tendance à changer moins fréquemment : nom d’affichage, lieu de résidence et bio. La charge utile JSON pour chaque Publication inclut des métadonnées de profil de compte pour l’auteur de la Publication. S’il s’agit d’un Retweet, elle inclut également les métadonnées de profil du compte qui a publié la Publication originale. La mutabilité des métadonnées de profil d’une Publication dépend entièrement du produit historique utilisé. Les Search APIs renvoient des Publications historiques avec les paramètres de profil tels qu’ils sont au moment de la récupération. Pour Historical PowerTrack, le profil est tel qu’il était au moment où la Publication a été publiée, à l’exception des données antérieures à 2011. Pour les Publications antérieures à 2011, les métadonnées de profil reflètent le profil tel qu’il était en septembre 2011.

​
Publication originale et Retweets

Les Retweets sont un autre exemple de conventions initiées par les utilisateurs qui sont devenues des objets officiels. Le Retweet est apparu comme un moyen de « transférer » du contenu à d’autres. Il a commencé comme un processus manuel consistant à copier/coller une Publication et à la faire précéder du motif « RT @ ». Ce processus a finalement été automatisé via un nouveau bouton Retweet, accompagné de nouvelles métadonnées JSON. Le Retweet « officiel » est né et l’action de retweeter est devenue un événement de Publication à part entière. Avec le nouveau bouton Retweet, de nouvelles métadonnées ont été introduites, comme le payload complet de la Publication originale. Le fait qu’une Publication soit originale ou partagée est un critère de filtrage courant. Dans certains cas, seul le contenu original est nécessaire. Dans d’autres, l’engagement autour des Publications est primordial, et les Retweets sont alors essentiels. L’opérateur PowerTrack is:retweet permet aux utilisateurs d’inclure ou d’exclure les Retweets. Si vous extrayez des données d’avant août 2009, vous devez prévoir deux stratégies pour la prise en compte (ou non) des Retweets. Avant août 2009, il est nécessaire de vérifier le message de la Publication elle‑même, en utilisant une correspondance de phrase exacte, pour trouver les correspondances avec le motif « @RT ». Pour les périodes postérieures à août 2009, l’opérateur is:retweet est disponible.

​
Classifications linguistiques des Publications

La langue dans laquelle une Publication est rédigée est un sujet d’intérêt courant. La langue d’une Publication peut aider à en déduire la localisation et, souvent, une seule langue spécifique est nécessaire pour l’analyse ou l’affichage. (Les profils X disposent également d’un paramètre de langue préférée.) Pour filtrer en fonction de la classification linguistique d’une Publication, les produits historiques de X (Search API et Historical PowerTrack) sont assez différents. Lors de la création de l’archive de recherche, toutes les Publications ont été complétées rétroactivement avec la classification linguistique de X. Par conséquent, l’opérateur lang: est disponible pour l’ensemble de l’archive des Publications. Avec Historical PowerTrack, les métadonnées de classification linguistique de X sont disponibles dans l’archive à partir du 26 mars 2013. 

​
Géoréférencement des Publications

Pouvoir déterminer où une Publication a été publiée (c’est-à-dire la géoréférencer) est important pour de nombreux cas d’utilisation. Il existe trois principales méthodes pour géoréférencer des Publications :
  • Références géographiques dans le message d’une Publication
  • Publications géolocalisées par l’utilisateur
  • Localisation « domicile » du profil de compte définie par un utilisateur
Références géographiques dans le message d’une Publication
L’appariement sur les références géographiques dans le message d’une Publication, bien que souvent la méthode la plus complexe puisqu’elle dépend de connaissances locales, est une option applicable à l’ensemble de l’archive de Publications. Voici un exemple de correspondance géoréférencée de 2006 pour la zone de San Francisco, basée sur un filtre « golden gate » : https://x.com/biz/statuses/28311
Publications géolocalisées par l’utilisateur
En novembre 2009, X a introduit son Post Geotagging API, qui permettait de géolocaliser des Publications avec un emplacement exact. En juin 2010, X a introduit X Places, qui représentent une zone géographique à l’échelle d’un lieu, d’un quartier ou d’une ville. Environ 1 à 2 % des Publications sont géolocalisées à l’aide de l’une ou l’autre de ces méthodes. L’historique de géolocalisation disponible dépend de l’API Historical que vous utilisez. Avec les Search APIs, la possibilité de commencer à faire correspondre des Publications à l’aide de certains Geo Operators a débuté en mars 2010, et avec d’autres en février 2015. Si vous utilisez Historical PowerTrack, le géoréférencement commence le 1er septembre 2011. Lors de la création de l’archive Historical PowerTrack, toutes les géolocalisations antérieures à cette date n’ont pas été prises en compte.
L’emplacement « domicile » du profil du compte défini par un utilisateur
Tous les utilisateurs X ont la possibilité de définir leur Profile Location, qui indique leur lieu de résidence. Des millions d’utilisateurs X fournissent cette information, ce qui accroît considérablement la quantité de géodonnées dans le X Firehose. Ces métadonnées d’emplacement sont une chaîne de texte libre, générée par l’utilisateur et non normalisée. Environ 30 % des comptes disposent de métadonnées Profile Geo qui peuvent être résolues au niveau du pays. Comme pour la géolocalisation des Publications, les méthodes de correspondance et les périodes disponibles dépendent de l’API historique que vous utilisez. Historical PowerTrack permet aux utilisateurs d’effectuer leur propre appariement personnalisé sur ces chaînes libres. Pour faciliter ce processus, X fournit également un Profile Geo Enrichment qui effectue, lorsque c’est possible, le géocodage et fournit des métadonnées normalisées ainsi que les opérateurs correspondants. Les opérateurs Profile Geo sont disponibles à la fois dans Historical PowerTrack et dans les Search APIs. Avec Historical PowerTrack, ces métadonnées Profile Geo sont disponibles à partir de juin 2014. Avec les Search APIs, ces métadonnées sont disponibles à partir de février 2015. Le partage de liens vers des pages web, de photos et de vidéos a toujours été un cas d’usage fondamental de X. Au début de son histoire, toutes ces actions impliquaient l’inclusion d’un lien URL directement dans le message de la Publication. En 2011, X a intégré le partage de photos directement dans son interface utilisateur. En 2016, les vidéos natives ont été ajoutées. Compte tenu de cette histoire, il existe une variété d’opérateurs de filtrage utilisés pour cibler ce type de contenu. Il existe un ensemble d’opérateurs qui vérifient si les Publications comportent des liens, des photos et des vidéos partagés. De plus, comme la plupart des URL partagées sur X sont raccourcies pour consommer moins de caractères d’une Publication (par exemple, générées par un service tel que bitly ou tinyurl), X fournit des enrichissements de données qui génèrent une URL complète et développée sur laquelle il est possible d’établir des correspondances. Par exemple, si vous souhaitez faire correspondre des Publications incluant des liens qui traitent de X et des systèmes d’alerte précoce, un filtre qui fait référence à « severe weather communication » correspondra à une Publication contenant cette URL http://bit.ly/1XV1tG4. En mars 2012, l’enrichissement d’URL développée a été introduit. Avant cette date, le corps des Publications incluait uniquement l’URL fournie par l’utilisateur. Ainsi, si l’utilisateur incluait une URL raccourcie, il pouvait être difficile de faire correspondre les URL (développées) d’intérêt. Avec Historical PowerTrack et les API Search, ces métadonnées sont disponibles à partir de mars 2012. En juillet 2016, l’enrichissement d’URL améliorée a été introduit. Cette version améliorée fournit le titre HTML et la description du site web dans le corps de la Publication, ainsi que des opérateurs permettant de faire des correspondances sur ces éléments. Avec Historical PowerTrack, ces métadonnées deviennent disponibles en juillet 2016. Avec les API Search, ces métadonnées commencent à apparaître en décembre 2014. En septembre 2016, X a introduit les « pièces jointes natives », pour lesquelles un lien partagé final n’est pas comptabilisé dans la limite de 140 caractères d’une Publication. Les deux enrichissements d’URL continuent de s’appliquer à ces liens partagés. Pour d’autres détails spécifiques au produit concernant le filtrage d’URL, consultez les articles correspondants pour plus d’informations.