您的招聘与人才获取数据模板

Greenhouse

← 返回改进指南

招聘与人才获取属性 (22) 招聘与人才获取活动 (14) 提取指南 (3)

您的招聘与人才获取数据模板

此模板为您收集“招聘与人才获取”流程的正确数据提供了全面指南。它概述了需要追踪的核心属性、需要捕捉的关键活动，以及从 Greenhouse 系统提取这些信息的清晰指导。遵循此模板将确保您拥有进行深度流程分析的数据基础。

建议收集的属性
需要追踪的关键活动
提取指南

不熟悉事件日志？了解如何创建流程挖掘事件日志.

下载模板

招聘与人才获取属性

为了对 Greenhouse 内的招聘与人才获取流程进行全面分析，建议在事件日志中包含以下数据字段。

5 必填 6 推荐 11 可选

	名称	描述
	活动名称 ActivityName	已发生的特定招聘活动或阶段的名称。
描述此属性记录了招聘流程中每个事件的名称，如“收到申请”、“安排面试”或“接受录用”。它构成了组成流程图的事件序列。分析这些活动的顺序和频率是流程挖掘的基础。它有助于可视化招聘漏斗，识别常见的流程路径，检测偏离标准工作流的情况，并精准定位流程停滞的瓶颈。例如，它可以追踪有多少申请从“已审核”推进到了“已初筛”。为何重要此属性定义了招聘流程中的各个步骤，支持流程图的可视化，并助力识别瓶颈和偏差。获取方式这通常通过映射 Greenhouse 内的申请阶段变更、面试状态、录用事件或其他可审计的操作衍生获得。可能需要一定的逻辑将系统事件转换为标准化的活动名称。示例申请已审查面试已完成已接受 Offer申请已拒绝
	活动时间戳 ActivityTimestamp	招聘活动发生的精确日期和时间。
描述活动时间戳记录了招聘流程中事件发生的精确时刻。它是所有基于绩效和时长的分析的基础，为每个职位申请提供了按时间顺序排列的活动记录。该时间戳对于计算所有与时间相关的 KPI 至关重要，例如“招聘周期”、“面试安排周期”和“面试反馈周转时间”。通过分析不同活动之间流逝的时间，组织可以衡量效率、识别延迟并监控对服务水平协议（SLA）的遵守情况，为专注于绩效和瓶颈的仪表板提供直接支持。为何重要此时间戳对于事件排序、计算周期以及分析招聘流程绩效至关重要。获取方式可在 Greenhouse 的各种对象中找到，例如 Application 对象上的“applied_at”、Offer 对象上的“created_at”，或活动提要和审计日志中的时间戳。示例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	职位申请 JobApplicationId	候选人对特定职位的单次申请的唯一标识符。
描述 Job Application ID 是招聘流程分析的核心，充当唯一的 Case ID。它关联了从初始提交、筛选到面试、录用及最终入职决策的所有活动，实现了对每位候选人旅程的全流程视图。在流程挖掘中，此属性用于重构候选人在招聘漏斗中的确切路径。它支持分析流程变体、单次申请周期和流失点，为每位申请人的整体招聘生命周期提供清晰画像。为何重要这是关联单次申请中所有招聘事件的关键 Case ID，使得分析从开始到结束的完整招聘旅程成为可能。获取方式这通常是申请对象的主键。请参考 Greenhouse API 文档中有关 Applications 端点的部分，通常称为 id 或 application_id。示例 987654321098765432119876543212
	最后数据更新 LastDataUpdate	指示此 event 的 data 上次刷新或提取时间的 timestamp。
描述此属性记录了数据从源系统提取的最后日期和时间。这是一个元数据字段，反映了流程挖掘模型中数据的时效性。此信息对于用户了解分析的时效性至关重要。它有助于管理对数据延迟的预期，并且对于验证数据流水线是否按计划运行至关重要。例如，如果“数据最后更新时间”是几天前的，用户就会知道仪表板反映的不是最新的招聘活动。为何重要指示数据的实时程度，帮助用户了解分析是否反映了流程的最新状态。获取方式此时间戳是在数据提取、转换和加载（ETL）过程中生成并标记到数据集上的。示例 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	源系统 SourceSystem	识别提取数据的记录系统。
描述此属性指定招聘数据的来源。对于此流程，该值始终为“Greenhouse”。虽然看起来是固定的，但明确追踪源系统对于数据治理、故障排除以及从 HRIS 等其他系统丰富数据的情形至关重要。它确保了数据来源的清晰性，并有助于维护组织整体数据环境的完整性。为何重要确保清晰的数据来源，这对于数据治理、验证以及管理来自多个渠道的数据至关重要。获取方式这是一个静态值，应在数据提取和转换（ETL）过程中添加，用于标记数据来源。示例 Greenhouse
	应用源 ApplicationSource	接收候选人申请的渠道。
描述此属性追踪申请的来源，例如“LinkedIn”、“员工推荐”、“公司官网”或“Indeed”。它揭示了不同招聘渠道的有效性。 “渠道有效性”仪表板完全围绕此属性构建。通过按来源分析申请量、招聘周期和入职率，组织可以优化招聘营销支出。这些数据有助于回答有关哪些渠道最能高效提供高质量人才的战略问题，并直接支持“渠道转化率”KPI。为何重要有助于衡量不同招聘渠道的有效性和投资回报率 (ROI)，从而支持在哪里投入搜寻精力的决策。获取方式在 Greenhouse 的 Candidate 对象中获取，该对象已链接到 Application。“source”字段提供了此信息。示例 LinkedIn员工推荐公司招聘页面Indeed
	录用状态 OfferStatus	已向候选人发放的录用通知的当前状态。
描述此属性追踪录用通知的状态，取值如“已创建”、“已发放”、“已接受”或“已拒绝”。它是招聘流程最后阶段的关键指标。此属性对于“录用接受率趋势”仪表板及相应 KPI 必不可少。通过追踪从“录用发放”到“接受”或“拒绝”的进展，企业可以衡量其人才“成单”能力。按部门或职位分析这些数据，可以揭示薪酬竞争力、候选人体验或其他影响候选人决策的因素。为何重要追踪录用通知的结果，这对于计算录用接受率 KPI 并了解如何改进它至关重要。获取方式在 Greenhouse 的 Offer 对象中获取，该对象已链接到 Application。“status”字段提供了此信息。示例已接受已驳回已发送已创建
	招聘人员姓名 RecruiterName	负责管理该职位申请的招聘负责人姓名。
描述此属性标识分配给特定申请或职位的招聘负责人。此人通常负责筛选、协调面试以及推动候选人走完流程。按招聘负责人分析流程是了解个人绩效和工作量分配的关键。“招聘人员工作量与效率”仪表板依靠此属性来计算人均吞吐量和周期。这有助于识别优秀员工，发现可能需要额外支持的个人，并确保人才获取团队的工作负载均衡。为何重要将流程活动归因于特定招聘人员，以便分析个人绩效、工作量和效率。获取方式在 Greenhouse 的 Job 对象中获取，通常位于“hiring_team”部分，其中指定了“招聘人员 (Recruiter)”等角色。示例爱丽丝·约翰逊Robert DavisMaria Garcia
	申请状态 ApplicationStatus	职位申请的最终结果或当前状态。
描述此属性指示申请的处理状态，如“已入职”、“已拒绝”或“进行中”。它代表了已完成流程的最终状态或进行中流程的当前状态。这是结果分析的一个关键维度。它允许过滤案例，以比较已入职与被拒绝候选人的流程路径，从而揭示成功旅程的特征。它还用于在“整体招聘漏斗”仪表板中计算转化率，显示有多少比例的申请最终转化为入职。为何重要定义招聘流程的结果，以便分析比较成功（已录用）与失败（已拒绝）的候选人旅程。获取方式此信息位于 Greenhouse 的 Application 对象中，可通过 API 中的 status 字段获取。示例已录用已驳回在职
	职位名称 JobTitle	候选人申请的职位名称。
描述此属性包含职位的正式名称，如“高级软件工程师”或“产品市场经理”。它提供了关于待聘岗位的核心背景。按职位名称分析招聘流程是理解特定岗位挑战的基础。例如，“招聘周期绩效”仪表板利用此属性显示高级或高度专业化的角色是否需要更长时间才能入职。它还有助于分析不同职位的录用接受率，为薪酬竞争力或职位吸引力提供洞察。为何重要允许筛选和比较特定岗位的招聘指标，帮助了解流程绩效如何随职位复杂程度或类型而变化。获取方式这是 Greenhouse 中 Job 对象的一个主要字段，通常在通过 API 查询 jobs 端点时以 name 形式提供。示例高级软件工程师客户执行 (AE)UX/UI 设计师
	职位部门 JobDepartment	正在填补职位的部门或业务单元。
描述此属性指定与职位申请关联的组织部门，如“研发”、“市场”或“销售”。它支持跨业务部门的招聘指标聚合与对比。按部门细分分析对于“招聘周期绩效”和“录用接受率趋势”等仪表板至关重要。它有助于识别某些部门是否存在招聘周期过长、录用被拒率偏高或流程合规性不同的问题。这些洞察支持针对各部门具体需求制定干预措施和流程改进方案。为何重要支持比较不同部门之间的招聘绩效和流程变体，揭示系统性问题或最佳实践。获取方式通常作为 Greenhouse 中 Job 对象的标准或自定义字段提供。可通过 API 在职位记录的 departments 部分找到。示例工程部产品管理销售市场营销
	任务 ID JobId	职位申请或发布的唯一标识符。
描述此属性是职位本身的唯一 ID，与申请 ID 不同。多次申请会链接到同一个 Job ID。使用 Job ID 可以实现职位维度的聚合分析。例如，可以分析特定职位收到的申请总数，或同类角色的平均招聘周期。它提供了一种以单个开放职位为中心来分析招聘成效的方法。为何重要允许汇总和分析与单个职位空缺相关的所有候选人数据，提供以需求为中心的视角。获取方式这是 Greenhouse 职位记录的主键，可通过 API 在 Job 对象中以 id 形式获取。示例 400123400124400125
	候选人ID CandidateId	候选人的唯一标识符，独立于任何单一申请。
描述 Candidate ID 用于唯一标识人才库中的个人，而 Job Application ID 则特定于某次职位申请。一个人可能会在不同时期有多次职位申请。虽然在这个流程视图中 Job Application ID 作为 Case ID，但通过 Candidate ID 可以进行另一种分析。它可以追踪候选人在多次申请中的历程，识别高频申请人，并分析与人才库的整体关系。这为招聘数据提供了一个以人为中心的视角。为何重要允许对同一候选人的多次申请进行跨度分析，从而更全面地了解候选人随时间推移的参与度。获取方式这是 Greenhouse 候选人记录的主键，可通过 API 在 Candidate 对象中以 id 形式获取。示例 123456123457123458
	拒绝原因 RejectionReason	拒绝候选人申请时提供的理由。
描述此属性捕捉候选人未能推进的具体原因。示例包括“文化不契合”、“薪资预期过高”或“有更合适的候选人”。分析拒绝原因可为招聘流程提供极具价值的反馈。它可以揭示职位描述不匹配、薪酬缺乏竞争力或人才库中反复出现的技能缺口等问题。通过了解招聘漏斗中常见的失败点，这些信息对于改进渠道策略和提升候选人体验尤为有用。为何重要提供关于候选人流失原因的定性洞察，助力优化职位描述、渠道来源及筛选标准。获取方式在申请被拒绝时，可在 Application 对象中获取。API 提供包含详细信息的“rejection_reason”对象。示例缺乏所需技能薪资预期过高选择了更合适的候选人
	招聘用时 TimeToHire	从收到申请到候选人标记为“已入职”的总时长。
描述此计算指标衡量一次成功招聘的全流程时长。它是评估人才获取职能整体效率最关键的 KPI 之一。此属性直接支持“招聘周期绩效”仪表板和“平均招聘周期”KPI。它计算特定申请中“收到申请”到“候选人入职”的时间差。分析此指标有助于组织设定基准，并识别招聘流程中的系统性延迟。为何重要这是一个关键绩效指标，用于衡量成功入职者的整体招聘漏斗效率。获取方式这是一个计算字段。它是通过“候选人入职”事件的时间戳减去“收到申请”事件的时间戳得出的。示例 259200043200003456000
	招聘经理姓名 HiringManagerName	相关职位申请的招聘经理姓名。
描述此属性标识空缺职位的团队经理。招聘经理是流程中的关键利害关系人，通常负责审核候选人、进行后期面试并做出最终录用决策。按招聘经理分析流程可以揭示重要的模式和瓶颈。例如，“面试排期瓶颈”仪表板可能会显示延迟经常与特定经理的空档时间有关。这有助于识别培训或支持需求，以确保经理能高效地参与招聘流程。为何重要识别关键利益相关者，以便分析与特定招聘经理相关的流程瓶颈或效率。获取方式在 Greenhouse 的 Job 对象中获取，通常位于“hiring_team”部分，其中指定了“招聘经理 (Hiring Manager)”等角色。示例 Emily Tran陈大卫Sophia Rodriguez
	是否合规 IsCompliant	一个计算出的标记，指示申请是否遵循了标准、预定义的招聘流程。
描述此布尔属性是合规性检查（Conformance Check）的结果，它将实际发生的招聘活动序列与预定义的理想流程模型进行对比，标示出发生偏差的案例（如跳过必要步骤或乱序操作）。这是“招聘合规偏差”仪表板的核心属性，支持“流程一致性比率”和“合规违规计数”KPI。通过过滤非合规案例，组织可以调查偏差发生的原因（培训不足、系统限制或必要的例外），从而有助于标准化工作流并降低合规风险。为何重要识别流程偏差，这对于测量流程一致性、确保合规以及标准化招聘工作流至关重要。获取方式这是由流程挖掘软件生成的计算字段。它将事件日志数据与定义的理想模型或业务规则集进行对比。示例 truefalse
	是否已自动化 IsAutomated	一个标记，指示该活动是否由系统自动执行。
描述此布尔属性指示活动是由用户执行还是由自动化系统规则执行。自动化活动的示例包括发送自动回复邮件，或自动拒绝未能通过基础筛选问题的候选人。分析此属性有助于了解招聘流程的自动化水平。它可以用来对比自动化步骤与人工步骤的效率和结果，并识别进一步自动化的机会，以提高速度和一致性。为何重要有助于区分手动和自动活动，从而分析自动化对流程效率和结果的影响。获取方式此信息并非标准字段，通常需要衍生获得。它可以从活动关联的用户（例如“系统”用户）或已知自动执行的特定事件类型中推断出来。示例 truefalse
	活动结束时间 ActivityEndTime	指示具有持续时间的活动结束的时间戳。
描述此属性记录跨越一段时间的活动（如面试或背景调查）的完成时间。虽然许多活动是瞬时完成的，但对于有持续时间的活动，记录开始和结束时间更有意义。拥有结束时间对于准确计算特定活动的“处理时间”或“时长”至关重要。这有助于区分步骤之间的“等待时间”与任务本身的“实际操作时间”。例如，它可以更精确地分析面试实际耗时，而不仅仅是排期耗时。为何重要支持精确计算活动处理时间，有助于区分流程中的主动工作时间与空闲等待时间。获取方式此信息可能在 Greenhouse 的 scheduled_interview 等对象中可用，这些对象通常包含“开始”和“结束”时间。对于其他活动，可能需要根据后续活动的时间戳进行推断。示例 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	评价表建议 ScorecardOverallRecommendation	已完成的面试评价表中的综合招聘建议。
描述此属性捕捉面试官在结构化面试评价表中给出的最终建议，通常为“强烈推荐”、“推荐”、“反对”或“强烈反对”。这些数据对于评估面试流程的质量和一致性至关重要。它有助于将面试反馈与真实的招聘结果关联起来，回答诸如“获得更强烈推荐的候选人是否更容易入职？”之类的问题。它也是“评价表完成率”KPI 的基础，用于衡量组织内部结构化招聘实践的普及程度。为何重要将结构化面试反馈与流程结果联系起来，帮助衡量数据驱动型招聘实践的采用情况。获取方式在 Greenhouse 中与已完成面试关联的评分卡 (Scorecard) 对象中获取。API 通过“scorecards”端点提供此信息。示例强烈反对否是强烈推荐
	面试反馈周转时间 InterviewFeedbackTurnaroundTime	面试完成到面试官提交反馈之间流逝的时间。
描述此计算指标衡量面试小组的响应速度。提交反馈的延迟会显著减慢招聘进度，并对候选人体验产生负面影响。此属性直接支持“面试反馈闭环分析”仪表板和“面试反馈周转时间”KPI。它计算“面试完成”与“反馈提交”活动之间的时间差。监控此指标有助于识别因反馈缓慢导致的瓶颈，并鼓励更快的决策。为何重要衡量面试后反馈闭环的效率，这是招聘流程中常见的延迟源。获取方式这是一个计算字段。它是通过“反馈已提交”事件的时间戳减去“面试已完成”事件的时间戳得出的。示例 86400172800259200
	面试阶段 InterviewStageName	面试阶段的具体名称或类型。
描述此属性指定面试流程中的具体阶段，如“招聘人员初筛”、“技术面试”或“终面”。它比通用的“面试已完成”提供了更细的颗粒度。通过分析每个面试阶段的指标，组织可以精准定位具体瓶颈。例如，您可以精确测量“各阶段候选人流失率”，从而识别候选人是在技术面试后还是初筛后更容易退出。这些细节对于针对性改进面试体验至关重要。为何重要提供面试流程的详细视图，以便分析每个具体面试步骤的周期和流失率。获取方式此信息是 Greenhouse 面试排期数据的一部分。职位申请中的 interviews 对象包含有关面试阶段的详细信息。示例招聘初筛用人经理面试技术测评现场终面

必填推荐可选

招聘与人才获取活动

这些是事件日志中需要捕捉的关键流程步骤和里程碑，用于实现精准的流程发现并优化招聘漏斗。

7 推荐 7 可选

	活动	描述
	候选人已入职	候选人已成功通过所有入职前检查，并正式标记为“已入职”。这是申请流程的成功完成和最终事件。
为何重要这是流程的主要成功结果。从“收到申请”到此事件的时间即为整体“招聘周期”，是一项关键的招聘 KPI。获取方式这是 Greenhouse 中的一个显式操作，招聘人员将候选人标记为特定职位的“已入职”。此操作将其从活跃候选人转为已入职员工。捕获从 Greenhouse 中“标记为已录用 (Mark as Hired)”操作的时间戳中捕获。事件类型 explicit
	已发出 Offer	正式录用通知已发送给候选人。这是面试和选拔过程走向成功的关键里程碑。
为何重要此活动是计算录用接受率（Offer Acceptance Rate）这一 KPI 的基础，标志着候选人进入最终决策阶段。获取方式这是在录用状态变更为“已发送”或“已发放”时，Greenhouse 记录的显式事件。Offers 对象包含这些状态变更的时间戳。捕获从录用状态正式标记为已发送的时间戳中捕获。事件类型 explicit
	已接受 Offer	候选人已正式接受录用通知。这是一个关键的成功里程碑，通常会触发后续的入职前活动，如背景调查。
为何重要这是一个关键的成功里程碑，也是“录用接受率”KPI 的核心组成部分，标志着从候选人向未来员工的身份转变。获取方式当录用通知状态在 Greenhouse 中更新为“已接受”时，系统会捕获此显式事件（无论是通过招聘人员操作还是候选人的电子确认）。捕获从录用状态更改为“已接受”的时间戳中捕获。事件类型 explicit
	已收到申请	此活动标志着特定职位申请招聘流程的开始。当候选人通过职业网站、渠道来源提交申请，或由人工录入 Greenhouse 时，系统会捕捉到此活动。
为何重要这是流程的主要启动事件。分析此活动到其他活动之间的时间对于衡量“招聘周期”和“渠道有效性”至关重要。获取方式这是在 Greenhouse 中创建申请时记录的显式事件。申请对象中的 Application Date 字段或创建时间戳提供了事件时间。捕获从申请记录的创建时间戳中捕获。事件类型 explicit
	申请已拒绝	候选人的申请在流程中的某个环节被拒绝。这是最常见的不成功终止事件，可能发生在任何阶段。
为何重要这是分析漏斗流失率的关键终止事件。了解拒绝发生的时机和原因有助于识别流程中的低效环节或不匹配的职位要求。获取方式这是用户在 Greenhouse 中拒绝申请时记录的显式事件。通常会附带拒绝原因，活动日志会捕获对应的时间戳。捕获从对申请执行拒绝操作的时间戳中捕获。事件类型 explicit
	面试已安排	已在系统中安排与候选人的面试。Greenhouse 与日历系统有集成，因此当面试确认时，通常会显式记录此事件。
为何重要此事件对于分析和识别面试安排流程中的瓶颈至关重要。该步骤与上一步骤之间的时间间隔是衡量招聘负责人和协调员效率的关键 KPI。获取方式从 Greenhouse 内部的面试排程功能中捕获。API 提供了有关已安排面试的数据，包括其创建时间戳。捕获在创建面试事件并将其与候选人申请关联时记录。事件类型 explicit
	面试已完成	已与候选人进行面试。这通常是根据预定的面试时间已过，或者更可靠地，根据该面试的反馈已提交来推断的。
为何重要此活动是候选人历程中的重大里程碑。它是衡量反馈提交时间以及后续推进速度的起点。获取方式通常通过推断获得。它可以从计划面试的结束时间衍生出来，或者更准确地，从该特定面试的第一份反馈提交的时间戳衍生获得。捕获根据预定的面试结束时间或后续反馈提交的时间戳推断。事件类型 inferred
	反馈已提交	面试官已提交关于候选人面试的评分卡或反馈。Greenhouse 的结构化招聘流程依赖于此进行决策，因此这是一个独立的、已记录的操作。
为何重要反馈的及时性对于推动候选人进展至关重要。此活动有助于分析反馈闭环效率和评价表完成率。获取方式这是面试官通过 Greenhouse 提交评价表时记录的显式事件。Scorecards API 对象包含 `submitted_at` 时间戳。捕获从面试评分卡的提交时间戳中捕获。事件类型 explicit
	已发起入职流程	新员工入职流程正式开始。这通常涉及从招聘系统到 HRIS 或入职平台的对接。
为何重要这用于追踪从招聘到 HR 环节的交接效率。这里的延迟可能导致新员工体验不佳，因此监控“入职交接时间”非常关键。获取方式如果 Greenhouse 与入职系统集成了，这可能是一个显式事件。否则，它将根据候选人被移动到最终“已入职”阶段的时间戳（触发交接的时间点）进行推断。捕获根据阶段变更或指示交接至 HRIS（人力资源信息系统）的集成日志推断。事件类型 inferred
	已发起背景调查	已为候选人启动背景调查，通常在接受录用通知后。这可能会记录为特定的阶段变更或与第三方服务的集成触发。
为何重要此活动对于合规性以及追踪入职前筛选延迟非常重要。它有助于分析从接受录用到完成必要检查之间所需的时间。获取方式这通常是从候选人移动到招聘管道中的“背景调查”阶段，或从与背景调查集成相关的活动日志中推断出来的。捕获根据状态更改为“背景调查”阶段或集成服务的 API 日志推断。事件类型 inferred
	录用申请被拒绝	候选人已正式拒绝录用通知。这是流程漏斗末端发生的一个不成功的终止事件。
为何重要追踪此结果对于分析录用接受率至关重要。该事件的高频发生可能预示着薪酬、企业文化或职位本身存在问题。获取方式当录用通知状态在 Greenhouse 中更新为“已拒绝”或“已谢绝”时，系统会捕获此显式事件。Offer 对象将包含此状态变更的时间戳。捕获从录用状态更改为“已拒绝”的时间戳中捕获。事件类型 explicit
	报价已创建	已起草正式的职位录用通知，可能正在等待内部审批。这标志着正式决定向候选人发出录用邀请。
为何重要此活动将“做出录用决策”与“实际发放录用通知”分开。它有助于分析录用通知送达候选人之前的内部审批时间和瓶颈。获取方式 Greenhouse 有一个专门的录用通知 (Offers) 模块。这是一个通过捕获与申请关联的录用对象创建时间戳而获得的显式事件。捕获在 Greenhouse 系统中创建录用记录时记录。事件类型 explicit
	招聘人员初筛已完成	招聘人员已完成与候选人的初次电话筛选或沟通。该活动通常通过将候选人移动到招聘渠道中的特定“电话筛选”阶段来捕获。
为何重要这是一个关键的资质里程碑，表示申请已通过初步筛选。它有助于衡量招聘负责人的工作量以及初筛的有效性。获取方式根据申请进入或移出 Greenhouse 招聘渠道中的“电话筛选”阶段时的时间戳推断。捕获源自申请的阶段历史记录，特别是进入“电话筛选”阶段的记录。事件类型 inferred
	申请已审查	招聘人员或招聘经理已对候选人的申请进行了初步审阅。这通常是在申请的阶段或状态从“新建”更改为活跃的审阅阶段（如“审阅中”）时推断出来的。
为何重要追踪此项有助于识别初筛阶段的瓶颈，并衡量新申请获得关注所需的时间。它是计算面试安排周期的起点。获取方式根据申请状态字段的更改推断。寻找从“新建”状态到“审阅”状态的状态更改，并使用该更改的时间戳。捕获根据状态更改为“审阅中”或类似阶段的时间戳推断。事件类型 inferred

推荐可选

提取指南

如何从 Greenhouse 获取数据

步骤

登录您的 Greenhouse 招聘账户。
点击主导航栏中的“报告”图标（类似于柱状图），进入“报告”部分。
在报告仪表板中，找到并点击“基本报告 (Essential Reports)”。本次提取的主要报告是“所有申请 (All Applications)”。该报告提供了申请及其关键里程碑的全面视图。
配置“所有申请”报告。点击“列 (Columns)”按钮。选择获取所需属性和活动时间戳所需的所有列。请务必包括：申请 ID (Application ID)、候选人、职位、部门、招聘人员、状态、来源、申请日期 (Applied On)、拒绝日期 (Rejected On)、录用日期 (Hired On)、最后阶段变更日期 (Last Stage Change On)、录用通知创建日期 (Offer Created On)、录用通知接受日期 (Offer Accepted On)、录用状态 (Offer Status)。
要获取面试相关的活动，您需要另一份报告。返回“基本报告”并选择“面试详情 (Interview Details)”。
配置“面试详情”报告。在“列”部分，至少选择：申请 ID (Application ID)、面试名称、计划开始时间和评分卡提交时间 (Scorecard Submitted At)。这将提供面试安排和反馈提交的时间戳。
对于这两个报告，请使用筛选器设置合适的日期范围。常用的筛选器是将“申请日期 (Applied On)”设置为“所有时间”或特定范围（如过去 6 个月），以获取相关的申请样本。
点击“更新”或“生成”按钮生成报告。显示报告后，点击“导出到 Excel”按钮，将数据下载为 CSV 文件。现在您将拥有两个独立的 CSV 文件。
导出的文件还不是事件日志格式。您必须使用 Python、R 或具有逆透视 (unpivot) 功能的表格程序（如 Microsoft Excel 的 Power Query）进行转换。
根据“申请 ID”合并来自“所有申请”和“面试详情”报告的数据。
对于每份申请，为您导出的每个相关日期列创建一个独立的行。例如，“申请日期 (Applied On)”列的值变为名为“申请已收到”活动的“ActivityTimestamp”；“拒绝日期 (Rejected On)”列的值创建“申请已拒绝”活动，以此类推，完成所有 14 个所需活动。如果缺乏专用时间戳，可使用“最后阶段变更日期 (Last Stage Change On)”列来推断“申请已审阅”或“招聘人员初筛已完成”等活动。
构建最终的转换文件，包含以下必需列：JobApplicationId、ActivityName、ActivityTimestamp、SourceSystem、LastDataUpdate 以及建议的属性。将此最终文件保存为单个 CSV 以供上传。

配置

主要报告：数据提取依赖于结合 Greenhouse “基本报告 (Essential Reports)” 部分中的多个报告，主要是“所有申请 (All Applications)”和“面试详情 (Interview Details)”。
关键列（所有申请）：为获取所有必要数据，请选择申请 ID (Application ID)、候选人、职位、部门、招聘人员、状态、来源、录用状态 (Offer Status) 以及所有相关的日期列，包括申请日期 (Applied On)、拒绝日期 (Rejected On)、录用日期 (Hired On)、录用通知创建日期 (Offer Created On) 和录用通知接受日期 (Offer Accepted On)。
关键列（面试详情）：为获取面试事件，请选择申请 ID (Application ID)、面试名称、计划开始时间和评分卡提交时间 (Scorecard Submitted At)。
日期范围筛选：建议根据“申请日期”筛选 3 到 6 个月内的申请，以确保数据集规模适中且具有参考价值。筛选过长的时间范围可能会影响系统性能。
前提条件：执行导出的用户必须拥有 Greenhouse 的权限，以访问“报告”部分并查看候选人数据。这通常需要“职位管理员 (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 账户。
- 导航至：配置 (Configure) > 开发中心 (Dev Center) > API 凭据管理 (API Credential Management)。
- 点击“创建新 API 密钥 (Create New API Key)”。
- 提供描述，例如“ProcessMind Extraction”。
- 选择“Harvest”作为类型。
- 授予密钥必要的权限。至少需要对以下各项的 GET 权限：Applications、Candidates、Jobs、Job Stages、Offers、Scorecards 和 Users。
- 安全地复制生成的 API 密钥。您之后将无法再次查看它。
设置 Python 环境
- 确保您的系统安装了 Python 3.6 或更高版本。
- 在终端运行以下命令安装必要的 Python 库：pip install requests 和 pip install pandas。
准备 Python 脚本
- 将“查询”部分提供的完整 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 速率限制：脚本在 API 请求之间包含了微小的固定延迟，以遵守 Greenhouse 的速率限制（约每秒 20 次请求）。对于极大量的数据，您可能需要调整此延迟以避免连接错误。
数据颗粒度：提取重点在于带有时间戳的事件和状态更改。它不会获取面试笔记或邮件通信等详细内容，仅获取事件发生的元数据。

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 招聘账户。
点击主导航栏中的“报告”图标（类似于柱状图），进入“报告”部分。
在报告仪表板中，找到并点击“基本报告 (Essential Reports)”。本次提取的主要报告是“所有申请 (All Applications)”。该报告提供了申请及其关键里程碑的全面视图。
配置“所有申请”报告。点击“列 (Columns)”按钮。选择获取所需属性和活动时间戳所需的所有列。请务必包括：申请 ID (Application ID)、候选人、职位、部门、招聘人员、状态、来源、申请日期 (Applied On)、拒绝日期 (Rejected On)、录用日期 (Hired On)、最后阶段变更日期 (Last Stage Change On)、录用通知创建日期 (Offer Created On)、录用通知接受日期 (Offer Accepted On)、录用状态 (Offer Status)。
要获取面试相关的活动，您需要另一份报告。返回“基本报告”并选择“面试详情 (Interview Details)”。
配置“面试详情”报告。在“列”部分，至少选择：申请 ID (Application ID)、面试名称、计划开始时间和评分卡提交时间 (Scorecard Submitted At)。这将提供面试安排和反馈提交的时间戳。
对于这两个报告，请使用筛选器设置合适的日期范围。常用的筛选器是将“申请日期 (Applied On)”设置为“所有时间”或特定范围（如过去 6 个月），以获取相关的申请样本。
点击“更新”或“生成”按钮生成报告。显示报告后，点击“导出到 Excel”按钮，将数据下载为 CSV 文件。现在您将拥有两个独立的 CSV 文件。
导出的文件还不是事件日志格式。您必须使用 Python、R 或具有逆透视 (unpivot) 功能的表格程序（如 Microsoft Excel 的 Power Query）进行转换。
根据“申请 ID”合并来自“所有申请”和“面试详情”报告的数据。
对于每份申请，为您导出的每个相关日期列创建一个独立的行。例如，“申请日期 (Applied On)”列的值变为名为“申请已收到”活动的“ActivityTimestamp”；“拒绝日期 (Rejected On)”列的值创建“申请已拒绝”活动，以此类推，完成所有 14 个所需活动。如果缺乏专用时间戳，可使用“最后阶段变更日期 (Last Stage Change On)”列来推断“申请已审阅”或“招聘人员初筛已完成”等活动。
构建最终的转换文件，包含以下必需列：JobApplicationId、ActivityName、ActivityTimestamp、SourceSystem、LastDataUpdate 以及建议的属性。将此最终文件保存为单个 CSV 以供上传。

配置

主要报告：数据提取依赖于结合 Greenhouse “基本报告 (Essential Reports)” 部分中的多个报告，主要是“所有申请 (All Applications)”和“面试详情 (Interview Details)”。
关键列（所有申请）：为获取所有必要数据，请选择申请 ID (Application ID)、候选人、职位、部门、招聘人员、状态、来源、录用状态 (Offer Status) 以及所有相关的日期列，包括申请日期 (Applied On)、拒绝日期 (Rejected On)、录用日期 (Hired On)、录用通知创建日期 (Offer Created On) 和录用通知接受日期 (Offer Accepted On)。
关键列（面试详情）：为获取面试事件，请选择申请 ID (Application ID)、面试名称、计划开始时间和评分卡提交时间 (Scorecard Submitted At)。
日期范围筛选：建议根据“申请日期”筛选 3 到 6 个月内的申请，以确保数据集规模适中且具有参考价值。筛选过长的时间范围可能会影响系统性能。
前提条件：执行导出的用户必须拥有 Greenhouse 的权限，以访问“报告”部分并查看候选人数据。这通常需要“职位管理员 (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 人才获取流程