Une publication est prévue à 00h30 WIB, tandis que le tableau de bord enregistre le travail sous la date UTC précédente. Sur le compte public, la publication racine est visible, les réponses sont manquantes, l'image apparaît et l'URL s'affiche uniquement sous forme de texte brut. Le message a-t-il échoué et devez-vous le renvoyer ?
Pas nécessairement. Les publications programmées juste après minuit sont faciles à classer à tort car quatre types de preuves sont mélangés : l'heure, le statut interne, la structure des publications et le résultat public. Faites d'abord correspondre le même instant, puis inspectez chaque composant dans le provider original avant de choisir une action.
Ce guide utilise une seule feuille de preuves pour décider s'il faut confirmer, attendre, réconcilier ou conserver.
Pourquoi 00h30 WIB peut-il apparaître sous une date UTC différente ?
WIB est UTC+7. Cela signifie que le 15 août à 00h30 WIB est le 14 août à 17h30 UTC. Les deux horodatages pointent vers le même instant même si les dates du calendrier sont différentes.
Une erreur courante consiste à comparer uniquement les chiffres des heures ou uniquement la date. L'opérateur considère alors que la tâche est en retard d'un jour, même si le tableau de bord et le calendrier local utilisent un fuseau horaire différent. Avant d'évaluer le retard, stockez les trois valeurs suivantes sur une seule ligne :
| Valeur | Exemple | Utilisations |
|---|---|---|
| Heure approuvée | 2026-08-15 00:30 WIB |
Promesses opérationnelles aux opérateurs |
| Temps gagné par le système | 2026-08-14T17:30:00Z |
Instant neutre pour comparer les logs |
| Temps d'observation du public | 2026-08-15 00:38 WIB |
Quand les résultats du fournisseur seront-ils réellement vérifiés |
Les conversions de fuseau horaire ne constituent pas une preuve de publication. Cela garantit simplement que vous évaluez le bon travail dans la bonne fenêtre.
Cinq champs de preuve pour chaque destination
Créez une ligne par compte de destination, et non une ligne pour l'ensemble du lot. Remplissez les cinq colonnes suivantes :
- Canaux et comptes publics — par exemple les fils de discussion
@merek, pas seulement les « fils de discussion ». - Instantané programmé : heure locale, fuseau horaire et équivalent UTC.
- Content ID ou job ID — identité stable pour suivre la même opération.
- Dernier statut et heure d'observation — valeur exacte telle que
scheduled,publishing,publishedoufailed. - URL des publications d'origine et résultats des composants — la racine, la réponse, les médias et les liens sont vérifiés séparément.
Ne saisissez pas de jetons, de mots de passe, d'URL de téléchargement signées, d'invites privées ou de données client. Cette fiche ne nécessite que des métadonnées opérationnelles et ce qui est visible sur l'espace public.
Auditez séparément la racine, la réponse, les médias et les liens
Un lien permanent ne prouve pas que la structure entière du message est correcte. Utilisez la matrice d'exhaustivité suivante sur la publication originale du fournisseur :
| Composants | Questions d'observation | Valeurs enregistrées |
|---|---|---|
| Racine | Correspondance du compte, du SMS et de le provider ID ? | vrai / faux / inconnu |
| Répondre | La réponse est là, dans le bon ordre, et attachée à la bonne racine ? | destination complète / manquante / erronée |
| Médias | L'image ou la vidéo est réellement rendue, pas seulement un espace réservé ? | affiché / échoué / toujours en cours de traitement |
| Lien | Existe-t-il une ancre cliquable dont le href va vers une destination approuvée ? | clic / texte uniquement / mauvaise destination |
Par exemple, une racine publique avec des réponses manquantes est une publication partielle, et non un échec complet. Renvoyer la racine pour corriger la réponse peut créer deux racines. De même, l'URL affichée dans la légende ne correspond pas nécessairement au chemin de clic ; notez le texte et l’ancre comme deux éléments de preuve différents.
Quatre actions de la fiche de preuve
Après avoir vérifié cinq colonnes et quatre composants, sélectionnez exactement l'une des actions suivantes.
1. Confirmez
Sélectionnez confirmer lorsque le compte, l'instance, l'ID, l'état du terminal et tous les composants publics correspondent. Enregistrez le permalien et le temps d'observation, puis fermez le travail. Ne soumettez pas à nouveau simplement pour obtenir une réponse API plus propre.
2. Attendez et vérifiez à nouveau
Sélectionnez attendre pendant que la tâche est toujours scheduled ou publishing, un ID stable est disponible et les observations se situent toujours dans une fenêtre raisonnable. Fixez une heure pour la prochaine inspection. Attendre indéfiniment n’est pas un contrôle ; attendre par pièce d'identité et date limite est une décision opérationnelle.
3. Réconcilier avant de réessayer
Sélectionnez réconcilier lorsque l'état interne affiche une erreur mais que l'objet racine, réponse, média ou fournisseur existe peut-être déjà. Conservez tous les identifiants, vérifiez les comptes sur une fenêtre de temps normalisée, puis déterminez quels composants sont vraiment incomplets. Ne répétez pas les lots lorsque d’autres objectifs sont corrects.
4. Conserver comme inconnu
Sélectionnez hold lorsqu'il n'y a pas d'ID stable et que les résultats publics ne sont pas concluants. Tidak diketahui n’est pas synonyme de gagal. Le modifier pour échouer sans preuve peut permettre une nouvelle tentative qui crée un deuxième objet.
Exemple d'audit après changement de date
Par exemple, un fil de discussion est programmé à 00h30 WIB :
account: @marque
scheduled_local: 2026-08-15 00:30 WIB
scheduled_utc: 2026-08-14T17:30:00Z
content_or_job_id: job_4821
last_state: failed at 00:32 WIB
provider_original: disponible
root: correct
reply: manquant
media: affiché
link: texte uniquement, pas d'ancre
observed_at: 00:38 WIBLa bonne décision n’est pas de « tout renvoyer ». Ce sont des résultats partiels qui doivent être rapprochés. La racine existe déjà, donc réessayer la racine risque de créer un doublon. Les liens de réponse et d'opérateur doivent être traités comme des composants distincts en fonction des capacités du fournisseur et des politiques de canal.
Utilisez le vérificateur comme outil de classification, et non comme preuve du fournisseur
Ouvrir gratuitement le vérificateur de preuves de publication sociale
Le vérificateur s'exécute localement dans le navigateur, ne nécessite pas de connexion et n'envoie ni n'enregistre les valeurs saisies. Cela permet de transformer cinq faits en quatre options d’action. Checker ne contacte pas les réseaux sociaux et ne peut pas prouver que les publications sont réellement publiques ; La publication originale du fournisseur reste la dernière source de preuve.
FAQ
Une date UTC différente signifie-t-elle que l'horaire est erroné ?
Pas toujours. Modifiez les deux horodatages au même instant. 00h30 WIB est identique à 17h30 UTC à la date précédente. L'horaire n'est incorrect que si l'instant est différent de celui approuvé.
Si root existe déjà mais que la réponse est manquante, le statut est-il réussi ?
A noter comme publication partielle. N'appelez pas l'intégralité du fil de discussion avec succès, mais ne republiez pas une racine déjà publique. Rapprochez les réponses séparément.
L'URL visible est-elle définitivement cliquable ?
Non. Vérifiez si la page du fournisseur restitue l'ancre et si le href décode vers la destination approuvée. Le texte d'une URL sans ancre n'est pas un support de clic.
Le vérificateur crée-t-il ou planifie-t-il des publications ?
Non. Le vérificateur regroupe simplement les preuves que vous saisissez. Il ne se connecte pas aux comptes sociaux, ne crée pas de contenu et ne publie rien.
Comment ANKK s'intègre dans ce flux de travail
Je suis Minho Jung, opérateur ANKK. ANKK n'est pas un générateur de contenu avec IA intégrée. ANKK connecte le contenu préparé par des humains, une IA externe ou des scripts à la planification, au statut par chaîne et à la vérification des publications originales des fournisseurs.
Le vérificateur gratuit est un outil de décision autonome. Pour les opérations répétées, ANKK permet de conserver le content ID, la tâche, l'état du terminal et l'URL du fournisseur dans le même flux.