Cómo obtener avisos de empleos nuevos sin listados repetidos

Términos esenciales

Entender estos términos básicos ayuda a mantener el seguimiento de empleos exacto y sin datos mezclados:

• Listado: Un anuncio público de empleo publicado en un tablero de empleos, identificado por una cadena de texto llamada ID de empleo.
• Actor: Un programa de recolección alojado que obtiene datos de empleo desde páginas web públicas.
• Task: Un conjunto guardado de entradas de búsqueda, como palabras clave objetivo y ubicación, usado por un Actor.
• Hora de primera observación: El momento exacto en que su sistema de seguimiento registra por primera vez un ID de listado específico. Esto es distinto de la hora de publicación original en el tablero de empleos.
• Estado del aviso: Un registro que muestra si un aviso de un empleo está pendiente, se envió con éxito o falló.

Configuración de su recolección de origen

Antes de seguir publicaciones nuevas, necesita un flujo diario estable de empleos. Puede usar el LinkedIn Jobs Scraper para recolectar listados de empleo en bruto.

Comience con un ajuste preestablecido de búsqueda estrecho para poder probar su registro de seguimiento con facilidad. La Task predeterminada usa varias palabras clave, pero debe cambiar la entrada para apuntar primero a una sola palabra clave.

{
  "searchTerm": "software engineer",
  "location": "United States",
  "maxItems": 3,
  "postedWithin": "7d", "distance": 25,
  "sortBy": "date",
  "jobType": "any",
  "workplaceType": "any",
  "experienceLevel": "any",
  "maxPagesPerSearch": 5,
  "saveOnlyUniqueItems": true,
  "balanceKeywordCoverage": true,
  "fetchJobDetails": true,
  "requestDelayMillis": 500
}

Si `saveOnlyUniqueItems` es `true`, se quitan los listados duplicados dentro de una sola ejecución. Sin embargo, eso no detiene las repeticiones entre días distintos. El límite `maxItems` se aplica a todos los términos de búsqueda de una ejecución. Si una ejecución alcanza un límite numérico o encuentra una falla de origen, algunos empleos pueden omitirse. Trate las recolecciones omitidas o fallidas como datos desconocidos, en lugar de suponer que se publicaron cero empleos nuevos.

Cuando una ejecución tiene éxito, extraiga estos campos clave para su canal de seguimiento:

El recolector produce campos específicos para cada listado.

Las etiquetas en bruto se mantienen junto con las horas analizadas o derivadas. La antigüedad relativa no es una hora exacta de publicación original. Los campos del lector de primera observación, última observación y acción están separados. La prueba de aceptación actual conocida, de tres filas, solo demuestra la identidad del origen y la estructura de los datos de tiempo. No prueba un sistema de avisos desplegado que funcione a lo largo de varios días.

El método diario de seguimiento en 8 pasos

Siga estos ocho pasos para procesar los listados entrantes y gestionar los avisos sin enviar duplicados.

1. Defina un aviso elegible: Un aviso elegible es un ID de listado recolectado que cumple sus criterios básicos (como el título del puesto o la ubicación) y que no se procesó antes. Mantenga las reglas de filtro junto a los registros de ejecución.
2. Conserve las filas de origen e inspeccione la salida de la ejecución: Guarde las salidas del lote en bruto. Revise errores de recolección, topes de ítems o advertencias antes de procesar las filas. Un lote fallido significa que las condiciones del mercado son desconocidas, no que haya cero listados nuevos.
3. Cree una tabla de seguimiento con clave de plataforma no vacía y jobId como texto. Los ID faltantes quedan como observaciones separadas y no resueltas, y los valores en blanco nunca se fusionan. Conserve los campos del lector `first_seen_at`, `last_seen_at`, `jobUrl`, `review_status`, `alert_state`, `alert_attempt_at` y `error_note`. El `scrapedAt` de la recolección de origen es distinto de la hora de acción del flujo de trabajo.
4. Procese los ID del lote entrante: Para cada clave única del lote actual, compruebe si existe en su tabla de seguimiento. Si existe, actualice solo `last_seen_at`. Si falta, cree una fila nueva con `review_status` en pendiente y `alert_state` en pendiente. Nunca sobrescriba `first_seen_at`.
5. Revise la elegibilidad antes de enviar: Verifique las condiciones requeridas, como el estado de ubicación o de trabajo remoto. Si una condición requerida no se puede verificar, deje `review_status` como pendiente. Si un empleo no cumple sus reglas, márquelo como excluido con un motivo claro para que las ejecuciones futuras no lo revisen de nuevo.
6. Dé al aviso una clave estable ligada a la plataforma más el ID de empleo. Envíe solo avisos pendientes que sean elegibles. Márquelo como enviado solo después de que el servicio del proveedor confirme su acción. Enviado significa un envío confirmado por el proveedor, no una prueba de llegada a la bandeja de entrada. La sola aceptación HTTP 200 no es una confirmación de entrega. Una confirmación desconocida significa que la entrega es desconocida y debe inspeccionarse antes de un reintento. No hay garantía de entrega exactamente una vez.
7. Gestione las fallas de entrega de forma segura: Si un aviso no se envía, reintente la entrega más tarde sin borrar `first_seen_at` ni volver a recolectar empleos del origen. Mantenga los errores de recolección separados de los errores de entrega. Guarde su estado después de cada paso para poder reiniciar de forma segura.
8. Informe las métricas con claridad: Separe las métricas en listados únicos recolectados, ID recién observados, avisos elegibles, avisos enviados confirmados y avisos pendientes o fallidos. No tener avisos nuevos significa que hoy no se encontraron coincidencias nuevas aceptadas, no que el mercado laboral en general haya dejado de contratar.

Ejemplo resuelto ficticio

Todos los ID, las fechas y los eventos son ficticios. La línea de base anterior al 3 de octubre contiene solo dos claves: `J1`, primera observación el 1 de octubre y enviado, y `J2`, primera observación el 2 de octubre y enviado. El registro final contiene cuatro claves, no la línea de base.

El 3 de octubre, la recolección devuelve cuatro filas en bruto o de importación con las claves `J1`, `J2`, `J3` y `J3`. Esto representa 4 observaciones, 3 claves distintas, 2 claves existentes y 1 clave no vista (`J3`). La revisión de `J3` se aprueba. Su primer intento de aviso queda confirmado como no aceptado, así que un reintento posterior es seguro en este caso ficticio.

El 4 de octubre, la recolección devuelve 3 claves: `J2`, `J3` y `J4`. Esto representa 3 claves distintas, 2 claves existentes y 1 clave no vista (`J4`). A `J4` le falta la ubicación: la revisión queda pendiente y no hay aviso. Un envío confirmado por el proveedor el 4 de octubre no es una entrega en la bandeja de entrada.

El 5 de octubre, una recolección fallida no cambia el historial y no aporta una afirmación de ausencia.

Tabla maestra de seguimiento:

Registro separado de avisos intentados y confirmados:

Resumen de actividad:

• ID no vistos el 3 de octubre: 1 (`J3`)
• ID no vistos el 4 de octubre: 1 (`J4`)
• Acciones confirmadas del proveedor en esos días: 1 (reintento de `J3`)
• Total de claves en seguimiento: 4