Programa mediciones recurrentes sin confundir vencimiento con ejecución

Trata una programación como un contrato de medición recurrente

Una programación de Position Tracking guarda qué debe medirse de nuevo y para qué workspace: selección fija de palabras clave o lista actual, tipo de datos, frecuencia, contexto SERP o paquetes de datos, límite opcional, estado y próxima fecha. Configura las siguientes solicitudes. No garantiza que el proveedor empiece a la hora exacta ni que todas las filas solicitadas devuelvan datos.

La vista de programaciones puede mostrar tareas SERP y de datos vinculadas a la lista elegida, selecciones fijas en el workspace y un resumen limitado de sus tareas. El límite actual predeterminado, tanto de recurso como de visualización, es de 30 programaciones activas o pausadas por workspace. El plan efectivo o una regla de seguridad puede reducirlo. Las programaciones archivadas desaparecen de las listas habituales.

Distingue una cohorte fija de una lista resuelta al ejecutar

Una programación de selección directa guarda un conjunto normalizado y sin duplicados. Solo admite SERP y actualmente acepta hasta 200 palabras clave de forma predeterminada. Su membresía cambia únicamente en el editor específico, que no permite guardar un conjunto vacío. Una programación vinculada a una lista guarda su identificador. Cada ejecución vuelve a resolver la membresía actual, de modo que las altas y bajas modifican la siguiente adquisición sin reescribir los recuentos históricos.

El límite actual por ejecución es de 500 palabras clave. La creación y la estimación rechazan una lista demasiado grande, y el dispatcher comprueba de nuevo su tamaño antes de cada solicitud. Si después supera el límite efectivo, una programación antes válida puede fallar antes del dispatch. La ejecución registra el error de membresía en vez de usar en silencio las primeras 500 filas.

• Una selección directa conserva su cohorte fija hasta que una persona la edita.
• Una programación de lista completa sigue su membresía actual. El coste y la comparabilidad pueden cambiar.
• Un subconjunto elegido en el asistente se guarda como selección directa fija, no como segmento dinámico de la lista.
• El recuento solicitado de cada ejecución es la evidencia inmutable de la membresía resuelta para esa solicitud.

Ajusta la frecuencia al tipo de datos y a la decisión

Las programaciones SERP pueden medir a diario, semanalmente, cada dos semanas o mensualmente. Los datos de palabras clave se actualizan mensual o trimestralmente y requieren al menos un paquete. El tipo de datos queda bloqueado al editar. Para pasar de SERP a datos de palabras clave, o al contrario, hace falta otra programación. Elige una frecuencia porque alguien revisará y usará esa evidencia, no porque un intervalo corto parezca más completo.

La proyección mensual usa una frecuencia media: 365 dividido entre 12 para diario, 52 dividido entre 12 para semanal, 26 dividido entre 12 para cada dos semanas, uno para mensual y un tercio para trimestral. Los meses reales no contienen los mismos días ni ocurrencias semanales. Las fechas mensuales y trimestrales avanzan por meses naturales UTC y ajustan los días imposibles al último del mes. Así, una programación del 31 de enero pasa al último día de febrero.

Mantén profundidad, dispositivo, ubicación e idioma con la medición

Una programación SERP exige profundidad Top 10 o Top 100, un código de ubicación positivo, un código de idioma válido y al menos escritorio o móvil. Elegir ambos dispositivos crea un grupo lógico con dos ejecuciones hijas, dos reservas y dos conjuntos de resultados específicos del contexto. La fila de la programación puede sumar lo solicitado y obtenido, mientras que el registro muestra las filas hijas. Un total solicitado duplicado puede representar dos dispositivos, no palabras repetidas en una misma petición.

Top 10 no puede demostrar si un dominio ausente está en la posición 11 o en la 100. Top 100 compra una observación más profunda y cambia el precio. Ubicación e idioma describen la adquisición. No traducen palabras clave ni vuelven intercambiables dos mercados. Dispositivo, profundidad, ubicación, idioma y membresía deben mantenerse estables si la cronología va a sostener una comparación antes y después.

Comprende qué puede editarse y qué cuenta como duplicado

En una programación vinculada a una lista, la protección de duplicados compara lista, tipo de datos y frecuencia. Para SERP añade el conjunto de dispositivos, la ubicación y el idioma. La profundidad, los paquetes y el límite presupuestario no forman parte de esa clave. Dos programaciones activas de la misma lista no pueden diferenciarse solo por Top 10 frente a Top 100, ni solo por los paquetes de datos, si el resto de la clave coincide. Una fila archivada no bloquea una programación nueva.

Al editar pueden cambiar la frecuencia, la profundidad SERP, el contexto, los dispositivos, los paquetes y el límite. El tipo de datos y la lista vinculada permanecen fijos. Una selección directa modifica sus palabras en el editor aparte, dentro de los límites actuales de cantidad, caracteres, selección y ejecución. Cambiar la frecuencia recalcula el próximo vencimiento desde ese momento. Los demás cambios no reescriben ejecuciones terminadas ni sus recuentos solicitados.

• Una edición cambia solicitudes futuras, no snapshots históricos ni filas ya liquidadas.
• Duplicar para móvil prepara una programación SERP móvil nueva sin modificar la original.
• Un aviso de duplicado es una regla de admisión, no evidencia de que dos informes tendrían la misma historia.
• Si debe cambiar el contexto y la comparación importa, termina la serie anterior y nombra con claridad el nuevo contrato.

Lee la vista previa como una estimación de admisión

La tarjeta de configuración calcula el precio de la membresía conocida en ese instante. Muestra coste estimado por ejecución, media de ejecuciones mensuales, palabras resueltas, una media visible por palabra, coste mensual estimado, saldo gastable actual de la organización y saldo tras una ejecución estimada. El saldo gastable ya descuenta las reservas activas. La línea por palabra divide y redondea la estimación para mostrarla. No es la tarifa unitaria del proveedor.

El precio SERP depende del número de palabras, Top 10 o Top 100, la cola y la cantidad de dispositivos. El precio de los datos depende del número y de los paquetes. La estimación mensual multiplica la cotización estándar por la frecuencia media y redondea al céntimo superior. No incluye ejecuciones prioritarias puntuales, crecimiento futuro de la lista, cambios de precio, una nueva solicitud pagada tras un reintento ni otros gastos del mismo saldo de organización.

Separa el límite de la programación del saldo de la organización

El límite mensual opcional pertenece a una sola programación y actualmente tiene un mínimo de 5 EUR. Ilimitado significa que no existe ese límite específico. Nunca significa que el saldo de la organización sea ilimitado. Antes de una solicitud, Crawl Foundry suma los costes liquidados y las estimaciones todavía reservadas de esa programación desde el inicio del mes UTC. Las ejecuciones manuales, recurrentes, estándar, prioritarias y las filas por dispositivo consumen el mismo registro.

Si el siguiente grupo completo superara el límite, no se envía nada. La admisión por saldo reserva entonces la estimación total de cada dispositivo antes de iniciar el worker. Si falla una reserva posterior, se revierten las reservas anteriores y las filas provisionales de esa solicitud. Así, una programación de dos dispositivos no ejecuta solo uno porque el saldo se agote durante la admisión.

Los bloqueos por límite y por saldo insuficiente usan el estado `skipped_balance`, aunque con códigos de error distintos. Cada caso aumenta el contador de bloqueos consecutivos. Tras dos casos, la programación pasa a `paused_balance` y puede prepararse un correo de pausa para el propietario. Un grupo terminado con éxito o de forma parcial reinicia el contador. Añadir saldo o ampliar el límite no reactiva por sí solo una programación pausada.

Comprueba la facturación y el saldo de la organización por separado del límite propio del calendario.

Una ejecución manual es una solicitud pagada, no un simple refresco

Ejecutar ahora usa la misma cola estándar que el trabajo SERP recurrente. Una programación SERP también puede ofrecer Medir rápido, con una cola prioritaria cuyo precio se calcula aparte para esa ejecución. Los datos de palabras clave no tienen opción prioritaria. Ambas acciones resuelven la membresía actual, comprueban el límite, reservan saldo, escriben las filas de dispatch y envían eventos al worker. Abrir la programación o el informe no hace nada de eso.

Una solicitud manual admitida mueve el próximo ancla de frecuencia a su hora de inicio. No es una observación extra que deje intacto el calendario. Ejecutar ahora también puede no iniciar nada si la programación está pausada o archivada, sigue habiendo una ejecución activa, falta saldo o se alcanzó el límite. La acción de la lista explica estos motivos y abre el registro. Una respuesta HTTP 200 no demuestra por sí sola que el worker haya empezado.

Al crear, Crawl Foundry guarda la programación y después llama a la misma ruta para obtener la primera base. La creación puede completarse aunque esa petición inmediata se omita o falle. El flujo actual comprueba la respuesta HTTP, pero no usa la cantidad devuelta de solicitudes iniciadas como condición final independiente. Revisa la primera fila del registro y su cobertura terminal antes de considerar inicializado el tracker.

Pausar, reanudar y finalizar afectan de forma distinta a la cronología

Pausar cambia la programación a `paused_user`. También cierra las ejecuciones hijas activas como fallidas con un código de cancelación y libera sus reservas. Reanudar vuelve a activarla, borra los fallos consecutivos y hace que venza de inmediato. El dispatcher horario puede solicitarla después, o una persona puede iniciarla manualmente. La reanudación no reconstruye la ejecución cancelada ni rellena su hueco.

Finalizar archiva la programación, fija su fecha de eliminación, cierra las ejecuciones activas, libera las reservas y retira la fila de las listas habituales. No es una pausa temporal y la interfaz no ofrece reanudarla. Archivar no convierte en éxito la evidencia histórica de ejecución o facturación. Una programación nueva sí podrá reutilizar esa configuración sin colisión de duplicado.

Trata la hora mostrada como un límite de vencimiento

El dispatcher recurrente revisa actualmente cada hora, en el minuto 20 UTC, un lote limitado de programaciones activas vencidas. Una fila cuya hora ya pasó puede indicar que se ejecutará pronto mientras espera esa revisión. Tras una solicitud, la siguiente fecha recurrente parte del límite planificado anterior, lo que reduce la deriva por latencia del proveedor. Una ejecución manual o una reanudación establecen a propósito un ancla nueva.

Si el dispatch no alcanza el worker, la ejecución pasa a `skipped_dispatch`, su reserva se libera y los primeros reintentos actuales esperan una hora antes de volver a la frecuencia normal. La fila lo identifica como reintento en vez de presentar la hora como una próxima ejecución sana. Una función desactivada, membresía actual inválida, un fallo de tenancy, el retraso del lote limitado o una caída del worker pueden impedir que una configuración vencida produzca medidas a la hora prevista.

Lee por separado solicitado, obtenido, sin datos, pendiente y ausente

Cada ejecución hija empieza en dispatching y cambia a running cuando llega progreso. Mientras sigue activa, la diferencia entre solicitado, obtenido y sin datos queda pendiente. Solo después de un estado terminal pasa a ausente. La interfaz separa estas situaciones para que una ejecución reciente con cero resultados no parezca fallida antes de que termine el worker.

Succeeded significa que la ejecución cumplió su contrato terminal. Partial indica que volvió evidencia o un resultado explícito sin datos, pero no hubo éxito completo. Failed indica que no hubo una finalización aprovechable, salvo cuando el modelo de lectura corrige para la vista una fila fallida con recuentos positivos a parcial. `skipped_balance` señala un bloqueo de presupuesto o saldo. `skipped_dispatch` señala una solicitud creada cuyo dispatch falló. Sin datos es un resultado explícito del proveedor. Ausente es el resto terminal sin explicar.

Usa el registro como prueba de ejecución y coste

El registro de cada programación se pagina desde lo más reciente y su política actual admite hasta 50 filas por página de forma predeterminada. El gráfico de salud resume un conjunto reciente limitado, actualmente 12 filas. Cada línea muestra estado, inicio, solicitado, obtenido, sin datos, ausente cuando es terminal, código de soporte si existe y coste liquidado cuando está disponible. Una solicitud para dos dispositivos crea dos filas hijas dentro de un grupo. La banda de progreso y el resumen pueden agregar ese grupo.

El worker liquida cada reserva según el trabajo realmente facturable y libera la parte no utilizada. Una ejecución formada solo por resultados sin datos puede liquidarse a cero sin volver gratuitas la programación ni las adquisiciones futuras. Una ejecución parcial puede tener coste positivo. Existen rutas de conciliación y recuperación para filas activas obsoletas y reservas varadas. Antes de reintentar, el estado terminal visible, los contadores, el código de error, el coste y la entrada de Activity siguen siendo la evidencia que revisar.

Usa el estado de la operación y los datos de coste sin considerar la hora programada una prueba de ejecución.

Revisa la programación antes de confiar en su cronología