> Kontinuierliche Prozessverbesserung > Recruiting und Personalgewinnung > Greenhouse > Daten Template

Ihr Daten-Template für Recruiting und Talentgewinnung

Greenhouse

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Recruiting und Talentgewinnung (21) Aktivitäten im Recruiting und bei der Talentgewinnung (14) Anleitungen zur Datenextraktion (3)

Ihr Daten-Template für Recruiting und Talentgewinnung

Dieses Template zeigt Ihnen, welche Daten Sie für die Analyse Ihres Recruiting- und Talentgewinnungsprozesses erfassen sollten. Es beschreibt die wichtigen Attribute und Aktivitäten und erklärt, wie Sie die Informationen aus Ihrem Greenhouse-System extrahieren. So schaffen Sie eine geeignete Datengrundlage für aussagekräftige Prozessanalysen.

Empfohlene Attribute für die Erfassung
Wichtige Aktivitäten für die Nachverfolgung
Anleitung zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Recruiting und Talentgewinnung

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um Ihren Recruiting- und Talentgewinnungsprozess in Greenhouse umfassend zu analysieren.

5 Erforderlich 6 Empfohlen 10 Optional

	Name	Beschreibung
	Aktivitäts-Timestamp ActivityTimestamp	Genaues Datum und genaue Uhrzeit der Recruiting-Aktivität.
Beschreibung Der Aktivitäts-Timestamp gibt den genauen Zeitpunkt eines Ereignisses im Recruiting-Prozess an. Er bildet die zeitliche Grundlage für alle Leistungs- und Daueranalysen und legt die chronologische Reihenfolge der Aktivitäten für jede Stellenbewerbung fest. Dieser Timestamp ist für die Berechnung aller zeitbezogenen Kennzahlen erforderlich, etwa der Time to Hire, der Zykluszeit für die Gesprächsplanung und der Bearbeitungszeit für Gesprächsrückmeldungen. Anhand der Zeit zwischen einzelnen Aktivitäten können Unternehmen die Effizienz messen, Verzögerungen erkennen und die Einhaltung von Service-Level-Vereinbarungen überwachen. Damit unterstützt der Timestamp Dashboards zu Leistung und Engpässen. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, Zykluszeiten zu berechnen und die Leistung des Recruiting-Prozesses zu analysieren. Woher beziehen In verschiedenen Greenhouse-Objekten zu finden, zum Beispiel als „applied_at“ im Application-Objekt, als „created_at“ in Offer-Objekten oder als Timestamp in Aktivitätsfeeds und Audit-Protokollen. Beispiele 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	Aktivitätsname ActivityName	Name der jeweiligen Recruiting-Aktivität oder der eingetretenen Prozessphase.
Beschreibung Dieses Attribut erfasst den Namen jedes Ereignisses im Recruiting-Prozess, zum Beispiel „Bewerbung eingegangen“, „Gespräch geplant“ oder „Angebot angenommen“. Die Ereignisse bilden zusammen die Abfolge im Prozessmodell. Die Abfolge und Häufigkeit dieser Aktivitäten zu analysieren, ist eine wichtige Grundlage für Process Mining. So lässt sich der Recruiting-Prozess visualisieren, häufige Abläufe erkennen, Abweichungen vom Standard-Workflow feststellen und Engpässe identifizieren. Zum Beispiel können Sie nachverfolgen, wie viele Bewerbungen von „Bewerbung geprüft“ zu „Screening durch Recruiterin oder Recruiter durchgeführt“ gelangen. Warum das wichtig ist Dieses Attribut bildet die Schritte des Recruiting-Prozesses ab. So lassen sich der Prozessablauf visualisieren sowie Engpässe und Abweichungen erkennen. Woher beziehen Dieses Attribut wird häufig aus Änderungen der Bewerbungsphase, Gesprächsstatus, Angebotsereignissen oder anderen auditfähigen Aktionen in Greenhouse abgeleitet. Dazu kann eine Logik erforderlich sein, die Systemereignisse in standardisierte Aktivitätsnamen überführt. Beispiele Bewerbung geprüftInterview geführtAngebot angenommenBewerbung abgelehnt
	Stellenbewerbung JobApplicationId	Eindeutige Kennung für die Bewerbung einer einzelnen kandidierenden Person auf eine bestimmte Stelle.
Beschreibung Die ID der Stellenbewerbung ist der zentrale Bezugspunkt für die Analyse des Recruiting-Prozesses und dient als eindeutige Case-ID. Sie verknüpft alle zugehörigen Aktivitäten, von der ersten Einreichung und Prüfung über Gespräche und Angebote bis zur endgültigen Einstellungsentscheidung. So lässt sich der gesamte Weg jeder kandidierenden Person nachvollziehen. Beim Process Mining dient dieses Attribut dazu, den genauen Ablauf jeder Bewerbung im Recruiting-Prozess zu rekonstruieren. Damit lassen sich Prozessvarianten, Zykluszeiten pro Bewerbung und Abbruchpunkte analysieren. So entsteht ein klares Bild des gesamten Recruiting-Prozesses für jede einzelne Bewerbung. Warum das wichtig ist Dies ist die zentrale Case-ID, die alle Recruiting-Ereignisse einer einzelnen kandidierenden Person verknüpft. So lässt sich der gesamte Einstellungsprozess von Anfang bis Ende analysieren. Woher beziehen Dies ist in der Regel der Primärschlüssel eines Bewerbungsobjekts. Weitere Informationen finden Sie in der Greenhouse-API-Dokumentation zum Endpunkt „Applications“, der häufig die Bezeichnung „id“ oder „application_id“ trägt. Beispiele 987654321098765432119876543212
	Letzte Datenaktualisierung LastDataUpdate	Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aktualisiert oder extrahiert wurden.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit des letzten Datenabrufs aus dem Quellsystem. Als Metadatenfeld gibt es an, wie aktuell die Daten im Process-Mining-Modell sind. Anhand dieser Information können Benutzer einschätzen, wie aktuell die Analyse ist. Sie hilft dabei, Erwartungen an die Datenlatenz zu steuern und zu prüfen, ob die Datenpipeline planmäßig läuft. Liegt die „Letzte Datenaktualisierung“ beispielsweise mehrere Tage zurück, wissen Benutzer, dass die Dashboards die jüngsten Recruiting-Aktivitäten nicht abbilden. Warum das wichtig ist Gibt an, wie aktuell die Daten sind, damit Benutzer einschätzen können, ob die Analyse den neuesten Prozessstand abbildet. Woher beziehen Dieser Timestamp wird während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	Quellsystem SourceSystem	Gibt das führende System an, aus dem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt die Herkunft der Recruiting-Daten an. Für diesen Prozess lautet der Wert durchgehend „Greenhouse“. Auch wenn der Wert statisch erscheint, ist die ausdrückliche Erfassung des Quellsystems wichtig für die Data Governance, die Fehlerbehebung und Szenarien, in denen Daten aus anderen Systemen wie einem HRIS ergänzt werden. So bleibt die Herkunft der Daten nachvollziehbar und ihre Integrität über die gesamte Datenlandschaft des Unternehmens hinweg gewahrt. Warum das wichtig ist Sorgt für eine nachvollziehbare Datenherkunft, die für Data Governance, Validierung und die Verwaltung von Daten aus mehreren Quellen wichtig ist. Woher beziehen Dies ist ein statischer Wert, der bei der Datenextraktion und -transformation ergänzt werden sollte, um die Herkunft der Daten zu kennzeichnen. Beispiele Greenhouse
	Abteilung der Stelle JobDepartment	Abteilung oder Geschäftseinheit, für die die Stelle besetzt wird.
Beschreibung Dieses Attribut gibt die organisatorische Abteilung an, zum Beispiel „Technik“, „Marketing“ oder „Vertrieb“, die der Personalanforderung zugeordnet ist. Damit lassen sich Recruiting-Kennzahlen für verschiedene Unternehmensbereiche zusammenfassen und vergleichen. Für Dashboards wie „Leistung bei der Time to Hire“ und „Trends bei der Angebotsannahmequote“ ist eine Auswertung nach Abteilung entscheidend. So lässt sich feststellen, ob bestimmte Abteilungen längere Einstellungszyklen, höhere Ablehnungsquoten bei Angeboten oder andere Compliance-Werte im Prozess aufweisen. Diese Erkenntnisse ermöglichen gezielte Maßnahmen und Prozessverbesserungen, die auf die Anforderungen der jeweiligen Abteilung abgestimmt sind. Warum das wichtig ist Ermöglicht den Vergleich der Recruiting-Leistung und Prozessvarianten zwischen Abteilungen. So werden systematische Probleme und bewährte Vorgehensweisen sichtbar. Woher beziehen In der Regel als Standard- oder benutzerdefiniertes Feld im Job-Objekt in Greenhouse verfügbar. Über die API im Abschnitt „departments“ eines Job-Datensatzes zu finden. Beispiele TechnikProduktmanagementVertriebMarketing
	Angebotsstatus OfferStatus	Aktueller Status eines Stellenangebots, das einer kandidierenden Person unterbreitet wurde.
Beschreibung Dieses Attribut erfasst den Status eines Stellenangebots, zum Beispiel „Erstellt“, „Unterbreitet“, „Angenommen“ oder „Abgelehnt“. Es ist ein wichtiger Indikator für die letzten Phasen des Recruiting-Prozesses. Dieses Attribut ist für das Dashboard „Trends bei der Angebotsannahmequote“ und die zugehörige Kennzahl unerlässlich. Wenn Unternehmen den Verlauf von „Angebot unterbreitet“ bis „Angebot angenommen“ oder „Angebot abgelehnt“ nachverfolgen, können sie messen, wie gut es ihnen gelingt, Bewerbungen erfolgreich abzuschließen. Eine Auswertung nach Abteilung oder Stellenbezeichnung kann Erkenntnisse zur Wettbewerbsfähigkeit der Vergütung, zur Erfahrung der kandidierenden Personen und zu weiteren Einflussfaktoren auf deren Entscheidung liefern. Warum das wichtig ist Erfasst das Ergebnis von Stellenangeboten. Das ist entscheidend für die Berechnung der Kennzahl zur Angebotsannahmequote und dafür, Verbesserungsmöglichkeiten zu erkennen. Woher beziehen Im Offer-Objekt in Greenhouse verfügbar, das mit einer Bewerbung verknüpft ist. Das Feld „status“ enthält diese Information. Beispiele AngenommenAbgelehntVersendetErstellt
	Bewerbungsquelle ApplicationSource	Kanal, über den die Bewerbung der kandidierenden Person eingegangen ist.
Beschreibung Dieses Attribut erfasst die Herkunft einer Stellenbewerbung, zum Beispiel „LinkedIn“, „Empfehlung durch Mitarbeitende“, „Unternehmenswebsite“ oder „Indeed“. So lässt sich die Wirksamkeit verschiedener Recruiting-Kanäle beurteilen. Das Dashboard „Effektivität der Recruiting-Kanäle“ basiert vollständig auf diesem Attribut. Durch die Analyse von Bewerbungsvolumen, Time to Hire und Einstellungsquoten nach Quelle können Unternehmen ihren Aufwand und ihre Ausgaben für Recruiting-Marketing gezielt steuern. Die Daten helfen bei strategischen Fragen dazu, welche Kanäle am effizientesten die qualifiziertesten Bewerbungen liefern. Außerdem unterstützen sie direkt die Kennzahl „Konversionsrate der Recruiting-Kanäle“. Warum das wichtig ist Hilft dabei, Wirksamkeit und ROI verschiedener Recruiting-Kanäle zu messen und datengetriebene Entscheidungen über den Einsatz von Ressourcen für die Kandidatensuche zu treffen. Woher beziehen Im Candidate-Objekt in Greenhouse verfügbar, das mit der Bewerbung verknüpft ist. Das Feld „source“ enthält diese Information. Beispiele LinkedInEmpfehlung durch MitarbeitendeKarriereseite des UnternehmensIndeed
	Bewerbungsstatus ApplicationStatus	Endergebnis oder aktueller Status der Stellenbewerbung.
Beschreibung Dieses Attribut gibt den Status einer Bewerbung an, zum Beispiel „Eingestellt“, „Abgelehnt“ oder „Aktiv“. Es bezeichnet den Endstatus eines abgeschlossenen Prozesses oder den aktuellen Status eines laufenden Prozesses. Für die Ergebnisanalyse ist dieses Attribut eine zentrale Dimension. Damit können Sie Cases filtern und die Prozessabläufe eingestellter und abgelehnter Personen vergleichen. So werden Merkmale erfolgreicher Bewerbungen sichtbar. Außerdem dient das Attribut zur Berechnung der Konversionsraten im Dashboard „Recruiting-Gesamtprozess“ und zeigt, welcher Anteil der Bewerbungen zu einer Einstellung führt. Warum das wichtig ist Gibt das Ergebnis des Recruiting-Prozesses an und ermöglicht den Vergleich erfolgreicher (eingestellter) und erfolgloser (abgelehnter) Bewerbungen. Woher beziehen Diese Information ist im Application-Objekt in Greenhouse über das API-Feld „status“ verfügbar. Beispiele EingestelltAbgelehntAktiv
	Name der Recruiterin oder des Recruiters RecruiterName	Name der Recruiterin oder des Recruiters, die oder der für die Stellenbewerbung zuständig ist.
Beschreibung Dieses Attribut gibt an, welche Recruiterin oder welcher Recruiter einer bestimmten Stellenbewerbung oder Personalanforderung zugeordnet ist. Diese Person ist in der Regel für die Vorauswahl, die Koordination von Gesprächen und den weiteren Ablauf der Bewerbung zuständig. Die Analyse nach Recruiterin oder Recruiter ist wichtig, um individuelle Leistung und Arbeitsauslastung zu verstehen. Das Dashboard „Arbeitsauslastung und Effizienz im Recruiting“ verwendet dieses Attribut, um Kennzahlen wie Durchsatz und Zykluszeiten pro Recruiterin oder Recruiter zu berechnen. So lassen sich besonders leistungsstarke Mitarbeitende erkennen, Unterstützungsbedarf feststellen und die Arbeitslast im Recruiting-Team ausgewogen verteilen. Warum das wichtig ist Ordnet Prozessaktivitäten einer bestimmten Recruiterin oder einem bestimmten Recruiter zu und ermöglicht so die Analyse von individueller Leistung, Arbeitsauslastung und Effizienz. Woher beziehen Im Job-Objekt in Greenhouse verfügbar, in der Regel im Abschnitt „hiring_team“, in dem Rollen wie „Recruiter“ angegeben sind. Beispiele Alice JohnsonRobert DavisMaria Garcia
	Stellenbezeichnung JobTitle	Bezeichnung der Stelle, auf die sich die kandidierende Person beworben hat.
Beschreibung Dieses Attribut enthält die offizielle Bezeichnung der Personalanforderung, zum Beispiel „Senior Software Engineer“ oder „Produktmarketing-Manager“. Es liefert wichtige Informationen zur zu besetzenden Stelle. Die Analyse des Recruiting-Prozesses nach Stellenbezeichnung ist wichtig, um rollenspezifische Herausforderungen zu verstehen. Das Dashboard „Leistung bei der Time to Hire“ zeigt beispielsweise anhand dieses Attributs, ob die Besetzung von Führungspositionen oder hoch spezialisierten Stellen länger dauert. Außerdem lassen sich Angebotsannahmequoten für verschiedene Stellen analysieren. Das gibt Aufschluss über die Wettbewerbsfähigkeit der Vergütung und die Attraktivität der jeweiligen Rolle. Warum das wichtig ist Ermöglicht das Filtern und Vergleichen von Recruiting-Kennzahlen für bestimmte Stellen. So lässt sich nachvollziehen, wie die Prozessleistung je nach Komplexität oder Art der Stelle variiert. Woher beziehen Ein zentrales Feld im Job-Objekt in Greenhouse, das bei API-Abfragen des Endpunkts „jobs“ häufig als „name“ verfügbar ist. Beispiele Senior Software EngineerAccount ExecutiveUX/UI-Designer
	Ablehnungsgrund RejectionReason	Grund für die Ablehnung der Bewerbung einer kandidierenden Person.
Beschreibung Dieses Attribut erfasst den konkreten Grund, warum eine kandidierende Person im Prozess nicht weiter berücksichtigt wurde. Beispiele sind „Passt nicht zur Unternehmenskultur“, „Gehaltsvorstellungen zu hoch“ oder „Qualifiziertere Person ausgewählt“. Die Analyse von Ablehnungsgründen liefert wertvolle Hinweise zur Verbesserung des Recruiting-Prozesses. Sie kann auf Probleme wie unpassende Stellenbeschreibungen, nicht wettbewerbsfähige Vergütung oder wiederkehrende Qualifikationslücken im Bewerberpool hinweisen. Diese Informationen helfen besonders dabei, die Strategien zur Kandidatensuche zu verbessern und die Erfahrung der kandidierenden Personen zu optimieren, indem häufige Abbruchpunkte im Recruiting-Prozess sichtbar werden. Warum das wichtig ist Liefert qualitative Erkenntnisse dazu, warum Bewerbungen im Recruiting-Prozess nicht weiterverfolgt werden. So lassen sich Stellenbeschreibungen, Kandidatensuche und Auswahlkriterien verbessern. Woher beziehen Bei abgelehnten Bewerbungen im Application-Objekt verfügbar. Die API stellt ein Objekt „rejection_reason“ mit weiteren Angaben bereit. Beispiele Erforderliche Kompetenzen fehltenGehaltsvorstellungen zu hochQualifiziertere Person ausgewählt
	Automatisiert IsAutomated	Kennzeichnet, ob eine Aktivität automatisch vom System ausgeführt wurde.
Beschreibung Dieses boolesche Attribut gibt an, ob eine Aktivität von einem Benutzer oder durch eine automatisierte Systemregel ausgeführt wurde. Automatisierte Aktivitäten können beispielsweise automatische Antwort-E-Mails oder die automatische Ablehnung von Bewerbungen sein, wenn eine grundlegende Screening-Frage nicht bestanden wurde. Die Analyse dieses Attributs zeigt, wie stark der Recruiting-Prozess automatisiert ist. Damit können Sie Effizienz und Ergebnisse automatisierter und manueller Schritte vergleichen und weitere Automatisierungsmöglichkeiten erkennen, um Geschwindigkeit und Einheitlichkeit zu verbessern. Warum das wichtig ist Unterscheidet manuelle von automatisierten Aktivitäten und ermöglicht so die Analyse, wie sich Automatisierung auf Prozesseffizienz und Ergebnisse auswirkt. Woher beziehen Diese Information ist kein Standardfeld und muss in der Regel abgeleitet werden. Sie lässt sich beispielsweise anhand des einer Aktivität zugeordneten Benutzers (etwa eines „System“-Benutzers) oder anhand bestimmter bekanntermaßen automatisierter Ereignistypen ermitteln. Beispiele truefalse
	Bearbeitungszeit für Gesprächsrückmeldungen InterviewFeedbackTurnaroundTime	Zeit zwischen dem Abschluss eines Gesprächs und der Abgabe der Rückmeldung durch die interviewende Person.
Beschreibung Diese berechnete Kennzahl misst, wie schnell das Gesprächsteam Rückmeldungen abgibt. Verzögerungen bei der Rückmeldung können den Einstellungsprozess erheblich verlangsamen und die Erfahrung der kandidierenden Personen beeinträchtigen. Dieses Attribut unterstützt direkt das Dashboard „Analyse des Rückmeldungsprozesses nach Gesprächen“ und die Kennzahl „Bearbeitungszeit für Gesprächsrückmeldungen“. Berechnet wird sie als Zeitdifferenz zwischen den Aktivitäten „Gespräch abgeschlossen“ und „Rückmeldung eingereicht“. Die Überwachung dieser Kennzahl hilft dabei, durch langsame Rückmeldungen verursachte Engpässe zu erkennen und schnellere Entscheidungen zu fördern. Warum das wichtig ist Misst die Effizienz des Rückmeldungsprozesses nach Gesprächen, der im Einstellungsprozess häufig zu Verzögerungen führt. Woher beziehen Dies ist ein berechnetes Feld. Es ergibt sich aus der Differenz zwischen dem Timestamp des Ereignisses „Gespräch abgeschlossen“ und dem Timestamp des Ereignisses „Rückmeldung eingereicht“. Beispiele 86400172800259200
	Empfehlung im Bewertungsbogen ScorecardOverallRecommendation	Gesamtempfehlung zur Einstellung aus einem ausgefüllten Gesprächsbewertungsbogen.
Beschreibung Dieses Attribut erfasst die abschließende Empfehlung einer interviewenden Person in einem strukturierten Gesprächsbewertungsbogen. Typische Werte sind „Eindeutig ja“, „Ja“, „Nein“ oder „Eindeutig nein“. Diese Daten sind wichtig, um Qualität und Einheitlichkeit des Gesprächsprozesses zu bewerten. Sie helfen dabei, Rückmeldungen aus Gesprächen mit tatsächlichen Einstellungsentscheidungen abzugleichen und Fragen zu beantworten wie: „Werden Personen mit besseren Empfehlungen häufiger eingestellt?“ Außerdem bilden sie die Grundlage für die Kennzahl „Ausfüllquote der Bewertungsbögen“, die zeigt, wie konsequent strukturierte Einstellungsverfahren im Unternehmen eingesetzt werden. Warum das wichtig ist Verknüpft strukturierte Rückmeldungen aus Gesprächen mit den Prozessergebnissen und hilft dabei, den Einsatz datengetriebener Einstellungsverfahren zu messen. Woher beziehen Im Scorecard-Objekt zu einem abgeschlossenen Gespräch in Greenhouse zu finden. Die API stellt diese Information über den Endpunkt „scorecards“ bereit. Beispiele Eindeutig neinNeinJaEindeutig ja
	Endzeit der Aktivität ActivityEndTime	Timestamp, der angibt, wann eine Aktivität mit bestimmter Dauer abgeschlossen wurde.
Beschreibung Dieses Attribut erfasst den Abschlusszeitpunkt von Aktivitäten, die sich über einen Zeitraum erstrecken, etwa ein Gespräch oder eine Hintergrundüberprüfung. Viele Aktivitäten finden unmittelbar statt. Bei Aktivitäten mit messbarer Dauer ist es jedoch sinnvoll, sowohl Start- als auch Endzeit zu erfassen. Eine Endzeit ist wichtig, um die Bearbeitungszeit oder Dauer bestimmter Aktivitäten genau zu berechnen. So lässt sich die Wartezeit zwischen Schritten von der tatsächlich für eine Aufgabe aufgewendeten Zeit unterscheiden. Beispielsweise können Sie genauer analysieren, wie lange Gespräche tatsächlich dauern und wie viel Zeit für ihre Planung benötigt wird. Warum das wichtig ist Ermöglicht die genaue Berechnung der Bearbeitungszeiten von Aktivitäten. So lässt sich aktive Arbeitszeit von Wartezeit im Prozess unterscheiden. Woher beziehen Diese Information ist möglicherweise in Objekten wie „scheduled_interview“ in Greenhouse verfügbar, die häufig sowohl eine „start“- als auch eine „end“-Zeit enthalten. Bei anderen Aktivitäten muss sie eventuell anhand des Timestamps der nachfolgenden Aktivität abgeleitet werden. Beispiele 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	Gesprächsphase InterviewStageName	Konkrete Bezeichnung oder Art der Gesprächsphase.
Beschreibung Dieses Attribut gibt die jeweilige Phase im gesamten Gesprächsprozess an, zum Beispiel „Screening durch Recruiterin oder Recruiter“, „Technisches Gespräch“ oder „Abschlussrunde“. Es bietet mehr Details als eine allgemeine Aktivität wie „Gespräch abgeschlossen“. Durch die Analyse von Kennzahlen für jede einzelne Gesprächsphase können Unternehmen gezieltere Engpässe erkennen. So lässt sich beispielsweise die „Abbruchquote kandidierender Personen nach Phase“ genau messen und feststellen, ob Personen eher nach dem technischen Gespräch oder nach dem ersten Screening abspringen. Diese Details sind wichtig, um gezielte Verbesserungen am Gesprächsprozess vorzunehmen. Warum das wichtig ist Ermöglicht eine detailliertere Analyse des Gesprächsprozesses und zeigt Zykluszeiten sowie Abbruchquoten für jeden einzelnen Gesprächsschritt. Woher beziehen Diese Information ist in den Daten zur Gesprächsplanung in Greenhouse enthalten. Das Objekt „interviews“ einer Stellenbewerbung enthält Angaben zur Gesprächsphase. Beispiele Screening durch Recruiterin oder RecruiterGespräch mit der einstellenden FührungskraftTechnische PrüfungAbschlussrunde vor Ort
	ID der kandidierenden Person CandidateId	Eindeutige Kennung der kandidierenden Person, unabhängig von einer einzelnen Bewerbung.
Beschreibung Die ID der kandidierenden Person identifiziert eine Person im Bewerberpool eindeutig. Die ID der Stellenbewerbung bezieht sich dagegen auf eine einzelne Bewerbung für eine bestimmte Stelle. Eine Person kann sich im Laufe der Zeit auf mehrere Stellen bewerben. Die ID der Stellenbewerbung dient in dieser Prozessansicht als Case-ID. Mit der ID der kandidierenden Person ist jedoch eine andere Art der Analyse möglich. Sie können damit den Weg einer Person über mehrere Bewerbungen hinweg nachverfolgen, häufige Bewerbungen erkennen und die gesamte Beziehung zum Bewerberpool analysieren. So erhalten Sie eine stärker auf einzelne Personen ausgerichtete Sicht auf die Recruiting-Daten. Warum das wichtig ist Ermöglicht die Analyse mehrerer Bewerbungen derselben Person und bietet einen umfassenderen Einblick in deren Interaktion mit dem Unternehmen im Zeitverlauf. Woher beziehen Dies ist der Primärschlüssel eines Kandidatendatensatzes in Greenhouse. Über die API ist er als „id“ im Candidate-Objekt verfügbar. Beispiele 123456123457123458
	Job-ID JobId	Eindeutige Kennung der Personalanforderung oder Stellenausschreibung.
Beschreibung Dieses Attribut ist die eindeutige ID der Stelle selbst und unterscheidet sich von der Bewerbungs-ID. Mehrere Bewerbungen können derselben Job-ID zugeordnet sein. Mit der Job-ID lassen sich Daten auf Ebene der Personalanforderung zusammenfassen. So können Sie beispielsweise die Gesamtzahl der Bewerbungen für eine bestimmte Stelle oder die durchschnittliche Time to Hire für alle Stellen eines ähnlichen Typs analysieren. Dadurch lassen sich Recruiting-Aktivitäten einer einzelnen offenen Stelle zuordnen und gemeinsam auswerten. Warum das wichtig ist Fasst alle Kandidatendaten zu einer einzelnen Stellenausschreibung zusammen und analysiert sie. So erhalten Sie eine auf die Stellenausschreibung ausgerichtete Sicht. Woher beziehen Dies ist der Primärschlüssel eines Stellendatensatzes in Greenhouse. Über die API ist er im Job-Objekt als 'id' verfügbar. Beispiele 400123400124400125
	Konform IsCompliant	Berechnete Kennzeichnung dafür, ob die Bewerbung dem festgelegten Standardprozess für Einstellungen folgte.
Beschreibung Dieses boolesche Attribut ergibt sich aus einer Konformitätsprüfung. Dabei wird die tatsächliche Abfolge der Aktivitäten einer Stellenbewerbung mit einem vorab festgelegten Sollprozess verglichen. Es kennzeichnet Cases mit Abweichungen, etwa wenn erforderliche Schritte ausgelassen oder Aktivitäten in der falschen Reihenfolge ausgeführt werden. Dieses zentrale Attribut wird im Dashboard „Abweichungen von der Compliance im Einstellungsprozess“ verwendet und unterstützt die Kennzahlen „Konformitätsrate des Prozesses“ und „Anzahl der Compliance-Verstöße“. Wenn Unternehmen nach nicht konformen Cases filtern, können sie untersuchen, ob Abweichungen durch unzureichende Schulungen, Systembeschränkungen oder notwendige Ausnahmen entstehen. So lassen sich Workflows standardisieren und Compliance-Risiken verringern. Warum das wichtig ist Erkennt Prozessabweichungen und ist damit entscheidend, um die Konformität des Prozesses zu messen, Compliance sicherzustellen und Einstellungs-Workflows zu standardisieren. Woher beziehen Dies ist ein berechnetes Feld, das von der Process-Mining-Software erzeugt wird. Dabei werden die Daten im Event Log mit einem festgelegten Sollmodell oder einer Reihe von Geschäftsregeln verglichen. Beispiele truefalse
	Name der einstellenden Führungskraft HiringManagerName	Name der einstellenden Führungskraft für die zugehörige Personalanforderung.
Beschreibung Dieses Attribut gibt die Führungskraft des Teams mit der offenen Stelle an. Die einstellende Führungskraft ist eine wichtige beteiligte Person im Prozess. Sie prüft häufig Bewerbungen, führt Gespräche in späteren Phasen und trifft die endgültige Einstellungsentscheidung. Die Analyse des Prozesses nach einstellender Führungskraft kann wichtige Muster und Engpässe aufzeigen. Das Dashboard „Engpässe bei der Gesprächsplanung“ könnte beispielsweise zeigen, dass Verzögerungen häufig mit der Verfügbarkeit bestimmter Führungskräfte zusammenhängen. So lässt sich feststellen, ob Schulungen oder Unterstützung erforderlich sind, damit Führungskräfte den Einstellungsprozess effizient begleiten können. Warum das wichtig ist Gibt eine wichtige beteiligte Person an und ermöglicht die Analyse von Engpässen und Effizienz im Prozess, die mit bestimmten einstellenden Führungskräften zusammenhängen. Woher beziehen Im Job-Objekt in Greenhouse verfügbar, in der Regel im Abschnitt „hiring_team“, in dem Rollen wie „Hiring Manager“ angegeben sind. Beispiele Emily TranDavid ChenSophia Rodriguez

Erforderlich Empfohlen Optional

Aktivitäten im Recruiting und bei der Talentgewinnung

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um Ihren Recruiting-Prozess präzise zu entdecken und zu optimieren.

7 Empfohlen 7 Optional

	Aktivität	Beschreibung
	Angebot angenommen	Der Bewerber hat das Stellenangebot offiziell angenommen. Dies ist ein wichtiger Erfolg und löst üblicherweise weitere Aktivitäten vor dem Arbeitsbeginn aus, etwa Hintergrundprüfungen.
Warum das wichtig ist Dies ist ein wichtiger Erfolgsmeilenstein und ein zentraler Bestandteil der KPI zur Annahmequote von Angeboten. Er markiert den Übergang vom Bewerber zum künftigen Mitarbeitenden. Woher beziehen Dieses Ereignis wird ausdrücklich erfasst, wenn der Angebotsstatus in Greenhouse von der Recruiterin oder dem Recruiter auf „Angenommen“ gesetzt wird oder die kandidierende Person das Angebot elektronisch annimmt. Erfassung Erfasst anhand des Timestamps, zu dem der Angebotsstatus auf „Angenommen“ geändert wird. Ereignistyp explicit
	Angebot unterbreitet	Das offizielle Stellenangebot wurde an den Bewerber gesendet. Dies ist ein wichtiger Meilenstein und der Abschluss des Interview- und Auswahlverfahrens.
Warum das wichtig ist Diese Aktivität bildet die Grundlage für die Berechnung der KPI zur Annahmequote von Angeboten. Sie markiert den Beginn der abschließenden Entscheidungsphase für den Bewerber. Woher beziehen Greenhouse protokolliert dieses Ereignis ausdrücklich, wenn der Angebotsstatus zu „Sent“ oder „Extended“ geändert wird. Das Angebotsobjekt enthält Timestamps für diese Statusänderungen. Erfassung Erfasst anhand des Timestamps, zu dem das Angebot offiziell als versendet markiert wird. Ereignistyp explicit
	Bewerbung abgelehnt	Die Bewerbung der kandidierenden Person wurde im Laufe des Prozesses abgelehnt. Dies ist das häufigste erfolglose Endereignis und kann in jeder Phase auftreten.
Warum das wichtig ist Dieses Endereignis ist entscheidend für die Analyse der Abbruchquoten im Recruiting-Prozess. Wenn Sie nachvollziehen, wann und warum Bewerbungen abgelehnt werden, können Sie Ineffizienzen im Prozess oder unpassende Stellenanforderungen erkennen. Woher beziehen Dieses Ereignis wird ausdrücklich erfasst, wenn ein Benutzer die Bewerbung in Greenhouse ablehnt. Häufig wird auch ein Ablehnungsgrund angegeben; das Aktivitätsprotokoll enthält den Timestamp. Erfassung Erfasst anhand des Timestamps der Ablehnung der Bewerbung. Ereignistyp explicit
	Bewerbung eingegangen	Diese Aktivität markiert den Beginn des Recruiting-Prozesses für eine bestimmte Bewerbung. Sie wird erfasst, wenn ein Bewerber seine Bewerbung über eine Karriereseite oder einen Suchkanal einreicht oder manuell in Greenhouse angelegt wird.
Warum das wichtig ist Dies ist das primäre Start-Event des Prozesses. Die Zeitspanne von dieser Aktivität bis zu anderen Aktivitäten ist entscheidend, um die Time-to-Hire und die Wirksamkeit der Suchkanäle zu messen. Woher beziehen Greenhouse protokolliert dieses Ereignis ausdrücklich, wenn eine Bewerbung angelegt wird. Als Ereigniszeit dient das Feld „Application Date“ oder der Erstellungs-Timestamp des Bewerbungsobjekts. Erfassung Erfasst anhand des Erstellungs-Timestamps des Bewerbungseintrags. Ereignistyp explicit
	Interview geführt	Ein Interview mit dem Bewerber hat stattgefunden. Dies wird häufig daraus abgeleitet, dass der geplante Interviewtermin verstrichen ist. Zuverlässiger ist der Zeitpunkt, zu dem Feedback zu diesem Interview eingereicht wird.
Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein im Bewerbungsprozess. Sie bildet den Ausgangspunkt, um die Zeit bis zur Abgabe des Feedbacks und den Übergang zur nächsten Phase zu messen. Woher beziehen Üblicherweise abgeleitet. Als Grundlage kann das geplante Ende des Interviews dienen. Genauer ist der Timestamp des ersten Feedbacks, das zu diesem Interview eingereicht wurde. Erfassung Abgeleitet aus dem geplanten Ende des Interviews oder dem Timestamp der anschließenden Feedbackabgabe. Ereignistyp inferred
	Interview geplant	Ein Interview mit dem Bewerber wurde im System geplant. Greenhouse lässt sich in Kalender integrieren. Daher wird dieses Ereignis üblicherweise ausdrücklich protokolliert, sobald ein Interview bestätigt ist.
Warum das wichtig ist Dieses Ereignis ist entscheidend, um Engpässe bei der Interviewplanung zu analysieren und zu erkennen. Die Zeit zwischen diesem und dem vorherigen Schritt ist eine wichtige KPI für die Effizienz von Recruitern und Koordinatoren. Woher beziehen Erfasst über die Interviewplanungsfunktion in Greenhouse. Die API liefert Daten zu geplanten Interviews, einschließlich ihres Erstellungs-Timestamps. Erfassung Protokolliert, wenn ein Interviewtermin angelegt und mit der Bewerbung des Kandidaten verknüpft wird. Ereignistyp explicit
	Kandidierende Person eingestellt	Die kandidierende Person hat alle Prüfungen vor der Einstellung erfolgreich abgeschlossen und wurde offiziell als eingestellt gekennzeichnet. Damit ist der Bewerbungsprozess erfolgreich abgeschlossen und beendet.
Warum das wichtig ist Dies ist das wichtigste Erfolgsergebnis des Prozesses. Die Zeit zwischen „Bewerbung eingegangen“ und diesem Ereignis entspricht der gesamten Time to Hire, einer zentralen Recruiting-Kennzahl. Woher beziehen In Greenhouse kennzeichnet die Recruiterin oder der Recruiter die kandidierende Person mit dieser ausdrücklichen Aktion für eine bestimmte Stelle als eingestellt. Dadurch wechselt ihr Status von aktiv zu eingestellt. Erfassung Erfasst anhand des Timestamps der Aktion „Als eingestellt kennzeichnen“ in Greenhouse. Ereignistyp explicit
	Angebot abgelehnt	Die kandidierende Person hat das Stellenangebot offiziell abgelehnt. Dieses erfolglose Endereignis tritt spät im Recruiting-Prozess auf.
Warum das wichtig ist Dieses Ergebnis nachzuverfolgen ist entscheidend für die Analyse der Angebotsannahmequote. Tritt dieses Ereignis häufig auf, kann das auf Probleme bei der Vergütung, der Unternehmenskultur oder der Stelle selbst hindeuten. Woher beziehen Dieses Ereignis wird ausdrücklich erfasst, wenn der Angebotsstatus in Greenhouse auf „Abgelehnt“ oder „Nicht angenommen“ gesetzt wird. Das Angebotsobjekt enthält einen Timestamp für diese Statusänderung. Erfassung Erfasst anhand des Timestamps, zu dem sich der Angebotsstatus in „Abgelehnt“ ändert. Ereignistyp explicit
	Angebot erstellt	Ein offizielles Stellenangebot wurde erstellt und wartet möglicherweise noch auf die interne Freigabe. Damit wird die formelle Entscheidung festgehalten, dem Bewerber ein Angebot zu unterbreiten.
Warum das wichtig ist Diese Aktivität unterscheidet die Entscheidung, ein Angebot zu machen, von dessen Unterbreitung. So lassen sich interne Freigabezeiten und Engpässe analysieren, bevor das Angebot den Bewerber erreicht. Woher beziehen Greenhouse verfügt über ein eigenes Angebotsmodul. Dieses Ereignis wird ausdrücklich anhand des Erstellungs-Timestamps des Angebotsobjekts erfasst, das mit der Bewerbung verknüpft ist. Erfassung Wird protokolliert, sobald im Greenhouse-System ein Angebotseintrag erstellt wird. Ereignistyp explicit
	Bewerbung geprüft	Ein Recruiter oder eine einstellende Führungskraft hat die Bewerbung des Kandidaten erstmals geprüft. Dies lässt sich üblicherweise daran erkennen, dass sich die Phase oder der Status der Bewerbung von „New“ zu einer aktiven Prüfphase wie „In Review“ ändert.
Warum das wichtig ist Die Erfassung dieser Aktivität hilft, Engpässe bei der ersten Vorauswahl zu erkennen und zu messen, wie lange neue Bewerbungen auf eine Prüfung warten. Sie ist außerdem der Ausgangspunkt für die Berechnung der Zykluszeit bis zur Interviewplanung. Woher beziehen Abgeleitet aus einer Änderung des Bewerbungsstatus. Suchen Sie nach Statusänderungen von „New“ zu „Review“ und verwenden Sie den Timestamp der Änderung. Erfassung Abgeleitet aus dem Timestamp einer Statusänderung zu „In Review“ oder einer vergleichbaren Phase. Ereignistyp inferred
	Erstes Gespräch mit Recruiter geführt	Ein Recruiter hat ein erstes Telefongespräch oder ein anderes Erstgespräch mit dem Bewerber geführt. Diese Aktivität wird häufig erfasst, wenn der Bewerber im Recruiting-Prozess in die Phase „Phone Screen“ verschoben wird.
Warum das wichtig ist Dieser wichtige Qualifizierungsschritt zeigt, dass die Bewerbung die erste Prüfung der Unterlagen bestanden hat. Er hilft, die Arbeitslast der Recruiter und die Wirksamkeit der ersten Vorauswahl zu messen. Woher beziehen Abgeleitet aus dem Timestamp, zu dem die Bewerbung im Greenhouse-Recruiting-Prozess in die Phase „Phone Screen“ verschoben wird oder diese Phase verlässt. Erfassung Abgeleitet aus dem Phasenverlauf der Bewerbung, insbesondere anhand des Eintritts in die Phase „Phone Screen“. Ereignistyp inferred
	Feedback eingereicht	Ein Interviewer hat seine Scorecard oder sein Feedback zum Interview mit einem Bewerber eingereicht. Der strukturierte Einstellungsprozess von Greenhouse stützt sich bei Entscheidungen auf diese Angaben. Daher wird die Abgabe als einzelner Vorgang protokolliert.
Warum das wichtig ist Zeitnahes Feedback ist entscheidend, damit Bewerber im Prozess weiterkommen. Anhand dieser Aktivität lassen sich die Effizienz des Feedbackprozesses und die Abschlussquote für Scorecards analysieren. Woher beziehen Greenhouse protokolliert dieses Ereignis ausdrücklich, wenn ein Interviewer eine Scorecard einreicht. Das Scorecards-API-Objekt enthält einen `submitted_at`-Timestamp. Erfassung Erfasst anhand des Einreichungs-Timestamps einer Interview-Scorecard. Ereignistyp explicit
	Hintergrundüberprüfung eingeleitet	Für die kandidierende Person wurde eine Hintergrundüberprüfung gestartet, in der Regel nach Annahme des Angebots. Dies wird möglicherweise als Änderung einer bestimmten Phase oder als Integrationsauslöser für einen Drittanbieterdienst erfasst.
Warum das wichtig ist Diese Aktivität ist wichtig für die Compliance und um Verzögerungen bei Überprüfungen vor der Einstellung nachzuverfolgen. Sie hilft dabei, die Zeit zwischen der Angebotsannahme und dem Abschluss der erforderlichen Überprüfungen zu analysieren. Woher beziehen Wahrscheinlich wird dieses Ereignis daraus abgeleitet, dass die kandidierende Person in der Bewerbungspipeline in die Phase „Hintergrundüberprüfung“ verschoben wird, oder aus einem Aktivitätsprotokoll zu einer Integration für Hintergrundüberprüfungen. Erfassung Abgeleitet aus einer Statusänderung zur Phase „Hintergrundüberprüfung“ oder aus einem API-Protokoll eines integrierten Dienstes. Ereignistyp inferred
	Onboarding eingeleitet	Das Onboarding der neuen Mitarbeiterin oder des neuen Mitarbeiters im Unternehmen hat offiziell begonnen. Häufig werden die Daten dafür vom Recruiting-System an ein HRIS oder eine Onboarding-Plattform übergeben.
Warum das wichtig ist Damit lässt sich die Effizienz der Übergabe vom Recruiting an die Personalabteilung nachverfolgen. Verzögerungen können die Erfahrung neuer Mitarbeitender beeinträchtigen. Deshalb ist es wichtig, die Übergabezeit zum Onboarding zu überwachen. Woher beziehen Wenn Greenhouse in ein Onboarding-System integriert ist, wird dieses Ereignis möglicherweise ausdrücklich erfasst. Andernfalls wird es anhand des Timestamps abgeleitet, zu dem die kandidierende Person in die abschließende Phase „Eingestellt“ verschoben wird und dadurch die Übergabe ausgelöst wird. Erfassung Abgeleitet aus einer Phasenänderung oder einem Integrationsprotokoll, das die Übergabe an ein HRIS dokumentiert. Ereignistyp inferred

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Greenhouse

Schritte

Melden Sie sich bei Ihrem Greenhouse-Recruiting-Konto an.
Öffnen Sie den Bereich „Reports“, indem Sie in der Hauptnavigation auf das Reports-Symbol (ein Balkendiagramm) klicken.
Suchen Sie im Reports-Dashboard nach „Essential Reports“ und öffnen Sie den Bereich. Ein wichtiger Bericht für diesen Export ist „All Applications“. Er bietet einen umfassenden Überblick über Bewerbungen und die zugehörigen Meilensteine.
Richten Sie den Bericht „All Applications“ ein. Klicken Sie auf „Columns“ und wählen Sie alle Spalten aus, die Sie für die erforderlichen Attribute und Aktivitäts-Timestamps benötigen. Nehmen Sie mindestens folgende Spalten auf: Application ID, Candidate, Job, Department, Recruiter, Status, Source, Applied On, Rejected On, Hired On, Last Stage Change On, Offer Created On, Offer Accepted On und Offer Status.
Für Aktivitäten rund um Vorstellungsgespräche benötigen Sie einen separaten Bericht. Gehen Sie zurück zu „Essential Reports“ und wählen Sie „Interview Details“ aus.
Richten Sie den Bericht „Interview Details“ ein. Wählen Sie im Bereich „Columns“ mindestens folgende Spalten aus: Application ID, Interview Name, Scheduled Start und Scorecard Submitted At. Damit erhalten Sie die Zeitstempel für die Terminplanung und die Übermittlung des Feedbacks.
Legen Sie für beide Berichte mithilfe der Filter den passenden Zeitraum fest. Häufig wird „Applied On“ auf „All Time“ oder einen bestimmten Zeitraum, etwa die letzten 6 Monate, gesetzt, damit eine relevante Gruppe von Bewerbungen erfasst wird.
Erstellen Sie die Berichte, indem Sie auf „Update“ oder „Generate“ klicken. Sobald ein Bericht angezeigt wird, klicken Sie auf „Export to Excel“, um die Daten als CSV-Datei herunterzuladen. Anschließend liegen Ihnen zwei separate CSV-Dateien vor.
Die exportierten Dateien liegen noch nicht im Event-Log-Format vor. Sie müssen sie mit einem Tool wie Python oder R oder mit einer Tabellenkalkulation mit Entpivotierungsfunktion, etwa Power Query in Microsoft Excel, umwandeln.
Führen Sie die Daten aus den Berichten „All Applications“ und „Interview Details“ anhand der Application ID zusammen.
Erstellen Sie für jede Bewerbung eine eigene Zeile für jede relevante Datumsspalte, die Sie exportiert haben. Der Wert in der Spalte „Applied On“ wird beispielsweise zum Wert für „ActivityTimestamp“ der Aktivität „Application Received“. Der Wert in „Rejected On“ erzeugt die Aktivität „Application Rejected“. Gehen Sie für alle 14 erforderlichen Aktivitäten entsprechend vor. Verwenden Sie die Spalte „Last Stage Change On“, um Aktivitäten wie „Application Reviewed“ oder „Recruiter Screen Conducted“ abzuleiten, wenn keine eigenen Zeitstempel verfügbar sind.
Strukturieren Sie die umgewandelte Datei mit den erforderlichen Spalten: JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate sowie den empfohlenen Attributen. Speichern Sie die fertige Datei als einzelne CSV-Datei, die Sie hochladen können.

Konfiguration

Primäre Berichte: Für die Extraktion werden Daten aus mehreren Berichten im Bereich „Essential Reports“ von Greenhouse zusammengeführt, vor allem aus „All Applications“ und „Interview Details“.
Wichtige Spalten (All Applications): Wählen Sie alle erforderlichen Spalten aus, darunter Application ID, Candidate, Job, Department, Recruiter, Status, Source, Offer Status sowie alle relevanten Datumsspalten wie Applied On, Rejected On, Hired On, Offer Created On und Offer Accepted On.
Wichtige Spalten (Interview Details): Wählen Sie für die Erfassung von Gesprächsereignissen Spalten wie Application ID, Interview Name, Scheduled Start und Scorecard Submitted At aus.
Filter für den Zeitraum: Es empfiehlt sich, Bewerbungen anhand des Datums „Applied On“ auf einen Zeitraum von 3 bis 6 Monaten zu begrenzen. So bleibt der Datensatz überschaubar und relevant. Längere Zeiträume können die Leistung beeinträchtigen.
Voraussetzungen: Die exportierende Person benötigt in Greenhouse die Berechtigung, den Bereich „Reports“ aufzurufen und Kandidatendaten einzusehen. Dafür ist in der Regel die Rolle „Job Admin“ oder „Site Admin“ erforderlich.

a Beispielabfrage 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'

Schritte

Voraussetzungen: Greenhouse-API-Schlüssel erstellen
- Melden Sie sich mit Entwicklerberechtigungen bei Ihrem Greenhouse-Konto an.
- Öffnen Sie Configure > Dev Center > API Credential Management.
- Klicken Sie auf "Create New API Key".
- Geben Sie eine Beschreibung ein, zum Beispiel "ProcessMind Extraction".
- Wählen Sie als Typ "Harvest" aus.
- Erteilen Sie dem Schlüssel die erforderlichen Berechtigungen. Mindestens benötigen Sie GET-Berechtigungen für: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards und Users.
- Kopieren Sie den generierten API-Schlüssel und bewahren Sie ihn sicher auf. Sie können ihn später nicht erneut anzeigen.
Python-Umgebung einrichten
- Stellen Sie sicher, dass Python 3.6 oder neuer auf Ihrem System installiert ist.
- Installieren Sie die erforderlichen Python-Bibliotheken, indem Sie im Terminal folgende Befehle ausführen: pip install requests und pip install pandas.
Python-Skript vorbereiten
- Kopieren Sie das vollständige Python-Skript aus dem Abschnitt "query" in eine neue Datei, zum Beispiel extract_greenhouse_logs.py.
- Ersetzen Sie den Platzhalter YOUR_GREENHOUSE_API_KEY durch den in Schritt 1 erstellten Schlüssel.
- Passen Sie die Variable START_DATE_ISO an, um den Beginn des Extraktionszeitraums festzulegen. Für den ersten Datenabruf empfiehlt sich ein Datum 3 bis 6 Monate zurück.
Zuordnung von Phasen zu Aktivitäten anpassen
- Prüfen Sie das Dictionary STAGE_TO_ACTIVITY im Skript.
- Es ordnet die Namen der unternehmensspezifischen Recruiting-Phasen in Greenhouse den standardisierten Aktivitätsnamen für Process Mining zu.
- Sie MÜSSEN diese Zuordnung an Ihre individuelle Greenhouse-Konfiguration anpassen. Heißt Ihre Phase „Recruiter Screen“ beispielsweise „Initial Recruiter Chat“, müssen Sie das Dictionary entsprechend ändern.
Extraktionsskript ausführen
- Öffnen Sie ein Terminal oder eine Eingabeaufforderung.
- Wechseln Sie in das Verzeichnis, in dem Sie extract_greenhouse_logs.py gespeichert haben.
- Führen Sie das Skript mit folgendem Befehl aus: python extract_greenhouse_logs.py.
- Das Skript stellt eine Verbindung zur Greenhouse API her, ruft die Daten ab, verarbeitet sie und gibt Statusmeldungen in der Konsole aus.
Event Log abrufen
- Nach erfolgreicher Ausführung erstellt das Skript im selben Verzeichnis die Datei greenhouse_event_log.csv.
- Diese CSV-Datei enthält das fertige Event Log mit den erforderlichen Spalten und Aktivitäten.
Inkrementelle Ladevorgänge durchführen
- Bei späteren Ausführungen können Sie die Variable START_DATE_ISO auf den Timestamp der letzten erfolgreichen Extraktion setzen. So werden nur neue oder aktualisierte Datensätze abgerufen und der Vorgang wird beschleunigt.
In ProcessMind hochladen
- Die erstellte Datei greenhouse_event_log.csv kann direkt in ProcessMind hochgeladen werden. Achten Sie darauf, dass die Spaltennamen in der Datei den Feldern Ihres ProcessMind-Projekts korrekt zugeordnet sind.

Konfiguration

Berechtigungen für den API-Schlüssel: Der Harvest-API-Schlüssel benötigt Lesezugriff (GET) auf folgende Endpunkte: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards und Users. Bei unzureichenden Berechtigungen fehlen Daten zu bestimmten Aktivitäten.
Filter für den Zeitraum: Das Skript verwendet den Parameter updated_after (Variable START_DATE_ISO), um Bewerbungen zu filtern. Verwenden Sie für die erste Extraktion einen längeren Zeitraum, zum Beispiel die letzten 6 Monate. Setzen Sie den Wert bei späteren inkrementellen Ladevorgängen auf den Timestamp des letzten erfolgreichen Durchlaufs, um die Leistung zu verbessern.
Zuordnung von Phasen zu Aktivitäten: Das Dictionary STAGE_TO_ACTIVITY im Skript ist entscheidend. Passen Sie es an die individuellen Recruiting-Phasen Ihres Unternehmens in Greenhouse an, damit Aktivitäten wie „Recruiter Screen Conducted“ und „Background Check Initiated“ korrekt erkannt werden.
Begrenzung der API-Aufrufe: Zwischen API-Anfragen wartet das Skript eine kurze, festgelegte Zeit, um die Aufrufbegrenzungen von Greenhouse einzuhalten (etwa 20 Anfragen pro Sekunde). Bei sehr großen Datenmengen müssen Sie diese Wartezeit möglicherweise anpassen, um Verbindungsfehler zu vermeiden.
Granularität der Daten: Die Extraktion erfasst Ereignisse mit Zeitstempel und Statusänderungen. Detaillierte Inhalte wie Interviewnotizen oder E-Mail-Mitteilungen werden nicht erfasst, sondern nur Metadaten dazu, dass ein Ereignis stattgefunden hat.

a Beispielabfrage 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.")

Schritte

Prüfen Sie, ob Ihre lizenzierte ETL-Plattform einen Greenhouse-Konnektor bereitstellt und ob dieser Greenhouse-Objekte oder replizierte Datensätze zu Bewerbungen, Phasenverläufen, Vorstellungsgesprächen, Gesprächsfeedback, Angeboten, Angebotsstatusänderungen, Hintergrundüberprüfungen, Übergaben ans Onboarding und Einstellungsergebnissen unterstützt. Die Bezeichnungen der Konnektorobjekte unterscheiden sich je nach Plattform. Prüfen Sie daher den Konnektorkatalog und den Schema-Browser, statt Tabellennamen vorauszusetzen.
Richten Sie in der ETL-Plattform die Verbindung zur Greenhouse-Quelle ein. Geben Sie die Greenhouse-Zugangsdaten, Autorisierungsdetails, Replikationseinstellungen und alle für Ihre Umgebung erforderlichen unternehmensspezifischen Filter ein. Folgen Sie dem dokumentierten Autorisierungsverfahren des Konnektors und erteilen Sie nur die Berechtigungen, die zum Lesen der ausgewählten Recruiting-Daten erforderlich sind.
Konfigurieren Sie ein Ziel-Warehouse und aktivieren Sie die Replikation der Quelldaten, die für den Aufbau des Event Logs erforderlich sind. Wählen Sie mindestens die Objekte aus, die Stellenbewerbungen, Bewerbungsstatus oder Phasenverläufe, Vorstellungsgespräche, Gesprächsfeedback, Angebote, Angebotsstatusänderungen, Ereignisse zu Hintergrundüberprüfungen, Übergaben ans Onboarding und Einstellungsergebnisse enthalten. Ist ein erforderliches Objekt nicht verfügbar, dokumentieren Sie diese Einschränkung und ordnen Sie gemäß Ihrer Greenhouse-Konfiguration die nächstliegende unterstützte Quelle zu.
Legen Sie das anfängliche Replikationsfenster auf den gewünschten Analysezeitraum fest, in der Regel die vergangenen 3 bis 6 Monate. Beziehen Sie einen früheren Zeitraum ein, wenn Bewerbungen bereits vor dem ausgewählten Zeitraum angelegt wurden, aber währenddessen weiterbearbeitet wurden. Richten Sie die inkrementelle Replikation ein und übernehmen Sie, sofern verfügbar, die Zeitstempel der Quellaktualisierungen.
Prüfen Sie das replizierte Schema und ersetzen Sie in der Abfrage alle Platzhalter durch das tatsächliche Zielschema, die Tabellen- und Spaltennamen, Zeitstempelfelder, Kennungen und Statuswerte Ihres Konnektors. Gehen Sie nicht davon aus, dass Phasenänderungen, Gesprächs-, Feedback-, Angebots- oder Hintergrundüberprüfungsdatensätze, Übergaben ans Onboarding oder Einstellungsergebnisse verfügbar sind, sofern sie nicht in den replizierten Daten enthalten sind.
Richten Sie die Transformationsabfrage als Vereinigung expliziter Ereignisextraktionen ein. Jede Extraktion muss JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource und OfferStatus zurückgeben. Vereinheitlichen Sie die Zeitzonen der Zeitstempel, entfernen Sie Datensätze ohne gültige Bewerbungskennung oder Aktivitätszeitstempel und behalten Sie für jedes Quellereignis, das eine Aktivität darstellt, eine eigene Zeile bei.
Wenden Sie die Zuordnungsregeln für Aktivitäten an. Verwenden Sie Daten zur Erstellung oder Einreichung einer Bewerbung für Application Received, einen expliziten Prüfstatus oder Statusübergang für Application Reviewed, einen Recruiter-Screen-Datensatz oder einen konfigurierten Übergang zur Telefoninterview-Phase für Recruiter Screen Conducted, eine Gesprächsbestätigung oder einen geplanten Zeitstempel für Interview Scheduled, den Abschluss eines Gesprächs oder die Übermittlung von Feedback für Interview Completed, die Übermittlung von Feedback für Feedback Submitted, die Angebotserstellung für Offer Created, den Status „versendet“ oder „unterbreitet“ für Offer Extended, den Status „angenommen“ für Offer Accepted, ein erfasstes Ereignis zum Beginn einer Hintergrundüberprüfung für Background Check Initiated, eine Übergabe oder ein Ereignis zum Beginn des Onboardings für Onboarding Initiated, ein Einstellungsergebnis für Candidate Hired, ein abgelehntes Angebot für Offer Rejected und ein abgelehntes Bewerbungsergebnis oder einen Übergang in eine Ablehnungsphase für Application Rejected.
Laden Sie das transformierte Ergebnis in eine Zieltabelle oder Ansicht, die für das ProcessMind-Event-Log vorgesehen ist. Behalten Sie doppelte Quellereignisse bei, sofern keine dokumentierte Geschäftsregel sie als technische Duplikate einstuft. Wenn eine Deduplizierung erforderlich ist, entfernen Sie nur Ereignisse mit identischen Quellereignisschlüsseln, etwa Bewerbungskennung, Aktivitätsname, Aktivitätszeitstempel und Quelldatensatzkennung.
Prüfen Sie das Ergebnis anhand der folgenden Kriterien. Vergewissern Sie sich, dass alle erforderlichen Spalten vorhanden sind, die Zeitstempel gültig sind, alle erforderlichen Aktivitäten erfasst werden, sofern Quelldaten vorliegen, und die Case-ID pro Bewerbung eindeutig ist. Prüfen Sie abgelehnte, zurückgezogene, archivierte und unvollständige Bewerbungen separat, damit Filter keine gültigen Prozessergebnisse unbeabsichtigt ausschließen.
Exportieren Sie das fertige Ergebnis als flache CSV-Datei oder stellen Sie es über eine unterstützte Warehouse-Verbindung für den Upload in ProcessMind bereit. Ordnen Sie JobApplicationId der Case-ID, ActivityName der Aktivität und ActivityTimestamp dem Ereigniszeitstempel zu. Nehmen Sie SourceSystem und LastDataUpdate auf, behalten Sie die empfohlenen Attribute bei, verwenden Sie ein einheitliches Zeitstempelformat wie ISO 8601 mit Zeitzonenangabe und verlassen Sie sich nicht darauf, dass ProcessMind Ereignisse ableitet, die in der Datei fehlen.

Konfiguration

Konnektor und Ziel: Verwenden Sie eine lizenzierte ETL-Plattform mit einem unterstützten Greenhouse-Konnektor und einem Ziel-Warehouse, auf das die Transformationsebene zugreifen kann. Funktionen des Konnektors, Objektbezeichnungen, Aktualisierungsintervalle und die Unterstützung historischer Replikation hängen von der gewählten Plattform und dem Abonnement ab.
Quellautorisierung: Richten Sie die für den Konnektor erforderlichen Greenhouse-Zugangsdaten und Berechtigungen ein. Vergewissern Sie sich, dass das autorisierte Konto Bewerbungsdatensätze, Phasen- oder Statusverläufe, Gesprächsdatensätze, Feedback, Angebote sowie alle für die Zuordnung verwendeten Daten zu integrierten Hintergrundüberprüfungen oder zum Onboarding lesen kann.
Replizierte Objekte: Wählen Sie alle Quellobjekte aus, die für die 14 Ereignisextraktionen erforderlich sind. Replizieren Sie nicht nur die aktuelle Bewerbungstabelle, wenn historische Phasenänderungen, Gesprächsaktivitäten, Feedbackübermittlungen, Angebotsübergänge oder nachgelagerte Übergaben separat gespeichert sind.
Zeitraum: Beginnen Sie für die operative Analyse mit 3 bis 6 Monaten. Erweitern Sie den Zeitraum, wenn Sie den gesamten Bewerbungsverlauf messen möchten, da Bewerbungen, die vor diesem Zeitraum erstellt wurden, erst später zu Gesprächen, Angeboten oder Einstellungen führen können.
Inkrementelle Aktualisierung: Übernehmen Sie, sofern verfügbar, Erstellungs-, Ereignis- und letzte Aktualisierungszeitstempel der Quelle. Richten Sie regelmäßige Aktualisierungen entsprechend der erforderlichen Aktualität der Berichte ein und berücksichtigen Sie einen kurzen Überlappungszeitraum für verspätet eintreffende oder korrigierte Datensätze.
Filter: Verwenden Sie nur dokumentierte unternehmensspezifische Filter, etwa nach Organisation, Abteilung, Stelle, Standort oder Bewerbungsdatum. Nutzen Sie keine allgemeinen Filter wie Company Code oder Document Type, sofern diese Felder nicht tatsächlich im replizierten Greenhouse-Schema vorhanden und für Ihre Konfiguration erforderlich sind.
Aktivitätszuordnung: Dokumentieren Sie die Zuordnung von Quellereignistyp, Phase, Status oder Zeitstempel zu jedem ActivityName. Legen Sie anhand der in Ihrem Unternehmen verwendeten Werte genaue Zuordnungen für Prüfung, Telefoninterview, Ablehnung, Angebot, Annahme, Hintergrundüberprüfung, Onboarding und Einstellungsergebnisse fest.
Umgang mit Nullwerten: RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource und OfferStatus dürfen Nullwerte enthalten, wenn die Quelle keine Angaben dazu liefert. Untersuchen Sie fehlende erforderliche Kennungen und Zeitstempel oder weisen Sie die betreffenden Datensätze zurück.
Zeitzonen: Konvertieren Sie alle Aktivitätszeitstempel in eine einheitliche Berichtszeitzone. Bewahren Sie den ursprünglichen Zeitstempel der Quelle auf, wenn dies für die Auditfähigkeit erforderlich ist. Stellen Sie sicher, dass LastDataUpdate den Aktualisierungs- oder Extraktionszeitpunkt und nicht den Zeitpunkt des Ereignisses angibt.
Leistung: Filtern Sie bei großen Datensätzen die Quellabfragen anhand replizierter Zeitstempelpartitionen, wählen Sie nur erforderliche Spalten aus, verwenden Sie inkrementelle Ladevorgänge und materialisieren Sie das fertige Event Log. Vermeiden Sie wiederholte Verknüpfungen des vollständigen Verlaufs mit aktuellen Bewerbungsdatensätzen ohne indizierte Kennungen.
Datenaufbewahrung: Prüfen Sie, ob die ETL-Plattform und der Greenhouse-Zugriff historische Phasen-, Gesprächs-, Feedback-, Angebots- und Ergebnisdatensätze für den ausgewählten Zeitraum aufbewahren. Aus Tabellen mit ausschließlich aktuellem Status lassen sich historische Aktivitäten nicht zuverlässig rekonstruieren.
Zuordnung in ProcessMind: Legen Sie JobApplicationId als Case-ID, ActivityName als Aktivitätsfeld und ActivityTimestamp als Ereigniszeitstempel fest. Vergewissern Sie sich, dass die exportierte Datei für jede Aktivität eine eigene Zeile enthält und nicht auf abgeleitete Übergänge angewiesen ist.

a Beispielabfrage 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;

Möchten Sie loslegen?

Nutzen Sie das volle Potenzial Ihrer Recruiting-Daten. Verwenden Sie dieses Template noch heute, um Ihren Recruiting-Prozess zu verbessern und datengetriebene Entscheidungen zu treffen.

Zurück zum Leitfaden zur Prozessverbesserung Template herunterladen

Verbessern Sie noch heute Ihre Talentgewinnung mit Greenhouse

Verkürzen Sie Ihren Recruiting-Zyklus um 30 % und verbessern Sie noch heute die Candidate Experience.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich • Einrichtung in 5 Minuten

Ihr Daten-Template für Recruiting und Talentgewinnung

Ihr Daten-Template für Recruiting und Talentgewinnung

Attribute für Recruiting und Talentgewinnung

Aktivitäten im Recruiting und bei der Talentgewinnung

Anleitungen zur Datenextraktion

Greenhouse Report Builder für manuelle CSV-Exporte

Schritte

Konfiguration

a Beispielabfrage config

Datenextraktion mit einem Python-Skript über die Greenhouse Harvest API

Schritte

Konfiguration

a Beispielabfrage python

Automatisiertes ETL-Tool mit Greenhouse-Konnektor

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Verbessern Sie noch heute Ihre Talentgewinnung mit Greenhouse

Ihr Daten-Template für Recruiting und Talentgewinnung

Ihr Daten-Template für Recruiting und Talentgewinnung

Attribute für Recruiting und Talentgewinnung

Aktivitäten im Recruiting und bei der Talentgewinnung

Anleitungen zur Datenextraktion

Greenhouse Report Builder für manuelle CSV-Exporte

Schritte

Konfiguration

a Beispielabfrage config

Datenextraktion mit einem Python-Skript über die Greenhouse Harvest API

Schritte

Konfiguration

a Beispielabfrage python

Automatisiertes ETL-Tool mit Greenhouse-Konnektor

Schritte

Konfiguration

a Beispielabfrage config

Möchten Sie loslegen?

Verbessern Sie noch heute Ihre Talentgewinnung mit Greenhouse

Der Schutz Ihrer Daten ist uns wichtig