Une publication est prévue à 00h15 au Vietnam, alors que le journal enregistre 17h15 UTC à la date précédente. Après l'heure prévue, le tableau de bord affiche failed, mais personne n'a vérifié le compte public. Devez-vous créer une nouvelle publication programmée immédiatement ?
Non. Confirmez d’abord que vous consultez le même instant, le même contenu et les mêmes identifiants de travail, ainsi que le bon compte fournisseur. Un changement de date entre ICT et UTC peut donner l'impression que la tâche correcte manque. Réessayer à une date erronée peut créer un doublon même si la première demande a déjà atteint le fournisseur.
La procédure ci-dessous aide les opérateurs à choisir parmi quatre actions : confirmer, attendre, réconcilier avant de réessayer ou conserver comme inconnu.
ICT et UTC peuvent avoir des dates différentes mais la même heure
L'heure du Vietnam utilise les TIC, qui sont UTC+7 et ne changent pas avec les saisons. Donc:
2026-08-15 00:15 ICT
= 2026-08-14T17:15:00ZLes deux valeurs correspondent à des dates calendaires différentes mais correspondent à la même heure. Lorsque vous vérifiez un travail au-delà de 0 heure, ne comparez pas le nombre de jours ou d'heures séparément. Enregistrez également l'heure locale, le fuseau horaire et les valeurs UTC standard.
| Champ de temps | Exemple | Objectif |
|---|---|---|
scheduled_at_local |
2026-08-15 00:15 ICT |
Article approuvé par l'opérateur |
scheduled_at_utc |
2026-08-14T17:15:00Z |
Clé publique pour comparer les journaux entre les systèmes |
observed_at |
2026-08-15 00:23 ICT |
Lorsque le message original est vérifié |
Si ces trois champs ne sont pas séparés, un travail ponctuel pourrait être étiqueté avec un jour de retard. Cependant, la modification du fuseau horaire ne fait que corriger la comparaison ; cela ne prouve pas que l'article a été publié.
Suivez la chaîne d'identification existante au lieu de créer une nouvelle demande
Chaque étape peut générer un identifiant différent. Mettez-les sur la même ligne pour voir où s’arrêtent les preuves :
- content ID — objet de contenu enregistré ;
- job ID : la tâche de planification ou de publication est en cours de traitement ;
- ID de publication du fournisseur — objet que le réseau social a reçu ou créé ;
- URL du provider original — surface publique que les téléspectateurs peuvent inspecter.
L'existence d'un Content ID ne signifie pas que la tâche a été exécutée. L'existence d'un ID de poste ne signifie pas que le prestataire a créé le poste. L'ID de publication du fournisseur est plus puissant, mais vous devez toujours ouvrir la publication d'origine pour vérifier le compte, le contenu et la visibilité.
Une fois que vous avez l'ID du travail, relisez le travail correct. Créer de nouveaux contenus ou tâches simplement pour « voir s'ils fonctionnent » perd la relation entre la demande d'origine et le résultat public.
Une source de preuve par compte cible
Ne combinez pas plusieurs chaînes en un seul état. Pour chaque compte, sauvegardez au minimum :
channel/account:
scheduled_at_local:
scheduled_at_utc:
content_id:
job_id:
last_state + observed_at:
provider_post_id:
provider_original_url:
public_outcome:Enregistrez uniquement les données d’exploitation sûres. N'enregistrez pas les mots de passe, les jetons d'accès, les URL de téléchargement signées, les invites de confidentialité ou les données client dans le panneau des incidents.
le provider original doit être vérifié pour chaque composant
Une URL publique ne prouve pas que l’intégralité de l’article est correcte. Ouvrez la page du fournisseur et notez chaque composant :
| Ingrédients | Questions auxquelles répondre | Valeur suggérée |
|---|---|---|
| Compte | L'article se trouve-t-il sur le profil/la page approuvé ? | vrai / faux / peu clair |
| Racine | Le texte et l'identifiant du fournisseur de la publication d'origine sont-ils corrects ? | vrai / manquant / faux |
| Répondre | La réponse existe-t-elle, dans le bon ordre et à la bonne racine ? | destination complète / manquante / erronée |
| Médias | Photo ou vidéo entièrement rendue ? | afficher/traitement/erreur |
| Lien | Existe-t-il une ancre cliquable avec le bon href ? |
cliquable / juste du texte / mauvaise destination |
La racine est publique mais la réponse manquante est un résultat partiel, pas une erreur complète. L'URL est visible dans la légende mais n'a pas d'ancre et ne constitue pas un chemin de clic complet. La séparation des composants vous aide à traiter uniquement la pièce manquante au lieu de republier la bonne pièce.
Quatre décisions après comparaison
1. Confirmation
Sélectionnez confirmer lorsque scheduled_at, la chaîne d'identification, le dernier statut et la publication d'origine correspondent. Le compte, la racine/réponse, le média et le lien sont tous corrects. Enregistrez l'URL avec l'heure d'observation, puis fermez le travail ; Ne réessayez pas de modifier une réponse API obsolète.
2. Attendez et réglez la prochaine heure de contrôle
Sélectionnez attendre pendant que la tâche est scheduled ou publishing, qu'elle possède un ID stable et qu'elle se trouve toujours dans une plage de traitement raisonnable. Précisez la prochaine date de contrôle. Attendre un délai est une action contrôlée ; Rafraîchir ou créer constamment de nouveaux emplois n’est pas une preuve.
3. Réconcilier avant de réessayer
Sélectionnez réconcilier lorsque le système signale une erreur mais que l'ID de publication du fournisseur, l'URL ou la publication sur un compte public existent peut-être déjà. Comparez la période de temps convertie ICT/UTC correcte, conservez l'ancien identifiant intact et déterminez quels composants sont réellement manquants. Si trois canaux sont corrects et qu’un canal n’est pas clair, ne réexécutez pas l’ensemble du lot.
4. Gardez le statut inconnu
Sélectionnez inconnu lorsqu'il n'y a pas d'ID stable et que les résultats ne peuvent pas être confirmés publiquement. Chưa rõ n'est pas synonyme de failed. Arrêtez les nouvelles tentatives automatiques et recherchez le dernier point avec des preuves avant d'autoriser de nouvelles demandes.
Exemple concret pour un quart de jour
Un petit groupe à Hô Chi Minh-Ville examine l'article à 23h50 ICT et fixe le programme pour 00h15 ICT. Le système enregistre 2026-08-14T17:15:00Z. À 00h17 ICT, le travail a été déplacé vers failed ; à 00h23 ICT, root apparaissait sur le bon compte mais la réponse contenait un lien qui n'était pas disponible.
Conclusion correcte :
- le fuseau horaire et la date ne sont pas faux : les deux fuseaux horaires sont la même heure ;
- le travail doit être conservé car l'ID associé à la racine est public ;
- le résultat est un échec partiel et non total ;
- réessayer l'intégralité du thread risque de créer des racines en double ;
- l'étape suivante consiste à comparer les réponses manquantes en fonction des capacités de la chaîne.
Cet exemple montre scheduled_at, l'ID et le message d'origine répondant à trois questions différentes. Ce n'est qu'en les plaçant côte à côte que l'opérateur saura quelle partie a été réalisée.
Utilisez un vérificateur pour classer, ne modifiez pas le provider original
Ouvrir gratuitement le vérificateur de preuves de publication sociale
Checker s'exécute localement dans le navigateur, ne nécessite pas de connexion et n'envoie ni n'enregistre les données que vous saisissez. Cela permet d’organiser les cinq éléments de preuve en quatre actions. Checker ne se connecte pas aux réseaux sociaux et ne vérifie pas les publications publiées ; L'URL du provider original reste la source finale des tests.
Questions fréquemment posées
Les TIC changent-elles de façon saisonnière comme certains autres fuseaux horaires ?
Non. Les TIC au Vietnam sont UTC+7 toute l'année. Cependant, enregistrez toujours le fuseau horaire avec scheduled_at afin que le journal international et l'interface locale soient comparés en même temps.
Que dois-je faire si j'ai un identifiant de poste mais pas d'identifiant de poste de fournisseur ?
Suivez l'ID de travail lui-même jusqu'à son statut final ou définissez la date d'échéance de l'inspection. Ne créez pas une nouvelle tâche simplement parce que le provider ID n'apparaît pas immédiatement.
La racine est publique mais la réponse est manquante. Est-ce une réussite ?
Veuillez écrire tel que partiellement publié. Conservez la racine correcte et comparez la réponse séparément ; Ne soumettez pas à nouveau l'intégralité du fil de discussion.
Si une URL apparaît sous forme de texte, les internautes peuvent-ils toujours cliquer dessus ?
Non. Vérifiez l'ancre et href sur le message d'origine. Une chaîne d'URL sans ancre n'est qu'un texte, pas un clic confirmé de l'opérateur.
Checker crée-t-il du contenu ou publie-t-il ?
Non. Checker trie uniquement les preuves dans le navigateur. Il ne connecte pas les comptes, ne crée pas de contenu, ne planifie pas et ne publie pas.
Comment ANKK s'intègre dans ce flux de travail
Je suis Minho Jung, l'opérateur d'ANKK. ANKK n'a pas de générateur de contenu AI intégré. ANKK connecte le contenu préparé par des humains, une IA externe ou des scripts avec les calendriers de publication, l'état de la chaîne et la vérification de la publication originale par le fournisseur.
Free Checker est un outil de décision indépendant. Pour les opérations répétées, ANKK permet de conserver le content ID, le job ID, le statut final et l'URL du provider original dans le même flux de suivi.