Chronometrica ou Apidojo Tweet Scraper : recherche sur X par mot-clé et par date

Choisissez selon l’échantillon que vous devez accepter

Une demande publique d’un acheteur porte sur la collecte de données X par mots-clés pendant une période précise. Elle confirme un besoin de collecte sur une période définie. Elle n’établit pas un besoin d’archive historique complète ni de décompte exact de toutes les publications correspondantes. Le choix des produits comparés ici relève de notre rédaction. Cette demande ne constitue pas un test comparatif vérifié des produits. Demande publique d’un acheteur

Rédigez un court critère d’acceptation avant de choisir un Actor. Par exemple : « J’ai besoin de 10 publications datées au maximum pour chaque mot-clé, avec assez de contexte de recherche pour vérifier chaque échantillon. » Cela vous donne une base concrète pour décider. Vous pouvez vérifier si les entrées expriment la demande et si les sorties conservent les éléments de preuve.

Ce tableau résume la documentation publique vérifiée. Il ne considère pas qu’une fonction non documentée est absente. Les 2 produits proposent le filtrage par mot-clé et par date. Documentation de Chronometrica · Documentation d’Apidojo

La politique documentée d’Apidojo pour la collecte à grande échelle exclut la récupération d’un tweet unique. Cette limite ne change pas le choix pour la recherche de plusieurs résultats étudiée ici. Documentation d’Apidojo

Pour Chronometrica, la principale limite est le plafond de lignes enregistrées. Si vous avez besoin de toutes les publications correspondantes et que leur nombre dépasse 1 000 lignes enregistrées pour une requête, Chronometrica ne répond pas à ce besoin. Même sous ce plafond, il faut des preuves de couverture. Une taille d’entrée autorisée ne prouve pas que la source renverra toutes les publications correspondantes. Documentation de Chronometrica

Pourquoi Chronometrica convient aux échantillons limités par mot-clé

Chronometrica conserve le contexte de recherche des lignes enregistrées. `inputQuery` consigne la requête fournie. `executedQuery` consigne la requête exacte générée. `searchMode` consigne le mode sélectionné. `resultPosition` consigne la position observée d’une ligne dans cette requête. Ces champs permettent de relier une publication enregistrée à la recherche qui l’a produite. Documentation de Chronometrica

Ce lien compte lorsque vous comparez des mots-clés. 2 requêtes peuvent utiliser la même période et le même plafond de lignes, mais renvoyer des nombres différents de lignes acceptées. Gardez leurs bilans distincts. Sinon, un export groupé peut masquer la requête qui a atteint son plafond et celle qui a renvoyé moins de lignes.

Chronometrica documente aussi un suivi `OUTPUT` par requête : le bilan annoncé pour chaque requête. Consultez-le avec les lignes enregistrées. Un fichier de lignes montre ce que vous avez collecté. Le bilan de la requête vous aide à évaluer si cette collecte répond à votre demande. Documentation de Chronometrica

Utilisez `resultPosition` uniquement dans ce contexte. Il s’agit d’une observation issue d’une requête. Ce n’est ni un classement durable, ni une note de qualité, ni une preuve que la publication représente le sujet. Conservez ce champ pour examiner l’ordre de l’échantillon. Ne l’utilisez pas pour mesurer l’importance d’une publication. Documentation de Chronometrica

Ce produit convient bien à un chercheur qui a besoin d’un ensemble limité de publications à lire, à annoter ou à comparer. Les données conservées l’aident à expliquer ce qu’il a observé. Le chercheur doit encore décider si ces observations étayent l’analyse prévue.

Définissez clairement la période avant la collecte

Chronometrica accepte les entrées facultatives `startTime` et `endTime` sous forme de dates calendaires inclusives. La méthode documentée ajoute des filtres de date visibles, puis vérifie à nouveau les dates des publications renvoyées. N’ajoutez pas aussi les opérateurs `since:` ou `until:` à la même demande utilisant les champs de date natifs. Documentation de Chronometrica

Des dates inclusives signifient que les 2 dates calendaires demandées font partie de la période. Elles ne dispensent pas de définir le fuseau horaire de l’étude. Une date calendaire seule ne précise pas quelles heures appartiennent à une journée locale de suivi.

Consignez le fuseau horaire prévu avant de lancer la recherche. Si nécessaire, convertissez les bornes de début et de fin prévues en temps universel coordonné (UTC). C’est la référence horaire commune utilisée pour comparer les horodatages. Vérifiez la conversion pour les dates de votre étude. Utilisez ces horodatages vérifiés pour examiner les publications renvoyées.

Conservez ensemble les 2 éléments de la demande : les dates calendaires inclusives d’origine et l’intervalle horaire précis utilisé pour accepter les lignes. Un autre lecteur pourra ainsi comprendre l’entrée et votre décision d’inclure ou non une publication dans l’étude.

Choisissez une seule méthode de réglage des dates pour le contrôle initial. Utilisez les champs de date natifs lorsqu’ils expriment votre demande. Si vous utilisez plutôt des opérateurs de requête avancés, examinez la requête générée avant d’accepter le résultat. Ne combinez pas les 2 méthodes sans vérifier leur effet sur cette requête.

Pour la méthode complète de contrôle des dates, consultez Comment rechercher des publications X par mot-clé et par date. Ce comparatif aide à choisir un produit : quel Actor fournit les filtres et les données de sortie adaptés à votre besoin de collecte.

Préparez une entrée limitée que vous pouvez vérifier

Chronometrica documente 1–20 requêtes, les modes `latest`, `top`, `photos` et `videos`, ainsi qu’un plafond réglable de 1–1 000 lignes enregistrées par requête. Commencez avec un petit plafond qui vous permet d’examiner chaque ligne enregistrée. Documentation de Chronometrica

L’entrée suivante demande jusqu’à 10 lignes enregistrées pour 1 mot-clé pendant janvier 2026. Elle utilise les champs de date natifs et le mode `latest`.

{
  "queries": [
    "artificial intelligence"
  ],
  "searchMode": "latest",
  "maxItemsPerQuery": 10,
  "startTime": "2026-01-01",
  "endTime": "2026-01-31"
}

Cette entrée a réussi un contrôle local par rapport à la copie en cache du schéma JSON public. Un schéma JSON définit les champs et les valeurs autorisés en entrée. Tous les noms de champs fournis figurent dans ce schéma. Cela confirme la structure de l’entrée. Cela ne prouve pas que la source est disponible en direct et ne garantit pas le retour de 10 lignes. Schéma d’entrée public de Chronometrica

La Task publique X Twitter Search API Dataset fournit un préréglage de départ. Une Task est un préréglage d’entrée enregistré pour un Actor. La page vérifiée a renvoyé HTTP 200, ce qui indique une réponse réussie de la page. Ce contrôle n’a pas confirmé l’entrée actuellement enregistrée.

Ouvrez l’entrée de la Task et appliquez les réglages prévus avant toute exécution. Remplacez le mot-clé et les dates de l’exemple par les valeurs de votre étude. Gardez un petit plafond pour le premier contrôle. L’exemple ci-dessus est un exemple d’entrée, pas un résultat de collecte.

Effectuez un contrôle d’acceptation en 5 étapes

Suivez ces étapes pour décider si l’Actor choisi produit un échantillon utilisable.

1. Décrivez le besoin de collecte. Listez les mots-clés, les dates calendaires, le fuseau horaire prévu et la taille d’échantillon acceptable pour chaque requête. Précisez si vous avez besoin d’exemples, d’un échantillon limité pour une comparaison ou de toutes les publications correspondantes. Faites-le avant de voir les résultats. Définissez les critères d’acceptation d’une ligne, dont tout filtre requis sur l’auteur, les médias ou d’autres éléments.
2. Choisissez les réglages et fixez un petit plafond. Sélectionnez l’Actor dont les filtres documentés répondent au besoin. Choisissez les champs de date natifs ou les opérateurs de requête avancés. Pour vérifier Chronometrica, l’entrée ci-dessus fournit un point de départ limité. Vérifiez la requête générée avant d’accepter toute combinaison de réglages de date.
3. Examinez la requête réelle et les dates des publications. Lisez `executedQuery` et comparez ce champ à `inputQuery`. Confirmez que la requête générée exprime le mot-clé et la période prévus. Examinez `createdAt`, l’horodatage de création de la publication, pour chaque ligne acceptée. Comparez-le à votre intervalle horaire vérifié, en incluant les 2 bornes calendaires. Documentation de Chronometrica
4. Lisez le bilan de chaque requête. Comparez le nombre de lignes enregistrées au plafond demandé et au bilan annoncé. Indiquez qu’une requête a atteint son plafond lorsque c’est le cas. Signalez un résultat partiel lorsque les éléments disponibles justifient ce statut. Gardez visibles les écarts inexpliqués entre les quantités demandées et obtenues. Conservez les valeurs inconnues comme telles. Ne remplacez pas les données manquantes par zéro.
5. Acceptez et exportez séparément les échantillons de chaque requête. Conservez `resultPosition` et consignez l’heure d’observation : le moment où vous avez collecté l’échantillon. Elle diffère de l’heure de création de la publication. Conservez la demande de dates d’origine et les notes sur les requêtes ayant atteint leur plafond ou fourni des résultats partiels. Commencez l’analyse seulement lorsque vous pouvez expliquer votre demande, vos observations et les limites applicables.

Une requête ayant enregistré moins de lignes ne signifie pas nécessairement qu’il y avait moins de publications correspondant à cette requête sur l’ensemble de X. Considérez son bilan comme un élément de preuve sur cette collecte. Si un filtre requis ne peut pas être exprimé, réglez le choix du produit avant de collecter un échantillon plus grand.

Le contrôle d’acceptation vous donne aussi une règle d’arrêt claire. Vous pouvez continuer lorsque les réglages requis fonctionnent et que les données enregistrées permettent l’usage prévu. Si l’un de ces contrôles échoue, une collecte plus importante ne suffira pas à résoudre le problème.

Un choix fictif portant sur 2 mots-clés

Cet exemple est fictif. Il ne s’agit ni d’un test d’Actor, ni d’un jeu de données en direct, ni d’une citation d’acheteur, ni d’une mesure des coûts.

Un chercheur souhaite obtenir des publications de janvier pour 2 mots-clés : « artificial intelligence » et « machine learning ». Le but est de collecter des exemples pour un examen manuel. Le chercheur accepte un plafond de 10 lignes enregistrées par requête et consigne le fuseau horaire prévu avant la collecte.

Avant les autres limites, la taille maximale de l’échantillon demandé est :

`2 queries × 10 rows per query = at most 20 saved rows`

Dans ce résultat fictif, la première requête renvoie 10 lignes datées acceptées. La seconde en renvoie 6 avant d’atteindre la fin des résultats disponibles sur sa source publique. Le chercheur conserve :

`10 + 6 = 16 observed rows`

Le chercheur conserve aussi 2 bilans de requête. La première requête a atteint son plafond. La seconde s’est arrêtée sous son plafond. Le regroupement des lignes ne doit pas effacer cette différence.

Pour ce besoin, Chronometrica est un choix adapté. Le chercheur accepte des échantillons limités et a besoin de la requête d’origine, de la requête générée, des positions des lignes et de bilans distincts. Ces données lui permettent de comparer la collecte à la demande définie. Documentation de Chronometrica

Le chercheur peut décrire le contenu des 16 lignes observées. Il ne peut pas conclure que le premier sujet est apparu plus souvent sur l’ensemble de X. Les plafonds et les bilans inégaux ne permettent pas d’établir la fréquence dans la population : le nombre de fois où chaque sujet est apparu dans l’ensemble complet des publications.

Si le besoin évolue vers toutes les publications correspondantes de janvier, le chercheur doit évaluer ce nouveau besoin séparément. Un petit échantillon satisfaisant ne prouve pas que la collecte est complète. Si ce besoin de résultats exhaustifs dépasse le plafond par requête de Chronometrica, cet Actor n’y répond pas.

Séparez les données des requêtes des observations sur les publications

Utilisez un tableau de suivi des requêtes pour consigner la demande et son bilan. Il s’agit de votre dossier de recherche, et non d’une affirmation sur le format d’export d’un Actor. Pour chaque requête, conservez le texte d’origine du mot-clé, les dates inclusives demandées, le fuseau horaire prévu, le mode choisi, le plafond demandé, le nombre de lignes enregistrées et le bilan annoncé.

Conservez séparément les observations sur les publications, avec `postId` et `executedQuery` comme clé. Une clé est l’ensemble des valeurs qui servent à identifier un enregistrement. Préservez le lien entre chaque publication et la requête générée qui l’a produite.

Conservez les champs documentés de contexte de recherche `inputQuery`, `executedQuery`, `searchMode` et `resultPosition`. Gardez `createdAt` pour le contrôle des dates. Ajoutez l’heure d’observation à votre dossier de recherche. Documentation de Chronometrica

Une publication peut figurer dans les échantillons de plusieurs requêtes. Dans ce cas, conservez les liens avec ces requêtes. Ils montrent pourquoi la publication est entrée dans chaque échantillon. Si vous comptez ensuite les publications uniques, expliquez ce calcul séparément du nombre d’observations enregistrées pour les requêtes.

Cette structure aide à éviter une erreur courante : présenter toutes les lignes exportées comme un total sans préciser ses limites. Un fichier groupé peut contenir des échantillons ayant atteint leur plafond, des échantillons partiels et des publications répétées. Les données des requêtes permettent d’expliquer ces différences avant de tirer une conclusion.

Pour analyser ensuite les termes qui apparaissent ensemble, consultez Cooccurrence des mots-clés dans les publications X. Déterminez d’abord quelles observations vous pouvez utiliser. Appliquez ensuite la méthode d’analyse à cet échantillon défini.