Chronometrica ou API Dojo : données de profils TikTok sans collecte de publications

Partez du résultat dont votre application a besoin

Dans une question publique sur la collecte de données TikTok, un développeur décrit une application qui a besoin d’informations sur des profils publics après l’arrêt de ses anciennes méthodes de collecte. Cela soulève une question pratique : quel service convient à une liste de profils connus ? Cela ne permet pas de déterminer quel service restera le plus fiable.

Décrivez le résultat requis avant de choisir un Actor. Pour une liste de profils, ce résultat peut comprendre un identifiant de compte stable, un nom affiché, un nombre d’abonnés et une date d’observation. Un identifiant est une valeur qui permet d’associer un enregistrement à un compte. La date d’observation indique quand les données ont été vérifiées.

Un besoin de publications change la tâche. Si votre application doit afficher des légendes récentes, comparer des publications ou appliquer des filtres sur leurs dates, une ligne de données de profil ne peut pas fournir les éléments requis. Le nombre total de vidéos ne contient ni les vidéos ni leur texte.

Cette distinction vous aide aussi à définir une règle d’acceptation claire. Vous pouvez vérifier si un profil renvoyé contient les champs nécessaires à votre application. Vous n’avez pas à évaluer le résultat selon le nombre total de champs renvoyés.

Pour une collecte limitée aux profils, définissez la réussite comme un compte correctement identifié avec les données requises. Conservez une place pour chaque entrée non résolue. Un résultat manquant doit rester visible afin que l’application puisse signaler les limites de ses données actuelles.

À quels besoins répondent les contrats des 2 Actors

Chronometrica accepte les URL ou les noms d’utilisateur de profils TikTok publics dans `startUrls`. Sa documentation prévoit un résultat à plat correspondant à chaque entrée unique. Un résultat à plat regroupe les champs du profil dans une seule ligne. L’Actor ne collecte ni vidéos ni listes d’abonnés. Ce contrat ciblé convient à une liste de profils fournie. Contrat de Chronometrica, schéma d’entrée.

API Dojo TikTok Profile Scraper renvoie des données de profil dans un processus axé sur les publications. Ses règles d’utilisation publiées préconisent des profils ayant au moins 10 publications et mettent en garde contre des limites de résultats très basses ou une date limite très proche. Considérez ces règles comme des conditions d’adéquation. Elles ne prouvent pas que chaque exécution sur un profil vide échoue. Contrat d’API Dojo.

Il s’agit de différences entre les contrats, pas de différences de performances mesurées. Vérifiez les versions actuelles du schéma d’entrée de Chronometrica et du schéma d’entrée d’API Dojo avant de configurer une tâche.

Choisissez les champs de profil qui rendent une ligne utile

Les champs documentés de Chronometrica couvrent l’identité, certaines données publiques et l’état de l’observation. Les champs pertinents comprennent `input`, `channelId`, `secUid`, `channelUrl`, `handle`, `displayName`, `description`, `bioLink`, `followersCount`, `followingCount`, `likesCount`, `videosCount`, `countPrecision`, `status`, `statusReason` et `observedAt`. Les valeurs manquantes restent `null`, ce qui signifie qu’aucune valeur n’est disponible. Contrat de Chronometrica.

Attribuez un rôle clair à chaque champ requis. Par exemple, votre application peut utiliser un identifiant de compte pour associer les enregistrements, `displayName` pour nommer un profil et `followersCount` pour afficher son nombre public d’abonnés. L’application peut stocker d’autres données sans en faire des conditions pour qu’une ligne soit utile.

Distinguez l’identité des libellés. Un nom affiché aide une personne à lire la liste. Il ne permet pas d’établir l’identité du compte. Un nom d’utilisateur peut changer. Vérifiez les champs d’identité renvoyés avant d’ajouter de nouvelles données à un enregistrement existant de l’application.

Conservez aussi l’entrée d’origine. Elle permet de relier la ligne renvoyée au nom d’utilisateur ou à l’URL qui a déclenché la vérification. C’est important lorsqu’un libellé renvoyé diffère de celui que votre application avait stocké. N’acceptez pas cette différence sans la signaler et sans vérifier qu’il s’agit du même compte.

Interprétez les compteurs en tenant compte de leurs limites. Un nombre d’abonnés ne permet ni d’identifier les abonnés ni de mesurer la qualité de l’audience. Un nombre de vidéos n’indique ni la qualité des publications ni l’adéquation du créateur. Si vous utilisez `accountRegion`, considérez ce champ comme un indice public lié au compte. Il ne prouve pas le lieu de résidence d’une personne. Contrat de Chronometrica.

N’exigez que les données dont votre application peut se servir. Si elle a besoin de l’identité et du nombre d’abonnés, une biographie manquante ne rend pas nécessairement la ligne inutilisable. Votre règle d’acceptation doit le préciser avant le début de la collecte.

Configurez l’entrée pour une collecte limitée aux profils

Le schéma public actuel de Chronometrica comporte un seul champ d’entrée : `startUrls`. Il accepte les URL ou les noms d’utilisateur des profils publics à vérifier. Vous n’avez pas besoin d’ajouter une limite de publications, un filtre de dates ou une option de collecte limitée aux profils. Le contrat de l’Actor est déjà limité aux profils. Schéma d’entrée de Chronometrica.

Cet exemple minimal a passé une vérification du schéma. Il n’a pas été exécuté et la disponibilité actuelle du profil d’exemple n’a pas été testée. Remplacez l’URL par celle d’un profil public que votre application doit vérifier.

{
  "startUrls": [
    "https://www.tiktok.com/@mrbeast"
  ]
}

La Task TikTok Profile Data API Dataset fournit une configuration d’entrée enregistrée. Une Task est une configuration d’entrée enregistrée pour un Actor. Examinez son entrée avant de l’utiliser pour vérifier qu’elle contient les profils que vous souhaitez contrôler.

Les entrées strictement identiques ne sont vérifiées qu’une fois. Tenez compte de cette règle si la liste de votre application contient des doublons. Décidez si votre application mesure la couverture par profil unique ou par enregistrement de sa propre liste. Précisez ensuite ce choix dans les rapports. Contrat de Chronometrica.

Utilisez une méthode d’acceptation simple

Utilisez la méthode suivante pour transformer les données renvoyées en un enregistrement utile à l’application. Cette méthode part du résultat requis et aboutit à une décision pour chaque profil fourni.

1. Définissez les champs requis et le besoin de publications. Rédigez une règle courte qu’une autre personne pourrait appliquer au même résultat. Par exemple, exigez que l’identité du compte corresponde et que le nombre d’abonnés soit présent. Précisez si le texte, l’historique ou les dates des publications sont requis. Cela détermine si un Actor limité aux profils peut accomplir la tâche.
2. Gardez chaque entrée fournie liée à son enregistrement dans l’application. Enregistrez le nom d’utilisateur ou l’URL d’origine avant la collecte. Conservez l’identifiant propre à l’enregistrement de l’application, s’il existe. Ne vous servez pas du seul nom affiché renvoyé pour relier les données à la liste. Gérez les entrées répétées sans perdre les enregistrements de la liste qui en dépendent.
3. Vérifiez l’identité avant de rattacher les données. Comparez les champs d’identité renvoyés avec ce que votre application connaît déjà. Utilisez des identifiants de compte stables lorsqu’ils sont disponibles. Si vous ne pouvez pas établir de correspondance, laissez l’enregistrement non résolu. Un nom plausible ne suffit pas à rattacher un nombre d’abonnés récemment relevé à un compte existant.
4. Examinez les champs d’observation ensemble. Consultez `status`, `statusReason`, `countPrecision` et `observedAt`. Ces champs vous aident à évaluer les données renvoyées et leurs limites. N’inventez pas de signification pour des valeurs que vous n’avez pas vérifiées. Déterminez si la précision disponible des compteurs répond à la règle de votre application. Gardez les entrées non résolues dans la liste avec l’état effectivement renvoyé. Contrat de Chronometrica.
5. Distinguez 0, les données manquantes et l’admissibilité. Un 0 explicite est une valeur de compteur. Un compteur manquant n’a aucune valeur disponible. L’admissibilité est la décision de votre application quant au respect de sa règle par la ligne. Ce sont des notions différentes. Ne remplacez jamais un nombre d’abonnés manquant par 0 pour simplifier un calcul ou la création d’un écran.
6. Enregistrez les données avec leur date d’observation. Un compteur actuel permet de décrire l’observation actuelle. Il ne permet pas d’établir une valeur passée. Enregistrez séparément les observations suivantes si votre application doit comparer les compteurs dans le temps. Si vous conservez une ancienne valeur après l’échec d’une mise à jour, gardez sa date d’origine pour que l’application ne la présente pas comme récente.
7. Réexaminez le choix de collecte lorsque les besoins changent. Une ligne de profil utile peut quand même ne pas contenir les éléments nécessaires à une nouvelle fonctionnalité. Si une fonctionnalité a besoin du texte ou des performances des publications, définissez les champs requis et choisissez un outil de collecte de publications. Ne déduisez pas les éléments manquants des totaux du profil.

Limitez la première vérification pour pouvoir l’examiner à la main. Comparez les champs réellement renvoyés avec la règle d’acceptation. Si un champ requis est absent, consignez ce résultat avant d’ajouter des entrées. Ajouter des profils ne rend pas une règle d’acceptation plus claire.

Pour en savoir plus sur les états manquants et indisponibles, consultez le guide des statuts d’accès aux profils TikTok. Ici, la décision centrale reste de savoir si l’application a besoin de données de profil ou de publications.

Étudiez une liste de profils d’une application fictive

Tout l’exemple de cette section est fictif. Il décrit la liste de profils fournie à une application. Il ne s’agit ni d’une exécution d’Actor, ni d’un test comparatif, ni d’un résultat client. Il ne montre pas que les données d’un compte vide particulier peuvent être collectées.

L’application fictive dispose de 3 profils fournis : A, B et C. Sa règle déclarée exige que l’identité du compte corresponde et que le nombre d’abonnés soit présent. Elle n’exige ni texte de publication ni nombre minimal de publications.

Le profil A possède un identifiant stable dont la correspondance est confirmée, un nom, un nombre d’abonnés renseigné et 60 publications publiques. Il répond à la règle de l’application, car son identité correspond et son compteur requis est présent.

Le profil B possède un identifiant stable dont la correspondance est confirmée, un nom, un nombre d’abonnés renseigné et un nombre de vidéos observé de 0. Il répond lui aussi à la règle. L’application n’exige pas de publications. Le nombre de vidéos égal à 0 ne le rend donc pas inadmissible.

Le profil C ne peut pas être résolu. L’application ne dispose pas d’un nombre d’abonnés récent et justifiable pour ce profil. C reste dans la liste comme non résolu. L’application ne doit ni qualifier C de profil vide ni lui attribuer 0 abonné.

Sur les 3 profils fournis, 2 répondent à la règle de l’application. La couverture de la liste en profils admissibles est donc :

`2 / 3 × 100 = 66.67%`

Ici, la liste désigne les profils fournis à l’application. La couverture est la part de cette liste qui répond à la règle déclarée. Ce pourcentage est un exemple portant sur les données d’une application. Ce n’est pas un taux de réussite de l’outil de collecte.

Le dénominateur inclut C, car C faisait partie de la liste d’origine. Si l’application retirait les profils non résolus avant le calcul, elle annoncerait une couverture calculée sur une liste plus courte. Cela masquerait les données manquantes dans la liste fournie.

Le contrat de Chronometrica limité aux profils convient à ce besoin fictif. B illustre pourquoi il faut distinguer l’absence de publications des données de profil manquantes. Il ne prouve pas qu’une nouvelle recherche sur un vrai profil vide aboutira. Chaque entrée réelle doit avoir son propre résultat consigné.

Réévaluez le choix de collecte lorsque les éléments requis changent

Supposons que l’application fictive ait ensuite besoin des légendes des 10 dernières publications. Le résultat requis a changé. Le processus d’API Dojo axé sur les publications devient pertinent. Comparez son contrat actuel et ses paramètres d’entrée avec le nouveau besoin. Contrat d’API Dojo, schéma d’entrée.

Conservez les champs de profil dont vous avez déjà besoin, mais ajoutez une exigence claire pour les publications. Précisez les données de publication que la fonctionnalité doit recevoir et les filtres de dates nécessaires. Évaluez ensuite un outil de collecte selon ce résultat.

Un nombre de vidéos stocké ne peut pas répondre à une question sur les légendes. Un nombre d’abonnés actuel ne permet pas d’établir la croissance du nombre d’abonnés avant la première observation enregistrée. Choisissez la méthode de collecte selon les éléments dont la fonctionnalité a besoin, plutôt que selon le nombre de champs annoncés par un Actor.

Pour la tâche initiale limitée aux profils, ce contrat ciblé reste une bonne raison de choisir Chronometrica. Il correspond directement à l’unité de travail requise : une ligne de profil correctement associée à une entrée connue.