Repérer les tendances TikTok avec un ensemble fixe de sujets

Définir les entrées de recherche et les limites du pilote

La version publique actuelle de TikTok Search, build 1.1.5, accepte des entrées natives exactes : `queries` (tableau de chaînes), `expandQueries` (booléen), `maxExpandedQueries` (entier), `maxResults` (entier), `resultsPerQuery` (entier), `maxPagesPerQuery` (entier) et `searchDistribution` ("balanced" ou "sequential"). Le champ `maxResults` fixe un maximum global de vidéos enregistrées distinctes pour toutes les requêtes. Le champ `resultsPerQuery` fixe le maximum de vidéos enregistrées distinctes par terme, bien qu’une répartition de recherche équilibrée puisse réduire cette limite effective par terme sans garantir une réallocation entre les termes.

Pour exécuter une première vérification pilote, remplacez les valeurs d’entrée enregistrées par défaut (tableau `queries` de trois requêtes d’exemple, `expandQueries` true, `maxExpandedQueries` 10, `maxResults` 150, `resultsPerQuery` 30, `maxPagesPerQuery` 2, `searchDistribution` "balanced") par une seule requête prévue dans le tableau `queries`. Utilisez des réglages de remplacement bornés : `expandQueries` false, `maxExpandedQueries` 0, `maxResults` 2, `resultsPerQuery` 2, `maxPagesPerQuery` 1 et `searchDistribution` "balanced".

Les sorties natives de recherche comprennent `postId`, `postUrl`, `authorId`, `profileHandle`, `publishedAt`, `query`, `rootQuery`, `querySource`, `pageIndex`, `pageRank`, `status`, `statusReason` et `observedAt`. Des champs de sortie comme `queryPlans` montrent seulement les requêtes et les sources prévues, pas les résultats réels d’exécution par requête. Les lecteurs doivent tenir un registre de tentatives indépendant à partir des preuves de l’exécution. Une exécution de contrôle avec "python tutorial" a renvoyé deux lignes de métadonnées et s’est arrêtée avec `max_results_reached`. Ses dates de publication étaient mai et août, ce qui prouve la provenance de base des champs de recherche, mais ne fournit aucune preuve de campagne en cours, de score de tendance ni de filtre de date automatique.

L’enregistrement de sortie fournit des métadonnées de collecte, notamment queriesSearched, queryPlans, maxResults, resultsPerQuery, effectiveResultsPerQuery, maxPagesPerQuery, searchDistribution, rowsSaved, fieldCoverage, candidateItemsSeen, rowsAddedBeforeGlobalDedupe, duplicatesSkipped, invalidCandidatesSkipped, stopReason, sourceStatusCounts, status et statusReason. Le champ queryPlans décrit les termes et les sources prévus, mais il n’enregistre pas les résultats individuels de réussite ou d’échec par requête. Les lecteurs doivent tenir leurs propres registres de tentatives à partir de la sortie collectée.

Réponse directe et méthode complète pour les candidats de tendance

Utilisez un ensemble fixe de sujets pour collecter des candidats, puis vérifiez les dates de publication, la pertinence et le nombre de créateurs distincts sur des observations répétées. Traitez une vidéo nouvellement trouvée comme une nouvelle observation jusqu’à la vérification de son heure de publication. Le résultat est un tableau d’examen de sujets, pas un graphique de tendances de la plateforme ni une prévision virale.

1. Définissez une décision de sujet et une fenêtre de publication récente avant la collecte. Par exemple, examinez si un format mérite un petit test original lors du prochain cycle de production. Conservez les familles de requêtes et les budgets déclarés exacts. Ne changez pas les termes en cours de route parce qu’un échantillon paraît prometteur. Le fil d’un lecteur et une recherche publique sans connexion ont des règles de sélection différentes.
2. Remplacez les sujets larges sans rapport de la Task enregistrée par l’ensemble de sujets prévu. Laissez les expansions désactivées pour une première répétition exacte, ou déclarez chaque famille de requêtes racines si les recherches associées sont incluses volontairement. L’entrée de recherche native n’a pas de filtre de date. L’inclusion récente est un examen, par le lecteur, de publishedAt et des preuves de source après la collecte, pas une promesse de filtre de date de l’Actor.
3. Rapprochez les requêtes tentées, les résultats des sources et les plafonds. Conservez les ID et URL des posts, les ID d’auteurs, la date de publication, observedAt et le code manuel de sujet ou de format. Une recherche qui renvoie des posts plus anciens fournit encore des candidats, mais peut ne pas répondre à une question de fenêtre récente. Les dates du contrôle actuel vérifié dataient de plusieurs mois ; ce contrôle n’est donc pas une preuve de tendance actuelle.
4. Séparez observedAt de publishedAt. La première observation signifie que le lecteur l’a trouvé dans les résultats de cet ensemble de sujets à ce moment. Elle ne signifie pas que le post a été publié alors, ni qu’il était auparavant inconnu sur TikTok. Les dates de publication inconnues restent inconnues et hors d’un décompte strict limité au récent tant qu’elles ne sont pas vérifiées. Ne convertissez pas la date de collecte en date de publication.
5. Appliquez manuellement les mêmes règles de pertinence du sujet et de fenêtre de publication. Examinez la vidéo publique réelle pour confirmer le format, pas seulement un hashtag large. Conservez le codage d’origine et le contexte. Comptez séparément les ID de posts connus distincts et les ID de créateurs connus distincts. Cinq vidéos liées d’un seul compte correspondent à un créateur connu ; les ID de créateurs manquants restent non résolus et séparés, et non un créateur partagé.
6. Relancez les recherches sur l’ensemble de sujets déclaré à un moment ultérieur enregistré lorsque le lecteur a besoin de preuves de persistance. Définissez un instantané comme une seule exécution des recherches sur cet ensemble à un instant donné. Enregistrez chaque instantané et ses arrêts de source. Comparez les ID nouvellement observés, les ID répétés et le nombre de créateurs distincts dans l’échantillon admissible. Les changements de recherche, les plafonds, les suppressions et la visibilité peuvent modifier l’ensemble. Aucune recherche publique répétée ne prouve une croissance à l’échelle de la plateforme ni une première découverte. Un instantané en échec empêche les comparaisons entre exécutions.
7. Construisez des états de sujet tels que insufficient_evidence, repeated_multi_creator_candidate et ready_for_small_original_test selon une règle éditoriale énoncée. Par exemple, exigez des vidéos récentes pertinentes d’au moins trois créateurs connus dans deux instantanés utiles avant un examen plus approfondi. Il s’agit du seuil du lecteur, pas d’une définition officielle de tendance ni d’une prédiction calibrée. Si un instantané a échoué, ne faites pas la comparaison.
8. Choisissez un candidat pour un examen manuel de la création et un petit test original. Notez pourquoi il convient au public et quelles preuves manquent encore. Les vues publiques peuvent fournir du contexte, mais l’âge, la taille du créateur et la visibilité diffèrent. N’additionnez pas des résultats de recherche partiels pour estimer la popularité sur la plateforme ni pour prédire la portée future.

Collectes répétées fictives originales sur un même ensemble de sujets

Le tableau de candidats suivant contient des données fictives originales à des fins d’enseignement. La fenêtre stricte de publication récente va du 6 octobre 2026 inclus à 00:00 UTC au 13 octobre 2026 exclus à 00:00 UTC.

L’intersection contient les ID de posts candidats qui apparaissent dans l’ensemble admissible des deux instantanés. L’union contient les ID de posts candidats qui apparaissent dans l’ensemble admissible de l’un ou l’autre instantané. Pour ces observations, l’ensemble d’intersection est {V2, V3}, soit deux ID de posts répétés. L’ensemble d’union est {V1, V2, V3, V6}, soit quatre vidéos admissibles distinctes chez trois créateurs connus (A, B et C). V6 a été observé pour la première fois pendant l’instantané S2 le 13 octobre, mais sa date de publication réelle est le 11 octobre. Ne qualifiez pas V6 de publié le 13 octobre.

Registre des décisions d’examen

Selon une règle stricte qui exige trois créateurs connus distincts dans *chaque* instantané individuel, l’état du sujet est marqué insufficient_evidence, parce que S1 n’avait que deux créateurs. Si l’on utilise un seuil plus faible qui exige trois créateurs distincts dans l’union des instantanés, l’état est ready_for_small_original_test. Aucun des deux seuils ne garantit une portée virale ni un statut de tendance automatisé.