Vérifiez le statut du profil TikTok avant d'utiliser une donnée manquante

Utilisez votre propre profil connu

Un Actor est un programme hébergé de collecte de données. Une Task est un préréglage d'entrée enregistré. L'Actor TikTok Channel Scraper collecte des lignes de source. Vous décidez quelles lignes votre travail peut utiliser. L'Actor ne prend pas cette décision à votre place.

La Task publique actuelle est Bulk TikTok Profile Scraper. Son entrée d'exemple enregistrée contient deux URL publiques :

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

Remplacez ces URL d'exemple par vos propres URL de profils publics connus. Une Task publique n'est qu'une entrée de départ. Elle ne prouve pas que le contrôle ou la décision est automatique.

La version publique 0.1.27 a été contrôlée le 2026-10-13. Cette date de contrôle n'est pas l'heure d'une ligne. `observedAt` est l'heure sur une ligne de source. Utilisez `observedAt` quand vous jugez si une valeur est actuelle.

Envoyez seulement des profils connus

Le champ d'entrée est `startUrls`. Vous pouvez envoyer de 1 à 1 000 URL ou handles de profils connus. Un handle est le nom public après le signe @. Envoyez des profils que vous connaissez déjà.

Cette entrée ne recherche pas d'utilisateurs. Elle ne découvre pas de pays. Elle ne collecte pas de posts ni de commentaires. Elle ne récupère pas de coordonnées privées. Elle ne se connecte pas. Elle ne contourne pas un captcha ni un challenge.

Les chaînes d'entrée en double sont contrôlées une seule fois. Une ligne de résultat enregistre une tentative de contrôle d'un profil. Cette ligne n'est pas toujours un profil utile. Lancez un contrôle sur un profil prévu avant d'envoyer une longue liste.

Lisez d'abord ces champs

Examinez `input`, `channelId`, `channelUrl`, `handle`, `status`, `statusReason`, `isBillable` et `observedAt` sur chaque ligne. `channelId` est l'identifiant source de ce profil. `status` est le résultat source de cette tentative. `statusReason` dit pourquoi le statut a été défini, quand une raison est présente.

Les champs facultatifs peuvent inclure `followersCount`, `bioLink`, `description`, `detectedEmails` et `accountRegion`. Quand `countPrecision` est présent, il indique la qualité d'un nombre. Lisez-le avec ce nombre. Ne l'ignorez pas.

`isBillable` est une donnée de facturation sur une ligne. La donnée indique si la ligne est éligible à une facturation. Éligible signifie que la ligne peut être facturée. La donnée n'est pas la preuve d'une facturation réelle. Un reçu de facturation prouve une facturation. `isBillable` ne prouve pas qui est le profil. Il ne prouve pas que chaque champ est complet. `billableRows` compte les lignes éligibles à une facturation. Ce nombre n'est pas une preuve de paiement.

Gardez chaque statut de source selon le schéma actuel. Le statut change ce que vous faites ensuite :

• `ok` signifie que le profil est revenu. Il vous faut encore une identité correspondante et vos champs obligatoires. Un champ facultatif peut encore être null.
• `partial` signifie que le profil est revenu, mais que la ligne est incomplète. N'écartez pas toute la ligne avant d'avoir contrôlé chaque champ obligatoire.
• `private` signifie que la partie privée reste indisponible. Ne traitez pas la ligne comme un zéro public.
• `login_required` signifie que la source a demandé une connexion. Arrêtez. Cet Actor ne se connecte pas.
• `not_found` signifie que le profil n'était pas visible dans ce contrôle. Il ne dit ni quand ni pourquoi. Il ne prouve pas une suppression.
• `blocked` signifie que l'accès à la source a été bloqué. Ne remplissez pas les champs manquants. Ne lisez pas le blocage comme zéro abonné.
• `challenge` signifie que la source a affiché un challenge. Ne le résolvez pas.
• `rate_limited` signifie que la source a limité le contrôle. Enregistrez la ligne. Vous pouvez planifier un nouveau contrôle plus tard. Ne réessayez pas en boucle.
• `parser_miss` signifie que le contrôle n'a pas lu les faits attendus. N'inventez pas ces faits.
• `invalid_input` signifie que le format de l'entrée n'était pas valide. Corrigez seulement un format dont vous pouvez montrer qu'il est incorrect.
• `failed` signifie que la tentative a échoué pour une autre raison de source. Enregistrez la raison et l'heure. N'inventez pas les faits manquants.

Une ligne indisponible ne prouve pas que le compte a été supprimé. Elle ne prouve pas que le compte n'a pas d'abonnés.

Sachez ce qu'un contrôle a fait et n'a pas fait

Le contrôle actuel 0.1.27 a utilisé un seul profil. La ligne correspondait au `channelId` prévu. Elle correspondait au `channelUrl` ou au handle prévu. Elle correspondait à `followersCount`. Son statut était `ok`.

Le champ facultatif `commerceCategory` était null. `isCommerce`, `isSeller` et `isPrivate` étaient false. Null signifie que la valeur n'a pas été donnée. False signifie que la source a donné un vrai non. Ne transformez pas false en valeur manquante. Ne transformez pas null en false. Ne copiez pas un `isCommerce` false dans le `commerceCategory` null.

Ce contrôle n'a pas testé les profils privés. Il n'a pas testé les profils bloqués. Il n'a pas prouvé que chaque champ de profil est complet. Un e-mail caché ou manquant ne peut pas être fabriqué. Si `detectedEmails` est null ou vide, cela ne prouve pas que le propriétaire n'a pas de contact public.

Comparez les totaux de l'exécution à votre liste

L'OUTPUT de l'exécution utilise ces noms exacts :

• `requestedChannels` est un nombre. Le nombre compte les tentatives d'entrée traitées. Le nombre est égal à `rows.length`. `rows.length` est le nombre de ces lignes de tentative. Ce nombre n'est pas la liste du registre d'origine. Le registre d'origine vous appartient. La liste reste séparée.
• `acceptedProfileInputs` est un nombre. Le nombre est égal à `rows.length` moins `rejectedInputs`.
• `rejectedInputs` est un nombre. Le nombre compte les entrées que l'exécution a refusées. L'exécution refuse les entrées non valides et les entrées non prises en charge. `rejectedInputs` n'est pas une liste.
• `datasetRows` est le nombre de lignes de profil renvoyées. Ces lignes enregistrent les tentatives de contrôle de profils.
• `usefulRows` est le nombre de lignes renvoyées que l'Actor marque comme utiles. L'Actor est le programme qui marque chaque ligne.
• `billableRows` est le nombre de lignes renvoyées éligibles à une facturation. Éligible signifie qu'une ligne peut être facturée. Le nombre n'est pas une preuve de paiement.
• `nonUsefulRows` est le nombre de lignes renvoyées qui ne sont pas utiles.
• `statusCounts` est le nombre de lignes renvoyées dans chaque statut. `datasetRows` et `statusCounts` décrivent les lignes renvoyées. Ils ne décrivent pas la liste du registre d'origine.

`datasetRows` n'est pas le nombre de profils contrôlés complets. Une exécution peut se terminer et contenir encore des cibles en échec. Une ligne utile peut encore manquer d'un champ que vous exigez. Une ligne facturable peut encore manquer d'un champ facultatif. Lisez la ligne. Ne vous arrêtez pas au total.

Nommez les champs dont votre travail a besoin

Avant d'écarter un profil partiel, listez les champs dont votre tâche suivante a besoin. Un champ dont vous n'avez pas besoin peut rester null. Un champ dont vous avez besoin doit être présent avant que vous acceptiez la ligne.

Pour chaque champ obligatoire, enregistrez la valeur source et un état de disponibilité. Utilisez un état seulement quand les données renvoyées par la source le justifient réellement :

• `present` signifie qu'une valeur est revenue. False est présent. Zéro est présent seulement quand la source a renvoyé zéro.
• `explicitly_empty` signifie que la source a renvoyé une valeur vide, par exemple une liste vide.
• `absent_or_unavailable` signifie que le champ est null, ou que la ligne n'a pas pu le fournir.
• `not_requested` signifie que cette tâche n'utilise pas ce champ.

Une liste vide n'est pas la même chose que null. Null est inconnu. N'enregistrez pas une valeur inconnue comme zéro.

Ceci est un enregistrement que vous écrivez. Ce n'est pas une ligne de sortie de l'Actor :

field: followersCount
source_value: null
availability: absent_or_unavailable
observedAt: the time on that source row

Contrôlez chaque profil dans cet ordre

1. Gardez votre registre d'origine de profils connus. Un registre est votre liste locale. Donnez à chaque ligne du registre sa propre clé locale. Lisez les états qui reviennent. Ne promettez pas un e-mail caché. Ne promettez pas un moyen de contourner un blocage. Ne promettez pas une réparation pour chaque échec de source. La même chaîne d'entrée est contrôlée une seule fois. Le nombre de lignes de votre registre et le nombre de tentatives distinctes peuvent différer. La clé locale garde chaque ligne du registre liée à la bonne observation.
2. Lancez d'abord un contrôle sur un profil prévu. Lisez l'identité renvoyée, le statut et `observedAt`. Contrôlez `channelId` quand il est présent. Contrôlez le handle et l'URL prévus. Un nom affiché connu ne suffit pas pour réparer une mauvaise cible. Faites d'abord correspondre l'identité. Cet article ne vous apprend pas à fusionner d'autres noms pour le même créateur. Après la correspondance de l'identité, vous décidez si les données sont utilisables.
3. Séparez un mauvais statut d'un champ vide. Le statut `ok` ou `partial`, avec une identité correspondante, peut encore avoir un `bioLink` facultatif null. Ce profil peut encore être utile. `blocked`, `challenge` et `login_required` signifient que la source n'a pas donné l'accès. `private` signifie que la partie privée reste indisponible. `not_found` ne vous dit pas quand le profil a cessé d'être visible. Il ne vous dit pas pourquoi.
4. Jugez chaque champ obligatoire séparément. Enregistrez la valeur source et l'état de disponibilité. Gardez false comme false. Gardez null comme inconnu. Gardez une liste vide séparée de null. Si votre tâche n'a pas besoin du champ, utilisez `not_requested`. Ne faites pas échouer le profil pour un champ que vous n'avez pas demandé à utiliser.
5. Comparez OUTPUT au registre. Comparez `acceptedProfileInputs` à vos entrées uniques. Comparez les lignes qui enregistrent les tentatives de contrôle à `datasetRows`. Lisez aussi `usefulRows`, `nonUsefulRows`, `rejectedInputs` et `statusCounts`. Ne signalez pas `datasetRows` comme des profils complets. Ne supposez pas que `billableRows` contient chaque champ facultatif.
6. Choisissez un état suivant pour chaque tentative distincte. Utilisez `accepted_for_required_fields` quand l'identité correspond et que chaque champ obligatoire est présent. Utilisez `useful_but_required_gap` quand l'identité correspond mais qu'un champ obligatoire manque. Utilisez `source_unavailable` quand la source n'a pas renvoyé le profil utilisable. Utilisez `identity_mismatch` quand l'identifiant, le handle ou l'URL n'est pas le profil prévu. Utilisez `invalid_input` quand le format lui-même est incorrect. Corrigez seulement un format dont vous pouvez montrer qu'il n'est pas valide. Un échec de source peut justifier un nouveau contrôle planifié plus tard. Il ne justifie pas une boucle de nouvelles tentatives. Il ne justifie pas la résolution d'un challenge. Gardez `observedAt` et `statusReason` avec l'observation.
7. Lors d'un rafraîchissement ultérieur, utilisez la même identité de source et les mêmes champs obligatoires. Si une ligne plus ancienne avait une valeur et que la nouvelle ligne est indisponible, vous n'avez pas d'observation actuelle. L'ancienne valeur est une donnée historique. Gardez sa date. Marquez la valeur actuelle comme inconnue. Ne reportez pas l'ancienne valeur comme valeur actuelle. Ne la changez pas en zéro. N'appelez pas le changement une baisse complète.
8. Écrivez un rapport de disponibilité. Ce rapport liste chaque profil, les champs obligatoires et chaque état non résolu. Utilisez une ligne seulement pour un travail dont les champs obligatoires sont présents. Gardez un manque dans la collecte séparé d'une affirmation sur le propriétaire. Un manque ne prouve pas l'absence de l'attribut ou de l'information sous-jacente chez le propriétaire. Il ne prouve pas non plus que le propriétaire n'a pas ce type de compte.

Choisissez accepter, partiel, réessayer ou revoir

L'état suivant décrit l'état des données. La décision du lecteur vous dit quoi faire. Utilisez l'une de ces quatre décisions : accepter, partiel, réessayer ou revoir.

Placez la ligne sur la liste de revue avant de penser à une autre exécution. Un nouveau contrôle plus tard est permis pour un échec de source tel que `rate_limited` ou `failed`. N'utilisez pas ce nouveau contrôle pour résoudre un challenge. Ne l'utilisez pas pour vous connecter. Ne l'utilisez pas pour ouvrir un profil privé. `challenge` reste en revue, parce que cet Actor ne résout pas les challenges. `login_required` reste en revue, parce que cet Actor ne se connecte pas. `private` reste indisponible. Un second appel ne rend pas publiques les données privées.

Apprenez les décisions avec une fiction originale

Les tableaux et les décomptes numériques de cette section sont une fiction originale. Ils ne sont pas un résultat de produit. Ils ne montrent pas un taux de réussite réel.

Le registre fictif a cinq lignes locales :

R1 et R2 utilisent la même chaîne d'entrée. Le contrôle accepte cette chaîne une seule fois. Vous gardez quand même cinq clés locales. L'exécution a quatre tentatives distinctes acceptées et quatre lignes de statut. Dans cette fiction, `acceptedProfileInputs` est 4. Cette fiction ne montre pas d'entrée refusée. Une exécution réelle peut encore donner `rejectedInputs` comme un nombre, donc vous devez lire ce nombre aussi.

Les lignes de statut fictives sont :

La tâche fictive a besoin de deux choses. `channelId` doit correspondre au profil prévu. Le `followersCount` actuel doit être présent.

R1 respecte les deux règles. L'identifiant est ID100. Le nombre actuel d'abonnés est 1 000, donc cette valeur est présente. `bioLink` est null. Cette tâche n'exigeait pas `bioLink`, donc le lien null reste inconnu. Vous n'inventez pas de lien. R1 est le seul profil distinct que vous pouvez accepter pour cette tâche. La décision du lecteur est accepter.

R2 n'est pas un deuxième créateur. C'est la même entrée que R1, et elle correspond à la même observation. Gardez la clé R2 pour que votre registre puisse expliquer le doublon. Ne comptez pas R2 comme un autre profil avec 1 000 autres abonnés.

R3 correspond à ID200, donc l'identité est bonne. Le statut est `partial`. Le nombre d'abonnés est null. Null n'est pas zéro, et la tâche exige ce nombre. Le lien de bio est présent, mais il ne peut pas remplacer le nombre d'abonnés manquant. R3 est `useful_but_required_gap`. La décision du lecteur est partiel. Gardez R3, et ne l'utilisez pas pour un travail qui a besoin du nombre actuel d'abonnés. Une ligne de source utile peut encore échouer à votre propre règle de champ.

R4 a le statut `private`. Ses faits obligatoires ne sont pas utilisables. R5 a le statut `blocked`. Ses faits obligatoires ne sont pas utilisables. Les deux sont `source_unavailable`. La décision du lecteur est revoir. Ne lisez aucune des deux lignes comme un compte supprimé. Ne lisez aucune des deux lignes comme zéro abonné. Cette fiction ne donne pas de `channelId` pour R4 ou R5. N'en inventez pas.

Les `statusCounts` fictifs suivent ces quatre lignes : un `ok`, un `partial`, un `private` et un `blocked`. Si ces quatre lignes sont vos `datasetRows`, le nombre est de 4 tentatives. Ce nombre n'est toujours pas 4 profils complets. Un profil distinct respecte la règle de l'identifiant et du nombre actuel d'abonnés. Une ligne, R3, a un manque sur un champ obligatoire. Deux lignes, R4 et R5, sont indisponibles. Ne transformez pas 1 profil accepté sur 4 tentatives en un taux de réussite réel.

Une deuxième observation fictive d'ID100 revient `blocked`. Gardez la valeur antérieure de 1 000 abonnés. Gardez la date de cette observation antérieure. Le nombre actuel est inconnu. Ne signalez pas zéro. Ne signalez pas une baisse de 100 %. La valeur antérieure de 1 000 est une donnée historique. Ce n'est pas le nombre actuel, et vous ne le reportez pas comme actuel.

Utilisez une paire fictive de plus pour que false et null restent séparés. Une valeur `isSeller` séparée égale à false est présente. La source a dit non. Une valeur `isSeller` séparée égale à null est inconnue. Elle ne signifie pas non. Aucun état de cette fiction ne prouve que le propriétaire n'a pas de contact public.

Restez dans le cadre de l'acceptation d'un profil

Cet article enseigne seulement comment accepter des données de profil. Vous contrôlez l'identité, le statut, l'heure et les champs dont votre tâche a besoin. Ensuite, vous acceptez la ligne, vous la gardez partielle, vous planifiez un nouveau contrôle, ou vous la revoyez.

Trier les profils par type de compte est une tâche séparée. Les retours sont une tâche séparée. Les anciens nombres de posts sont une tâche séparée. Cette méthode ne fait pas de scraping des profils privés. Elle ne renvoie pas de listes d'abonnés. Elle ne découvre pas de contacts. Elle ne construit pas un historique de croissance. Une valeur actuelle manquante est un manque dans ce contrôle. Ce n'est pas un changement mesuré.