> 継続的なプロセス改善 > 採用・タレント獲得 > Greenhouse > データテンプレート

採用・タレント獲得データテンプレート

Greenhouse

採用・タレント獲得の属性 (22) 採用・タレント獲得活動 (14) 抽出ガイド (3)

採用・タレント獲得データテンプレート

このテンプレートは、採用・タレント獲得プロセスに適したデータ収集のための包括的なガイドです。追跡すべき必須属性、記録すべき主要な活動、Greenhouseシステムからこの情報を抽出するための明確なガイダンスを概説しています。このテンプレートに従うことで、洞察に満ちたプロセス分析のためのデータ基盤を確実に構築できます。

収集を推奨する項目
追跡すべき主要アクティビティ
抽出の手引き

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

テンプレートをダウンロード

採用・タレント獲得の属性

Greenhouse内での採用・タレント獲得プロセスを包括的に分析するために、イベントログに含めることが推奨されるデータフィールドです。

5 必須 6 推奨 11 任意

	名前	説明
	`アクティビティタイムスタンプ` ActivityTimestamp	採用活動が発生した正確な日時です。
説明アクティビティタイムスタンプは、採用プロセスでイベントが発生した正確な時刻を示します。これは、すべてのパフォーマンスおよび期間ベースの分析の時間的基盤となり、各求人応募に対するアクティビティの時系列順を提供します。このタイムスタンプは、採用リードタイム、面接スケジューリングサイクルタイム、面接フィードバック回答時間など、時間関連のすべてのKPIを算出するために不可欠です。異なるアクティビティ間の経過時間を分析することで、組織は効率を測定し、遅延を特定し、サービスレベル契約への順守状況を監視できます。これは、パフォーマンスとボトルネックに焦点を当てたダッシュボードを直接的にサポートします。その重要性このタイムスタンプは、イベントの順序付け、サイクルタイムの計算、および採用プロセスのパフォーマンス分析に不可欠です。取得元 Greenhouse内の様々なオブジェクトで検出されます。例えば、Applicationオブジェクトの「applied_at」、Offerオブジェクトの「created_at」、またはアクティビティフィードや監査ログ内のタイムスタンプなどです。例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	アクティビティ名 ActivityName	発生した特定の採用活動またはステージの名前です。
説明この属性は、「応募受付」、「面接設定」、「オファー受諾」など、採用プロセスにおける各イベントの名前を記録します。これは、プロセスマップを構成するイベントのシーケンスを形成します。これらの活動の順序と頻度を分析することは、プロセスマイニングの基礎です。採用ファネルを可視化し、共通のプロセスパスを特定し、標準ワークフローからの逸脱を検出し、プロセスが停滞するボトルネックを特定するのに役立ちます。例えば、「応募内容レビュー済み」から「リクルータースクリーニング実施済み」に進む応募の数を追跡できます。その重要性この属性は採用プロセスのステップを定義し、プロセスフローの可視化、ボトルネックや逸脱の特定を可能にします。取得元これは、Greenhouse内の応募ステージの変更、面接ステータス、オファーイベント、またはその他の監査可能なアクションをマッピングすることによって派生されることがよくあります。システムイベントを標準化された活動名に変換するためのロジックが必要となる場合があります。例申請レビュー済み面接完了内定承諾済み申請却下済み
	求人応募 JobApplicationId	特定の求人に対する個々の候補者の応募を一意に識別するIDです。
説明求人応募IDは、採用プロセス分析の要であり、一意のケース識別子として機能します。初期応募とスクリーニングから、面接、オファー、最終的な採用決定まで、関連するすべての活動を結びつけます。これにより、各候補者のジャーニーを完全にエンドツーエンドで把握できます。プロセスマイニングにおいて、この属性は各候補者が採用ファネルをたどる正確なパスを再構築するために使用されます。これにより、プロセスバリアント、応募ごとのサイクルタイム、および離脱地点の分析が可能になり、個々の応募者に対する採用ライフサイクル全体を明確に把握できます。その重要性これは、単一の候補者に関するすべての採用イベントを結びつける不可欠なケースIDであり、採用ジャーニー全体を最初から最後まで分析することを可能にします。取得元これは通常、アプリケーションオブジェクトのプライマリキーです。Greenhouse APIドキュメントの「Applications」エンドポイントを参照してください。これはしばしば「id」または「application_id」と呼ばれます。例 987654321098765432119876543212
	ソースシステム SourceSystem	データが抽出された記録システムを特定します。
説明この属性は、採用データの起源を特定します。このプロセスでは、値は一貫して「Greenhouse」となります。静的な値に見えるかもしれませんが、ソースシステムを明示的に追跡することは、データガバナンス、トラブルシューティング、およびHRISなどの他のシステムからデータが充実される可能性のあるシナリオにおいて重要です。これにより、データの出所を明確にし、組織のデータランドスケープ全体でデータ整合性を維持するのに役立ちます。その重要性明確なデータの出所を確保し、これはデータガバナンス、検証、および複数のソースからのデータ管理にとって不可欠です。取得元これは、データ抽出および変換プロセス中にデータの起源をラベル付けするために追加されるべき静的な値です。例 Greenhouse
	最終データ更新 LastDataUpdate	このイベントのデータが最後に更新または抽出された日時を示すタイムスタンプ。
説明この属性は、データがソースシステムから最後に取得された日時を記録します。これは、プロセスマイニングモデル内のデータの鮮度を反映するメタデータフィールドです。この情報は、ユーザーが分析の現状を理解するために不可欠です。データレイテンシに関する期待値を管理するのに役立ち、データパイプラインがスケジュールどおりに実行されていることを検証するために重要です。例えば、「最終データ更新」が数日前のものだった場合、ユーザーはダッシュボードが最新の採用活動を反映していないことを認識します。その重要性データの鮮度を示し、分析がプロセスの最新状態を反映しているかどうかをユーザーが理解するのに役立ちます。取得元このタイムスタンプは、データ抽出、変換、ロード（ETL）プロセス中に生成され、データセットに記録されます。例 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	アプリケーションソース ApplicationSource	候補者の応募が受け付けられたチャネルです。
説明この属性は、求人応募の発生元（例：LinkedIn、社員紹介、会社ウェブサイト、Indeedなど）を追跡します。これにより、さまざまな採用チャネルの有効性に関する洞察が得られます。「ソーシングチャネル効果」ダッシュボードは、この属性を中心に構築されています。応募数、採用リードタイム、および発生元ごとの採用率を分析することで、組織は採用マーケティング費用と労力を最適化できます。このデータは、どのチャネルが最も効率的に質の高い候補者を提供するかという戦略的な疑問に答えるのに役立ち、「ソーシングチャネルコンバージョン率」KPIを直接的にサポートします。その重要性さまざまな採用チャネルの効果とROI（投資収益率）を測定するのに役立ち、ソーシングの取り組みをどこに投資すべきかについてデータに基づいた意思決定を可能にします。取得元 Greenhouseの候補者オブジェクトで利用可能で、応募にリンクされています。「source」フィールドがこの情報を提供します。例 LinkedIn従業員紹介会社`採用ページ`Indeed
	リクルーター名 RecruiterName	求人応募の管理を担当するリクルーターの名前です。
説明この属性は、特定の求人応募または募集に割り当てられたリクルーターを識別します。この人物は通常、スクリーニング、面接の調整、候補者をプロセスを通じて進める責任を負います。リクルーター別にプロセスを分析することは、個々のパフォーマンスと業務負荷の配分を理解する上で重要です。「リクルーターの業務負荷と効率」ダッシュボードは、この属性に依存して、リクルーターごとのスループットやサイクルタイムなどの指標を計算します。これは、トップパフォーマーを特定し、追加のサポートが必要な個人を明確にし、タレント獲得チーム全体の業務負荷のバランスを確保するのに役立ちます。その重要性プロセスアクティビティを特定の採用担当者に帰属させ、個々のパフォーマンス、業務負荷、および効率の分析を可能にします。取得元 Greenhouseのジョブオブジェクトで利用可能で、通常「hiring_team」セクションの一部として、「Recruiter」のような役割が指定されます。例 Alice Johnsonロバート・デイビスMaria Garcia
	内定ステータス OfferStatus	候補者に提示された求人オファーの現在のステータスです。
説明この属性は、「作成済み」、「提示済み」、「受諾済み」、「却下済み」などの求人オファーの状況を追跡します。これは採用プロセスの最終段階を示す重要な指標です。この属性は「オファー受諾率トレンド」ダッシュボードおよび関連するKPIにとって不可欠です。「オファー提示済み」から「オファー受諾済み」または「オファー却下済み」への進捗を追跡することで、企業は候補者を獲得する能力を測定できます。これを部署別または役職別に分析することで、報酬の競争力、候補者体験、または候補者の決定に影響を与えるその他の要因に関する洞察を明らかにすることができます。その重要性求人オファーの結果を追跡し、オファー受諾率KPIの算出とその改善方法を理解する上で重要です。取得元 Greenhouseのオファーオブジェクトで利用可能で、応募にリンクされています。「status」フィールドがこの情報を提供します。例受諾済み却下送信済み作成済み
	役職 JobTitle	候補者が応募したポジションの役職名です。
説明この属性には、「シニアソフトウェアエンジニア」や「プロダクトマーケティングマネージャー」など、求人募集の正式な役職名が含まれています。これは、募集中の職務に関する重要な文脈を提供します。役職ごとに採用プロセスを分析することは、職務固有の課題を理解する上で不可欠です。例えば、「採用リードタイムパフォーマンス」ダッシュボードでは、この属性を使用して、上級職や高度に専門化された職務が埋まるまでに時間がかかるかどうかを示します。また、異なるポジションのオファー受諾率を分析するのにも役立ち、報酬の競争力や職務の魅力に関する洞察を提供します。その重要性特定の役割に関する採用メトリクスをフィルタリングし比較することを可能にし、職務の複雑さやタイプによってプロセスパフォーマンスがどのように異なるかを理解するのに役立ちます。取得元これはGreenhouseのJobオブジェクトのプライマリフィールドであり、APIを介して「jobs」エンドポイントを照会する際に「name」として利用できることがよくあります。例シニア`ソフトウェアエンジニア`アカウントエグゼクティブUX/UIデザイナー
	求人部署 JobDepartment	求人ポジションが募集されている部署または事業単位です。
説明この属性は、求人募集に関連する「エンジニアリング」、「マーケティング」、「セールス」などの組織部門を指定します。これにより、ビジネスの異なる部分間で採用指標を集計し、比較することが可能になります。部署別に分析をセグメント化することは、「採用リードタイムパフォーマンス」や「オファー受諾率トレンド」のようなダッシュボードにとって重要です。これにより、特定の部署がより長い採用サイクル、高いオファー辞退率、または異なるプロセスコンプライアンスレベルを持つかどうかを特定するのに役立ちます。これらの洞察は、各部署の特定のニーズに合わせて調整されたターゲットを絞った介入とプロセス改善を可能にします。その重要性異なる部署間の採用パフォーマンスとプロセスバリエーションの比較を可能にし、システム的な問題やベストプラクティスを明らかにします。取得元通常、GreenhouseのJobオブジェクト上の標準またはカスタムフィールドとして利用可能です。APIを介してJobレコードの「departments」セクションで見つけることができます。例エンジニアリングプロダクトマネジメント営業マーケティング
	申請ステータス ApplicationStatus	求人応募の最終結果または現在のステータスです。
説明この属性は、「採用済み」、「却下済み」、「アクティブ」など、応募の処理状況を示します。これは、完了したプロセスの最終状態、または進行中のプロセスの現在の状態を表します。これは結果分析にとって重要な次元です。採用された候補者と却下された候補者のプロセスパスを比較するためにケースをフィルタリングでき、これにより成功したジャーニーの特性を明らかにすることができます。また、「全体的な採用ファネル」ダッシュボードでコンバージョン率を計算するためにも使用され、応募の何パーセントが採用につながったかを示します。その重要性採用プロセスの結果を定義し、成功した（採用された）候補者のジャーニーと不成功に終わった（不採用となった）候補者のジャーニーを比較する分析を可能にします。取得元この情報はGreenhouseのApplicationオブジェクトにあり、APIの「status」フィールドから利用可能です。例採用済み却下アクティブ
	アクティビティ終了時間 ActivityEndTime	期間を持つアクティビティが完了したことを示すタイムスタンプ。
説明この属性は、面接やバックグラウンドチェックなど、一定期間にわたる活動の完了時間を記録します。多くの活動は瞬間的ですが、測定可能な期間を持つ活動は、開始時刻と終了時刻の両方を持つことで恩恵を受けます。終了時刻は、特定の活動の処理時間または期間を正確に計算するために不可欠です。これにより、ステップ間の待機時間とタスクに実際に費やされた時間を区別するのに役立ちます。例えば、面接が実際にどれくらいの時間がかかるか、それとも面接をスケジュールするのにどれくらいの時間がかかるかをより正確に分析することが可能になります。その重要性アクティビティ処理時間の正確な計算を可能にし、これによりプロセスにおけるアクティブな作業時間とアイドル待ち時間を区別するのに役立ちます。取得元この情報は、Greenhouseの「scheduled_interview」のようなオブジェクトで利用できる場合があります。これには多くの場合、「開始」時刻と「終了」時刻の両方が含まれています。他の活動については、後続の活動のタイムスタンプから推測する必要があるかもしれません。例 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	コンプライアンス遵守 IsCompliant	応募が標準的な定義された採用プロセスに従ったかどうかを示す計算フラグです。
説明このブール型属性は、求人応募に対する実際のアクティビティシーケンスと、事前に定義された理想的なプロセスモデルを比較する適合性チェックの結果です。必須ステップのスキップや、順序外での活動実行など、逸脱したケースにフラグを立てます。これは、「採用コンプライアンス逸脱」ダッシュボードのコア属性であり、「プロセス適合率」と「コンプライアンス違反件数」のKPIをサポートします。不適合なケースをフィルタリングすることで、組織は不適切なトレーニング、システム制限、または必要な例外など、逸脱が発生する理由を調査できます。これにより、ワークフローの標準化とコンプライアンスリスクの軽減に役立ちます。その重要性プロセス逸脱を特定し、これはプロセス適合性を測定し、コンプライアンスを確保し、採用ワークフローを標準化するために不可欠です。取得元これはプロセスマイニングソフトウェアによって生成される算出フィールドです。イベントログデータを定義されたターゲットモデルまたはビジネスルールセットと比較します。例 truefalse
	ジョブID JobId	求人募集または求人票の一意の識別子です。
説明この属性は、応募IDとは異なる、求人自体の一意のIDです。複数の応募が同じ求人IDにリンクされます。求人IDを使用すると、募集レベルでデータを集計できます。例えば、特定の求人に対する総応募数を分析したり、類似するすべての職務の平均採用リードタイムを分析したりできます。これにより、単一の募集を中心とした採用活動をグループ化して分析する方法が提供されます。その重要性単一の求人に関連するすべての候補者データを集計・分析することを可能にし、求人中心の視点を提供します。取得元これはGreenhouseのJobレコードのプライマリキーであり、APIを介したJobオブジェクトの「id」として利用可能です。例 400123400124400125
	スコアカード推奨 ScorecardOverallRecommendation	完了した面接スコアカードからの全体的な採用推奨です。
説明この属性は、面接官が構造化された面接スコアカードで行った最終的な推奨（通常、「強く推奨」、「推奨」、「非推奨」、「強く非推奨」などの値）を記録します。このデータは、面接プロセスの質と一貫性を評価する上で極めて重要です。「より強く推奨された候補者がより多く採用されるか？」といった疑問に答えることで、面接フィードバックと実際の採用結果を関連付けるのに役立ちます。また、組織内での構造化された採用慣行の導入度合いを測定する「スコアカード完了率」KPIの基礎でもあります。その重要性構造化された面接フィードバックをプロセス結果に結びつけ、データ駆動型採用プラクティスの導入を測定するのに役立ちます。取得元 Greenhouseで完了した面接に関連付けられたスコアカードオブジェクト内にあります。APIは「scorecards」エンドポイントを介してこの情報を提供します。例強く非推奨いいえはい強く推奨
	候補者ID CandidateId	単一の応募とは独立した、候補者固有の識別子です。
説明候補者IDはタレントプール内で個人を一意に識別しますが、求人応募IDは特定の1つの求人に対する1つの応募に特有のものです。1人の候補者が複数の求人に応募することもあります。求人応募IDがこの特定のプロセスビューにおけるケースIDとして機能する一方で、候補者IDを持つことで異なる種類の分析が可能になります。これを用いると、複数の求人応募にわたる候補者のジャーニーを追跡したり、頻繁に応募する候補者を特定したり、タレントプール全体との関係を分析したりできます。これにより、採用データに対してより個人中心の視点を提供します。その重要性同じ候補者からの複数の応募にわたる分析を可能にし、候補者のエンゲージメントの時間的推移に関するより広範な視点を提供します。取得元これはGreenhouseの候補者レコードのプライマリキーであり、APIを介したCandidateオブジェクトの「id」として利用可能です。例 123456123457123458
	却下理由 RejectionReason	候補者の応募を却下した理由です。
説明この属性は、候補者がプロセスに進まなかった特定の理由を記録します。例えば、「文化的に不適合」、「給与期待が高すぎる」、「より適格な候補者がいた」などです。不採用理由の分析は、採用プロセスにとって非常に貴重なフィードバックを提供します。これは、職務記述書の不一致、競争力のない報酬、またはタレントプールにおける繰り返し発生するスキルギャップなどの問題を浮き彫りにすることができます。この情報は、採用ファネルにおける一般的な失敗点を理解することで、ソーシング戦略を改善し、候補者体験を向上させる上で特に有用です。その重要性なぜ候補者が採用プロセスから脱落するのかについて質的な洞察を提供し、職務記述書、ソーシング、スクリーニング基準の改善に役立ちます。取得元応募が却下された際にアプリケーションオブジェクトで利用できます。APIは詳細情報を含む「rejection_reason」オブジェクトを提供します。例必要スキル不足給与期待が高すぎるより適格な候補者を採用
	採用にかかる時間 TimeToHire	応募が受け付けられてから候補者が採用済みとマークされるまでの合計期間です。
説明この算出された指標は、成功した採用プロセスのエンドツーエンドの期間を測定します。これは、タレント獲得機能全体の効率を評価するための最も重要なKPIの一つです。この属性は、「採用リードタイムパフォーマンス」ダッシュボードおよび「平均採用リードタイム」KPIを直接サポートします。特定の求人応募について、「応募受付」と「候補者採用済み」の活動間の時間差として計算されます。この指標を分析することで、組織はベンチマークを設定し、採用プロセスにおけるシステム的な遅延を特定するのに役立ちます。その重要性これは、成功した採用のための採用ファネル全体の効率を測定する主要な業績評価指標です。取得元これは算出フィールドです。「応募受付」イベントのタイムスタンプを「候補者採用済み」イベントのタイムスタンプから差し引くことによって導出されます。例 259200043200003456000
	採用マネージャー名 HiringManagerName	関連する求人募集の採用マネージャーの名前です。
説明この属性は、空きポジションを持つチームのマネージャーを特定します。採用マネージャーはプロセスの主要な関係者であり、候補者のレビュー、後半の面接実施、最終的な採用決定に頻繁に関与します。採用マネージャー別にプロセスを分析することで、重要なパターンやボトルネックを明らかにできます。例えば、「面接スケジューリングのボトルネック」ダッシュボードでは、遅延が特定のマネージャーの可用性と頻繁に関連していることが示されるかもしれません。これは、マネージャーが採用プロセスに効率的に関与していることを確実にするためのトレーニングやサポートの必要性を特定するのに役立ちます。その重要性主要なステークホルダーを特定し、特定の採用マネージャーに関連するプロセスボトルネックや効率性の分析を可能にします。取得元 Greenhouseのジョブオブジェクトで利用可能で、通常「hiring_team」セクションの一部として、「Hiring Manager」のような役割が指定されます。例 Emily TranDavid Chenソフィア・ロドリゲス
	自動化 IsAutomated	活動がシステムによって自動的に実行されたかどうかを示すフラグです。
説明このブール型属性は、活動がユーザーによって実行されたか、自動システムルールによって実行されたかを示します。自動化された活動の例には、自動返信メールの送信や、基本的なスクリーニング質問に不合格だった候補者の自動却下などが含まれます。この属性を分析することは、採用プロセスにおける自動化のレベルを理解するのに役立ちます。自動化されたステップと手動ステップの効率性および結果を比較するために使用でき、速度と一貫性を向上させるためのさらなる自動化の機会を特定するのに役立ちます。その重要性手動活動と自動活動を区別するのに役立ち、自動化がプロセス効率と結果に与える影響の分析を可能にします。取得元この情報は標準フィールドではなく、通常は派生させる必要があります。活動に関連付けられたユーザー（例：「システム」ユーザー）や、自動化されていることが知られている特定のイベントタイプから推測できます。例 truefalse
	面接ステージ InterviewStageName	面接ステージの特定の名称または種類です。
説明この属性は、「リクルータースクリーニング」、「技術面接」、「最終面接」など、面接プロセス全体の特定の段階を示します。一般的な「面接完了」アクティビティよりも詳細な粒度を提供します。各面接段階で指標を分析することで、組織はより具体的なボトルネックを特定できます。例えば、「候補者離脱率（段階別）」を高い精度で測定し、技術面接後と初期スクリーニング後で候補者が辞退する傾向があるかどうかを特定できます。この詳細は、面接体験にターゲットを絞った改善を行う上で不可欠です。その重要性面接プロセスのより詳細なビューを提供し、各面接ステップでのサイクルタイムと離脱率の分析を可能にします。取得元この情報はGreenhouseの面接スケジューリングデータの一部です。求人応募の「interviews」オブジェクトには、面接段階に関する詳細が含まれています。例 `リクルーター`面談採用マネージャー面接技術アセスメント最終面接（対面）
	面接フィードバック所要時間 InterviewFeedbackTurnaroundTime	面接が完了してから面接官がフィードバックを提出するまでの経過時間です。
説明この算出された指標は、面接担当チームの対応速度を測定します。フィードバック提出の遅延は、採用プロセスを著しく遅らせ、候補者体験に悪影響を与える可能性があります。この属性は、「面接フィードバックループ分析」ダッシュボードおよび「面接フィードバック回答時間」KPIを直接サポートします。これは「面接完了」と「フィードバック提出済み」の活動間の時間差として計算されます。この指標を監視することは、遅いフィードバックによって引き起こされるボトルネックを特定し、より迅速な意思決定を促進するのに役立ちます。その重要性面接後のフィードバックループの効率を測定します。これは採用プロセスにおける一般的な遅延の原因です。取得元これは算出フィールドです。「面接完了」イベントのタイムスタンプから「フィードバック提出済み」イベントのタイムスタンプを差し引くことによって導出されます。例 86400172800259200

必須推奨任意

採用・タレント獲得活動

これらは、採用ファネルの正確なプロセス発見と最適化のために、イベントログに記録すべき主要なプロセスステップとマイルストーンです。

7 推奨 7 任意

	アクティビティ	説明
	候補者採用済み	候補者はすべての採用前チェックを無事完了し、正式に採用されました。これは応募プロセスの成功裏の完了と最終イベントです。
その重要性これはプロセスの主要な成功結果です。「応募受付」からこのイベントまでの時間は、全体の採用リードタイムであり、重要な採用KPIです。取得元これはGreenhouseでの明示的なアクションであり、リクルーターが特定の求人に対して候補者を採用済みとマークします。このアクションにより、候補者はアクティブな状態から採用済みの状態へ移行します。取得 Greenhouseの「採用済みとしてマーク」アクションのタイムスタンプから取得されます。イベントタイプ explicit
	内定承諾済み	候補者が正式に求人オファーを受諾しました。これは主要な成功マイルストーンであり、通常、バックグラウンドチェックなどの採用前活動が後続します。
その重要性これは重要な成功マイルストーンであり、オファー受諾率KPIの主要な構成要素です。候補者から将来の従業員への移行を意味します。取得元これは、リクルーターまたは候補者の電子的な受諾により、Greenhouseでオファーステータスが「Accepted（受諾済み）」に更新された際に捕捉される明示的なイベントです。取得オファーのステータスが「受諾」に変更されたタイムスタンプから取得されます。イベントタイプ explicit
	内定提示済み	公式な求人オファーが候補者に送信されました。これは面接と選考プロセスの集大成を示す重要なマイルストーンです。
その重要性この活動は、オファー受諾率KPIを算出する基礎となります。候補者にとっての最終決定フェーズの開始を意味します。取得元これはGreenhouseでオファーのステータスが「送信済み」または「提示済み」に変更された際に記録される明示的なイベントです。オファーオブジェクトには、これらのステータス変更のタイムスタンプが含まれています。取得オファーのステータスが正式に「送信済み」とマークされたタイムスタンプから取得されます。イベントタイプ explicit
	応募を受理しました	このアクティビティは、特定の求人応募における採用プロセスの開始をマークします。候補者がキャリアサイトやソーシングチャネルを通じて応募を提出した際、またはGreenhouseに手動で入力された際に記録されます。
その重要性これはプロセスの主要な開始イベントです。この活動から他の活動までの時間を分析することは、採用リードタイムとソーシングチャネルの有効性を測定するために極めて重要です。取得元これは、Greenhouseで応募が作成されたときにログに記録される明示的なイベントです。応募オブジェクトの「Application Date」フィールドまたは作成タイムスタンプがイベント時間を提供します。取得応募レコードの作成タイムスタンプから取得されます。イベントタイプ explicit
	申請却下済み	候補者の応募はプロセス中のどこかの時点で却下されました。これは最も一般的な不成功の終了イベントであり、どの段階でも発生する可能性があります。
その重要性これは、ファネルの離脱率を分析するための重要な終了イベントです。却下が発生する時期と理由を理解することは、プロセスの非効率性や不適切な職務要件を特定するのに役立ちます。取得元これは、ユーザーがGreenhouseで応募を却下した際に記録される明示的なイベントです。多くの場合、却下理由が付随し、アクティビティログにはタイムスタンプが記録されます。取得応募に適用された却下アクションのタイムスタンプから取得されます。イベントタイプ explicit
	面接予定	候補者との面接がシステム内でスケジュールされました。Greenhouseはカレンダーとの連携機能があるため、このイベントは通常、面接が確定した際に明示的にログに記録されます。
その重要性このイベントは、面接スケジューリングプロセスにおけるボトルネックを分析・特定するために極めて重要です。このイベントと前のステップとの間の時間は、リクルーターとコーディネーターの効率性を示す主要なKPIとなります。取得元 Greenhouse内の面接スケジューリング機能から取得されます。APIは、面接予定の作成タイムスタンプを含むデータを提供します。取得面接イベントが作成され、候補者の応募に関連付けられた際にログに記録されます。イベントタイプ explicit
	面接完了	候補者との面接が実施されました。これは多くの場合、面接予定時刻が過ぎたこと、またはより信頼性の高い方法として、その面接に対するフィードバックが提出されたことに基づいて推測されます。
その重要性このアクティビティは、候補者のジャーニーにおける重要なマイルストーンです。フィードバック提出時間や次のステージへの進行を測定する起点となります。取得元通常は推測されます。スケジュールされた面接の終了時刻から、またはより正確には、その特定の面接のために提出された最初のフィードバックのタイムスタンプから導出できます。取得スケジュールされた面接終了時刻、またはその後のフィードバック提出のタイムスタンプから推測されます。イベントタイプ inferred
	`オンボーディング`開始	新入社員の会社へのオンボーディングプロセスが正式に開始されました。これは多くの場合、採用システムからHRISまたはオンボーディングプラットフォームへの引き渡しを伴います。
その重要性これは採用から人事への引き渡しの効率を追跡します。ここでの遅延は、新入社員の体験を悪化させる可能性があるため、オンボーディング引き渡し時間の監視は非常に重要です。取得元これは、Greenhouseがオンボーディングシステムと統合されている場合は明示的なイベントとなる可能性があります。そうでない場合は、候補者が最終的な「採用済み」ステージに移動し、それが引き渡しをトリガーするタイムスタンプから推測されます。取得ステージ変更、またはHRISへの引き継ぎを示す連携ログから推測されます。イベントタイプ inferred
	オファー作成済み	正式な求人オファーが作成され、社内承認を待っている可能性があります。これは、候補者へのオファーを進めるという正式な決定を示します。
その重要性この活動は、オファーを出す決定と実際にオファーを提示する行為を区別します。これにより、オファーが候補者に届く前の社内承認時間やボトルネックを分析するのに役立ちます。取得元 Greenhouseには専用のオファーモジュールがあります。これは、応募に関連付けられたオファーオブジェクトの作成タイムスタンプから捕捉される明示的なイベントです。取得 Greenhouseシステムでオファーレコードが作成された際にログに記録されます。イベントタイプ explicit
	オファー却下	候補者が正式に求人オファーを辞退しました。これは採用プロセスの終盤で発生する、不成功に終わったイベントです。
その重要性この結果を追跡することは、オファー受諾率を分析する上で極めて重要です。このイベントの発生頻度が高い場合、報酬、文化、または職務そのものに問題がある可能性を示唆します。取得元これは、Greenhouseでオファーステータスが「Rejected（却下）」または「Declined（辞退）」に更新された際に捕捉される明示的なイベントです。オファーオブジェクトには、このステータス変更のタイムスタンプが含まれます。取得オファーのステータスが「辞退」に変更されたタイムスタンプから取得されます。イベントタイプ explicit
	フィードバック提出済	面接官が候補者の面接に関するスコアカードまたはフィードバックを提出しました。Greenhouseの構造化された採用プロセスは、意思決定のためにこれに依存しており、個別のログに記録されるアクションです。
その重要性フィードバックの適時性は、候補者選考を進める上で極めて重要です。この活動は、フィードバックループの効率性やスコアカード完了率の分析に役立ちます。取得元これは、面接官がGreenhouseを通じてスコアカードを提出した際に記録される明示的なイベントです。Scorecards APIオブジェクトには`submitted_at`タイムスタンプが含まれています。取得面接スコアカードの提出タイムスタンプから取得されます。イベントタイプ explicit
	リクルータースクリーニング実施済み	採用担当者が候補者との初回電話スクリーニングまたは会話を完了しました。この活動は、候補者を採用パイプライン内の特定の「電話スクリーニング」ステージに移動させることによって捕捉されることがよくあります。
その重要性これは、応募が初期書類選考を通過したことを示す重要な選考マイルストーンです。リクルーターの業務負荷と初期スクリーニングの有効性を測定するのに役立ちます。取得元応募がGreenhouseの求人パイプライン内で「電話スクリーニング」ステージに移動した、またはそのステージから移動したタイムスタンプから推測されます。取得応募のステージ履歴から導出され、特に「電話スクリーニング」ステージへの移行を記録します。イベントタイプ inferred
	申請レビュー済み	採用担当者または採用マネージャーが候補者の応募書類の初期レビューを実施しました。これは通常、応募のステージまたはステータスが「新規」から「審査中」のようなアクティブな審査ステージに変更されたときに推測されます。
その重要性これを追跡することで、初期スクリーニング段階のボトルネックを特定し、新規応募に注意が払われるまでの時間を測定できます。これは面接スケジューリングサイクルタイムを計算する出発点となります。取得元応募ステータスフィールドの変更から推測されます。変更のタイムスタンプを使用して、「新規」状態から「審査中」状態へのステータス変更を探します。取得ステータスが「審査中」または類似のステージに変更されたタイムスタンプから推測されます。イベントタイプ inferred
	身元調査を開始しました	候補者のバックグラウンドチェックが開始されました。通常、オファー受諾後に行われます。これは特定のステージ変更として、またはサードパーティサービスとの連携トリガーとして記録される場合があります。
その重要性このアクティビティは、コンプライアンスと採用前スクリーニングの遅延追跡にとって重要です。オファー受諾から必要なチェックの完了までの時間を分析するのに役立ちます。取得元これは、採用パイプラインで候補者を「バックグラウンドチェック」ステージに移動すること、またはバックグラウンドチェック統合に関連する活動ログから推測される可能性が高いです。取得「バックグラウンドチェック」ステージへのステータス変更、または統合サービスからのAPIログから推測されます。イベントタイプ inferred

推奨任意

抽出ガイド

Greenhouseからデータを取得する方法

ステップ

Greenhouse Recruitingアカウントにログインします。
メインナビゲーションバーのレポートアイコン（棒グラフのようなもの）をクリックして、「レポート」セクションに移動します。
レポートダッシュボードで、「Essential Reports」を見つけてクリックします。この抽出の主要レポートは「All Applications」です。このレポートは、応募とそれらの主要なマイルストーンを包括的に表示します。
「All Applications」レポートを設定します。「Columns」ボタンをクリックします。必要な属性とアクティビティのタイムスタンプを捕捉するために必要なすべての列を選択します。以下を含めることを確認してください: Application ID、Candidate、Job、Department、Recruiter、Status、Source、Applied On、Rejected On、Hired On、Last Stage Change On、Offer Created On、Offer Accepted On、Offer Status。
面接関連の活動を捕捉するには、別のレポートが必要です。Essential Reportsに戻り、「Interview Details」を選択します。
「Interview Details」レポートを設定します。「Columns」セクションで、少なくとも以下を選択します: Application ID、Interview Name、Scheduled Start、Scorecard Submitted At。これにより、スケジュールとフィードバック提出のタイムスタンプが得られます。
両方のレポートで、フィルターを使用して適切な日付範囲を設定します。一般的なフィルターは、「Applied On」を「All Time」または過去6ヶ月のような特定の範囲に設定し、関連する応募群を捕捉することです。
「Update」または「Generate」ボタンをクリックして、各レポートを生成します。レポートが表示されたら、「Export to Excel」ボタンをクリックしてデータをCSVファイルとしてダウンロードします。これで2つの別々のCSVファイルが得られます。
エクスポートされたファイルはまだイベントログ形式ではありません。Python、R、またはMicrosoft ExcelのPower Queryのようなアンピボット機能を備えたスプレッドシートプログラムなどのツールを使用して、変換ステップを実行する必要があります。
「All Applications」と「Interview Details」レポートのデータを、Application IDで結合します。
各応募について、エクスポートした関連するすべての日付列に対して個別の行を作成します。例えば、「Applied On」列の値は、「Application Received」という名前のアクティビティの「ActivityTimestamp」になります。「Rejected On」列の値は「Application Rejected」アクティビティを作成し、その他すべての必要な14のアクティビティについても同様です。専用のタイムスタンプが利用できない場合は、「Last Stage Change On」列を使用して、「Application Reviewed」や「Recruiter Screen Conducted」などのアクティビティを推測します。
最終的な変換済みファイルを、必要な列: JobApplicationId、ActivityName、ActivityTimestamp、SourceSystem、LastDataUpdate、および推奨される属性で構造化します。この最終ファイルを1つのCSVとして保存し、アップロードします。

設定

主要レポート: データ抽出では、Greenhouseの「Essential Reports」セクションにある複数のレポート、主に「All Applications」と「Interview Details」のデータを組み合わせます。
主要な列（All Applications）: 必要なすべてのデータを取得するには、アプリケーションID、候補者、求人、部署、採用担当者、ステータス、ソース、オファー状況、および応募日、不採用日、採用日、オファー作成日、オファー受諾日を含むすべての関連日付列を選択します。
主要な列（Interview Details）: 面接イベントを捕捉するには、アプリケーションID、面接名、面接予定開始日時、スコアカード提出日時などの列を選択します。
日付範囲フィルター: 管理しやすく関連性の高いデータセットを確保するため、3〜6ヶ月間の「Applied On」日付に基づいて応募をフィルタリングすることをお勧めします。より長い期間でフィルタリングすると、パフォーマンスに影響が出る可能性があります。
前提条件: エクスポートを実行するユーザーは、Greenhouseの「Reports」セクションにアクセスし、候補者データを表示する権限を持っている必要があります。これは通常、「Job Admin」または「Site Admin」の役割が必要です。

a クエリ例 config

This extraction method uses the Greenhouse user interface and does not involve a query language. The configuration is performed by selecting reports and columns.

**Report 1: All Applications**
*   **Report to run**: Go to Reports > Essential Reports > All Applications
*   **Columns to select**:
    *   Application ID
    *   Candidate
    *   Job
    *   Department
    *   Current Company
    *   Current Title
    *   Recruiter
    *   Status
    *   Source
    *   Applied On
    *   Rejected On
    *   Rejection Reason
    *   Hired On
    *   Last Stage Change On
    *   Offer Created On
    *   Offer Accepted On
    *   Offer Status

**Report 2: Interview Details**
*   **Report to run**: Go to Reports > Essential Reports > Interview Details
*   **Columns to select**:
    *   Application ID
    *   Candidate
    *   Job
    *   Interview Name
    *   Interviewer
    *   Scheduled Start
    *   Scheduled End
    *   Scorecard Submitted At

**Post-Export Transformation Logic**:
Combine the reports and unpivot the date columns to create the event log. Map source columns to `ActivityName` and `ActivityTimestamp`:
*   'Applied On' -> 'Application Received'
*   'Last Stage Change On' (when moving to a review stage) -> 'Application Reviewed'
*   'Last Stage Change On' (when moving to a screen stage) -> 'Recruiter Screen Conducted'
*   'Scheduled Start' -> 'Interview Scheduled'
*   'Scheduled Start' (after the time has passed) -> 'Interview Completed'
*   'Scorecard Submitted At' -> 'Feedback Submitted'
*   'Offer Created On' -> 'Offer Created'
*   'Last Stage Change On' (when moving to offer extended stage) -> 'Offer Extended'
*   'Offer Accepted On' -> 'Offer Accepted'
*   'Last Stage Change On' (when moving to background check stage) -> 'Background Check Initiated'
*   'Last Stage Change On' (when moving to onboarding stage) -> 'Onboarding Initiated'
*   'Hired On' -> 'Candidate Hired'
*   'Last Stage Change On' (when offer status is 'Rejected') -> 'Offer Rejected'
*   'Rejected On' -> 'Application Rejected'

ステップ

前提条件：Greenhouse APIキーの取得
- 開発者権限を持つGreenhouseアカウントにログインします。
- 設定 > 開発者センター > API認証情報管理へ移動します。
- 「新しいAPIキーを作成」をクリックします。
- 例えば、「ProcessMind抽出」のような説明を入力します。
- タイプとして「Harvest」を選択します。
- 必要な権限をキーに付与します。最低限、Applications、Candidates、Jobs、Job Stages、Offers、Scorecards、Usersに対するGET権限が必要です。
- 生成されたAPIキーを安全にコピーしてください。再度表示することはできません。
Python環境のセットアップ
- システムにPython 3.6以降がインストールされていることを確認してください。
- ターミナルで以下のコマンドを実行して、必要なPythonライブラリをインストールします: pip install requests と pip install pandas。
Pythonスクリプトの準備
- 「query」セクションに提供されている完全なPythonスクリプトを、例えば extract_greenhouse_logs.py という新しいファイルにコピーします。
- プレースホルダー YOUR_GREENHOUSE_API_KEY を、手順1で取得したキーに置き換えます。
- 抽出期間の開始を定義するために START_DATE_ISO 変数を調整します。初回ロードの場合、過去3〜6ヶ月の日付が推奨されます。
ステージからアクティビティへのマッピングのカスタマイズ
- スクリプト内の STAGE_TO_ACTIVITY 辞書を確認します。
- この辞書は、貴社独自のGreenhouseの採用ステージ名を、プロセスマイニングに必要な標準化されたアクティビティ名にマッピングします。
- 貴社のGreenhouse固有の設定に合わせて、このマッピングを更新する必要があります。例えば、「Recruiter Screen」ステージが「Initial Recruiter Chat」という名前の場合、辞書をそれに応じて更新してください。
抽出スクリプトの実行
- ターミナルまたはコマンドプロンプトを開きます。
- extract_greenhouse_logs.py を保存したディレクトリに移動します。
- python extract_greenhouse_logs.py コマンドを使用してスクリプトを実行します。
- スクリプトはGreenhouse APIに接続し、データを取得、処理し、コンソールにステータス更新を出力します。
イベントログの取得
- 成功すると、スクリプトは同じディレクトリに greenhouse_event_log.csv という名前のファイルを生成します。
- このCSVファイルは、必要な列とアクティビティでフォーマットされた最終的なイベントログです。
増分ロードの処理
- その後の実行では、START_DATE_ISO 変数を前回の成功した抽出のタイムスタンプに更新できます。これにより、新規または更新されたレコードのみをフェッチし、プロセスを高速化できます。
ProcessMindへのアップロード
- 生成された greenhouse_event_log.csv ファイルは、ProcessMindに直接アップロードする準備ができています。ファイル内の列名がProcessMindプロジェクトのフィールドに正しくマッピングされていることを確認してください。

設定

APIキーの権限: Harvest APIキーは、以下のエンドポイントに対する読み取り専用（GET）アクセス権限が必要です。Applications、Candidates、Jobs、Job Stages、Offers、Scorecards、Users。権限が不十分な場合、特定の活動のデータが不足します。
日付範囲フィルター: スクリプトはupdated_afterパラメーター（START_DATE_ISO変数）を使用して応募をフィルタリングします。初回抽出では、過去6ヶ月のような広範囲を使用してください。その後の増分ロードでは、パフォーマンス向上のため、前回の成功した実行のタイムスタンプに設定してください。
ステージからアクティビティへのマッピング: スクリプト内のSTAGE_TO_ACTIVITY辞書は非常に重要です。貴社独自のGreenhouse採用ステージを正確に反映するように設定し、「採用担当者によるスクリーニング実施」や「バックグラウンドチェック開始」などの活動を正しく識別する必要があります。
APIレート制限: スクリプトは、Greenhouseのレート制限（1秒あたり約20リクエスト）を尊重するため、APIリクエスト間に短い固定遅延が含まれています。非常に大量のデータの場合、接続エラーを避けるためにこの遅延を調整する必要があるかもしれません。
データ粒度: 抽出はタイムスタンプ付きイベントとステータス変更に焦点を当てています。面接メモやメール通信のような詳細な内容は捕捉せず、イベント発生のメタデータのみを捕捉します。

a クエリ例 python

import requests
import pandas as pd
import time
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration ---
API_KEY = class="hl-string">'YOUR_GREENHOUSE_API_KEY' class=class="hl-string">"hl-comment"># Replace with your Harvest API Key
START_DATE_ISO = class="hl-string">'2023-01-01T00:00:00Z' class=class="hl-string">"hl-comment"># Set the start date for the data pull (ISO 8601 format)
BASE_URL = class="hl-string">'https://harvest.greenhouse.io/v1/'

class=class="hl-string">"hl-comment"># IMPORTANT: Customize this dictionary to map your Greenhouse stage names to standard activities
STAGE_TO_ACTIVITY = {
    class="hl-string">'Application Review': class="hl-string">'Application Reviewed',
    class="hl-string">'Phone Screen': class="hl-string">'Recruiter Screen Conducted',
    class="hl-string">'Background Check': class="hl-string">'Background Check Initiated',
    class="hl-string">'Onboarding': class="hl-string">'Onboarding Initiated'
    class=class="hl-string">"hl-comment"># Add other custom stage mappings here, for example:
    class=class="hl-string">"hl-comment"># class="hl-string">'Hiring Manager Interview': class="hl-string">'Interview Completed'
}

class=class="hl-string">"hl-comment"># --- Script ---
headers = {class="hl-string">'Authorization': fclass="hl-string">'Basic {API_KEY}'}
event_log_records = []

def get_all_pages(endpoint, params=None):
    class="hl-string">"""Helper function to handle pagination for Greenhouse API requests."""
    url = fclass="hl-string">"{BASE_URL}{endpoint}"
    all_data = []
    page = 1
    while url:
        print(fclass="hl-string">"Fetching page {page} from {endpoint}...")
        try:
            response = requests.get(url, headers=headers, params=params)
            response.raise_for_status()
            data = response.json()
            all_data.extend(data)
            class=class="hl-string">"hl-comment"># Greenhouse uses Link header for pagination
            url = response.links.get(class="hl-string">'next', {}).get(class="hl-string">'url')
            page += 1
            time.sleep(0.1) class=class="hl-string">"hl-comment"># Respect rate limits
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {url}: {e}")
            break
        class=class="hl-string">"hl-comment"># Params are only needed for the first request
        params = None
    return all_data

print(class="hl-string">"Fetching initial data from Greenhouse API...")
params = {class="hl-string">'updated_after': START_DATE_ISO, class="hl-string">'per_page': 100}
applications = get_all_pages(class="hl-string">'applications', params=params)
jobs = {job[class="hl-string">'id']: job for job in get_all_pages(class="hl-string">'jobs', params={class="hl-string">'status': class="hl-string">'all'})}
candidates = {cand[class="hl-string">'id']: cand for cand in get_all_pages(class="hl-string">'candidates')}
users = {user[class="hl-string">'id']: user for user in get_all_pages(class="hl-string">'users')}

print(fclass="hl-string">"Processing {len(applications)} applications...")

for app in applications:
    job_id = app.get(class="hl-string">'job_id')
    job = jobs.get(job_id, {})
    candidate = candidates.get(app.get(class="hl-string">'candidate_id'), {})
    source_system = class="hl-string">"Greenhouse"
    last_data_update = datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for all events for this application
    base_attributes = {
        class="hl-string">'JobApplicationId': app[class="hl-string">'id'],
        class="hl-string">'SourceSystem': source_system,
        class="hl-string">'LastDataUpdate': last_data_update,
        class="hl-string">'JobTitle': job.get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'JobDepartment': (job.get(class="hl-string">'departments', [{}])[0] or {}).get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'ApplicationStatus': app.get(class="hl-string">'status', class="hl-string">''),
        class="hl-string">'ApplicationSource': (app.get(class="hl-string">'source', {}) or {}).get(class="hl-string">'public_name', class="hl-string">''),
        class="hl-string">'RecruiterName': class="hl-string">''
    }
    if app.get(class="hl-string">'recruiter') and app[class="hl-string">'recruiter'].get(class="hl-string">'id') in users:
        recruiter_user = users[app[class="hl-string">'recruiter'][class="hl-string">'id']]
        base_attributes[class="hl-string">'RecruiterName'] = fclass="hl-string">"{recruiter_user.get('first_name', '')} {recruiter_user.get('last_name', '')}".strip()

    class=class="hl-string">"hl-comment"># --- Activity: Application Received ---
    if app.get(class="hl-string">'submitted_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Application Received',
            class="hl-string">'ActivityTimestamp': app[class="hl-string">'submitted_at'],
            class="hl-string">'OfferStatus': None
        })

    class=class="hl-string">"hl-comment"># --- Activities from Stage History ---
    for stage_move in app.get(class="hl-string">'stage_history', []):
        stage_name = stage_move.get(class="hl-string">'stage_name')
        if stage_name in STAGE_TO_ACTIVITY:
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': STAGE_TO_ACTIVITY[stage_name],
                class="hl-string">'ActivityTimestamp': stage_move.get(class="hl-string">'exited_on'), class=class="hl-string">"hl-comment"># Timestamp when they entered the *next* stage
                class="hl-string">'OfferStatus': None
            })

    class=class="hl-string">"hl-comment"># --- Activities: Interview Scheduled & Completed ---
    interviews = get_all_pages(fclass="hl-string">"applications/{app['id']}/scheduled_interviews")
    for interview in interviews:
        if interview.get(class="hl-string">'start'):
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Interview Scheduled',
                class="hl-string">'ActivityTimestamp': interview[class="hl-string">'start'][class="hl-string">'date'],
                class="hl-string">'OfferStatus': None
            })
        if interview.get(class="hl-string">'end'):
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Interview Completed',
                class="hl-string">'ActivityTimestamp': interview[class="hl-string">'end'][class="hl-string">'date'],
                class="hl-string">'OfferStatus': None
            })

    class=class="hl-string">"hl-comment"># --- Activity: Feedback Submitted ---
    scorecards = get_all_pages(fclass="hl-string">"scorecards", params={class="hl-string">'application_id': app[class="hl-string">'id']})
    for sc in scorecards:
        if sc.get(class="hl-string">'submitted_at'):
            event_log_records.append({
                **base_attributes,
                class="hl-string">'ActivityName': class="hl-string">'Feedback Submitted',
                class="hl-string">'ActivityTimestamp': sc[class="hl-string">'submitted_at'],
                class="hl-string">'OfferStatus': None
            })

    class=class="hl-string">"hl-comment"># --- Activities: Hired or Application Rejected ---
    if app.get(class="hl-string">'status') == class="hl-string">'hired' and app.get(class="hl-string">'hired_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Candidate Hired',
            class="hl-string">'ActivityTimestamp': app[class="hl-string">'hired_at'],
            class="hl-string">'OfferStatus': None
        })
    elif app.get(class="hl-string">'status') == class="hl-string">'rejected' and app.get(class="hl-string">'rejected_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Application Rejected',
            class="hl-string">'ActivityTimestamp': app[class="hl-string">'rejected_at'],
            class="hl-string">'OfferStatus': None
        })

class=class="hl-string">"hl-comment"># --- Activities from Offers (separate loop for efficiency) ---
print(class="hl-string">"Fetching and processing offer data...")
all_offers = get_all_pages(class="hl-string">'offers')
for offer in all_offers:
    if not offer.get(class="hl-string">'application_id'):
        continue

    app_id = offer[class="hl-string">'application_id']
    class=class="hl-string">"hl-comment"># Find the corresponding application's base attributes
    matching_app = next((item for item in applications if item[class="hl-string">'id'] == app_id), None)
    if not matching_app:
        continue
    
    job_id = matching_app.get(class="hl-string">'job_id')
    job = jobs.get(job_id, {})
    base_attributes = {
        class="hl-string">'JobApplicationId': app_id,
        class="hl-string">'SourceSystem': class="hl-string">"Greenhouse",
        class="hl-string">'LastDataUpdate': datetime.utcnow().isoformat() + class="hl-string">'Z',
        class="hl-string">'JobTitle': job.get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'JobDepartment': (job.get(class="hl-string">'departments', [{}])[0] or {}).get(class="hl-string">'name', class="hl-string">''),
        class="hl-string">'ApplicationStatus': matching_app.get(class="hl-string">'status', class="hl-string">''),
        class="hl-string">'ApplicationSource': (matching_app.get(class="hl-string">'source', {}) or {}).get(class="hl-string">'public_name', class="hl-string">''),
        class="hl-string">'RecruiterName': class="hl-string">'' class=class="hl-string">"hl-comment"># Can be enriched similarly if needed
    }

    class=class="hl-string">"hl-comment"># Offer Created
    if offer.get(class="hl-string">'created_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Offer Created',
            class="hl-string">'ActivityTimestamp': offer[class="hl-string">'created_at'],
            class="hl-string">'OfferStatus': offer.get(class="hl-string">'status')
        })
    class=class="hl-string">"hl-comment"># Offer Extended
    if offer.get(class="hl-string">'sent_at'):
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': class="hl-string">'Offer Extended',
            class="hl-string">'ActivityTimestamp': offer[class="hl-string">'sent_at'],
            class="hl-string">'OfferStatus': offer.get(class="hl-string">'status')
        })
    class=class="hl-string">"hl-comment"># Offer Accepted/Rejected
    if offer.get(class="hl-string">'resolved_at'):
        if offer.get(class="hl-string">'status') == class="hl-string">'accepted':
            activity_name = class="hl-string">'Offer Accepted'
        elif offer.get(class="hl-string">'status') == class="hl-string">'deprecated': class=class="hl-string">"hl-comment"># Often used for rejected
            activity_name = class="hl-string">'Offer Rejected'
        else:
            continue
        event_log_records.append({
            **base_attributes,
            class="hl-string">'ActivityName': activity_name,
            class="hl-string">'ActivityTimestamp': offer[class="hl-string">'resolved_at'],
            class="hl-string">'OfferStatus': offer.get(class="hl-string">'status')
        })

print(class="hl-string">"Consolidating data and exporting to CSV...")
df = pd.DataFrame(event_log_records)
df_sorted = df.sort_values(by=[class="hl-string">'JobApplicationId', class="hl-string">'ActivityTimestamp'])
df_sorted.to_csv(class="hl-string">'greenhouse_event_log.csv', index=False)

print(class="hl-string">"Extraction complete. File 'greenhouse_event_log.csv' created.")

ステップ

Greenhouse Recruitingアカウントにログインします。
メインナビゲーションバーのレポートアイコン（棒グラフのようなもの）をクリックして、「レポート」セクションに移動します。
レポートダッシュボードで、「Essential Reports」を見つけてクリックします。この抽出の主要レポートは「All Applications」です。このレポートは、応募とそれらの主要なマイルストーンを包括的に表示します。
「All Applications」レポートを設定します。「Columns」ボタンをクリックします。必要な属性とアクティビティのタイムスタンプを捕捉するために必要なすべての列を選択します。以下を含めることを確認してください: Application ID、Candidate、Job、Department、Recruiter、Status、Source、Applied On、Rejected On、Hired On、Last Stage Change On、Offer Created On、Offer Accepted On、Offer Status。
面接関連の活動を捕捉するには、別のレポートが必要です。Essential Reportsに戻り、「Interview Details」を選択します。
「Interview Details」レポートを設定します。「Columns」セクションで、少なくとも以下を選択します: Application ID、Interview Name、Scheduled Start、Scorecard Submitted At。これにより、スケジュールとフィードバック提出のタイムスタンプが得られます。
両方のレポートで、フィルターを使用して適切な日付範囲を設定します。一般的なフィルターは、「Applied On」を「All Time」または過去6ヶ月のような特定の範囲に設定し、関連する応募群を捕捉することです。
「Update」または「Generate」ボタンをクリックして、各レポートを生成します。レポートが表示されたら、「Export to Excel」ボタンをクリックしてデータをCSVファイルとしてダウンロードします。これで2つの別々のCSVファイルが得られます。
エクスポートされたファイルはまだイベントログ形式ではありません。Python、R、またはMicrosoft ExcelのPower Queryのようなアンピボット機能を備えたスプレッドシートプログラムなどのツールを使用して、変換ステップを実行する必要があります。
「All Applications」と「Interview Details」レポートのデータを、Application IDで結合します。
各応募について、エクスポートした関連するすべての日付列に対して個別の行を作成します。例えば、「Applied On」列の値は、「Application Received」という名前のアクティビティの「ActivityTimestamp」になります。「Rejected On」列の値は「Application Rejected」アクティビティを作成し、その他すべての必要な14のアクティビティについても同様です。専用のタイムスタンプが利用できない場合は、「Last Stage Change On」列を使用して、「Application Reviewed」や「Recruiter Screen Conducted」などのアクティビティを推測します。
最終的な変換済みファイルを、必要な列: JobApplicationId、ActivityName、ActivityTimestamp、SourceSystem、LastDataUpdate、および推奨される属性で構造化します。この最終ファイルを1つのCSVとして保存し、アップロードします。

設定

主要レポート: データ抽出では、Greenhouseの「Essential Reports」セクションにある複数のレポート、主に「All Applications」と「Interview Details」のデータを組み合わせます。
主要な列（All Applications）: 必要なすべてのデータを取得するには、アプリケーションID、候補者、求人、部署、採用担当者、ステータス、ソース、オファー状況、および応募日、不採用日、採用日、オファー作成日、オファー受諾日を含むすべての関連日付列を選択します。
主要な列（Interview Details）: 面接イベントを捕捉するには、アプリケーションID、面接名、面接予定開始日時、スコアカード提出日時などの列を選択します。
日付範囲フィルター: 管理しやすく関連性の高いデータセットを確保するため、3〜6ヶ月間の「Applied On」日付に基づいて応募をフィルタリングすることをお勧めします。より長い期間でフィルタリングすると、パフォーマンスに影響が出る可能性があります。
前提条件: エクスポートを実行するユーザーは、Greenhouseの「Reports」セクションにアクセスし、候補者データを表示する権限を持っている必要があります。これは通常、「Job Admin」または「Site Admin」の役割が必要です。

a クエリ例 config

This extraction method uses the Greenhouse user interface and does not involve a query language. The configuration is performed by selecting reports and columns.

**Report 1: All Applications**
*   **Report to run**: Go to Reports > Essential Reports > All Applications
*   **Columns to select**:
    *   Application ID
    *   Candidate
    *   Job
    *   Department
    *   Current Company
    *   Current Title
    *   Recruiter
    *   Status
    *   Source
    *   Applied On
    *   Rejected On
    *   Rejection Reason
    *   Hired On
    *   Last Stage Change On
    *   Offer Created On
    *   Offer Accepted On
    *   Offer Status

**Report 2: Interview Details**
*   **Report to run**: Go to Reports > Essential Reports > Interview Details
*   **Columns to select**:
    *   Application ID
    *   Candidate
    *   Job
    *   Interview Name
    *   Interviewer
    *   Scheduled Start
    *   Scheduled End
    *   Scorecard Submitted At

**Post-Export Transformation Logic**:
Combine the reports and unpivot the date columns to create the event log. Map source columns to `ActivityName` and `ActivityTimestamp`:
*   'Applied On' -> 'Application Received'
*   'Last Stage Change On' (when moving to a review stage) -> 'Application Reviewed'
*   'Last Stage Change On' (when moving to a screen stage) -> 'Recruiter Screen Conducted'
*   'Scheduled Start' -> 'Interview Scheduled'
*   'Scheduled Start' (after the time has passed) -> 'Interview Completed'
*   'Scorecard Submitted At' -> 'Feedback Submitted'
*   'Offer Created On' -> 'Offer Created'
*   'Last Stage Change On' (when moving to offer extended stage) -> 'Offer Extended'
*   'Offer Accepted On' -> 'Offer Accepted'
*   'Last Stage Change On' (when moving to background check stage) -> 'Background Check Initiated'
*   'Last Stage Change On' (when moving to onboarding stage) -> 'Onboarding Initiated'
*   'Hired On' -> 'Candidate Hired'
*   'Last Stage Change On' (when offer status is 'Rejected') -> 'Offer Rejected'
*   'Rejected On' -> 'Application Rejected'

採用・タレント獲得データテンプレート

採用・タレント獲得データテンプレート

採用・タレント獲得の属性

採用・タレント獲得活動

抽出ガイド

手動CSVエクスポート用Greenhouseレポートビルダー

ステップ

設定

a クエリ例 config

Greenhouse Harvest APIによるPythonスクリプト抽出

ステップ

設定

a クエリ例 python

Greenhouseコネクタを備えた自動ETLツール

ステップ

設定

a クエリ例 config

今すぐ始めますか？

今すぐGreenhouseでタレント獲得を効率化しましょう

採用・タレント獲得データテンプレート

採用・タレント獲得データテンプレート

採用・タレント獲得の属性

採用・タレント獲得活動

抽出ガイド

手動CSVエクスポート用Greenhouseレポートビルダー

ステップ

設定

a クエリ例 config

Greenhouse Harvest APIによるPythonスクリプト抽出

ステップ

設定

a クエリ例 python

Greenhouseコネクタを備えた自動ETLツール

ステップ

設定

a クエリ例 config

お客様のプライバシーを大切にしています

今すぐ始めますか？

今すぐGreenhouseでタレント獲得を効率化しましょう