Chronometrica ou Kaix : quel Actor Naukri choisir pour votre flux public d’offres d’emploi ?

Ce qu’un portail emploi doit tirer de cette comparaison

Une demande publique sur Reddit cherche à savoir si une API existante peut fournir des offres d’emploi en Inde pour un portail emploi développé comme projet personnel. Elle soulève une question utile : un service de collecte peut-il fournir les données requises sans que le propriétaire du portail crée un outil d’extraction ? Un outil d’extraction est un programme qui collecte des données sur un site web. Cette demande n’établit ni une préférence pour un fournisseur, ni une couverture complète des employeurs, ni une autorisation de republier les descriptions. Demande initiale pour le portail emploi

Pour prendre cette décision, distinguez les 3 tâches que votre système doit accomplir. Il doit d’abord trouver des offres pertinentes. Il doit ensuite enregistrer chaque offre observée avec assez d’informations pour la vérifier. Enfin, il doit décider quelles informations afficher et quand les vérifier à nouveau.

Un Actor prend en charge la collecte. Votre portail a toujours besoin de règles pour le stockage, la vérification et l’affichage. Un résultat utile ne se limite donc pas à une requête API réussie. Les lignes renvoyées doivent contenir les champs requis. Vous devez aussi comprendre pourquoi la collecte s’est arrêtée.

Cet article vous aide à choisir entre les 2 Actors. Pour connaître la méthode de requête à l’API existante, consultez Comment collecter des offres d’emploi publiques Naukri via une API.

Comparez d’abord les modes de collecte

Un mode de collecte désigne la façon dont vous demandez au programme de trouver des offres. Déterminez le mode nécessaire avant de comparer le nombre de champs disponibles.

Le tableau s’appuie sur la documentation Chronometrica et la documentation Kaix vérifiées. Les identifiants de taxonomie désignent les catégories du système de classification de Naukri.

Chronometrica convient clairement à la recherche simple décrite ici. Ses paramètres documentés permettent de préciser le poste, le lieu, l’expérience et l’ancienneté de l’offre, puis de limiter les lignes enregistrées. Un formulaire plus complet compte lorsqu’un mode de collecte requis en dépend. Un formulaire simple ne prouve pas, à lui seul, une meilleure couverture. Documentation des entrées Chronometrica

Le tableau aide à prendre cette décision précise. Il ne constitue pas un inventaire complet des fonctionnalités. Ne considérez pas qu’une fonctionnalité est absente parce que le tableau ne la documente pas.

Pourquoi Chronometrica convient à un flux de découverte au périmètre défini

Chronometrica documente `searchTerm`, `location`, `experienceYears`, `postedWithinDays`, `sortBy`, `searchDepth` et `maxItems`. Ces champs donnent à un petit portail un formulaire de recherche défini. Ils conviennent à un portail qui peut préciser le périmètre de collecte avant une exécution. Documentation des entrées Chronometrica

La ligne enregistrée comprend `jobId`, `jobUrl`, `title`, `companyName`, `location`, `descriptionText`, `skills`, ainsi que les informations disponibles sur le salaire et l’expérience. Chronometrica enregistre chaque `jobId` unique observé 1 seule fois par exécution. Les informations publiques manquantes restent à `null`. Cette valeur signifie que l’information est inconnue ou indisponible. Documentation des sorties Chronometrica

Cette structure de ligne donne à un petit portail une base utile. Le portail peut identifier l’offre, conserver le lien source et noter les informations à vérifier. Un identifiant d’offre désigne une offre observée. Il ne prouve pas que la page de candidature est toujours active.

Le plafond commun rend la limite de collecte claire. `maxItems` s’applique après le filtrage et la suppression des doublons. Il limite le nombre total de lignes enregistrées pendant l’exécution. Il n’accorde pas un quota distinct à chaque mot-clé. Si votre plan suppose un quota distinct pour chaque mot-clé, modifiez ce plan avant la collecte. Limite de lignes enregistrées de Chronometrica

`searchDepth` propose les niveaux d’effort `standard`, `extended` et `deep`. Un niveau plus élevé ne garantit ni la collecte de toutes les offres ni une meilleure qualité des données. Utilisez ce paramètre pour choisir l’effort de collecte, puis examinez les observations enregistrées. Paramètres de recherche Chronometrica

Ces fonctionnalités vérifiées justifient la recommandation pour une découverte d’offres au périmètre défini. Elles ne prouvent ni un coût inférieur, ni des exécutions plus rapides, ni une couverture complète.

Vérifiez l’adéquation avec un petit jeu de paramètres

La Task publique Naukri Jobs API Dataset fournit un préréglage de départ. Une Task est un préréglage d’entrée enregistré pour un Actor. Examinez les paramètres actuellement définis dans la Task avant de l’utiliser. Lors de la vérification consignée, la page a renvoyé le code HTTP 200, qui indique que la requête a réussi. Cette vérification n’a pas confirmé les paramètres actuellement enregistrés.

Cette requête fictive fournit un petit exemple de contrôle d’acceptation. Un contrôle d’acceptation détermine si un résultat répond aux besoins que vous avez définis.

{
  "searchTerm": "data engineer",
  "location": "Bengaluru",
  "experienceYears": 3,
  "postedWithinDays": "7",
  "searchDepth": "standard",
  "maxItems": 5
}

Ces paramètres ont passé une vérification locale par rapport au schéma JSON public mis en cache. Un schéma JSON définit les champs d’entrée autorisés, les types de valeurs et les limites. Tous les noms de champs fournis figurent dans ce schéma. Cette vérification confirme la structure des paramètres. Elle ne prouve pas la disponibilité de la source en conditions réelles et ne prédit pas le nombre de lignes enregistrées. Aucune exécution de l’Actor n’a été effectuée pour cet exemple. Schéma public de Chronometrica

Conservez les types de valeurs indiqués. `searchTerm` et `location` sont des chaînes de caractères, c’est-à-dire des valeurs textuelles. `experienceYears` est un entier compris entre 0 et 30. Un entier est un nombre sans partie décimale. `maxItems` est un entier supérieur ou égal à 1. Ici, `postedWithinDays` utilise la chaîne `"7"`, et `searchDepth` utilise `"standard"`. Ces valeurs fournies ont passé la vérification par rapport au schéma mis en cache. Schéma d’entrée de Chronometrica

La requête demande 3 ans d’expérience. Vous devez tout de même comparer les exigences de chaque offre renvoyée à cette valeur. Une offre peut indiquer une plage d’expérience ou inclure d’autres conditions dans son texte. La valeur demandée ne prouve pas, à elle seule, que chaque poste renvoyé convient.

Appliquez 5 contrôles d’acceptation

Décrivez le résultat attendu avant la collecte. Un jeu de données rempli n’est utile que si ses lignes répondent aux besoins du flux prévu. Utilisez ces contrôles pour déterminer si l’Actor sélectionné répond à ce besoin.

1. Définissez la recherche et les champs requis. Précisez le poste, le lieu, l’expérience et l’ancienneté de l’offre. Listez les informations dont votre portail a besoin pour identifier et évaluer une offre. Distinguez les besoins de collecte des décisions d’affichage et de republication. Par exemple, un salaire inconnu peut être acceptable si le portail le laisse inconnu.
2. Sélectionnez le mode de collecte. Déterminez si vous devez découvrir des offres ou récupérer un ensemble connu. Appliquez la condition de changement présentée au début avant de sélectionner l’Actor. Ne supposez pas que des recherches larges répétées retrouveront toutes les offres connues.
3. Fixez un petit plafond commun de lignes enregistrées. Examinez les paramètres actuels de la Task et comparez-les au formulaire de l’Actor. Appliquez les paramètres de l’exemple uniquement s’ils correspondent à votre besoin. Consignez le plafond comme un total pour l’exécution. Ne le multipliez pas par le nombre de mots-clés.
4. Examinez les lignes et le résumé d’exécution. Vérifiez les doublons de `jobId`, les URL sources des offres, les textes disponibles sur le salaire et l’expérience, ainsi que les champs manquants. Lisez le résumé `OUTPUT` pour connaître les motifs d’arrêt. Comparez le résultat à vos exigences écrites et vérifiez notamment si la collecte s’est arrêtée au plafond. Documentation des sorties Chronometrica
5. Vérifiez la source avant l’affichage. Ouvrez les pages de candidature à la source pour vérifier leur état actuel. Examinez les conditions applicables de la source avant de publier un flux. Conservez les informations manquantes à `null`. Ajoutez une date et une heure d’observation dans votre propre stockage pour savoir quand les données ont été collectées.

Ces contrôles peuvent mener à 3 décisions utiles : accepter la recherche simple, modifier les exigences ou évaluer l’autre mode. Une inadéquation claire du mode ne nécessite pas un vaste programme de tests. Même si le mode convient, vous devez examiner les lignes avant de relier sa sortie à un flux public.

Si une information requise manque, distinguez ce constat du nombre de lignes. 5 lignes enregistrées ne répondent pas à une exigence de 5 lignes utilisables si certaines n’ont pas un champ nécessaire à votre portail. Décidez quels champs manquants sont acceptables avant d’évaluer le résultat.

Une décision fictive avec un calcul vérifié

Prenons un portail emploi fictif qui souhaite obtenir un petit ensemble d’offres en ingénierie des données à Bengaluru. Il accepte les salaires inconnus, exige une URL source et limite cette collecte à 5 offres uniques enregistrées.

Dans cet exemple inventé, la collecte rencontre 8 occurrences d’offres candidates. 3 occurrences reprennent des valeurs de `jobId` déjà enregistrées à partir d’un autre mot-clé pendant la même collecte. La suppression de ces répétitions laisse 5 offres uniques observées :

`8 candidate appearances − 3 duplicate appearances = 5 unique job rows`

Le calcul est vérifié. Les nombres sont fictifs. Cet exemple ne constitue ni un test d’Actor, ni un jeu de données réel, ni une citation d’acheteur, ni un résultat de coût mesuré.

Le portail enregistre l’URL source de chaque ligne. Il vérifie ensuite si la page de candidature est active. Il consigne aussi la date et l’heure d’observation et note les informations manquantes. Il peut ainsi évaluer les lignes enregistrées sans affirmer davantage que ce que montrent les observations.

5 lignes uniques ne signifient pas 5 employeurs ou 5 postes vacants actifs. Les lignes n’établissent pas non plus une autorisation de republier les descriptions complètes. Ces décisions nécessitent des vérifications distinctes.

Pour ce besoin de découverte au périmètre défini, Chronometrica satisfait à la règle de sélection. Le portail dispose d’une base définie pour collecter un petit ensemble d’offres observées et les examiner.

Modifions maintenant l’exigence fictive. Le portail possède déjà 5 identifiants d’offres précis et a besoin de leurs détails. Il doit évaluer la recherche directe de Kaix plutôt que d’utiliser la découverte pour retrouver ces enregistrements. Modes de recherche directe de Kaix

Stockez les observations sans compter de postes vacants supplémentaires

Utilisez une table d’observations d’offres dans votre propre système. Pour une même exécution, utilisez `jobId` comme clé des lignes. Une clé est la valeur que le stockage utilise pour distinguer une ligne d’une autre. Conservez l’URL source canonique, c’est-à-dire l’adresse source principale de l’offre. Notez les champs manquants.

Ajoutez la date et l’heure auxquelles votre système a observé les données. Il s’agit d’une recommandation de stockage. Elle n’affirme pas que l’Actor fournit un champ d’horodatage particulier. Gardez l’enregistrement de collecte distinct de la décision ultérieure sur l’affichage du poste sur le portail.

Une observation répétée ne crée pas un autre poste vacant. Si la même offre apparaît à nouveau, consignez cette nouvelle observation. N’augmentez pas le nombre d’offres distinctes uniquement parce que l’offre est apparue dans une autre recherche ou à une autre date.

Conservez les informations inconnues comme telles. Un salaire manquant n’est pas un salaire de 0. Une expérience manquante ne signifie pas une exigence de 0 an. Remplacer une valeur inconnue par un nombre crée une information fausse.

Cette méthode de stockage rend le choix de l’outil utile au-delà de la première requête. Votre portail doit préserver le sens des lignes collectées lorsqu’il les stocke, les compte et les affiche.

Quand la recommandation ne convient plus

Le plafond de lignes enregistrées de Chronometrica rend le périmètre de collecte explicite. Il ne prouve pas que les lignes enregistrées comprennent toutes les offres correspondantes. Si votre exigence initiale consiste à enregistrer tous les résultats et que leur nombre dépasse le plafond configuré, Chronometrica ne répond pas à cette exigence avec cette configuration. Paramètres des lignes enregistrées de Chronometrica

Augmenter le plafond ne prouve pas une couverture complète de la source. Augmenter `searchDepth` ne le prouve pas non plus. Les éléments vérifiés n’établissent pas l’exhaustivité. Conservez votre exigence de récupérer tous les résultats lorsque vous évaluez l’outil. Ne la remplacez pas par un échantillon plus petit en déclarant que l’exigence est satisfaite.

Chaque contrôle d’acceptation répond à une question différente. Une entrée valide possède une structure autorisée. Une ligne enregistrée consigne une observation. Une page de candidature vérifiée fournit des éléments sur cette page au moment de l’examen. Aucun de ces contrôles ne répond à lui seul aux 3 questions.

Chronometrica est une API d’Actor indépendante, pas une API officielle de Naukri. L’accès public n’établit pas non plus des droits de republication sans restriction. Conservez les liens sources et examinez les conditions applicables de la source avant d’afficher un flux. Actor Chronometrica