Como receber alertas de vagas novas sem anúncios repetidos

Termos essenciais

Entender estes termos básicos ajuda a manter o acompanhamento de vagas limpo e preciso:

• Anúncio: um anúncio público de vaga publicado em um quadro de vagas, identificado por uma cadeia de texto chamada ID da vaga.
• Actor: um programa de coleta hospedado que busca dados de vagas em páginas públicas da web.
• Task: um conjunto salvo de entradas de busca, como palavras-chave de destino e local, usado por um Actor.
• Horário da primeira vez vista: o instante exato em que o seu sistema de acompanhamento registra pela primeira vez um ID de anúncio específico. Isto é diferente do horário original de publicação no quadro de vagas.
• Estado do alerta: um registro que mostra se um aviso de uma vaga está pendente, foi enviado com sucesso ou falhou.

Como configurar a coleta de origem

Antes de acompanhar publicações novas, você precisa de um fluxo diário estável de vagas. Você pode usar o LinkedIn Jobs Scraper para coletar anúncios brutos de vagas.

Comece com uma predefinição de busca estreita, para testar o registro de acompanhamento com facilidade. A task padrão usa várias palavras-chave, mas você deve mudar a entrada para mirar primeiro em uma única palavra-chave.

{
  "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
}

Definir `saveOnlyUniqueItems` como `true` remove anúncios duplicados dentro de uma única execução. Porém, isso não impede repetições em dias diferentes. O limite `maxItems` vale para todos os termos de busca em uma execução. Se uma execução atinge um limite numérico ou encontra uma falha da origem, algumas vagas podem ficar de fora. Trate coletas perdidas ou com falha como dados desconhecidos, em vez de supor que zero vagas novas foram publicadas.

Quando uma execução tem sucesso, extraia estes campos principais para o seu fluxo de acompanhamento:

O coletor produz campos específicos para cada anúncio.

Os rótulos brutos permanecem junto dos horários interpretados ou derivados. A idade relativa não é um horário original exato de publicação. Os campos do leitor para a primeira vez vista, a última vez vista e a ação são separados. A aceitação atual conhecida, de três linhas, sustenta apenas a identidade da origem e a estrutura dos dados de tempo. Ela não prova um fluxo operacional de alerta ao longo de vários dias.

O método diário de acompanhamento em 8 passos

Siga estes oito passos para processar os anúncios que chegam e gerir os alertas sem enviar duplicatas.

1. Defina um alerta elegível: um alerta elegível é um ID de anúncio coletado que atende aos seus critérios básicos (como título do cargo ou local) e que ainda não foi processado. Mantenha as regras de filtro ao lado dos registros da execução.
2. Preserve as linhas da origem e inspecione a saída da execução: salve as saídas brutas do lote. Verifique erros de coleta, tetos de itens ou avisos antes de processar as linhas. Um lote com falha significa que as condições do mercado são desconhecidas, não que haja zero anúncios novos.
3. Crie uma tabela de acompanhamento com chave formada por plataforma não vazia e jobId como texto. IDs ausentes permanecem como observações separadas não resolvidas e nunca unem valores em branco. Mantenha os campos do leitor `first_seen_at`, `last_seen_at`, `jobUrl`, `review_status`, `alert_state`, `alert_attempt_at` e `error_note`. O `scrapedAt` da coleta de origem é diferente do horário da ação do fluxo.
4. Processe os IDs do lote que chega: para cada chave única no lote atual, verifique se ela existe na tabela de acompanhamento. Se existir, atualize apenas `last_seen_at`. Se estiver ausente, crie uma linha nova com `review_status` definido como pending e `alert_state` definido como pending. Nunca substitua `first_seen_at`.
5. Revise a elegibilidade antes de enviar: verifique as condições exigidas, como local ou situação de trabalho remoto. Se uma condição exigida não puder ser verificada, mantenha `review_status` como pending. Se uma vaga falhar nas suas regras, marque-a como excluída com um motivo claro, para que execuções futuras não a revisem de novo.
6. Dê ao aviso uma chave estável ligada à plataforma mais o ID da vaga. Envie apenas avisos elegíveis pendentes. Marque como enviado somente depois que o serviço do provedor confirmar a sua ação. Enviado significa envio confirmado pelo provedor, não prova de chegada à caixa de entrada. A aceitação HTTP 200 sozinha não é confirmação de entrega. Confirmação desconhecida significa que a entrega é desconhecida e deve ser inspecionada antes da nova tentativa. Não há garantia de entrega exatamente uma vez.
7. Trate falhas de entrega com segurança: se um aviso falhar no envio, tente a entrega de novo mais tarde sem limpar `first_seen_at` nem coletar as vagas de novo na origem. Mantenha os erros de coleta separados dos erros de entrega. Salve o estado depois de cada passo, para poder reiniciar com segurança.
8. Relate as métricas com clareza: separe as métricas em anúncios únicos coletados, IDs observados pela primeira vez, avisos elegíveis, avisos enviados confirmados e avisos pendentes ou com falha. Não ter avisos novos significa que nenhuma correspondência nova aceita foi encontrada hoje, não que o mercado de trabalho como um todo tenha parado de contratar.

Exemplo resolvido fictício

Todos os IDs, datas e eventos são fictícios. A linha de base antes de 3 de outubro contém apenas duas chaves: `J1`, vista pela primeira vez em 1º de outubro e enviada, e `J2`, vista pela primeira vez em 2 de outubro e enviada. O registro final contém quatro chaves, não a linha de base.

Em 3 de outubro, a coleta devolve quatro linhas brutas/de importação com as chaves `J1`, `J2`, `J3` e `J3`. Isto representa 4 observações, 3 chaves distintas, 2 chaves existentes e 1 chave ainda não vista (`J3`). A revisão de `J3` é aprovada. A primeira tentativa de aviso é confirmada como não aceita, então uma nova tentativa posterior é segura neste caso fictício.

Em 4 de outubro, a coleta devolve 3 chaves: `J2`, `J3` e `J4`. Isto representa 3 chaves distintas, 2 chaves existentes e 1 chave ainda não vista (`J4`). O local ausente de `J4` fica com revisão pendente e sem aviso. Um envio confirmado pelo provedor em 4 de outubro não é entrega na caixa de entrada.

Em 5 de outubro, uma coleta com falha não altera nenhum histórico e não gera nenhuma afirmação de ausência.

Tabela principal de acompanhamento:

Registro separado de avisos tentados e confirmados:

Resumo da atividade:

• IDs ainda não vistos em 3 de out.: 1 (`J3`)
• IDs ainda não vistos em 4 de out.: 1 (`J4`)
• Ações confirmadas do provedor nesses dias: 1 (nova tentativa de `J3`)
• Total de chaves acompanhadas: 4