Indeedの求人説明全文を取得するには：ChronometricaとMisceresを比較

作業に必要な求人説明フィールドで選ぶ

Actorは、ホスト上で動作するデータ収集プログラムです。入力によって、何を収集するかを指定します。出力には、次の作業で使うレコードが含まれます。

購入を判断する際は、ドキュメントに記載された出力フィールドと、その意味を確認してください。説明フィールドに有用なテキストが入っていても、プロジェクトに必要なテキストがすべて含まれているとは限りません。どのレコードを分析対象にできるか、判断する方法が必要です。

Chronometricaは、その確認に使う4つの独立したフィールドをドキュメントに記載しています。

• `descriptionSnippet`は、抜粋を別に保持します。
• `descriptionText`は、取得できた場合に求人説明のテキストを提供します。
• `descriptionHtml`は、取得できた場合にHTML形式の求人説明を提供します。HTMLは、リストなどの要素を保持できるページ形式です。
• `descriptionStatus`は、求人説明がどこまで完全に取得されたかを示す状態の確認に役立ちます。

これらのフィールドは、明確な採用基準を設けるのに役立ちます。ただし、返されるすべての求人説明がその基準を満たすと証明するものではありません。状態が`full`のレコードでも、そのテキストが対象の求人に関するものかを確認する必要があります。Chronometricaの出力ドキュメント。

Misceresは、求人説明のほか、職種名、企業名、勤務地、給与などの求人フィールドをドキュメントに記載しています。検索フォームには、職種、勤務地、国、取得件数の上限があります。これらは適合性を検討する理由になりますが、完全性に差があることの証拠ではありません。Misceresの製品ドキュメント。

別々の求人説明フィールドと状態の確認を採用基準に含めるなら、Chronometricaは有力な選択肢です。この推奨は、ドキュメントで確認できる作業手順との適合性に基づいています。すべての検索で、一方の製品がより完全な求人説明を取得できると示すものではありません。

収集前に「全文」の基準を決める

利用者の目的は明確です。Indeedの検索結果から、その求人の説明全文を取得することです。公開されたプログラミングの質問投稿にも、この目的が書かれています。ただし、その投稿は、どちらのActorの性能評価にもなりません。求人説明全文の取得に関する元の質問。

どちらの製品を使う場合でも、実行前に、その目的に沿った基準を決めてください。応募要件の調査なら、次の基準が役立ちます。

求人説明が特定した求人のものであり、調査に必要な、公表済みの職務内容と応募要件を含む場合、そのレコードを採用します。取得元ページのアドレス、つまりURLと、確認時刻を保持してください。未解決の欠落があるレコードは、要確認としてください。

一律の文字数基準を使わないでください。短い説明でも、公表された応募要件がすべて含まれている場合があります。長い文章でも、企業紹介の繰り返し、ナビゲーション、ページの別の部分の内容が含まれている場合があります。文字数は、確認するレコードを探す助けになります。ただし、文字数だけでは完全性を判断できません。

次の2つの問いも分けてください。収集によって、関連する公開テキストを取得できたか。そのテキストは、調査の問いに答えられるか。公開求人の全文を取得しても、調べたい資格要件が書かれていない場合があります。これは、資格要件が書かれたセクションの取得に失敗した場合とは異なります。

採用基準を平易な言葉で書いてください。どのセクションが重要か、どの欠落を要確認とするか、どの取得元情報を保持するかを明記してください。両製品に同じ基準を適用してください。これにより、両製品が異なるフィールド構造を返す場合でも、役立つ比較ができます。

より幅広いテキスト確認方法については、求人のエクスポートに説明全文が含まれているかを確認する方法を参照してください。

初回実行前に入力を確認する

Taskは、Actorの入力設定を保存したものです。Chronometricaの公開Taskを出発点にできます。実行前に入力を開き、値を確認してください。Taskの公開ページがあるだけでは、現在保存されている入力内容は確認できません。

次の少量取得用の入力は、この比較のために記録した公開入力スキーマとの照合に合格しました。スキーマは、使用できるフィールド名、型、値を定義するものです。

{
  "country": "us",
  "searchTerm": "chemical engineer",
  "location": "United States",
  "maxItems": 3
}

確認したスキーマでは、`country`に`us`を指定できます。`searchTerm`と`location`にはテキストを指定できます。`maxItems`には1から10,000までの整数が必要です。これらはドキュメントに記載された入力の制約です。検索によって、指定した件数の利用可能なレコードが返されることの証拠ではありません。Chronometricaの入力ドキュメント。

化学エンジニアの検索条件は、保存された利用者の検索例に基づいています。この執筆資料の作成では、収集を実行していません。スキーマの確認だけでは、現在の化学エンジニアの求人、取得元へのアクセス、求人説明全文の取得は検証できません。

最初の確認では、取得総件数の上限を小さくしてください。3件なら、短時間で手動確認できます。ただし、それだけでは市場全体での性能を示せません。その後のレコードも同じ内容品質になると証明することもできません。

上限も重要です。1回の実行で10,000件を超える結果が必要なら、確認したスキーマではChronometricaはその要件を満たしません。上限付きのエクスポートを、全件の結果として扱わないでください。この比較は、市場全体を漏れなく収集する方法を示すものではありません。

確認済みの入力値`us`以外の国を対象にする場合は、製品を選ぶ前に、ドキュメントに対応が記載されているか確認してください。国の値を変えるだけで、その国の収集に対応するとは考えないでください。

少数のレコードを採用基準で確認し、購入を判断する

役立つ比較には、明確な入力、明確な採用基準、内容を確認できるレコードが必要です。出力を分析に使う前に、次の手順を実施してください。

1. 必要なテキストを定義します。プロジェクトに必要な職務内容、応募要件、取得元情報を書き出してください。どのような場合にレコードを要確認とするか決めてください。テキストの長さだけに基づく基準は避けてください。
2. 入力への対応をドキュメントで確認します。対象の国、検索条件、勤務地、取得件数の上限が、製品のドキュメントに記載された入力に適合するか確認してください。ChronometricaのTaskでは、実行前に実際の保存値を確認してください。
3. 少数のレコードを収集します。手動で確認できる取得総件数の上限から始めてください。入力と確認時刻を記録してください。これらの情報により、何を対象に確認したのかが分かります。
4. 各求人説明を確認します。Chronometricaでは、`descriptionStatus`を`descriptionText`および`descriptionHtml`と併せて確認してください。`descriptionSnippet`は別に保持してください。テキストが特定した求人のものであり、関連する職務内容と応募要件を含むか確認してください。
5. 取得元の求人情報と比較します。取得元の求人情報を開き、関連するセクションを返されたテキストと比較してください。欠落やフィールド間の矛盾で疑問が残る場合は、さらに求人情報を確認してください。未解決のレコードは要確認のままにしてください。
6. 製品を選び、根拠を保持します。対応する入力と返される内容が、自分の基準を満たす製品を選んでください。取得元URL、確認時刻、採用理由をレコードとともに保持してください。スキルや応募要件の分類には、採用済みテキストの集合だけを使ってください。この分類作業をコーディングと呼びます。

他の人にも分かる理由を記録してください。「必要な職務内容と応募要件がある」は、「良さそう」より役立ちます。「抜粋のみ。応募要件のセクションを分析対象として採用できない」は、「問題のあるレコード」より役立ちます。

製品を直接比較する場合は、両製品が対応している範囲で、対象の国と検索条件をそろえてください。求人情報の変更による混乱を減らすため、できるだけ近い時刻に確認してください。入力が異なる場合は、その違いを記録してください。入力の違いにより、比較から分かることには限りが生じます。

少数の確認で分かるのは、出力が確認対象の作業に適しているかどうかです。あらゆる場合の精度や信頼性を主張する根拠にはなりません。後に別の国や新しい職種を扱う場合は、その入力と内容を再確認してください。

架空の3件を使った判断例

次の例は架空のものです。Actorのテスト、実際のデータセット、利用者の結果、製品の完全性を実測した割合のいずれでもありません。

ある調査者が、化学エンジニアの求人の応募要件をコーディングしようとしています。架空のエクスポートには3件のレコードがあります。各レコードには、取得元URLと確認時刻を保持しています。以下のラベルは架空のレコードを示すもので、実際の求人情報ではありません。

AとBについて、調査者は状態と内容の両方を確認します。テキストには、調査に必要な職務内容と応募要件が含まれています。両レコードを採用済みテキストの集合に含めます。

Cの抜粋には、その職種に関する有用な情報があります。ただし、全文として採用できるテキストはありません。調査者は返された状態の値を保持し、内容の欠落を記録します。代わりの状態を作ったり、抜粋を求人説明全文として扱ったりはしません。

計算は次のとおりです。

エクスポートした3件 − 採用できる全文がない1件 = 採用した求人説明レコード2件。

数えている単位は、採用した求人説明レコードです。応募要件の数、重複を除いた雇用主の数、存在する全求人の検証済み件数ではありません。

調査者がCの抜粋で特定のスキルを見つけられなかったとします。それだけでは、その求人がそのスキルを必要としないとは結論できません。欠けている求人説明に、そのスキルが含まれている可能性があります。そのため、Cは、その判断に使う集合に含めません。

この例は、採用するかどうかの判断方法を示しています。採用した2件から、製品の成功率を示すことはできません。

テキストの欠落と応募要件の記載がないことを分ける

収集後に最も重要なのは、値の欠落と、採用済みテキストを確認して記載がなかった場合を区別することです。

値の欠落は、判断に必要な情報がないことを意味します。確認の結果、記載がなかった場合は、関連する採用済みテキストを調べ、自分のコーディング基準ではその項目が見つからなかったことを意味します。分析では、この2つの状態を分けてください。

例えば、給与フィールドが空でも、給与が0という意味ではありません。スキルの値が欠けていても、その職種にスキルが不要という意味ではありません。求人説明が不完全でも、雇用主が応募要件を公表していないという意味ではありません。

Chronometricaのドキュメントには、取得できる給与、スキル、福利厚生、全文が、公開求人の内容に依存すると明記されています。任意の企業情報や応募情報の補完ができても、求人説明全文を取得できた証拠にはなりません。Chronometricaの求人情報と出力に関するドキュメント。

後から付けた分類コードとともに、元の求人説明を保持してください。スキルがあると判定した場合は、その判断の根拠となるテキストを保持してください。テキストが不完全なら、要確認とした理由を保持してください。これにより、収集した証拠を失わずに分析を修正できます。

結果を報告する際は、どのレコードのテキストを使ったか明記してください。「採用した求人説明2件」なら、対象範囲が明確です。架空の例で「3件の求人を分析」と書くと、未解決のレコードがあることを隠してしまいます。

次の分析手順については、求人のスキル用語のコーディングを参照してください。

選択が変わる条件をプロジェクトに当てはめる

抜粋、テキスト、HTMLの各フィールドが別々にあり、`descriptionStatus`もあることが採用基準に合うなら、Chronometricaを選んでください。分析前に求人説明の内容を確認する作業手順では、これがChronometricaを選ぶ明確な理由になります。Chronometrica Indeed Jobs Scraper。

Misceresのドキュメントに記載された対応国や入力範囲を選びたい場合、または既存の作業手順ではMisceresのほうが望ましい場合は、Misceresを検討してください。Misceresも求人説明の抽出をドキュメントに記載しています。Misceres Indeed Scraper。

対象の求人情報について、どちらの製品が要件を満たすかは、確認した内容で判断してください。返されたレコードに必要なテキストがなければ、そのプロジェクトでは全文と判定しないでください。必要なレコードについて、どちらの製品も採用できるテキストを返さない場合、どちらもその部分の要件を満たしていません。

Chronometricaを推奨するうえでの主な限界は、ドキュメントに記載されたフィールドと完全性の状態だけでは、すべての求人について関連する全文を保証できないことです。国や取得元の変更は、返されるフィールドに影響する可能性があります。そのため、購入の判断には、ドキュメントによる入力対応の確認と、少数のレコードを対象とした内容確認の両方が必要です。

この比較には、価格、速度、精度、信頼性の優位性を示す実測の根拠はありません。推奨は、確認した求人説明フィールドと、それらを使って行える確認手順に基づいています。