Planifier des mesures récurrentes sans confondre échéance et exécution

Considérez le planning comme un contrat de mesure récurrent

Un planning Position Tracking conserve ce qui doit être mesuré à nouveau et pour quel workspace : sélection fixe de mots-clés ou liste actuelle, type de données, fréquence, contexte SERP ou paquets de données de mots-clés, plafond éventuel, état et prochaine échéance. Il configure les prochaines demandes. Il ne garantit ni un appel fournisseur à l’heure exacte ni une réponse complète pour chaque ligne demandée.

La vue des plannings peut afficher les tâches SERP et de données de mots-clés liées à la liste choisie, les sélections fixes au niveau du workspace et un résumé borné des tâches du workspace. La limite actuelle par défaut est de 30 plannings actifs ou en pause, pour la ressource comme pour l’affichage. Le forfait effectif ou une règle de sécurité peut la réduire. Les plannings archivés quittent les listes ordinaires.

Distinguez une cohorte fixe d’une liste résolue à l’exécution

Un planning par sélection directe conserve un tableau de mots-clés normalisé et dédupliqué. Réservé aux SERP, il accepte actuellement jusqu’à 200 mots-clés par défaut. Seul son éditeur dédié modifie ses membres et il refuse un ensemble vide. Un planning lié à une liste conserve plutôt l’identifiant de cette liste. Chaque exécution relit ses membres actuels. Les ajouts et retraits affectent donc la prochaine acquisition sans réécrire les compteurs historiques.

Le plafond actuel par exécution est de 500 mots-clés. La création et l’estimation refusent une liste trop grande, puis le dispatcher contrôle de nouveau sa taille avant chaque demande. Une liste qui dépasse ensuite la limite effective peut faire échouer un planning jusque-là valide avant le dispatch. L’exécution conserve l’erreur de membres au lieu de prendre silencieusement les 500 premières lignes.

• Une sélection directe reste fixe jusqu’à ce qu’une personne la modifie.
• Un planning portant sur toute la liste suit ses membres actuels. Coût et comparabilité peuvent donc évoluer.
• Un sous-ensemble choisi dans l’assistant devient une sélection directe fixe, pas une tranche dynamique de la liste.
• Le nombre demandé par l’exécution est la preuve immuable des membres résolus pour cette demande.

Adaptez la fréquence au type de données et à la décision

Les SERP peuvent être mesurées chaque jour, chaque semaine, toutes les deux semaines ou chaque mois. Les données de mots-clés se mettent à jour chaque mois ou chaque trimestre et exigent au moins un paquet. Le type de données reste verrouillé pendant la modification. Passer de SERP aux données de mots-clés, ou l’inverse, demande un autre planning. Choisissez une fréquence parce qu’une personne examinera et utilisera les résultats, pas parce qu’un intervalle plus court paraît plus complet.

La projection mensuelle emploie une fréquence moyenne : 365 divisé par 12 pour le quotidien, 52 divisé par 12 pour l’hebdomadaire, 26 divisé par 12 pour toutes les deux semaines, un pour le mensuel et un tiers pour le trimestriel. Les mois réels n’ont ni le même nombre de jours ni le même nombre d’occurrences hebdomadaires. Les échéances mensuelles et trimestrielles suivent les mois calendaires UTC et ramènent une date impossible au dernier jour du mois. Le 31 janvier mène ainsi au dernier jour de février.

Gardez profondeur, appareil, lieu et langue avec la mesure

Un planning SERP exige une profondeur Top 10 ou Top 100, un code de lieu positif, un code de langue valide et au moins ordinateur ou mobile. Choisir les deux appareils crée un groupe logique composé de deux exécutions enfants, deux réservations et deux ensembles de résultats propres à leur contexte. La ligne du planning peut agréger les volumes demandés et récupérés, tandis que le journal conserve les lignes enfants. Un total demandé doublé peut donc signaler deux appareils, pas des mots-clés dupliqués dans une requête.

Une mesure Top 10 ne peut pas dire si un domaine absent occupe la position 11 ou 100. Top 100 achète une observation plus profonde et change le prix. Lieu et langue décrivent la demande d’acquisition. Ils ne traduisent pas les mots-clés et ne rendent pas deux marchés interchangeables. Appareil, profondeur, lieu, langue et membres doivent rester stables pour défendre une comparaison avant et après.

Comprenez les champs modifiables et la règle de doublon

Pour un planning lié à une liste, la protection contre les doublons compare liste, type de données et fréquence. Pour les SERP, elle ajoute ensemble d’appareils, lieu et langue. Profondeur, choix des paquets et plafond budgétaire n’entrent pas dans cette clé. Deux plannings actifs de la même liste ne peuvent donc pas différer seulement par Top 10 ou Top 100, ni seulement par leurs paquets de données, si le reste de la clé demeure identique. Une ligne archivée ne bloque pas un nouveau planning.

La modification peut changer fréquence, profondeur SERP, contexte, appareils, paquets et plafond. Type de données et liste liée restent fixes. Une sélection directe peut changer ses mots-clés dans son propre éditeur, sous les limites actuelles de nombre, de caractères, de sélection et d’exécution. Modifier la fréquence recalcule la prochaine échéance depuis cette modification. Les autres changements ne réécrivent ni les exécutions terminées ni leurs volumes demandés.

• Une modification concerne les prochaines demandes, pas les snapshots historiques ni les lignes déjà facturées.
• Dupliquer pour mobile préremplit un nouveau planning SERP mobile sans modifier la ligne source.
• Une alerte de doublon est une règle d’admission, pas la preuve que deux rapports auraient la même histoire.
• Si le contexte doit changer alors que la comparaison compte, terminez l’ancienne série et nommez clairement le nouveau contrat.

Lisez l’aperçu comme une estimation d’admission

La carte de configuration chiffre les membres connus à cet instant. Elle affiche le coût estimé par exécution, le nombre moyen d’exécutions mensuelles, le nombre de mots-clés résolus, une moyenne affichée par mot-clé, le coût mensuel estimé, le solde actuellement disponible pour l’organisation et le solde après une exécution estimée. Le solde disponible déduit déjà les réservations actives. La ligne par mot-clé divise et arrondit l’estimation pour l’affichage. Ce n’est pas le tarif unitaire du fournisseur.

Le prix SERP dépend du nombre de mots-clés, de Top 10 ou Top 100, de la file et du nombre d’appareils. Celui des données de mots-clés dépend du nombre et des paquets. L’estimation mensuelle multiplie le devis standard par la fréquence moyenne et arrondit au centime supérieur. Elle exclut les exécutions prioritaires ponctuelles, la croissance future de la liste, les changements de prix, une nouvelle demande payante après une nouvelle tentative et les autres dépenses puisées dans le même solde d’organisation.

Séparez le plafond du planning du solde de l’organisation

Le plafond mensuel facultatif appartient à un seul planning et son minimum actuel est de 5 EUR. Illimité signifie que ce plafond propre au planning est absent. Le solde de l’organisation reste toujours limité. Avant une demande, Crawl Foundry additionne les coûts réglés et les estimations encore réservées de ce planning depuis le début du mois UTC. Exécutions manuelles, récurrentes, standards, prioritaires et lignes par appareil consomment toutes le même registre du planning.

Si le prochain groupe complet dépassait le plafond, rien n’est dispatché. Le contrôle de solde réserve ensuite l’estimation entière de chaque appareil avant le travail du worker. Si une réservation ultérieure échoue, les réservations précédentes et les lignes provisoires de cette demande sont annulées. Un planning à deux appareils ne démarre donc pas un seul appareil parce que le solde s’épuise pendant l’admission.

Un blocage de plafond et un solde insuffisant utilisent tous deux l’état `skipped_balance`, avec des codes d’erreur différents. Chaque cas augmente le compteur de blocages consécutifs. Après deux cas, le planning passe à `paused_balance` et un message de pause peut être prévu pour le propriétaire. Un groupe terminé avec succès ou partiellement remet le compteur à zéro. Ajouter du solde ou relever le plafond ne réactive pas le planning tout seul.

Vérifiez la facturation et le solde de l'organisation séparément du plafond propre au calendrier.

Une exécution manuelle est une demande payante, pas un simple rafraîchissement

Exécuter maintenant utilise la file standard des tâches SERP récurrentes. Un planning SERP peut aussi proposer Mesurer rapidement, avec une file prioritaire tarifée séparément pour cette seule exécution. Les données de mots-clés n’ont pas d’option prioritaire. Dans les deux cas, Crawl Foundry résout les membres actuels, vérifie le plafond, réserve le solde, écrit les lignes de dispatch puis envoie les événements au worker. Ouvrir le planning ou le rapport ne déclenche rien de cela.

Une demande manuelle admise replace l’ancre de la prochaine fréquence à son heure de départ. Ce n’est pas une observation supplémentaire sans effet sur le calendrier. Exécuter maintenant peut ne rien lancer si le planning est en pause ou archivé, si une exécution reste active, si le solde manque ou si le plafond est atteint. L’action de la liste explique ces motifs et ouvre le journal. Une réponse HTTP 200 ne prouve pas à elle seule qu’un worker a démarré.

À la création, Crawl Foundry enregistre le planning puis appelle la même route pour établir la première base. La création peut réussir même si cette demande immédiate est ignorée ou échoue. Le parcours actuel contrôle la réponse HTTP, mais ne traite pas le nombre de demandes réellement lancées comme une condition de fin distincte. Vérifiez la première ligne du registre et sa couverture terminale avant de considérer le tracker comme initialisé.

Pause, reprise et fin n’ont pas le même effet sur la chronologie

Mettre en pause place le planning en `paused_user`. Ses exécutions enfants encore actives sont aussi fermées comme échecs avec un code d’annulation, puis leurs réservations actives sont libérées. Reprendre réactive le planning, efface les échecs consécutifs et le rend immédiatement échu. Le dispatcher horaire peut alors le demander, ou une personne peut le lancer manuellement. La reprise ne reconstruit pas l’exécution annulée et ne comble pas sa lacune.

Terminer archive le planning, inscrit sa date de suppression, ferme les exécutions actives, libère leurs réservations et retire la ligne des listes ordinaires. Ce n’est pas une pause temporaire et l’interface ne propose pas de reprise. Les preuves historiques d’exécution et de facturation ne deviennent pas des succès par l’archivage. Un nouveau planning pourra toutefois réutiliser cette configuration sans collision de doublon.

Traitez l’heure affichée comme une limite d’échéance

Le dispatcher récurrent examine actuellement chaque heure, à la minute 20 UTC, un lot borné de plannings actifs arrivés à échéance. Une ligne dont l’heure est passée peut donc annoncer une exécution prochaine en attendant ce balayage. Après une demande, l’échéance récurrente suivante part de la limite planifiée précédente, ce qui évite une dérive progressive due au fournisseur. Une exécution manuelle ou une reprise établit volontairement une nouvelle ancre.

Si le dispatch n’atteint pas le worker, l’exécution devient `skipped_dispatch`, sa réservation est libérée et les premières nouvelles tentatives utilisent un délai d’une heure avant le retour à la fréquence normale. La ligne indique une nouvelle tentative au lieu de présenter son heure comme une prochaine exécution saine. Une fonctionnalité désactivée, des membres actuels invalides, une erreur de tenancy, un retard du lot borné ou une panne du worker peuvent empêcher une configuration échue de produire sa mesure à l’heure attendue.

Lisez séparément demandé, récupéré, sans données, en attente et manquant

Chaque exécution enfant commence en dispatching et passe en running lorsque la progression arrive. Tant qu’elle reste active, la différence entre demandé, récupéré et sans données est en attente. Ce reliquat ne devient manquant qu’après un état terminal. L’interface sépare ces états afin qu’une exécution récente avec zéro résultat ne paraisse pas échouée avant la fin du worker.

Succeeded signifie que l’exécution a rempli son contrat terminal. Partial signifie qu’une preuve ou un résultat explicite sans données est revenu sans succès complet. Failed signifie qu’aucune fin exploitable n’a été obtenue, sauf si le modèle de lecture corrige pour l’affichage une ligne en échec avec des compteurs positifs en partiel. `skipped_balance` indique un blocage de budget ou de solde. `skipped_dispatch` indique une demande créée dont le dispatch a échoué. Sans données est une réponse fournisseur explicite. Manquant est le reliquat terminal non expliqué.

Utilisez le journal comme preuve d’exécution et de coût

Le journal de chaque planning est paginé du plus récent au plus ancien. Sa règle actuelle accepte par défaut jusqu’à 50 lignes par page. Le graphique de santé résume un ensemble récent borné, actuellement 12 lignes. Chaque ligne indique état, départ, demandé, récupéré, sans données, manquant une fois terminal, code de support s’il existe et coût réglé dès qu’il est disponible. Une demande à deux appareils crée deux lignes enfants dans un groupe. Le bandeau en direct et le résumé du planning peuvent agréger le groupe.

Le worker règle chaque réservation selon le travail réellement facturable et libère la partie inutilisée. Une exécution entièrement sans données peut coûter zéro sans rendre gratuits le planning ou les prochains relevés. Une exécution partielle peut avoir un coût positif. Des chemins de rapprochement et de récupération existent pour les lignes actives devenues anciennes et les réservations échouées. Avant une nouvelle tentative, l’état terminal visible, les compteurs, le code d’erreur, le coût et l’entrée Activity restent les preuves à examiner.

Utilisez le statut de l'opération et les données de coût sans considérer l'heure prévue comme une preuve d'exécution.

Contrôlez le planning avant de croire sa chronologie