求人情報を繰り返し記録して採用動向を測る方法

収集の設定

Indeed Jobs Scraper ActorとIndeed Job Market Data Taskを開きます。現在のプリセットでは、検索クエリは5つ、対象国は米国、掲載期間は過去7日間、最大取得件数は500件、最大ページ数は15ページ、並び順は日付順、重複のない項目だけを保存する設定は有効です。まずは検索クエリを1つにし、上限を小さく設定して試験収集を始めます。最大取得件数は検索全体で共有されます。国、検索クエリ、バッチは入力内容の証拠であり、出力の各行に含まれることが保証されたフィールドではありません。jobId、jobUrl、title、companyName、locationRaw、postedAt、postedAtRaw、scrapedAtを保持します。IDが欠損している求人は未解決のまま残し、IDの重複を除く集計には含めません。1回の実行内で重複を除いても、別の日の観測記録との重複は除かれません。出力として保存された行、重複、フィルター、停止理由の証拠を確認します。現在の確認用実行で検証したのはソースデータの構造であり、複数日にわたる動向のベンチマークではありません。収集に失敗した日は不明、上限に達した日は収集範囲が限定されているという状態を保持します。

このTaskに保存されている入力値は、`country`が`us`、`searchTerm`が5つの検索クエリ、`postedWithinDays`が`7`、`maxItems`が`500`、`maxPagesPerSearch`が`15`、`sortBy`が`date`、`saveOnlyUniqueItems`が`true`です。試験収集では、`searchTerm`を1つの検索クエリに置き換え、行数とページ数の上限を小さく設定します。`maxItems`の上限は、すべてのキーワードで共有されます。現在の2行・1バッチの確認用実行で検証しているのはソースデータの構造であり、実際の複数日にわたる動向ではありません。

収集パネルを使う方法

1. 収集パネルを定義します。職種の検索クエリ、対象国、サイト、勤務地、フィルター、並び順の方針、行数またはページ数の上限、予定確認時刻を同じ条件にそろえます。調査で明らかにしたいことを変える場合は、新しい比較用パネルを作るか、範囲の変更を明示します。変更を示さずに従来の時系列へ追加してはいけません。
2. 実行マニフェストを保存します。これは実行内容の記録です。バッチID、予定時刻、実際の時刻、入力値、実行結果、保存行数、停止状態、警告を記録します。収集しなかった日や収集に失敗した日は欠測のまま扱い、0にはしません。
3. バッチ、掲載元、求人IDをキーとして観測記録を保持します。集計対象とした各バッチ内では、掲載元の各求人を1回だけ数えます。バッチをまたぐ場合は各観測記録を残し、求人の初回観測表を更新します。求人名が同じという理由だけで、自動的に同一の求人と見なしてはいけません。
4. 返された行の未加工の件数、そのバッチで観測した求人の重複を除いた件数、パネル内で初めて観測したID数、過去にも観測したID数、掲載元または収集上の制約を報告します。「今日初めて観測した」とは、自分の収集処理で初めて取得したという意味です。雇用主が今日初めて掲載したとは限りません。
5. 調査目的に照らして比較できる範囲と収集状態だけを比較します。上限に達したサンプルからも、確認すべき新しいIDは見つけられます。ただし、求人総数の増減は判断できません。収集に失敗した日を、市場の求人数が少なかった日として扱ってはいけません。
6. 時系列を示す際は、数値の横に欠測や収集範囲の制限を示す印を付けます。分母と単位が分かる説明表も用意します。不明な日を測定済みであるかのように、前後の点を線でつないではいけません。
7. 結果の適用範囲を限定して述べます。この固定した観測パネルで分かったことと、依然として不明な比較を説明します。採用についてより広い範囲の主張が必要な場合は、サンプルを広げるか、公的な労働統計を使います。
8. 日次のパネル集計表、初回観測台帳、収集範囲の注記を成果物として提出します。この結果は、掲載元の追加確認や一貫したサンプリングに役立ちます。採用実績や雇用主の意図を測るものではありません。

架空の例と検算済みの件数

この節の求人、時刻、結果はすべて架空です。固定パネルでは、アナリスト職の検索クエリを1つ、対象国を1つにし、同じフィルター方針を使います。確認は毎日12:00 UTCに行う予定とします。

• 1日目に集計対象とする検証用の小さなテストデータには、重複のない4件の求人、J1、J2、J3、J4があります。初回観測は4件、過去に観測済みの求人は0件です。
• 2日目の集計対象データには、重複のない4件の求人、J2、J3、J4、J5があります。初回観測はJ5の1件です。過去に観測済みの求人は3件です。日次の合計が同じでも、新しい掲載元IDがないとは限りません。
• 3日目は収集に失敗しました。集計対象データはありません。観測件数と初回観測件数は不明であり、0ではありません。最後に集計対象データを反映した2日目の台帳を保持します。
• 4日目の集計対象データには、重複のない4件の求人、J3、J4、J5、J6があります。初回観測はJ6の1件です。過去に観測済みの求人は3件です。J6を初めて観測したのは4日目ですが、欠測した3日目に掲載された可能性もあります。作成日を4日目と決めてはいけません。
• 5日目のデータは上限によって収集範囲が限定されています。上限の2件に達したため、重複のない保存項目はJ4とJ7の2件です。初回観測はJ7の1件です。過去に観測済みの求人は1件です。件数が少ないのは、適用中の上限を変更したためです。そのため、留保のない減少の主張からは除外します。範囲の変更を記録するか、数値の横に収集範囲が限定されていると明示します。

集計対象とした観測記録全体の和集合には、J1からJ7までの重複のない7つの掲載元IDが含まれます。求人を観測した延べ件数は4＋4＋4＋2で14件です。各キーの初回観測を除いた再観測の延べ件数は14−7で7件です。これは観測回数であり、7件の求人が再掲載されたという意味ではありません。台帳への新規追加件数は4＋1＋1＋1で7件です。3日目は測定値が0なのではなく不明なので、計算から除外します。日別の重複を除いた件数である4件、4件、4件、2件を足して、重複のない14件の求人機会と呼んではいけません。

現在の実行時検証は1バッチのみであり、実際の複数日にわたる動向のベンチマークではありません。この小さな架空の例で集計対象とした1日目、2日目、4日目のデータが完全なのは、この架空のパネル内だけです。実際のプラットフォームでの完全性を保証するものではありません。