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

Greenhouse

← 返回改进指南

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

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

此模板全面介绍如何为招聘与人才获取流程收集正确的数据，涵盖需要跟踪的关键属性、需要记录的重要活动，以及如何从Greenhouse系统中提取这些信息的清晰指引。按照此模板操作，可为深入的流程分析建立可靠的数据基础。

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

刚接触事件日志？了解如何创建流程挖掘事件日志.

下载模板

招聘与人才获取属性

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

5 必需 6 建议 10 可选

	名称	说明
	活动名称 ActivityName	已发生的具体招聘活动或阶段的名称。
说明此属性记录招聘流程中每个事件的名称，例如“Application Received”、“Interview Scheduled”或“Offer Accepted”，构成流程图中的事件序列。分析这些活动的顺序和频率，是流程挖掘的基础。它有助于将招聘漏斗可视化，识别常见流程路径，检测偏离标准工作流的情况，并定位流程停滞的瓶颈。例如，您可以跟踪有多少申请从“Application Reviewed”进入“Recruiter Screen Conducted”。为什么重要此属性定义招聘流程中的步骤，用于可视化流程并识别瓶颈和偏差。获取位置通常通过映射Greenhouse中的申请阶段变化、面试状态、offer事件或其他可审计操作得出。可能需要使用相应逻辑，将系统事件转换为标准化活动名称。示例审核申请完成面试接受offer拒绝申请
	活动时间戳 ActivityTimestamp	招聘活动实际发生的准确日期和时间。
说明活动时间戳标记招聘流程中事件发生的准确时刻，是所有绩效和时长分析的时间基础，并为每个职位申请提供活动的时间顺序。此时间戳对于计算所有时间相关KPI至关重要，例如招聘周期、面试安排周期和面试反馈周转时间。通过分析不同活动之间经过的时间，组织可以衡量效率、识别延迟，并监控服务级别协议的遵循情况，直接支持聚焦绩效和瓶颈的仪表板。为什么重要此时间戳对于排列事件顺序、计算周期时间和分析招聘流程绩效至关重要。获取位置可在Greenhouse的多个对象中找到，例如Application对象中的“applied_at”、Offer对象中的“created_at”，以及活动流和审计日志中的时间戳。示例 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	职位申请 JobApplicationId	单个候选人针对特定职位申请的唯一标识符。
说明 Job Application ID是招聘流程分析的基础，作为唯一的案例标识符，将从初次提交和筛选到面试、offer及最终录用决定的所有相关活动关联起来，从而完整呈现每位候选人的端到端旅程。在流程挖掘中，此属性用于重建每位候选人通过招聘漏斗的实际路径。它支持分析每个申请的流程变体、周期时间和流失节点，清晰呈现每位申请人的完整招聘生命周期。为什么重要这是连接单个候选人所有招聘事件的核心Case ID，使您能够分析从开始到结束的完整招聘旅程。获取位置这通常是申请对象的主键。请参阅Greenhouse API文档中的“Applications”端点，通常称为“id”或“application_id”。示例 987654321098765432119876543212
	上次数据更新时间 LastDataUpdate	表示此事件的数据上次刷新或提取的时间戳。
说明此属性记录数据上次从源系统提取的日期和时间。它是一个元数据字段，反映流程挖掘模型中数据的新鲜度。这些信息对于了解分析数据的时效性至关重要。它有助于管理对数据延迟的预期，也是验证数据管道是否按计划运行的关键依据。例如，如果“上次数据更新时间”已是几天前，用户就能知道仪表板未反映最新的招聘活动。为什么重要反映数据的新鲜度，帮助用户了解分析是否体现流程的最新状态。获取位置此时间戳会在数据提取、转换和加载（ETL）过程中生成并写入数据集。示例 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	源系统 SourceSystem	标识提取数据所来自的记录系统。
说明此属性用于指定招聘数据的来源。对于此流程，该值始终为“Greenhouse”。虽然它看似是静态值，但明确记录源系统对于数据治理、问题排查以及数据可能从其他系统（例如HRIS）补充的场景至关重要。它有助于明确数据来源，并维护整个组织数据环境中的数据完整性。为什么重要确保数据来源清晰，这对于数据治理、验证以及管理来自多个来源的数据至关重要。获取位置这是一个静态值，应在数据提取和转换过程中添加，用于标记数据来源。示例 Greenhouse
	Offer状态 OfferStatus	向候选人发出的职位Offer的当前状态。
说明此属性记录职位Offer的状态，取值包括“Created”“Extended”“Accepted”或“Rejected”。它是招聘流程最后阶段的重要指标。此属性是“Offer Acceptance Rate Trends”仪表板及其对应KPI的基础。通过跟踪从“Offer Extended”到“Offer Accepted”或“Offer Rejected”的进展，企业可以衡量促成候选人接受Offer的能力。按部门或职位名称分析，还可以了解薪酬竞争力、候选人体验及其他影响候选人决策的因素。为什么重要跟踪职位Offer的结果，对于计算Offer Acceptance Rate KPI并了解如何提升该指标至关重要。获取位置可在Greenhouse的Offer对象中获取，该对象与Application关联。“status”字段提供此信息。示例已接受已拒绝已发送已创建
	招聘人员姓名 RecruiterName	负责管理该职位申请的招聘人员姓名。
说明此属性用于标识负责某个职位申请或招聘需求的招聘人员。该人员通常负责筛选候选人、协调面试，并推动候选人完成招聘流程。按招聘人员分析流程，有助于了解个人绩效和工作量分配。“Recruiter Workload & Efficiency”仪表板依靠此属性计算每位招聘人员的吞吐量和周期时间等指标。它有助于识别表现优秀的人员、找出可能需要额外支持的人员，并确保人才招聘团队的工作量保持均衡。为什么重要将流程活动归属到具体招聘人员，从而分析个人绩效、工作量和效率。获取位置可在Greenhouse的Job对象中获取，通常位于“hiring_team”部分，其中会指定“Recruiter”等角色。示例 Alice JohnsonRobert DavisMaria Garcia
	申请来源 ApplicationSource	接收候选人申请的渠道。
说明此属性记录职位申请的来源，例如“LinkedIn”“Employee Referral”“Company Website”或“Indeed”，帮助了解不同招聘渠道的效果。 “Sourcing Channel Effectiveness”仪表板完全围绕此属性构建。按来源分析申请量、招聘周期和录用率后，组织可以优化招聘营销投入和工作量。这些数据有助于回答哪些渠道能够以最高效率带来高质量候选人等战略问题，并直接支持“Sourcing Channel Conversion Rate”KPI。为什么重要帮助衡量不同招聘渠道的效果和投资回报率，为招聘来源投入提供数据依据。获取位置可在Greenhouse的Candidate对象中获取，该对象与Application关联。“source”字段提供此信息。示例 LinkedIn员工推荐公司招聘页面Indeed
	申请状态 ApplicationStatus	职位申请的最终结果或当前状态。
说明此属性表示申请的处理结果，例如“Hired”“Rejected”或“Active”。对于已完成流程，它代表终止状态；对于进行中的流程，它代表当前状态。这是分析结果的关键维度。通过筛选案例，可以比较已录用候选人与被拒候选人的流程路径，发现成功路径的特征。它还用于计算“Overall Recruitment Funnel”仪表板中的转化率，展示最终获得录用的申请占比。为什么重要定义招聘流程结果，支持比较成功（已录用）与未成功（被拒）候选人的流程路径。获取位置此信息位于Greenhouse的Application对象中，可通过API中的“status”字段获取。示例已录用已拒绝有效
	职位名称 JobTitle	候选人申请的职位名称。
说明此属性包含招聘需求的正式职位名称，例如“Senior Software Engineer”或“Product Marketing Manager”，为正在招聘的岗位提供必要背景。按职位名称分析招聘流程，是了解不同岗位特有问题的基础。例如，“Time To Hire Performance”仪表板利用此属性展示高级或高度专业化岗位是否需要更长时间才能完成招聘。它还支持分析不同职位的Offer接受率，从而了解薪酬竞争力或岗位吸引力。为什么重要支持筛选和比较特定岗位的招聘指标，帮助了解流程绩效如何随职位复杂度或类型变化。获取位置这是Greenhouse中Job对象的主要字段，通过API查询“jobs”端点时通常以“name”提供。示例高级软件工程师客户经理UX/UI设计师
	职位部门 JobDepartment	正在招聘该职位的部门或业务单元。
说明此属性用于指定与招聘需求相关的组织部门，例如“Engineering”“Marketing”或“Sales”。它支持汇总和比较企业不同部门的招聘指标。按部门细分分析，对于“Time To Hire Performance”和“Offer Acceptance Rate Trends”等仪表板至关重要。它有助于识别某些部门是否存在更长的招聘周期、更高的Offer拒绝率或不同的流程合规水平。这些洞察支持针对各部门具体需求制定改进措施，推动流程优化。为什么重要支持比较不同部门的招聘绩效和流程差异，发现系统性问题或最佳实践。获取位置通常可作为Greenhouse中Job对象的标准字段或自定义字段获取。通过API查询Job记录时，可在“departments”部分找到。示例工程产品管理销售市场营销
	Scorecard建议 ScorecardOverallRecommendation	已完成面试Scorecard给出的总体录用建议。
说明此属性记录面试官在结构化面试Scorecard上给出的最终建议，通常包括“Strong Yes”“Yes”“No”或“Strong No”。这些数据对于评估面试流程的质量和一致性至关重要。它有助于将面试反馈与实际录用结果关联起来，回答“获得更积极建议的候选人是否更容易被录用”等问题。它也是“Scorecard Completion Rate”KPI的基础，用于衡量组织对结构化招聘实践的采用程度。为什么重要将结构化面试反馈与流程结果关联起来，并帮助衡量数据驱动招聘实践的采用程度。获取位置可在Greenhouse中与已完成面试关联的Scorecard对象中找到。API通过“scorecards”端点提供此信息。示例明确不通过不通过通过明确通过
	候选人ID CandidateId	用于唯一标识候选人的标识符，与任何单个申请无关。
说明 Candidate ID用于唯一标识人才池中的个人，而Job Application ID仅对应某个职位的一次申请。同一候选人可能在不同时间提交多个职位申请。 Job Application ID在此流程视图中充当Case ID，而Candidate ID支持另一类分析。它可用于跟踪候选人在多个职位申请中的经历、识别频繁申请者，并分析候选人与人才池之间的整体关系，从而提供以个人为中心的招聘数据视图。为什么重要支持分析同一候选人的多个申请，提供更全面的候选人长期参与情况视图。获取位置这是Greenhouse中候选人记录的主键，可通过API从Candidate对象的“id”字段获取。示例 123456123457123458
	拒绝原因 RejectionReason	拒绝候选人申请时提供的原因。
说明此属性记录候选人未能继续进入招聘流程的具体原因，例如“Not a culture fit”“Salary expectations too high”或“More qualified candidates”。分析拒绝原因可以为招聘流程提供重要反馈，帮助发现职位描述不匹配、薪酬缺乏竞争力或人才池中反复出现的技能缺口等问题。了解招聘漏斗中的常见失败点，有助于改进招聘来源策略并提升候选人体验。为什么重要提供候选人退出招聘漏斗原因的定性洞察，帮助优化职位描述、招聘来源和筛选标准。获取位置当Application被拒绝时可获取。API通过“rejection_reason”对象提供详细信息。示例缺少所需技能薪资期望过高已选择更合适的候选人
	招聘经理姓名 HiringManagerName	相关招聘需求的招聘经理姓名。
说明此属性用于标识负责招聘岗位所在团队的经理。招聘经理是流程中的关键干系人，通常参与候选人审核、后期面试以及最终录用决策。按招聘经理分析流程，可以发现重要模式和瓶颈。例如，“Interview Scheduling Bottlenecks”仪表板可能显示，延迟经常与特定经理的时间安排有关。这有助于识别培训或支持需求，确保经理能够高效参与招聘流程。为什么重要识别关键干系人，支持分析与特定招聘经理相关的流程瓶颈或效率。获取位置可在Greenhouse的Job对象中获取，通常位于“hiring_team”部分，其中会指定“Hiring Manager”等角色。示例 Emily TranDavid ChenSophia Rodriguez
	是否合规 IsCompliant	用于标识申请是否遵循标准化、已定义的招聘流程的计算标志。
说明此布尔属性来自一致性检查，用于将职位申请的实际活动序列与预定义的理想流程模型进行比较。它会标记跳过必需步骤或活动顺序错误等偏离流程的案例。这是“Hiring Compliance Deviation”仪表板的核心属性，并支持“Process Conformance Rate”和“Compliance Violation Count”KPI。通过筛选不合规案例，组织可以调查偏离原因，例如培训不足、系统限制或必要例外。这有助于标准化工作流并降低合规风险。为什么重要识别流程偏离，对于衡量流程一致性、确保合规以及标准化招聘工作流至关重要。获取位置这是由流程挖掘软件生成的计算字段，用于将事件日志数据与定义的目标模型或业务规则集进行比较。示例 truefalse
	是否自动执行 IsAutomated	用于标识某项活动是否由系统自动执行的标志。
说明此布尔属性表示活动由用户执行，还是由自动化系统规则执行。自动化活动包括发送自动回复邮件，或自动拒绝未通过基本筛选问题的候选人。分析此属性有助于了解招聘流程的自动化程度。它可用于比较自动化步骤与人工步骤的效率和结果，并识别进一步自动化的机会，从而提升速度和一致性。为什么重要帮助区分人工活动和自动化活动，支持分析自动化对流程效率和结果的影响。获取位置这不是标准字段，通常需要通过推导获得。可以根据与活动关联的用户（例如“System”用户）或已知为自动化的特定事件类型进行判断。示例 truefalse
	活动结束时间 ActivityEndTime	表示具有持续时长的活动结束时间的时间戳。
说明此属性记录持续一段时间的活动的完成时间，例如面试或背景调查。许多活动是瞬时完成的，但对于具有可衡量时长的活动，同时记录开始和结束时间更有价值。结束时间对于准确计算特定活动的处理时间或持续时长至关重要。它有助于区分步骤之间的等待时间与任务实际耗时。例如，可以更准确地分析面试本身持续了多久，以及安排面试花费了多长时间。为什么重要支持精确计算活动处理时间，帮助区分流程中的实际工作时间和空闲等待时间。获取位置此信息可能存在于Greenhouse的“scheduled_interview”等对象中，该对象通常同时包含“start”和“end”时间。对于其他活动，可能需要根据后续活动的时间戳推断。示例 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	职位ID JobId	招聘需求或职位发布的唯一标识符。
说明此属性是职位本身的唯一ID，与申请ID不同。多个申请可以关联同一个Job ID。使用Job ID可以在招聘需求层面汇总数据。例如，可以分析某个职位收到的申请总数，或同类岗位的平均招聘周期。它支持围绕某个开放职位对招聘工作进行分组和分析。为什么重要支持汇总和分析与单个职位空缺相关的所有候选人数据，提供以招聘需求为中心的视图。获取位置这是Greenhouse中职位记录的主键，可通过API从Job对象的“id”字段获取。示例 400123400124400125
	面试反馈周转时间 InterviewFeedbackTurnaroundTime	从面试完成到面试官提交反馈之间经过的时间。
说明此计算指标用于衡量面试小组的响应速度。提交反馈的延迟会显著拖慢招聘流程，并对候选人体验产生负面影响。此属性直接支持“Interview Feedback Loop Analysis”仪表板和“Interview Feedback Turnaround Time”KPI。它通过计算“Interview Completed”和“Feedback Submitted”活动之间的时间差得出。监控该指标有助于识别由反馈缓慢造成的瓶颈，并推动更快做出决策。为什么重要衡量面试后的反馈闭环效率，这是招聘流程中常见的延迟来源。获取位置这是一个计算字段，通过“Feedback Submitted”事件的时间戳减去“Interview Completed”事件的时间戳得出。示例 86400172800259200
	面试阶段 InterviewStageName	面试阶段的具体名称或类型。
说明此属性用于指定完整面试流程中的具体阶段，例如“Recruiter Screen”“Technical Interview”或“Final Round”。相比通用的“Interview Completed”活动，它提供更细的分析粒度。按各个面试阶段分析指标，可以更准确地定位具体瓶颈。例如，可以精确衡量“Candidate Drop-off Rate by Stage”，识别候选人更容易在技术面试后退出，还是在初步筛选后退出。这些细节对于针对性改善面试体验至关重要。为什么重要提供更详细的面试流程视图，支持分析每个具体面试环节的周期时间和退出率。获取位置此信息属于Greenhouse的面试安排数据。职位申请中的“interviews”对象包含面试阶段详情。示例招聘人员初筛招聘经理面试技术评估现场终面

必需建议可选

招聘与人才获取活动

应在事件日志中记录以下关键流程步骤和里程碑，以准确发现流程并优化招聘漏斗。

7 建议 7 可选

	活动	说明
	发出offer	正式职位offer已发送给候选人。这是面试和甄选流程完成后的关键里程碑。
为什么重要此活动是计算Offer Acceptance Rate KPI的基础，标志着候选人最终决策阶段开始。获取位置当Greenhouse中的offer状态变为“Sent”或“Extended”时，系统会明确记录此事件。offers对象包含这些状态变化的时间戳。采集从offer状态正式标记为已发送时的时间戳中获取。事件类型 explicit
	安排面试	系统中已为候选人安排面试。Greenhouse支持日历集成，因此面试确认后通常会明确记录此事件。
为什么重要此事件对于分析和识别面试安排流程中的瓶颈至关重要。它与上一步之间的时间，是衡量招聘人员和协调人员效率的重要KPI。获取位置从Greenhouse的面试安排功能中获取。API会提供已安排面试的数据，包括创建时间戳。采集创建面试事件并将其与候选人申请关联时记录。事件类型 explicit
	完成面试	候选人已参加面试。通常可根据已安排的面试时间已过来推断，更可靠的方式是以该面试提交反馈的时间为准。
为什么重要此活动是候选人旅程中的重要里程碑，也是衡量反馈提交时间和进入下一阶段情况的起点。获取位置通常需要推断。可以根据已安排面试的结束时间得出，更准确的方式是使用该面试提交第一条反馈的时间戳。采集根据已安排面试的结束时间或后续反馈提交的时间戳推断。事件类型 inferred
	录用候选人	候选人已成功完成所有入职前检查，并正式标记为已录用。这是申请流程成功完成的结束事件。
为什么重要这是流程的主要成功结果。从“Application Received”到此事件的时间就是整体招聘周期，是关键的招聘KPI。获取位置这是Greenhouse中的明确操作，招聘人员将候选人标记为某个职位的已录用人员，使其从活跃候选人变为已录用人员。采集从Greenhouse中“Mark as Hired”操作的时间戳中获取。事件类型 explicit
	拒绝申请	候选人的申请在流程中的某个阶段被拒绝。这是最常见的非成功结束事件，可能发生在任何阶段。
为什么重要这是分析招聘漏斗流失率的关键结束事件。了解拒绝发生的时间和原因，有助于识别流程低效或职位要求不匹配的问题。获取位置用户在Greenhouse中拒绝申请时，系统会明确记录此事件。通常还会附带拒绝原因，活动日志会记录时间戳。采集从对申请执行拒绝操作时的时间戳中获取。事件类型 explicit
	接受offer	候选人已正式接受职位offer。这是关键的成功里程碑，通常会触发背景调查等后续入职前活动。
为什么重要这是关键的成功里程碑，也是Offer Acceptance Rate KPI的重要组成部分，标志着候选人即将成为员工。获取位置当Greenhouse中的offer状态更新为“Accepted”时，系统会明确记录此事件。状态可能由招聘人员更新，也可能由候选人通过电子方式接受后更新。采集从offer状态变为“Accepted”时的时间戳中获取。事件类型 explicit
	收到申请	此活动标志着某个职位申请的招聘流程开始。当候选人通过招聘网站或来源渠道提交申请，或被手动录入Greenhouse时，系统会记录该活动。
为什么重要这是流程的主要开始事件。分析从该活动到其他活动的时间，对于衡量招聘周期和来源渠道效果至关重要。获取位置当Greenhouse创建申请时，系统会明确记录此事件。申请对象中的Application Date字段或创建时间戳可提供事件时间。采集从申请记录的创建时间戳中获取。事件类型 explicit
	创建offer	正式职位offer已起草，可能正在等待内部审批。这标志着组织正式决定向候选人发出offer。
为什么重要此活动将发出offer的决定与实际发送offer区分开来，有助于分析offer到达候选人之前的内部审批时间和瓶颈。获取位置 Greenhouse提供专用的offers模块。此事件可从与申请关联的offer对象创建时间戳中明确获取。采集在Greenhouse系统创建offer记录时记录。事件类型 explicit
	启动入职	新员工入职流程已正式开始。这通常包括从招聘系统向HRIS或入职平台进行交接。
为什么重要此活动用于跟踪从招聘到HR的交接效率。交接延迟可能导致新员工体验不佳，因此监控Onboarding Handoff Time至关重要。获取位置如果Greenhouse已与入职系统集成，这可能是明确记录的事件。否则，可根据候选人进入最终“Hired”阶段的时间戳推断，因为该变化会触发交接。采集根据阶段变化或表明已交接至HRIS的集成日志推断。事件类型 inferred
	启动背景调查	候选人的背景调查已启动，通常发生在接受offer之后。系统可能通过特定阶段变化或与第三方服务的集成触发记录此活动。
为什么重要此活动对于合规以及跟踪入职前筛查延迟非常重要，有助于分析从接受offer到完成必要调查所需的时间。获取位置通常可根据候选人进入招聘管道中的“Background Check”阶段，或与背景调查集成相关的活动日志推断。采集根据状态变为“Background Check”阶段，或集成服务的API日志推断。事件类型 inferred
	完成招聘人员初筛	招聘人员已完成与候选人的初次电话筛选或沟通。候选人进入招聘管道中的“Phone Screen”阶段时，通常会记录此活动。
为什么重要这是重要的资格评估里程碑，表示申请已通过初步简历筛选。它有助于衡量招聘人员的工作负载和初筛效果。获取位置根据申请进入或离开Greenhouse职位管道中“Phone Screen”阶段时的时间戳推断。采集根据申请的阶段历史记录得出，重点关注进入“Phone Screen”阶段的时间。事件类型 inferred
	审核申请	招聘人员或招聘经理已对候选人的申请进行初步审核。通常可根据申请阶段或状态从“New”变为“In Review”等活跃审核阶段来推断。
为什么重要跟踪此活动有助于识别初筛阶段的瓶颈，并衡量新申请获得关注所需的时间，也是计算面试安排周期的起点。获取位置根据申请状态字段的变化推断。查找从“New”状态变为“Review”状态的变化，并使用变化发生时的时间戳。采集根据状态变为“In Review”或类似阶段时的时间戳推断。事件类型 inferred
	拒绝offer	候选人已正式拒绝职位offer。这是流程后段发生的非成功结束事件。
为什么重要跟踪此结果对于分析Offer Acceptance Rate至关重要。此事件频繁发生，可能表明薪酬、企业文化或职位本身存在问题。获取位置当Greenhouse中的offer状态更新为“Rejected”或“Declined”时，系统会明确记录此事件。offer对象会记录该状态变化的时间戳。采集从offer状态变为“Rejected”时的时间戳中获取。事件类型 explicit
	提交反馈	面试官已提交关于候选人面试表现的scorecard或反馈。Greenhouse的结构化招聘流程依赖这些信息进行决策，因此这是一个独立记录的操作。
为什么重要反馈提交的及时性对于推动候选人进入下一阶段至关重要。此活动有助于分析反馈闭环效率和Scorecard Completion Rate。获取位置面试官通过Greenhouse提交scorecard时，系统会明确记录此事件。Scorecards API对象包含`submitted_at`时间戳。采集从面试scorecard的提交时间戳中获取。事件类型 explicit

建议可选

提取指南

如何从Greenhouse获取数据

步骤

登录您的Greenhouse Recruiting账户。
点击主导航栏中类似柱状图的报表图标，进入Reports部分。
在Reports仪表板中找到并点击“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文件。此时您将获得两个独立的CSV文件。
导出的文件尚未采用事件日志格式。您必须使用Python、R或具备逆透视功能的电子表格工具，例如Microsoft Excel的Power Query，执行转换。
合并“All Applications”和“Interview Details”报表，并通过Application ID进行关联。
对每个申请，为导出的每个相关日期列创建一行独立记录。例如，“Applied On”列的值作为“Application Received”活动的“ActivityTimestamp”；“Rejected On”列的值生成“Application Rejected”活动，其他必需活动依此处理。如果没有专用时间戳，可使用“Last Stage Change On”推断“Application Reviewed”或“Recruiter Screen Conducted”等活动。
使用以下必需列组织最终转换文件：JobApplicationId、ActivityName、ActivityTimestamp、SourceSystem、LastDataUpdate及任何推荐属性。将最终文件保存为单个CSV，以便上传。

配置

主要报表：提取过程依赖于合并Greenhouse的Essential Reports部分中的多份报表，主要是“All Applications”和“Interview Details”。
关键列（All Applications）：为获取完整数据，请选择Application ID、Candidate、Job、Department、Recruiter、Status、Source、Offer Status，以及所有相关日期列，包括Applied On、Rejected On、Hired On、Offer Created On和Offer Accepted On。
关键列（Interview Details）：为记录面试事件，请选择Application ID、Interview Name、Scheduled Start和Scorecard Submitted At等列。
日期范围筛选：建议根据“Applied On”日期筛选3至6个月的数据，以确保数据集规模适中且具有相关性。时间范围过长可能影响性能。
前提条件：执行导出的用户必须拥有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 Key
- 使用具备开发者权限的账户登录Greenhouse。
- 进入Configure > Dev Center > API Credential Management。
- 点击“Create New API Key”。
- 填写描述，例如“ProcessMind Extraction”。
- 将类型选择为“Harvest”。
- 授予API Key所需权限。至少需要对以下对象拥有GET权限：Applications、Candidates、Jobs、Job Stages、Offers、Scorecards和Users。
- 安全复制生成的API Key。之后将无法再次查看。
设置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 Key权限：Harvest API Key必须对以下端点拥有只读（GET）访问权限：Applications、Candidates、Jobs、Job Stages、Offers、Scorecards和Users。权限不足会导致部分活动缺少数据。
日期范围筛选：脚本使用updated_after参数（START_DATE_ISO变量）筛选申请。首次提取请使用较宽的范围，例如最近6个月。后续增量加载时，将其设置为上次成功运行的时间戳，以提高性能。
阶段到活动的映射：脚本中的STAGE_TO_ACTIVITY字典至关重要。必须根据公司在Greenhouse中使用的独有招聘阶段进行配置，才能正确识别“Recruiter Screen Conducted”和“Background Check Initiated”等活动。
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.")

步骤

确认您许可的ETL平台提供Greenhouse连接器，并确认该连接器支持包含申请、申请阶段历史、面试、面试反馈、录用通知、录用状态变更、背景调查、入职交接和录用结果的Greenhouse对象或复制数据集。不同平台的连接器对象名称可能不同，因此请使用连接器目录和架构浏览器，不要自行假定表名。
在ETL平台中创建Greenhouse源连接。输入Greenhouse凭据、授权信息、复制设置，以及环境所需的公司专用筛选条件。按照连接器文档规定的授权流程操作，并仅授予读取所选招聘数据所需的权限。
配置目标数据仓库，并为构建事件日志所需的源对象启用复制。至少选择能够提供职位申请、申请状态或阶段历史、面试、面试反馈、录用通知、录用状态变更、背景调查事件、入职交接和录用结果的对象。如果某个必需对象不可用，请记录该限制，并根据您的Greenhouse配置映射到最接近的受支持数据源。
将初始复制窗口设置为所需分析期间，通常为过去三至六个月。如果申请可能在所选期间之前创建、但在该期间内推进，请纳入更早的回溯期。配置增量复制，并在可用时保留源更新时间戳。
检查复制后的架构，并将查询中的每个占位符替换为连接器实际提供的目标架构、表名、列名、时间戳字段、标识符和状态值。除非复制数据中确实存在，否则不要假定其中包含阶段变更、面试记录、反馈记录、录用记录、背景调查记录、入职交接或录用结果。
将转换查询配置为明确事件提取的联合查询。每个提取结果必须包含JobApplicationId、ActivityName、ActivityTimestamp、SourceSystem、LastDataUpdate、RecruiterName、JobDepartment、JobTitle、ApplicationStatus、ApplicationSource和OfferStatus。将时间戳统一为一个时区，删除缺少有效申请标识或活动时间戳的记录，并为每个代表一项活动的源事件保留一行。
应用事件映射规则。使用申请创建或提交数据映射“收到申请”，使用明确的审核阶段或状态转换映射“申请已审核”，使用招聘人员筛选记录或已配置的电话筛选阶段转换映射“已完成招聘人员筛选”，使用面试确认或计划时间戳映射“面试已安排”，使用面试完成或反馈提交时间戳映射“面试已完成”，使用反馈提交映射“反馈已提交”，使用录用通知创建映射“录用通知已创建”，使用录用通知发送或发出状态映射“录用通知已发出”，使用已接受录用状态映射“录用通知已接受”，使用记录在案的背景调查启动事件映射“背景调查已启动”，使用入职交接或启动事件映射“入职已启动”，使用录用结果映射“候选人已录用”，使用拒绝录用结果映射“录用通知已拒绝”，使用拒绝申请结果或拒绝阶段转换映射“申请已拒绝”。
将转换结果加载到专用于ProcessMind事件日志的目标表或视图中。除非已记录的业务规则认定其为技术重复，否则保留重复源事件。如需去重，仅对完全相同的源事件键去重，例如申请标识、活动名称、活动时间戳和源记录标识。
使用以下检查验证结果：确认所有必需列均存在、时间戳有效、源数据存在时每项必需活动均有记录，并确认每个申请对应唯一案例标识。分别检查被拒绝、撤回、归档和不完整的申请，避免筛选条件意外删除有效流程结果。
将最终结果导出为扁平CSV，或通过ProcessMind支持的数据仓库连接提供结果。将JobApplicationId映射为案例标识，将ActivityName映射为活动，将ActivityTimestamp映射为事件时间戳。包含SourceSystem和LastDataUpdate，保留建议属性，使用带时区信息的ISO 8601等统一时间戳格式，并且不要依赖ProcessMind推断文件中缺失的事件。

配置

连接器和目标系统：使用获得许可且支持Greenhouse连接器的ETL平台，并配置转换层可访问的目标数据仓库。连接器能力、对象名称、刷新间隔和历史复制支持取决于所选平台及订阅方案。
源授权：配置连接器所需的Greenhouse凭据和权限。确认授权账户可以读取申请记录、阶段或状态历史、面试记录、反馈、Offer，以及映射所需的集成背景调查或入职数据。
复制对象：选择14项事件提取所需的全部源对象。不要只启用当前申请表，因为历史阶段变更、面试操作、反馈提交、Offer转换或后续交接可能分别存储在其他对象中。
日期范围：运营分析建议从3至6个月开始。衡量完整申请生命周期时应扩大范围，因为周期开始前创建的申请可能在周期内进入面试、获得Offer或完成录用。
增量刷新：在可用时保留源创建时间、发生时间和最后更新时间戳。根据所需报表时效配置定期刷新，并设置较小的重叠窗口，以处理延迟到达或更正的记录。
筛选条件：仅应用已记录的公司特定筛选条件，例如组织、部门、职位、地点或申请日期。除非复制后的Greenhouse架构中确实存在且配置确实需要，否则不要使用Company Code或Document Type等通用筛选条件。
活动映射：维护从源事件类型、阶段、状态或时间戳到每个ActivityName的文档化映射。根据组织实际使用的值，配置审核、电话筛选、拒绝、Offer、接受、背景调查、入职和录用结果的精确值。
空值处理：如果源数据未提供RecruiterName、JobDepartment、JobTitle、ApplicationStatus、ApplicationSource和OfferStatus，可允许其为空。缺少必需标识符和时间戳时，应拒绝记录或进行调查。
时区：将所有活动时间戳转换为统一的报表时区；如需审计，可同时保留原始源时间戳。确保LastDataUpdate表示刷新或提取时间，而非活动发生时间。
性能：对于大型数据集，按复制时间戳分区筛选源提取范围，仅选择必需列，使用增量加载，并将最终事件日志实体化。避免在没有索引标识符的情况下反复将完整历史记录与当前申请记录连接。
数据保留：确认ETL平台和Greenhouse访问权限在所选周期内保留历史阶段、面试、反馈、Offer和结果记录。仅依赖当前状态表无法可靠重建历史活动。
ProcessMind映射：将JobApplicationId配置为案例标识符，将ActivityName配置为活动字段，将ActivityTimestamp配置为事件时间戳。确保导出文件为每项活动保留一行明确记录，不依赖推断转换。

a 示例查询 config

WITH
application_received AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Application Received' AS ActivityName,
        [ApplicationReceivedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your application event table]
    WHERE [ApplicationReceivedTimestamp] IS NOT NULL
),
application_reviewed AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Application Reviewed' AS ActivityName,
        [StageChangeTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your application stage history table]
    WHERE [StageChangeTimestamp] IS NOT NULL
      AND [NewStageName] IN ('In Review')
),
recruiter_screen_conducted AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Recruiter Screen Conducted' AS ActivityName,
        [ScreenCompletedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your recruiter screen event table]
    WHERE [ScreenCompletedTimestamp] IS NOT NULL
),
interview_scheduled AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Interview Scheduled' AS ActivityName,
        [InterviewScheduledTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your interview table]
    WHERE [InterviewScheduledTimestamp] IS NOT NULL
),
interview_completed AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Interview Completed' AS ActivityName,
        [InterviewCompletedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your interview table]
    WHERE [InterviewCompletedTimestamp] IS NOT NULL
),
feedback_submitted AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Feedback Submitted' AS ActivityName,
        [FeedbackSubmittedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your interview feedback table]
    WHERE [FeedbackSubmittedTimestamp] IS NOT NULL
),
offer_created AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Created' AS ActivityName,
        [OfferCreatedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferCreatedTimestamp] IS NOT NULL
),
offer_extended AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Extended' AS ActivityName,
        [OfferExtendedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferExtendedTimestamp] IS NOT NULL
),
offer_accepted AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Accepted' AS ActivityName,
        [OfferAcceptedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferAcceptedTimestamp] IS NOT NULL
),
background_check_initiated AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Background Check Initiated' AS ActivityName,
        [BackgroundCheckInitiatedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your background check event table]
    WHERE [BackgroundCheckInitiatedTimestamp] IS NOT NULL
),
onboarding_initiated AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Onboarding Initiated' AS ActivityName,
        [OnboardingInitiatedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your onboarding handoff table]
    WHERE [OnboardingInitiatedTimestamp] IS NOT NULL
),
candidate_hired AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Candidate Hired' AS ActivityName,
        [HiredTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your hiring outcome table]
    WHERE [HiredTimestamp] IS NOT NULL
),
offer_rejected AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Offer Rejected' AS ActivityName,
        [OfferRejectedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your offer table]
    WHERE [OfferRejectedTimestamp] IS NOT NULL
),
application_rejected AS (
    SELECT
        [JobApplicationId] AS JobApplicationId,
        'Application Rejected' AS ActivityName,
        [ApplicationRejectedTimestamp] AS ActivityTimestamp,
        'Greenhouse' AS SourceSystem,
        [LastDataUpdate] AS LastDataUpdate,
        [RecruiterName] AS RecruiterName,
        [JobDepartment] AS JobDepartment,
        [JobTitle] AS JobTitle,
        [ApplicationStatus] AS ApplicationStatus,
        [ApplicationSource] AS ApplicationSource,
        [OfferStatus] AS OfferStatus
    FROM [Your application outcome table]
    WHERE [ApplicationRejectedTimestamp] IS NOT NULL
)
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM application_received
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM application_reviewed
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM recruiter_screen_conducted
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM interview_scheduled
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM interview_completed
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM feedback_submitted
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_created
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_extended
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_accepted
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM background_check_initiated
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM onboarding_initiated
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM candidate_hired
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM offer_rejected
UNION ALL
SELECT JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource, OfferStatus FROM application_rejected;

准备开始了吗？

释放招聘数据的全部价值。立即使用此模板，简化招聘流程并基于数据做出决策。

返回改进指南下载模板

立即简化您在Greenhouse中的人才获取流程

立即将招聘周期缩短30%，改善候选人体验。

开始免费试用

无需信用卡\b•5分钟完成设置

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

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

招聘与人才获取属性

招聘与人才获取活动

提取指南

Greenhouse报表生成器：手动导出CSV

步骤

配置

a 示例查询 config

通过Greenhouse Harvest API使用Python脚本提取

步骤

配置

a 示例查询 python

使用带Greenhouse连接器的自动化ETL工具

步骤

配置

a 示例查询 config

准备开始了吗？

立即简化您在Greenhouse中的人才获取流程

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

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

招聘与人才获取属性

招聘与人才获取活动

提取指南

Greenhouse报表生成器：手动导出CSV

步骤

配置

a 示例查询 config

通过Greenhouse Harvest API使用Python脚本提取

步骤

配置

a 示例查询 python

使用带Greenhouse连接器的自动化ETL工具

步骤

配置

a 示例查询 config

准备开始了吗？

立即简化您在Greenhouse中的人才获取流程

我们重视您的隐私