Les données Polymarket ne deviennent un jeu de données de recherche qu’une fois que quelqu’un a décidé ce que signifie chaque enregistrement, quelles observations appartiennent à l’échantillon et quand les informations étaient disponibles. Ces choix peuvent influer sur un résultat autant que le modèle appliqué ensuite. Même des archives volumineuses peuvent étayer une conclusion trompeuse si elles excluent silencieusement des marchés difficiles ou fournissent trop tôt des informations ultérieures.
Un jeu de données utile conserve la provenance, les versions des schémas et les observations manquantes aux côtés des prix et des résultats. Il doit permettre à un autre chercheur de reconstituer la manière dont une ligne a été produite et de déterminer quelles affirmations les éléments disponibles peuvent étayer. L’objectif est de rendre le sens reproductible, au-delà de la simple possibilité de rouvrir un fichier.
Ce guide porte sur les données de Polymarket International. Polymarket US dispose d’interfaces distinctes et d’un contexte de plateforme qui lui est propre. Les effectifs des échantillons, les dates, les heures et les calculs ci-dessous sont fictifs et proposés à des fins pédagogiques. Ils illustrent la conception d’un jeu de données, sans décrire de véritables archives de marché ni établir les performances d’une stratégie de trading.
Définir la question avant de collecter les données Polymarket
Un jeu de données doit être conçu autour d’une question de recherche. Étudier le calibrage des prévisions exige des estimations de probabilité datées et des résultats. Étudier les coûts d’exécution exige des carnets d’ordres correspondant aux quantités prévues et aux moments de décision. Étudier les performances d’un compte exige des enregistrements privés dont l’accès est autorisé et que les données publiques de marché ne fournissent pas nécessairement.
Formulez en une phrase l’affirmation que vous souhaitez tester. Par exemple, un projet pourrait chercher à savoir si une mise à jour particulière d’une source améliore les prévisions réalisées un jour avant l’échéance d’un contrat. Cette question détermine les repères temporels, les définitions des contrats et les unités d’évaluation nécessaires. Collecter tous les champs accessibles sans question précise peut produire du volume sans éléments exploitables.
Le guide plus ancien sur le trading algorithmique sur les marchés de prédiction souligne l’importance de la reproductibilité. La conception du jeu de données fait partie de cette exigence. Un algorithme appliqué ultérieurement ne peut pas réparer des archives dépourvues des heures d’observation ou des correspondances entre contrats nécessaires pour tester équitablement ce qu’il prétend tirer des informations.
Choisir l’unité d’observation
Décidez de ce que représente une ligne : un instantané du marché, une transaction, une prévision pour un contrat et un jour donnés, un épisode d’observation d’éléments probants ou une exécution sur un compte. Ces unités ne doivent pas être mélangées dans un même tableau sans relation clairement définie. Un nombre de lignes n’a de sens qu’une fois l’unité définie.
Supposons que la recherche utilise une prévision par contrat à un horizon fixe. Dix instantanés de cotations intrajournalières pour ce contrat ne créent pas dix résultats de prévision indépendants. Ils peuvent fournir un contexte utile sur l’exécution, mais le résultat de l’événement sous-jacent reste commun.
Préservez les relations entre les événements, les marchés et les jetons associés aux différentes issues. Plusieurs contrats peuvent se rapporter aux seuils d’une même observation, et plusieurs enregistrements peuvent décrire un même contrat au fil du temps. Un jeu de données qui traite chaque ligne comme indépendante peut surestimer la quantité d’éléments disponibles pour évaluer un modèle ou estimer l’incertitude.
Constituer un registre de provenance du jeu de données
Un registre de provenance du jeu de données précise la source, la méthode de récupération, l’heure de récupération, l’identifiant brut et la version de la transformation pour chaque enregistrement dérivé ou lot cohérent. Il doit être possible de remonter d’une donnée d’entrée du modèle aux éléments à partir desquels elle a été construite.
La présentation des API de Polymarket distingue les interfaces de découverte, du CLOB et de données. Un jeu de données doit conserver l’identité de l’interface ayant fourni un enregistrement, au lieu de traiter tous les champs comme s’ils provenaient d’une source uniforme. Des noms similaires d’une interface à l’autre peuvent recouvrir des périmètres ou des comportements de mise à jour différents.
La provenance comprend aussi les choix du chercheur. Consignez les règles de filtrage, les méthodes de normalisation et les corrections manuelles. Une correction doit expliquer le problème initial et conserver la valeur d’origine lorsque cela est pertinent. Un nettoyage silencieux peut faciliter l’utilisation d’un fichier tout en supprimant les éléments nécessaires pour comprendre pourquoi un résultat a changé.
Conserver les enregistrements bruts aux côtés des données normalisées
Les enregistrements bruts préservent la représentation d’origine de la source. Les données normalisées facilitent l’analyse en exprimant les concepts communs de manière cohérente. Conserver les deux permet au chercheur de déterminer si un résultat inattendu provient du marché ou d’une transformation.
Les archives brutes doivent être suffisamment organisées pour permettre de retrouver l’enregistrement pertinent, sans devenir le seul jeu de données utilisable. La couche normalisée doit comporter des liens stables vers ces archives, ainsi que les versions des schémas et des transformations. Cela sépare concrètement la conservation des éléments probants de la commodité d’analyse.
Ne supposez pas que la normalisation est neutre. Remplacer une valeur manquante par zéro, arrondir un prix ou déduire le côté correspondant à une issue peut en modifier le sens. Chaque transformation nécessite une règle définie et une justification adaptée à la question de recherche. Lorsque la source ne permet pas une interprétation fiable, l’enregistrement normalisé doit conserver une valeur explicitement non résolue.
Versionner le sens des contrats au fil du temps
Un jeu de données de recherche exige davantage que le titre d’un marché. Conservez la question complète du contrat, les règles pertinentes, les références aux sources, les échéances et la correspondance entre les issues, avec leurs heures d’observation. Si les métadonnées changent, conservez la relation entre les versions plutôt que d’écraser l’historique.
Une clarification ultérieure des règles peut être importante pour interpréter le résultat final, mais un enregistrement historique de décision doit toujours montrer ce que le processus savait à ce moment-là. Ce sont deux perspectives utiles : l’ensemble des informations disponibles à l’époque et l’interprétation qui a finalement fait autorité. Elles ne doivent pas être fusionnées sans explication.
Le guide de l’analyse des marchés Kalshi souligne l’importance de règles de détermination exactes dans le contexte d’une autre plateforme. Un projet de recherche portant sur plusieurs plateformes doit préserver séparément le sens de chaque contrat. La similitude des titres ou la conversion des prix en pourcentages ne suffit pas à établir que les instruments offrent des versements équivalents.
Préserver la disponibilité des informations à chaque instant
La disponibilité à un instant donné décrit le moment où un processus particulier aurait pu utiliser un enregistrement. L’heure de l’événement à la source, l’heure de publication, la réception locale et le stockage ultérieur peuvent différer. Une simulation historique ne doit pas utiliser un enregistrement avant son heure de disponibilité pertinente au seul motif que son horodatage à la source est antérieur.
Dans un cas fictif, une cotation porte une heure à la source de 11:59:58, mais parvient au collecteur à 12:00:03. Une décision prise par ce collecteur à 12:00:00 ne pouvait pas utiliser cette cotation, à moins que des éléments distincts n’établissent une réception antérieure par une autre voie. Trier uniquement selon l’heure à la source peut introduire un biais d’anticipation.
Conservez à la fois les heures à la source et les heures de réception lorsqu’elles sont disponibles, et expliquez les champs manquants. Ne remplacez pas une heure à la source inconnue par l’heure de réception sous le même libellé. Le jeu de données peut toujours servir à des recherches utiles dont les affirmations temporelles sont plus limitées, à condition que cette limite reste visible et que l’évaluation la respecte.
Définir l’univers admissible avant de connaître les résultats
Un jeu de données de recherche Polymarket doit consigner quels contrats étaient admissibles selon les règles de l’étude au moment pertinent. Ne sélectionner que les marchés actifs aujourd’hui ou ceux dont les résultats sont mémorables peut introduire des effets de survivance et de sélection. L’échantillon risque d’omettre précisément les cas difficiles à négocier ou à interpréter.
Définissez l’admissibilité à partir de critères observables tels que la famille de contrats, la clarté des règles, l’horizon et la couverture des données requise. Appliquez la règle de manière cohérente et conservez les candidats exclus avec les motifs de leur exclusion. Ne retirez pas un contrat parce que son résultat final donne une moins bonne image de la stratégie proposée.
Le guide d’une stratégie Kalshi montre pourquoi une routine reproductible nécessite un univers de contrats défini. Le même principe s’applique à la construction d’un jeu de données. Le chercheur doit pouvoir expliquer quelles occasions le processus aurait envisagées de manière prospective, y compris celles qui ont ensuite disparu d’une liste de découverte pratique.
Distinguer quatre types de données manquantes
L’absence d’éléments probants à la source, une lacune de collecte, une issue non résolue et un contrat délibérément exclu sont des situations différentes. Elles ne doivent pas être représentées par un même champ vide sans explication. Chacune influe différemment sur l’interprétation et l’évaluation.
Une lacune de collecte signifie que le processus manque d’observations pendant un intervalle. Une issue non résolue signifie que l’étiquette cible n’est pas encore disponible. Un contrat exclu peut se trouver hors du périmètre de l’étude malgré des données complètes. Une source manquante peut signifier que les éléments nécessaires étaient indisponibles alors même que les prix du marché ont été enregistrés.
Utilisez des codes de motif clairs et des descriptions compréhensibles. Le chercheur peut alors déterminer si les données manquantes se concentrent autour de périodes volatiles, de contrats inhabituels ou de défaillances opérationnelles. Cette répartition peut compter davantage que le pourcentage global de lignes complètes, car les observations manquantes peuvent différer systématiquement de celles qui ont été conservées.
Quantifier l’effet des résultats manquants
Considérons un échantillon fictif de 120 prévisions admissibles. Quatre-vingt-dix ont des résultats binaires observés, dont cinquante-quatre résultats Oui, tandis que trente résultats restent manquants. La fréquence observée des Oui parmi les quatre-vingt-dix est de 60 %. Elle ne décrit pas automatiquement l’ensemble de l’échantillon admissible.
Si les trente résultats manquants étaient tous Non, la fréquence des Oui sur l’ensemble de l’échantillon serait de 54 divisé par 120, soit 45 %. S’ils étaient tous Oui, elle serait de 84 divisé par 120, soit 70 %. Il s’agit de bornes logiques sous l’hypothèse binaire simple, et non d’intervalles de confiance statistiques.
Cet exemple montre pourquoi ne présenter que les cas complets peut masquer l’incertitude. Le chercheur doit examiner pourquoi des étiquettes manquent et si le sous-ensemble observé diffère des cas omis. Un pourcentage précis calculé à partir des lignes disponibles peut être arithmétiquement correct tout en n’étayant qu’une affirmation bien plus limitée que ne le laisse entendre le rapport.
Recommandez et gagnez des USDC
Recommandez et gagnez des USDCNotre programme d’affiliation paie en temps réel.
Représenter fidèlement les étiquettes non résolues et les cas exceptionnels
Ne forcez pas chaque contrat dans la catégorie Oui ou Non avant que sa résolution effective ne justifie cette étiquette. Un marché peut rester non résolu, faire l’objet d’une contestation ou comporter une disposition exceptionnelle. Le jeu de données doit préserver l’état officiel et les informations de versement applicables plutôt que d’inventer une réponse binaire par commodité.
La documentation sur la résolution de Polymarket décrit les sources définies par les règles et les cas limites. Une étude centrée sur les résultats binaires simples peut définir des règles d’admissibilité pour les cas exceptionnels, mais ces règles doivent être établies et divulguées plutôt qu’appliquées sélectivement après avoir pris connaissance des résultats.
La disponibilité des étiquettes compte également. Un modèle entraîné à un moment historique donné ne peut pas utiliser un résultat final qui n’était pas encore connu. Conservez l’heure à laquelle l’étiquette est devenue disponible pour le processus de recherche et distinguez-la de l’heure de fin apparente de l’événement sous-jacent.
Traiter les changements de schéma comme des événements du jeu de données
Un changement de schéma peut modifier les noms des champs, la précision, les structures d’enveloppe ou l’interprétation. Consignez la version de la source et celle de l’analyseur utilisées pour chaque lot. Un jeu de données normalisé doit indiquer quand une transformation a changé et si les anciens enregistrements ont été retraités.
Consultez la documentation actuelle avant de supposer que d’anciens exemples de clients décrivent encore l’interface active. Réussir à analyser une réponse ne prouve pas la compatibilité sémantique. Un nouveau champ peut être présent alors qu’une ancienne hypothèse sur les unités ou le sens reste intégrée à l’analyse.
Le guide plus ancien du collecteur de carnets d’ordres Polymarket explique comment assurer une collecte fiable. Étendez cette rigueur aux migrations : testez des enregistrements connus, conservez les entrées brutes et comparez les sorties dérivées avant de remplacer une transformation. Si le changement modifie des valeurs historiques, publiez une version du jeu de données et expliquez quelles analyses sont concernées.
Préserver les valeurs décimales sans arrondi prématuré
Les prix, les quantités et les valeurs calculées doivent conserver une précision suffisante pour la recherche prévue. Un prix arrondi pour faciliter l’affichage peut convenir à un graphique, mais pas à la reconstitution d’une faible marge de coûts. Conservez les représentations décimales brutes et utilisez une arithmétique exacte lorsque le calcul l’exige.
Consignez la règle d’arrondi séparément de la valeur stockée. Si une analyse arrondit délibérément les prix à une grille plus grossière pour une étude, il s’agit d’une transformation à documenter. Il ne faut pas la confondre avec les incréments de négociation effectivement valides à la source à cette époque.
Il en va de même pour les quantités et les frais. Un modèle qui suppose que chaque observation représente des parts entières peut déformer les enregistrements contenant des quantités fractionnaires. Un jeu de données doit expliciter les unités et la précision afin que les calculs ultérieurs n’héritent pas d’une simplification commode mais sans fondement.
Stocker les carnets d’ordres en fonction de la question d’exécution
Un jeu de données destiné à estimer les coûts d’exécution doit contenir suffisamment d’informations sur le carnet d’ordres pour la quantité envisagée. Une série de dernières transactions ou un graphique du prix médian entre achat et vente ne peut pas reconstituer une profondeur historique qui n’a jamais été collectée. L’étude doit identifier cette limite avant de simuler des exécutions.
Si seules les données des meilleurs prix à l’achat et à la vente sont disponibles, l’analyse peut formuler une affirmation limitée à ce niveau de prix et à cette quantité observés. Elle ne doit pas accorder à un ordre hypothétique important un accès illimité au même prix. De même, un instantané pris chaque minute n’établit pas ce qui était disponible entre les instantanés.
Le guide des données Kalshi offre un autre point de vue sur la planification d’un jeu de données, dans le contexte d’une autre plateforme. Les recherches sur plusieurs plateformes doivent préserver les limites d’échantillonnage et de couverture de chaque source. Des noms de colonnes identiques ne rendent pas un flux dense et des archives d’instantanés espacés aussi instructifs l’un que l’autre sur les occasions d’exécution de courte durée.
Dédoublonner les enregistrements sans supprimer d’événements légitimes
La répétition de messages de transport ne doit pas créer des observations économiques répétées. Utilisez des identifiants stables et la sémantique documentée de la source pour repérer les doublons ou les révisions. Une correspondance fondée uniquement sur le prix, la quantité et l’heure peut fusionner à tort des transactions distinctes qui partagent fortuitement ces valeurs.
Conservez une trace des décisions de dédoublonnage. Le jeu de données nettoyé doit expliquer combien d’enregistrements bruts ont été regroupés en un événement normalisé, et pourquoi. Un changement de schéma ultérieur peut imposer de revoir cette logique, ce qui est beaucoup plus facile lorsque les éléments bruts restent disponibles.
Pour les données de carnet d’ordres, une observation répétée de l’état peut toujours porter une nouvelle heure de réception, même si les niveaux restent inchangés. Décidez si la recherche a besoin des deux observations et documentez ce choix. Le dédoublonnage est une décision de modélisation sur l’identité et l’échantillonnage, et pas simplement un exercice de réduction de la taille des fichiers.
Construire les variables uniquement à partir d’informations antérieures
Une variable doit être calculée à partir d’enregistrements disponibles avant la décision qu’elle est censée éclairer. Une moyenne glissante qui comprend le résultat courant, une valeur source révisée ou une cotation ultérieure peut laisser fuiter des informations futures, même si le jeu de données final est trié chronologiquement.
Définissez la limite temporelle de chaque variable et testez-la avec des exemples délibérément délicats. Un enregistrement arrivant après la décision ne doit pas entrer dans la variable au seul motif que l’horodatage de son événement est antérieur. Une correction ultérieure ne doit apparaître qu’au moment où elle est devenue disponible selon le modèle d’information choisi pour l’étude.
Le guide plus ancien de l’analyse des marchés de prédiction explique comment interpréter les mesures. La construction du jeu de données ajoute l’exigence que chaque mesure soit disponible à temps. Une formule valide appliquée à un ensemble d’informations invalide peut produire un résultat impressionnant qu’aucun processus réel n’aurait pu atteindre.
Séparer les échantillons d’évaluation par événement et dans le temps
Les contrats liés à un même événement sous-jacent doivent rester ensemble lors de la séparation des échantillons de développement et d’évaluation. Sinon, des informations sur le même événement peuvent se retrouver des deux côtés de la séparation. Le nombre réel de tests indépendants peut alors être bien inférieur à ce que suggère le nombre de lignes.
Utilisez une séparation chronologique lorsque l’usage prévu est la prévision d’événements futurs. Réservez une période ultérieure qui n’a pas servi à choisir les variables, les seuils ou les exclusions. Si la conception change après l’examen de cette période, celle-ci devient un ensemble d’éléments de développement pour la nouvelle version, plutôt qu’un nouveau test indépendant.
Indiquez la composition de l’échantillon ainsi que sa taille. Les familles d’événements, les horizons, la liquidité et la répartition des données manquantes peuvent différer d’une période à l’autre. Une variation des performances peut refléter cette composition plutôt qu’un changement universel de la qualité du modèle. Le jeu de données doit permettre ces comparaisons sans obliger le chercheur à reconstituer de mémoire l’admissibilité.
Séparer les données publiques de recherche des comptes privés
Les enregistrements publics de marché peuvent servir à analyser les prix et l’activité, mais ils n’établissent pas automatiquement l’intégralité des positions ou des résultats d’un utilisateur individuel. La recherche sur les performances d’un compte exige un accès autorisé aux ordres privés, aux exécutions, aux frais et aux autres enregistrements pertinents, avec leur propre provenance et leurs propres contrôles d’accès.
Ne déduisez pas l’identité ou les motivations privées d’une personne à partir d’une adresse publique de portefeuille. Le jeu de données peut décrire l’activité observable et l’incertitude sans y associer d’affirmations personnelles non étayées. La visibilité publique d’un enregistrement ne rend pas valide toute interprétation concernant le participant.
Si des données publiques et privées sont jointes pour une étude autorisée, conservez les éléments justifiant la jointure et protégez les informations sensibles du compte. Les résultats de la recherche ne doivent comprendre que ce qui est nécessaire à l’affirmation avancée. L’évaluation d’un modèle nécessite rarement des identifiants de connexion réutilisables ou des renseignements personnels superflus dans ses fichiers d’analyse.
Publier une fiche du jeu de données pour examen
Une fiche de jeu de données explique brièvement la question, l’unité d’observation, les sources, la couverture temporelle, les règles d’admissibilité, les transformations et les limites connues. Elle doit identifier les versions et expliquer comment sont représentés les cas manquants ou exceptionnels. Cela rend les archives utilisables par une personne qui ne les a pas constituées.
Précisez les affirmations que le jeu de données ne peut pas étayer. Des archives d’instantanés peuvent permettre une analyse générale des écarts entre achat et vente tout en manquant des détails nécessaires à une simulation exacte de la position dans la file d’attente. Un ensemble complet de résultats peut être dépourvu de prévisions contemporaines et donc ne pas convenir à l’évaluation d’un signal historique sans éléments supplémentaires.
La fiche doit évoluer lorsque le jeu de données change. De nouvelles sources, des schémas retraités ou des étiquettes corrigées peuvent affecter les résultats antérieurs. Versionner cette explication avec les données donne au chercheur une référence fiable pour interpréter les différences entre les analyses, plutôt que de considérer chaque rapport régénéré comme directement comparable.
Rendre reproductible le sens des données Polymarket
Un jeu de données de recherche doit préserver le chemin qui mène de l’observation brute à l’enregistrement normalisé, à l’échantillon admissible, à la variable disponible à temps et à l’étiquette vérifiée. La provenance, les versions des schémas et les données manquantes font partie de ce chemin ; ce ne sont pas des détails administratifs facultatifs ajoutés après la modélisation.
Partez d’une question précise et conservez les informations nécessaires pour la tester honnêtement. Séparez la disponibilité à l’époque des connaissances ultérieures, préservez les définitions des contrats et évitez de prétendre disposer de détails d’exécution historiques qui n’ont jamais été observés. Évaluez les enregistrements liés au niveau de l’événement approprié.
Le jeu de données le plus solide est celui dont les limites peuvent être énoncées clairement et dont les transformations peuvent être reproduites. Il permet au lecteur de comprendre pourquoi un résultat est apparu et si les éléments disponibles étayent la conclusion proposée. Ce socle est plus durable qu’un nombre impressionnant de lignes constitué d’enregistrements dont le sens ou les repères temporels ont été perdus.