Consultez nos guides de comparaison :
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
{}) :
Veuillez noter : il est fortement recommandé d’utiliser le format Enriched Native pour les API de données Enterprise.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.
- 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_countetquote_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.
- Enrichissement des URL développées et améliorées
- Enrichissement des règles de correspondance
- Enrichissement des métadonnées de sondage
- Enrichissement de la géolocalisation de profil
- 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.
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 v2Lorsque 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
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
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
Publications étendues
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 de l’objet Coordinates
Introduction
Les entités fournissent des métadonnées et des informations contextuelles supplémentaires sur le contenu publié sur X. La sectionentities 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 :
- 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.
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.
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.
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.
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
typede 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.
has:media donnera une correspondance si ce tableau contient au moins un élément.
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.
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.
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 :
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.
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.
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 :
- Volume streams (Decahose )
- Real-time PowerTrack
- API de recherche X (Full-Archive Search et 30-Day Search)
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.
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. 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.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.
Voici la section
entities pour cette Publication :
extented_entities pour cette Publication :
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 :
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 ».
Vous trouverez ci-dessous les métadonnées des extended entities pour cette Publication avec un GIF animé :
Vous souhaitez en savoir plus sur la façon dont le format de données Activity Streams correspond au format 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.
Attributs obsolètes
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.
{ "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é :
Attributs obsolètes (deprecated)
Exemples
twitter_entities a le même format et utilise le même dictionnaire de données que l’objet entities du format enrichi natif.
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.
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é.
Exemple :
twitter_extended_entities
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**
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. 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. 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 », notammenthas: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.
- Octobre
- @replies devient une convention d’usage.
- Les cashtags deviennent des liens cliquables et recherchables en juin 2012.
- Novembre - Introduction des favoris.
- 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.
- 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.
- 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.
- Mai - Lancement du bouton « Follow », qui facilite le suivi des comptes associés à des sites web.
- Août - Introduction des photos natives.
- Juin - les $Cashtags deviennent des liens cliquables et recherchables.
- mars - Identification des personnes sur les photos et prise en charge de jusqu’à quatre photos. Les métadonnées Extended X Entities ont été introduites.
- avril - Les émojis sont pris en charge nativement dans l’interface utilisateur de X. Les émojis étaient couramment utilisés dans les Publications depuis au moins 2008.
- 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.
- Février - GIFs pouvant être recherchés, hébergés nativement dans l’éditeur de Publication.
- Mai - « Doing More with 140 » (dmw140) annoncé, présentant des nouveautés dans la gestion des réponses (Replies) et des médias joints par rapport à la limite de 140 caractères d’une Publication.
- Juin - Prise en charge native de la vidéo
- Juin - Mise à disposition générale des Retweets cités.
- Juin - Autocollants introduits pour les photos.
- Septembre - Introduction des « native attachments » avec l’URL finale non comptabilisée dans les 140 caractères (« dmw140, part 1 »).
- 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 »).
- Mai - Mises à jour RGPD : user.time_zone défini sur null, user.utc_offset défini sur null, user.profile_background_image_url défini sur la valeur par défaut
- Juin - Mise à jour des modifications de formatage de quoteTweet
- 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
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.
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 neigebientôt$ ! ».
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.
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.
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.
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.
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