> Miglioramento continuo dei processi > Recruiting e acquisizione dei talenti > Greenhouse > Template dei dati

Il Suo Template dei dati per il recruiting e l'acquisizione di talenti

Greenhouse

Attributi di recruiting e acquisizione dei talenti (21) Attività di recruiting e acquisizione dei talenti (14) Guide all'estrazione (3)

Il Suo Template dei dati per il recruiting e l'acquisizione di talenti

Questo Template offre una guida completa alla raccolta dei dati corretti per il processo di recruiting e acquisizione di talenti. Illustra gli Attributi essenziali da monitorare, le attività principali da acquisire e indicazioni chiare per estrarre queste informazioni dal Suo sistema Greenhouse. Seguendo questo Template, disporrà delle basi dati necessarie per un'analisi approfondita del processo.

Attributi consigliati da raccogliere
Attività principali da monitorare
Indicazioni per l'estrazione

Non conosce ancora gli Event Log? Scopra come creare un Event Log per il Process Mining.

Scarica il Template

Attributi di recruiting e acquisizione dei talenti

Questi sono i campi dati consigliati da includere nel Suo Event Log per un’analisi completa del processo di recruiting e acquisizione dei talenti in Greenhouse.

5 Obbligatorio 6 Consigliato 10 Facoltativo

	Nome	Descrizione
	Candidatura di lavoro JobApplicationId	L'identificativo univoco della candidatura di un singolo candidato per una specifica posizione.
Descrizione Il Job Application ID è il fondamento dell'analisi del processo di recruiting e funge da identificativo univoco del caso. Collega tutte le attività correlate, dall'invio e dallo screening iniziali ai colloqui, alle offerte e alla decisione finale di assunzione. Ciò consente di ottenere una visione completa, end-to-end, del percorso di ogni candidato. Nel Process Mining, questo Attributo viene utilizzato per ricostruire il percorso esatto seguito da ciascun candidato nel funnel di assunzione. Consente di analizzare le varianti del processo, i tempi di ciclo per candidatura e i punti di abbandono, offrendo un quadro chiaro dell'intero ciclo di vita del recruiting per ogni candidato. Perché è importante Questo è il Case ID essenziale che collega tutti gli eventi di recruiting relativi a un singolo candidato, rendendo possibile analizzare l'intero percorso di assunzione dall'inizio alla fine. Dove reperirlo In genere è la chiave primaria di un oggetto application. Consulti la documentazione API di Greenhouse per l'endpoint 'Applications', spesso indicato come 'id' o 'application_id'. Esempi 987654321098765432119876543212
	Nome dell'attività ActivityName	Il nome della specifica attività o fase di recruiting che si è verificata.
Descrizione Questo Attributo registra il nome di ogni evento nel processo di recruiting, come 'Application Received', 'Interview Scheduled' o 'Offer Accepted'. Costituisce la sequenza di eventi che compone la mappa del processo. Analizzare la sequenza e la frequenza di queste attività è fondamentale per il Process Mining. Aiuta a visualizzare il funnel di recruiting, identificare i percorsi più comuni, rilevare le deviazioni dal Workflow standard e individuare i colli di bottiglia in cui il processo si arresta. Ad esempio, consente di monitorare quante candidature passano da 'Application Reviewed' a 'Recruiter Screen Conducted'. Perché è importante Questo Attributo definisce i passaggi del processo di recruiting, consentendo di visualizzare il flusso del processo e identificare colli di bottiglia e deviazioni. Dove reperirlo Spesso viene ricavato mappando i cambiamenti delle fasi della candidatura, gli stati dei colloqui, gli eventi relativi alle offerte o altre azioni verificabili all'interno di Greenhouse. Potrebbe essere necessaria una logica per tradurre gli eventi di sistema in nomi di attività standardizzati. Esempi Candidatura esaminataColloquio completatoOfferta accettataCandidatura rifiutata
	Timestamp dell'attività ActivityTimestamp	La data e l'ora esatte in cui si è verificata l'attività di recruiting.
Descrizione Il timestamp dell'attività indica il momento preciso in cui si è verificato un evento nel processo di recruiting. Costituisce la base temporale di tutte le analisi delle prestazioni e delle durate, fornendo l'ordine cronologico delle attività per ogni Job Application. Questo timestamp è essenziale per calcolare tutti i KPI legati al tempo, come Time to Hire, Interview Scheduling Cycle Time e Interview Feedback Turnaround Time. Analizzando il tempo trascorso tra attività diverse, le organizzazioni possono misurare l'efficienza, identificare i ritardi e monitorare il rispetto degli accordi sui livelli di servizio, supportando direttamente le Dashboard dedicate alle prestazioni e ai colli di bottiglia. Perché è importante Questo timestamp è fondamentale per ordinare gli eventi, calcolare i tempi di ciclo e analizzare le prestazioni del processo di recruiting. Dove reperirlo Si trova in diversi oggetti di Greenhouse, come 'applied_at' nell'oggetto Application, 'created_at' negli oggetti Offer oppure nei timestamp dei feed delle attività e dei log di audit. Esempi 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	Sistema di origine SourceSystem	Identifica il sistema di riferimento da cui sono stati estratti i dati.
Descrizione Questo attributo specifica l'origine dei dati di recruiting. Per questo processo, il valore sarebbe sempre «Greenhouse». Sebbene possa sembrare statico, registrare esplicitamente il sistema di origine è fondamentale per la governance dei dati, la risoluzione dei problemi e gli scenari in cui i dati potrebbero essere arricchiti da altri sistemi, come un HRIS. Garantisce chiarezza sulla provenienza dei dati e contribuisce a preservarne l'integrità nell'intero panorama dei dati dell'organizzazione. Perché è importante Garantisce una chiara provenienza dei dati, essenziale per la governance e la convalida dei dati e per la gestione di dati provenienti da più fonti. Dove reperirlo È un valore statico che deve essere aggiunto durante il processo di estrazione e trasformazione dei dati per indicarne l'origine. Esempi Greenhouse
	Ultimo aggiornamento dei dati LastDataUpdate	Il timestamp che indica quando i dati relativi a questo evento sono stati aggiornati o estratti l'ultima volta.
Descrizione Questo attributo registra la data e l'ora in cui i dati sono stati estratti l'ultima volta dal sistema di origine. È un campo di metadati che riflette l'aggiornamento dei dati nel modello di Process Mining. Questa informazione è essenziale per comprendere quanto sia aggiornata l'analisi. Aiuta a gestire le aspettative sulla latenza dei dati ed è fondamentale per verificare che la pipeline dei dati venga eseguita secondo la pianificazione. Ad esempio, se «Ultimo aggiornamento dei dati» risale a diversi giorni prima, gli utenti sanno che i Dashboard non riflettono le attività di recruiting più recenti. Perché è importante Indica l'aggiornamento dei dati e aiuta gli utenti a comprendere se l'analisi riflette lo stato più recente del processo. Dove reperirlo Questo timestamp viene generato e applicato al dataset durante il processo di estrazione, trasformazione e caricamento (ETL) dei dati. Esempi 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	Dipartimento della posizione JobDepartment	Il dipartimento o l'unità aziendale per cui viene coperta la posizione.
Descrizione Questo attributo specifica il dipartimento organizzativo, ad esempio «Engineering», «Marketing» o «Sales», associato alla richiesta di assunzione. Consente di aggregare e confrontare le metriche di recruiting tra le diverse aree dell'azienda. Segmentare l'analisi per dipartimento è fondamentale per Dashboard come «Prestazioni del time to hire» e «Andamento del tasso di accettazione delle offerte». Aiuta a individuare se determinati dipartimenti presentano cicli di assunzione più lunghi, tassi di rifiuto delle offerte più elevati o livelli diversi di conformità del processo. Questi insight consentono di definire interventi mirati e miglioramenti del processo, adattati alle esigenze specifiche di ciascun dipartimento. Perché è importante Consente di confrontare le prestazioni del recruiting e le variazioni del processo tra diversi dipartimenti, facendo emergere problemi sistemici o best practice. Dove reperirlo Generalmente disponibile come campo standard o personalizzato nell'oggetto Job di Greenhouse. Può essere trovato nella sezione «departments» di un record Job tramite API. Esempi IngegneriaGestione del prodottoVenditeMarketing
	Fonte della candidatura ApplicationSource	Il canale attraverso il quale è stata ricevuta la candidatura del candidato.
Descrizione Questo attributo registra l'origine di una candidatura, ad esempio «LinkedIn», «Employee Referral», «Company Website» o «Indeed». Fornisce insight sull'efficacia dei diversi canali di recruiting. Il Dashboard «Efficacia dei canali di sourcing» è interamente basato su questo attributo. Analizzando il volume delle candidature, il time to hire e i tassi di assunzione per fonte, le organizzazioni possono ottimizzare gli investimenti e gli sforzi di marketing del recruiting. Questi dati aiutano a rispondere a domande strategiche su quali canali forniscano i candidati di maggiore qualità nel modo più efficiente, supportando direttamente il KPI «Tasso di conversione del canale di sourcing». Perché è importante Aiuta a misurare l'efficacia e il ROI dei diversi canali di recruiting, consentendo di decidere sulla base dei dati dove concentrare gli sforzi di sourcing. Dove reperirlo Disponibile nell'oggetto Candidate di Greenhouse, collegato all'Application. Il campo «source» fornisce questa informazione. Esempi LinkedInSegnalazione da parte di un dipendentePagina Lavora con noi dell'aziendaIndeed
	Nome del recruiter RecruiterName	Il nome del recruiter responsabile della gestione della candidatura.
Descrizione Questo attributo identifica il recruiter assegnato a una specifica candidatura o richiesta di assunzione. Questa persona è generalmente responsabile dello screening, del coordinamento dei colloqui e dell'avanzamento del candidato nel processo. Analizzare il processo per recruiter è fondamentale per comprendere le prestazioni individuali e la distribuzione del carico di lavoro. Il Dashboard «Carico di lavoro ed efficienza dei recruiter» utilizza questo attributo per calcolare metriche come il throughput e i tempi di ciclo per ciascun recruiter. Aiuta a individuare i migliori risultati, identificare le persone che potrebbero aver bisogno di ulteriore supporto e garantire una distribuzione equilibrata del carico di lavoro nel team di acquisizione dei talenti. Perché è importante Attribuisce le attività del processo a uno specifico recruiter, consentendo di analizzare prestazioni individuali, carico di lavoro ed efficienza. Dove reperirlo Disponibile nell'oggetto Job di Greenhouse, generalmente nella sezione «hiring_team», in cui vengono specificati ruoli come «Recruiter». Esempi Alice JohnsonRobert DavisMaria Garcia
	Stato dell'offerta OfferStatus	Lo stato attuale di un'offerta di lavoro presentata a un candidato.
Descrizione Questo attributo registra lo stato di un'offerta di lavoro, con valori come «Created», «Extended», «Accepted» o «Rejected». È un indicatore chiave delle fasi finali del processo di recruiting. Questo attributo è essenziale per il Dashboard «Andamento del tasso di accettazione delle offerte» e per il KPI corrispondente. Monitorando il passaggio da «Offer Extended» a «Offer Accepted» o «Offer Rejected», le aziende possono misurare la propria capacità di concludere positivamente il percorso dei candidati. Analizzare questo dato per dipartimento o titolo della posizione può fornire insight sulla competitività della retribuzione, sull'esperienza del candidato o su altri fattori che influenzano la decisione del candidato. Perché è importante Registra l'esito delle offerte di lavoro, un dato fondamentale per calcolare il KPI del tasso di accettazione delle offerte e comprenderne le modalità di miglioramento. Dove reperirlo Disponibile nell'oggetto Offer di Greenhouse, collegato a un'Application. Il campo «status» fornisce questa informazione. Esempi AccettataRifiutataInviatoCreato
	Stato della candidatura ApplicationStatus	L'esito finale o lo stato attuale della candidatura.
Descrizione Questo attributo indica l'esito di una candidatura, ad esempio «Hired», «Rejected» o «Active». Rappresenta lo stato terminale di un processo completato oppure lo stato attuale di un processo ancora in corso. È una dimensione fondamentale per l'analisi degli esiti. Consente di filtrare i casi e confrontare i percorsi dei candidati assunti con quelli dei candidati rifiutati, facendo emergere le caratteristiche dei percorsi di successo. Viene inoltre utilizzato per calcolare i tassi di conversione nel Dashboard «Funnel complessivo del recruiting», mostrando quale percentuale delle candidature si conclude con un'assunzione. Perché è importante Definisce l'esito del processo di recruiting e consente di confrontare i percorsi dei candidati assunti con quelli dei candidati rifiutati. Dove reperirlo Questa informazione si trova nell'oggetto Application di Greenhouse ed è disponibile tramite il campo «status» nell'API. Esempi AssuntoRifiutataAttivo
	Titolo della posizione JobTitle	Il titolo della posizione per cui il candidato ha presentato la candidatura.
Descrizione Questo attributo contiene il titolo ufficiale della richiesta di assunzione, ad esempio «Senior Software Engineer» o «Product Marketing Manager». Fornisce il contesto essenziale sul ruolo da ricoprire. Analizzare i processi di recruiting per titolo della posizione è fondamentale per comprendere le difficoltà specifiche di ciascun ruolo. Ad esempio, il Dashboard «Prestazioni del time to hire» utilizza questo attributo per mostrare se le posizioni senior o altamente specializzate richiedono più tempo per essere coperte. Aiuta inoltre ad analizzare i tassi di accettazione delle offerte per le diverse posizioni, fornendo insight sulla competitività della retribuzione o sull'attrattività del ruolo. Perché è importante Consente di filtrare e confrontare le metriche di recruiting per ruoli specifici, aiutando a comprendere come le prestazioni del processo varino in base alla complessità o alla tipologia della posizione. Dove reperirlo È un campo principale dell'oggetto Job in Greenhouse, spesso disponibile come «name» quando si interroga l'endpoint «jobs» tramite API. Esempi Ingegnere software seniorAccount ExecutiveDesigner UX/UI
	È automatizzata IsAutomated	Un flag che indica se un'attività è stata eseguita automaticamente dal sistema.
Descrizione Questo attributo booleano indica se un'attività è stata eseguita da un utente o da una regola automatizzata del sistema. Esempi di attività automatizzate sono l'invio di e-mail di risposta automatica o il rifiuto automatico dei candidati che non superano una domanda di screening di base. Analizzare questo attributo aiuta a comprendere il livello di automazione del processo di recruiting. Può essere utilizzato per confrontare l'efficienza e gli esiti dei passaggi automatizzati con quelli manuali e per individuare opportunità di ulteriore automazione, così da migliorare rapidità e coerenza. Perché è importante Aiuta a distinguere tra attività manuali e automatizzate e consente di analizzare l'impatto dell'automazione sull'efficienza e sugli esiti del processo. Dove reperirlo Questa informazione non è un campo standard e generalmente deve essere derivata. Può essere dedotta dall'utente associato a un'attività, ad esempio un utente «System», oppure da specifici tipi di evento noti per essere automatizzati. Esempi truefalse
	È conforme IsCompliant	Un flag calcolato che indica se la candidatura ha seguito il processo di assunzione standard e definito.
Descrizione Questo attributo booleano è il risultato di un controllo di conformità, che confronta la sequenza effettiva delle attività di una candidatura con un modello di processo ideale predefinito. Segnala i casi che si sono discostati dal modello, ad esempio saltando passaggi obbligatori o eseguendo attività fuori sequenza. È un attributo fondamentale per il Dashboard «Deviazioni dalla conformità del processo di assunzione» e supporta i KPI «Tasso di conformità del processo» e «Numero di violazioni della conformità». Filtrando i casi non conformi, le organizzazioni possono analizzare le cause delle deviazioni, dovute ad esempio a formazione insufficiente, limitazioni del sistema o eccezioni necessarie. Ciò aiuta a standardizzare i Workflow e a ridurre i rischi di non conformità. Perché è importante Identifica le deviazioni dal processo, un elemento fondamentale per misurare la conformità del processo, garantire la conformità e standardizzare i Workflow di assunzione. Dove reperirlo È un campo calcolato generato dal software di Process Mining. Confronta i dati dell'Event Log con un modello obiettivo definito o con un insieme di regole aziendali. Esempi truefalse
	Fase del colloquio InterviewStageName	Il nome o il tipo specifico della fase del colloquio.
Descrizione Questo attributo specifica la fase particolare all'interno del processo complessivo di colloquio, ad esempio «Recruiter Screen», «Technical Interview» o «Final Round». Offre un livello di dettaglio maggiore rispetto a un'attività generica «Interview Completed». Analizzando le metriche per ciascuna fase distinta del colloquio, le organizzazioni possono individuare colli di bottiglia più specifici. Ad esempio, è possibile misurare con precisione il «Tasso di abbandono dei candidati per fase» e capire se i candidati tendono a ritirarsi dopo il colloquio tecnico anziché dopo lo screening iniziale. Questo livello di dettaglio è fondamentale per apportare miglioramenti mirati all'esperienza del colloquio. Perché è importante Offre una visione più dettagliata del processo di colloquio e consente di analizzare tempi di ciclo e tassi di abbandono per ciascun passaggio specifico. Dove reperirlo Questa informazione fa parte dei dati di pianificazione dei colloqui in Greenhouse. L'oggetto «interviews» di una candidatura contiene i dettagli relativi alla fase del colloquio. Esempi Colloquio con il recruiterColloquio con il responsabile delle assunzioniValutazione tecnicaColloquio finale in presenza
	ID candidato CandidateId	Un identificativo univoco del candidato, indipendente da una singola candidatura.
Descrizione Il Candidate ID identifica univocamente una persona nel bacino di talenti, mentre il Job Application ID è specifico di una candidatura per una determinata posizione. Uno stesso candidato può presentare più candidature nel tempo. Sebbene il Job Application ID funga da Case ID per questa specifica vista del processo, il Candidate ID consente un tipo diverso di analisi. Può essere utilizzato per seguire il percorso di un candidato attraverso più candidature, individuare i candidati che si candidano più frequentemente e analizzare la relazione complessiva con il bacino di talenti. Offre una visione dei dati di recruiting maggiormente incentrata sulla persona. Perché è importante Consente di analizzare più candidature dello stesso candidato e offre una visione più ampia del coinvolgimento dei candidati nel tempo. Dove reperirlo È la chiave primaria di un record candidato in Greenhouse, disponibile come «id» nell'oggetto Candidate tramite API. Esempi 123456123457123458
	ID posizione JobId	Identificativo univoco della richiesta di assunzione o dell'annuncio di lavoro.
Descrizione Questo attributo è l'ID univoco della posizione, distinto dall'ID della candidatura. Più candidature saranno collegate allo stesso Job ID. Utilizzare il Job ID consente di aggregare i dati a livello di richiesta di assunzione. Ad esempio, è possibile analizzare il numero totale di candidature ricevute per una posizione specifica o il tempo medio di assunzione per tutti i ruoli di tipologia simile. Offre un modo per raggruppare e analizzare le attività di recruiting relative a una singola posizione aperta. Perché è importante Consente di aggregare e analizzare tutti i dati dei candidati relativi a una singola posizione aperta, offrendo una visione incentrata sulla richiesta di assunzione. Dove reperirlo È la chiave primaria di un record Job in Greenhouse, disponibile come «id» nell'oggetto Job tramite API. Esempi 400123400124400125
	Motivo del rifiuto RejectionReason	Il motivo indicato per il rifiuto della candidatura di un candidato.
Descrizione Questo attributo registra il motivo specifico per cui un candidato non è stato fatto avanzare nel processo. Tra gli esempi figurano «Not a culture fit», «Salary expectations too high» o «More qualified candidates». Analizzare i motivi del rifiuto fornisce un feedback prezioso sul processo di recruiting. Può evidenziare problemi quali descrizioni delle posizioni non allineate, retribuzioni non competitive o lacune ricorrenti nelle competenze dei candidati. Questa informazione è particolarmente utile per migliorare le strategie di sourcing e l'esperienza del candidato, comprendendo i punti di insuccesso più frequenti nel funnel di assunzione. Perché è importante Fornisce insight qualitativi sui motivi per cui i candidati vengono esclusi dal funnel e aiuta a perfezionare descrizioni delle posizioni, sourcing e criteri di screening. Dove reperirlo Disponibile nell'oggetto Application quando la candidatura viene rifiutata. L'API fornisce un oggetto «rejection_reason» con i relativi dettagli. Esempi Competenze richieste insufficientiAspettative salariali troppo elevateSelezionato un candidato più qualificato
	Nome del responsabile delle assunzioni HiringManagerName	Il nome del responsabile delle assunzioni per la richiesta di assunzione associata.
Descrizione Questo attributo identifica il responsabile del team con la posizione aperta. Il responsabile delle assunzioni è uno stakeholder fondamentale del processo, spesso coinvolto nella valutazione dei candidati, nei colloqui delle fasi avanzate e nella decisione finale di assunzione. Analizzare il processo per responsabile delle assunzioni può far emergere pattern e colli di bottiglia importanti. Ad esempio, il Dashboard «Colli di bottiglia nella pianificazione dei colloqui» potrebbe mostrare che i ritardi sono spesso associati alla disponibilità di determinati responsabili. L'analisi aiuta a individuare la necessità di formazione o supporto, così da garantire un coinvolgimento efficiente dei responsabili nel processo di assunzione. Perché è importante Identifica uno stakeholder chiave e consente di analizzare i colli di bottiglia o le efficienze del processo associati a specifici responsabili delle assunzioni. Dove reperirlo Disponibile nell'oggetto Job di Greenhouse, generalmente nella sezione «hiring_team», in cui vengono specificati ruoli come «Hiring Manager». Esempi Emily TranDavid ChenSophia Rodriguez
	Ora di fine dell'attività ActivityEndTime	Il timestamp che indica quando si è conclusa un'attività con una durata.
Descrizione Questo attributo registra l'ora di completamento delle attività che si svolgono nell'arco di un periodo, come un colloquio o un controllo dei precedenti. Sebbene molte attività siano istantanee, quelle con una durata misurabile traggono vantaggio dalla disponibilità sia dell'ora di inizio sia dell'ora di fine. Disporre dell'ora di fine è fondamentale per calcolare con precisione il tempo di elaborazione o la durata di attività specifiche. Ciò aiuta a distinguere il tempo di attesa tra i passaggi dal tempo effettivamente dedicato a un'attività. Ad esempio, consente di analizzare con maggiore precisione la durata effettiva dei colloqui rispetto al tempo necessario per programmarli. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività e aiuta a distinguere il tempo di lavoro effettivo dal tempo di attesa nel processo. Dove reperirlo Questa informazione potrebbe essere disponibile in oggetti come «scheduled_interview» in Greenhouse, che spesso includono sia un'ora di «start» sia un'ora di «end». Per le altre attività, potrebbe essere necessario dedurla dal timestamp dell'attività successiva. Esempi 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	Raccomandazione della scorecard ScorecardOverallRecommendation	La raccomandazione complessiva risultante da una scorecard di colloquio completata.
Descrizione Questo attributo registra la raccomandazione finale formulata da un intervistatore in una scorecard strutturata, generalmente con valori come «Strong Yes», «Yes», «No» o «Strong No». Questi dati sono fondamentali per valutare la qualità e la coerenza del processo di colloquio. Aiutano a correlare il feedback dei colloqui con gli esiti effettivi delle assunzioni e a rispondere a domande come «I candidati con raccomandazioni più positive vengono assunti più spesso?». Costituiscono inoltre la base per il KPI «Tasso di completamento delle scorecard», che misura l'adozione di pratiche di assunzione strutturate all'interno dell'organizzazione. Perché è importante Collega il feedback strutturato dei colloqui agli esiti del processo e aiuta a misurare l'adozione di pratiche di assunzione basate sui dati. Dove reperirlo Si trova nell'oggetto Scorecard associato a un colloquio completato in Greenhouse. L'API fornisce questa informazione tramite l'endpoint «scorecards». Esempi Decisamente noNoSìDecisamente sì
	Tempo di risposta sul feedback del colloquio InterviewFeedbackTurnaroundTime	Il tempo trascorso tra il completamento di un colloquio e l'invio del feedback da parte dell'intervistatore.
Descrizione Questa metrica calcolata misura la reattività del panel di intervistatori. I ritardi nell'invio del feedback possono rallentare significativamente il processo di assunzione e compromettere l'esperienza del candidato. Questo attributo supporta direttamente il Dashboard «Analisi del ciclo di feedback dei colloqui» e il KPI «Tempo di risposta sul feedback del colloquio». Viene calcolato come differenza temporale tra le attività «Interview Completed» e «Feedback Submitted». Il monitoraggio di questa metrica aiuta a individuare i colli di bottiglia causati dalla lentezza del feedback e incoraggia decisioni più rapide. Perché è importante Misura l'efficienza del ciclo di feedback successivo al colloquio, una fonte comune di ritardi nel processo di assunzione. Dove reperirlo È un campo calcolato. Si ottiene sottraendo il timestamp dell'evento «Interview Completed» dal timestamp dell'evento «Feedback Submitted». Esempi 86400172800259200

Obbligatorio Consigliato Facoltativo

Attività di recruiting e acquisizione dei talenti

Questi sono i passaggi e i traguardi chiave del processo da acquisire nel Suo Event Log per individuare con precisione il processo e ottimizzare il funnel di assunzione.

7 Consigliato 7 Facoltativo

	Attività	Descrizione
	Candidato assunto	Il candidato ha completato con successo tutti i controlli pre-assunzione ed è stato ufficialmente contrassegnato come assunto. Questo evento rappresenta il completamento del processo e il suo evento finale positivo per la candidatura.
Perché è importante Questo è il principale risultato positivo del processo. Il tempo che intercorre tra 'Application Received' e questo evento costituisce il Time to Hire complessivo, un KPI di recruiting fondamentale. Dove reperirlo Si tratta di un'azione esplicita in Greenhouse, con cui un Recruiter contrassegna il candidato come assunto per una specifica posizione. L'azione lo fa passare dallo stato di candidato attivo a quello di assunto. Acquisizione Acquisito dal timestamp dell'azione 'Mark as Hired' in Greenhouse. Tipo di evento explicit
	Candidatura ricevuta	Questa attività segna l'inizio del processo di recruiting per una specifica candidatura. Viene registrata quando un candidato invia la propria candidatura tramite un career site o un canale di sourcing, oppure quando viene inserito manualmente in Greenhouse.
Perché è importante Questo è il principale evento di avvio del processo. Analizzare il tempo che intercorre tra questa attività e le successive è fondamentale per misurare il Time to Hire e l'efficacia del canale di sourcing. Dove reperirlo Si tratta di un evento esplicito registrato in Greenhouse quando viene creata una candidatura. Il campo Application Date o il timestamp di creazione dell'oggetto application fornisce l'orario dell'evento. Acquisizione Acquisito dal timestamp di creazione del record della candidatura. Tipo di evento explicit
	Candidatura rifiutata	La candidatura del candidato è stata rifiutata in una fase del processo. Si tratta dell'evento finale negativo più comune e può verificarsi in qualsiasi momento.
Perché è importante Questo è un evento finale fondamentale per analizzare i tassi di abbandono del funnel. Comprendere quando e perché si verificano i rifiuti aiuta a individuare inefficienze del processo o requisiti del ruolo non allineati. Dove reperirlo Si tratta di un evento esplicito registrato quando un utente rifiuta la candidatura in Greenhouse. Spesso è accompagnato da un motivo del rifiuto e il log delle attività ne registra il timestamp. Acquisizione Acquisito dal timestamp dell'azione di rifiuto applicata alla candidatura. Tipo di evento explicit
	Colloquio completato	Il colloquio con il candidato si è svolto. Spesso viene dedotto in base al superamento dell'orario previsto per il colloquio oppure, in modo più affidabile, quando viene inviato il feedback relativo al colloquio.
Perché è importante Questa attività rappresenta una tappa importante nel percorso del candidato. Costituisce il punto di partenza per misurare i tempi di invio del feedback e l'avanzamento verso la fase successiva. Dove reperirlo In genere viene dedotto. Può essere ricavato dall'orario di fine del colloquio pianificato o, con maggiore precisione, dal timestamp del primo feedback inviato per quello specifico colloquio. Acquisizione Deducibile dall'orario di fine del colloquio pianificato o dal timestamp dell'invio successivo del feedback. Tipo di evento inferred
	Colloquio pianificato	Un colloquio con il candidato è stato pianificato nel sistema. Greenhouse dispone di integrazioni con i calendari, pertanto questo evento viene generalmente registrato in modo esplicito quando il colloquio è confermato.
Perché è importante Questo evento è fondamentale per analizzare e identificare i colli di bottiglia nel processo di pianificazione dei colloqui. Il tempo tra questo evento e il passaggio precedente è un KPI chiave dell'efficienza di Recruiter e coordinatori. Dove reperirlo Acquisito dalla funzionalità di pianificazione dei colloqui di Greenhouse. L'API fornisce i dati sui colloqui pianificati, incluso il timestamp di creazione. Acquisizione Registrato quando viene creato un evento di colloquio associato alla candidatura del candidato. Tipo di evento explicit
	Offerta accettata	Il candidato ha accettato formalmente l'offerta di lavoro. Si tratta di una tappa fondamentale del successo del processo e in genere attiva le successive attività pre-assunzione, come i controlli dei precedenti.
Perché è importante Questa è una tappa fondamentale del successo e una componente chiave del KPI Offer Acceptance Rate. Segna il passaggio da candidato a futuro dipendente. Dove reperirlo Si tratta di un evento esplicito acquisito quando lo stato dell'offerta viene aggiornato a 'Accepted' in Greenhouse, dal Recruiter oppure tramite l'accettazione elettronica del candidato. Acquisizione Acquisito dal timestamp del momento in cui lo stato dell'offerta cambia in 'Accepted'. Tipo di evento explicit
	Offerta inviata al candidato	L'offerta di lavoro ufficiale è stata inviata al candidato. Si tratta di una tappa fondamentale, che rappresenta il culmine del processo di colloquio e selezione.
Perché è importante Questa attività costituisce la base per calcolare il KPI Offer Acceptance Rate. Segna l'inizio della fase decisionale finale per il candidato. Dove reperirlo Si tratta di un evento esplicito registrato in Greenhouse quando lo stato dell'offerta cambia in 'Sent' o 'Extended'. L'oggetto offers contiene i timestamp di questi cambiamenti di stato. Acquisizione Acquisito dal timestamp del momento in cui lo stato dell'offerta viene ufficialmente contrassegnato come inviata. Tipo di evento explicit
	Candidatura esaminata	Un Recruiter o un responsabile delle assunzioni ha effettuato una prima valutazione della candidatura. In genere ciò viene dedotto quando la fase o lo stato della candidatura cambia da 'New' a una fase di valutazione attiva, come 'In Review'.
Perché è importante Il monitoraggio di questa attività aiuta a identificare i colli di bottiglia nella fase iniziale di screening e a misurare il tempo necessario affinché le nuove candidature ricevano attenzione. Costituisce il punto di partenza per calcolare il tempo del ciclo di pianificazione dei colloqui. Dove reperirlo Deducibile da una modifica del campo relativo allo stato della candidatura. Individui i cambiamenti dallo stato 'New' allo stato 'Review', utilizzando il timestamp della modifica. Acquisizione Deducibile dal timestamp di una modifica dello stato a 'In Review' o a una fase analoga. Tipo di evento inferred
	Controllo dei precedenti avviato	È stato avviato un controllo dei precedenti del candidato, in genere dopo l'accettazione dell'offerta. L'avvio può essere registrato come modifica di una fase specifica o come attivazione di un'integrazione con un servizio di terze parti.
Perché è importante Questa attività è importante per la Conformità e per monitorare i ritardi nello screening pre-assunzione. Aiuta ad analizzare il tempo necessario tra l'accettazione dell'offerta e il completamento dei controlli richiesti. Dove reperirlo È probabile che venga dedotto dallo spostamento del candidato nella fase 'Background Check' della pipeline di assunzione o da un log delle attività relativo a un'integrazione per il controllo dei precedenti. Acquisizione Deducibile da una modifica dello stato alla fase 'Background Check' o da un log API proveniente da un servizio integrato. Tipo di evento inferred
	Feedback inviato	Un intervistatore ha inviato la propria scorecard o il proprio feedback sul colloquio del candidato. Il processo di assunzione strutturato di Greenhouse si basa su questo elemento per prendere decisioni, pertanto si tratta di un'azione distinta e registrata.
Perché è importante La tempestività del feedback è fondamentale per far avanzare i candidati. Questa attività aiuta ad analizzare l'efficienza del ciclo di feedback e il tasso di completamento delle Scorecard. Dove reperirlo Si tratta di un evento esplicito registrato quando un intervistatore invia una scorecard tramite Greenhouse. L'oggetto Scorecards API contiene un timestamp `submitted_at`. Acquisizione Acquisito dal timestamp di invio della scorecard del colloquio. Tipo di evento explicit
	Offerta creata	È stata redatta un'offerta di lavoro ufficiale, potenzialmente in attesa di approvazione interna. Questo evento segna la decisione formale di procedere con un'offerta per il candidato.
Perché è importante Questa attività distingue la decisione di formulare un'offerta dall'atto di inviarla. Aiuta ad analizzare i tempi di approvazione interna e i colli di bottiglia prima che l'offerta raggiunga il candidato. Dove reperirlo Greenhouse dispone di un modulo dedicato alle offerte. Si tratta di un evento esplicito, acquisito dal timestamp di creazione dell'oggetto offerta associato alla candidatura. Acquisizione Registrato al momento della creazione di un record dell'offerta nel sistema Greenhouse. Tipo di evento explicit
	Offerta rifiutata	Il candidato ha rifiutato formalmente l'offerta di lavoro. Si tratta di un evento finale negativo del processo, che si verifica in una fase avanzata del funnel.
Perché è importante Monitorare questo risultato è fondamentale per analizzare l'Offer Acceptance Rate. Un'elevata frequenza di questo evento può indicare problemi relativi alla retribuzione, alla cultura aziendale o al ruolo. Dove reperirlo Si tratta di un evento esplicito acquisito quando lo stato dell'offerta viene aggiornato a 'Rejected' o 'Declined' in Greenhouse. L'oggetto dell'offerta conterrà un timestamp per questa modifica di stato. Acquisizione Acquisito dal timestamp del momento in cui lo stato dell'offerta cambia in 'Rejected'. Tipo di evento explicit
	Onboarding avviato	È iniziato ufficialmente il processo di onboarding del nuovo assunto in azienda. Spesso ciò comporta un passaggio dal sistema di recruiting a un HRIS o a una piattaforma di onboarding.
Perché è importante Questa attività misura l'efficienza del passaggio dal recruiting alle risorse umane. I ritardi in questa fase possono compromettere l'esperienza del nuovo assunto, pertanto è fondamentale monitorare l'Onboarding Handoff Time. Dove reperirlo Può trattarsi di un evento esplicito se Greenhouse è integrato con un sistema di onboarding. In caso contrario, viene dedotto dal timestamp del momento in cui il candidato viene spostato nella fase finale 'Hired', che attiva il passaggio. Acquisizione Deducibile da una modifica della fase o da un log di integrazione che indica il passaggio a un HRIS. Tipo di evento inferred
	Screening del Recruiter completato	Un Recruiter ha completato una prima telefonata di screening o una conversazione con il candidato. Questa attività viene spesso registrata spostando il candidato in una fase specifica 'Phone Screen' nella pipeline di assunzione.
Perché è importante Si tratta di una tappa fondamentale di qualificazione, che indica che la candidatura ha superato lo screening iniziale del curriculum. Aiuta a misurare il carico di lavoro dei Recruiter e l'efficacia dello screening iniziale. Dove reperirlo Deducibile dal timestamp del momento in cui la candidatura viene spostata dentro o fuori dalla fase 'Phone Screen' nella pipeline di lavoro Greenhouse. Acquisizione Derivato dalla cronologia delle fasi della candidatura, con particolare riferimento all'ingresso nella fase 'Phone Screen'. Tipo di evento inferred

Consigliato Facoltativo

Guide all'estrazione

Come ottenere i Suoi dati da Greenhouse

Passaggi

Acceda al Suo account Greenhouse Recruiting.
Acceda alla sezione Reports facendo clic sull'icona dei report, raffigurante un grafico a barre, nella barra di navigazione principale.
Nella Dashboard Reports, individui e selezioni "Essential Reports". Il report principale per questa estrazione è "All Applications", che offre una panoramica completa delle candidature e delle relative tappe principali.
Configuri il report "All Applications". Faccia clic sul pulsante "Columns" e selezioni tutte le colonne necessarie per acquisire gli Attributi richiesti e i timestamp delle attività. Si assicuri di includere: 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.
Per acquisire le attività relative ai colloqui, dovrà utilizzare un report separato. Torni a Essential Reports e selezioni "Interview Details".
Configuri il report "Interview Details". Nella sezione "Columns", selezioni almeno: Application ID, Interview Name, Scheduled Start e Scorecard Submitted At. In questo modo acquisirà i timestamp della pianificazione e dell'invio del feedback.
Per entrambi i report, imposti l'intervallo di date appropriato utilizzando i filtri. Un filtro comune consiste nell'impostare "Applied On" su "All Time" oppure su un intervallo specifico, ad esempio gli ultimi 6 mesi, per acquisire una coorte pertinente di candidature.
Generi ciascun report facendo clic sul pulsante "Update" o "Generate". Quando il report viene visualizzato, faccia clic su "Export to Excel" per scaricare i dati come file CSV. A questo punto disporrà di due file CSV separati.
I file esportati non sono ancora in formato Event Log. Dovrà eseguire una trasformazione utilizzando uno strumento come Python, R oppure un programma per fogli di calcolo con funzionalità di unpivot, ad esempio Power Query di Microsoft Excel.
Combini i dati dei report "All Applications" e "Interview Details", unendoli tramite Application ID.
Per ogni candidatura, crei una riga distinta per ciascuna colonna di data rilevante esportata. Ad esempio, il valore della colonna "Applied On" diventa l'"ActivityTimestamp" per un'attività denominata "Application Received". Il valore della colonna "Rejected On" crea l'attività "Application Rejected", e così via per tutte le 14 attività richieste. Utilizzi la colonna "Last Stage Change On" per dedurre attività come "Application Reviewed" o "Recruiter Screen Conducted" quando non sono disponibili timestamp dedicati.
Strutturi il file trasformato finale con le colonne richieste: JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate e gli eventuali Attributi consigliati. Salvi questo file finale come un unico CSV da caricare.

Configurazione

Report principali: l'estrazione si basa sulla combinazione dei dati provenienti da più report nella sezione Essential Reports di Greenhouse, principalmente "All Applications" e "Interview Details".
Colonne principali (All Applications): per acquisire tutti i dati necessari, selezioni colonne quali Application ID, Candidate, Job, Department, Recruiter, Status, Source, Offer Status e tutte le colonne di data pertinenti, tra cui Applied On, Rejected On, Hired On, Offer Created On e Offer Accepted On.
Colonne principali (Interview Details): per acquisire gli eventi dei colloqui, selezioni colonne quali Application ID, Interview Name, Scheduled Start e Scorecard Submitted At.
Filtri per l'intervallo di date: si consiglia di filtrare le candidature in base alla data "Applied On" per un periodo compreso tra 3 e 6 mesi, così da ottenere un insieme di dati gestibile e pertinente. Intervalli più lunghi possono incidere sulle prestazioni.
Prerequisiti: l'utente che esegue l'esportazione deve disporre delle autorizzazioni necessarie in Greenhouse per accedere alla sezione Reports e visualizzare i dati dei candidati. In genere è richiesto il ruolo "Job Admin" o "Site Admin".

a Query di esempio 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'

Passaggi

Prerequisiti: ottenere la chiave API di Greenhouse
- Acceda al Suo account Greenhouse con autorizzazioni di sviluppatore.
- Acceda a Configure > Dev Center > API Credential Management.
- Faccia clic su "Create New API Key".
- Inserisca una descrizione, ad esempio "ProcessMind Extraction".
- Selezioni "Harvest" come tipo.
- Conceda alla chiave le autorizzazioni necessarie. Come minimo, sono richieste autorizzazioni GET per: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards e Users.
- Copi e conservi in modo sicuro la chiave API generata. Non sarà possibile visualizzarla nuovamente.
Configuri l'ambiente Python
- Si assicuri di avere Python 3.6 o una versione successiva installata sul sistema.
- Installi le librerie Python necessarie eseguendo nel terminale i seguenti comandi: pip install requests e pip install pandas.
Prepari lo script Python
- Copi lo script Python completo fornito nella sezione "query" in un nuovo file, ad esempio extract_greenhouse_logs.py.
- Sostituisca il segnaposto YOUR_GREENHOUSE_API_KEY con la chiave ottenuta al passaggio 1.
- Modifichi la variabile START_DATE_ISO per definire l'inizio del periodo di estrazione. Per il caricamento iniziale, si consiglia di utilizzare una data compresa tra 3 e 6 mesi nel passato.
Personalizzi la mappatura da fase ad attività
- Esamini il dizionario STAGE_TO_ACTIVITY nello script.
- Questo dizionario associa i nomi delle fasi di assunzione specifiche della Sua azienda in Greenhouse ai nomi standard delle attività richiesti per il Process Mining.
- DEVE aggiornare questa mappatura affinché corrisponda alla configurazione Greenhouse specifica della Sua organizzazione. Ad esempio, se la fase "Recruiter Screen" è denominata "Initial Recruiter Chat", dovrà aggiornare di conseguenza il dizionario.
Esegua lo script di estrazione
- Apra un terminale o un prompt dei comandi.
- Acceda alla directory in cui ha salvato extract_greenhouse_logs.py.
- Esegua lo script con il comando: python extract_greenhouse_logs.py.
- Lo script si collegherà all'API di Greenhouse, recupererà i dati, li elaborerà e visualizzerà gli aggiornamenti di stato nella console.
Recuperi l'Event Log
- Al termine dell'esecuzione, nella stessa directory verrà generato un file denominato greenhouse_event_log.csv.
- Questo file CSV costituisce l'Event Log finale, formattato con le colonne e le attività richieste.
Gestisca i caricamenti incrementali
- Per le esecuzioni successive, può aggiornare la variabile START_DATE_ISO impostandola sul timestamp dell'ultima estrazione completata correttamente. In questo modo verranno recuperati solo i record nuovi o aggiornati, rendendo il processo più rapido.
Carichi i dati in ProcessMind
- Il file greenhouse_event_log.csv generato è pronto per essere caricato direttamente in ProcessMind. Si assicuri che i nomi delle colonne siano associati correttamente ai campi del progetto ProcessMind.

Configurazione

Autorizzazioni della chiave API: la chiave API Harvest deve disporre dell'accesso in sola lettura (GET) ai seguenti endpoint: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards e Users. Autorizzazioni insufficienti comporteranno l'assenza di dati per alcune attività.
Filtro per l'intervallo di date: lo script utilizza un parametro updated_after (variabile START_DATE_ISO) per filtrare le candidature. Per la prima estrazione, utilizzi un intervallo più ampio, ad esempio gli ultimi 6 mesi. Per i caricamenti incrementali successivi, imposti il parametro sul timestamp dell'ultima esecuzione completata correttamente, così da migliorare le prestazioni.
Mappatura da fase ad attività: il dizionario STAGE_TO_ACTIVITY nello script è fondamentale. Deve essere configurato affinché rifletta con precisione le fasi di assunzione specifiche della Sua azienda in Greenhouse, così da identificare correttamente attività come "Recruiter Screen Conducted" e "Background Check Initiated".
Limitazione della frequenza delle API: lo script include una breve pausa fissa tra le richieste API per rispettare i limiti di Greenhouse, pari a circa 20 richieste al secondo. Per volumi di dati molto elevati, potrebbe essere necessario modificare questa pausa per evitare errori di connessione.
Granularità dei dati: l'estrazione si concentra sugli eventi con timestamp e sui cambiamenti di stato. Non acquisisce contenuti dettagliati come note dei colloqui o comunicazioni via e-mail, ma solo i metadati relativi all'avvenimento di un evento.

a Query di esempio 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.")

Passaggi

Verifichi che la piattaforma ETL in licenza disponga di un connettore Greenhouse e che il connettore supporti gli oggetti Greenhouse o i dataset replicati contenenti candidature, cronologia delle fasi delle candidature, colloqui, feedback dei colloqui, offerte, cambiamenti di stato delle offerte, verifiche dei precedenti, passaggi di onboarding ed esiti delle assunzioni. I nomi degli oggetti del connettore variano in base alla piattaforma; utilizzi quindi il catalogo del connettore e il browser dello schema, senza dare per scontati i nomi delle tabelle.
Crei la connessione alla sorgente Greenhouse nella piattaforma ETL. Inserisca le credenziali Greenhouse, i dettagli di autorizzazione, le impostazioni di replica e gli eventuali filtri specifici dell'azienda richiesti dal Suo ambiente. Utilizzi la procedura di autorizzazione documentata dal connettore e conceda solo le autorizzazioni necessarie per leggere i dati di recruiting selezionati.
Configuri un data warehouse di destinazione e abiliti la replica degli oggetti sorgente necessari per costruire l'Event Log. Come minimo, selezioni gli oggetti che espongono candidature, cronologia degli stati o delle fasi, colloqui, feedback dei colloqui, offerte, cambiamenti di stato delle offerte, eventi relativi alle verifiche dei precedenti, passaggi di onboarding ed esiti delle assunzioni. Se un oggetto richiesto non è disponibile, documenti la limitazione e associ la sorgente supportata più vicina in base alla configurazione Greenhouse.
Imposti la finestra di replica iniziale sul periodo di analisi richiesto, in genere i 3-6 mesi precedenti. Includa un periodo di lookback più ampio quando le candidature possono essere state create prima dell'intervallo selezionato ma aver proseguito il percorso al suo interno. Configuri la replica incrementale e conservi, quando disponibili, i timestamp degli aggiornamenti della sorgente.
Esamini lo schema replicato e sostituisca ogni segnaposto nella query con lo schema di destinazione effettivo, i nomi reali di tabelle e colonne, i campi timestamp, gli identificativi e i valori di stato esposti dal connettore. Non dia per scontato che un cambiamento di fase, un colloquio, un feedback, un'offerta, una verifica dei precedenti, un passaggio di onboarding o un esito dell'assunzione siano disponibili se non risultano presenti nei dati replicati.
Configuri la query di trasformazione come un'unione di estrazioni esplicite degli eventi. Ogni estrazione deve restituire JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource e OfferStatus. Normalizzi i timestamp su un unico fuso orario, rimuova i record privi di un identificativo valido della candidatura o di un timestamp dell'attività e conservi una riga per ogni evento sorgente che rappresenta un'attività.
Applichi le regole di mappatura degli eventi. Utilizzi i dati di creazione o invio della candidatura per Application Received, una fase di revisione esplicita o una transizione di stato per Application Reviewed, un record di screening da parte del recruiter o una transizione configurata della fase di screening telefonico per Recruiter Screen Conducted, una conferma del colloquio o il timestamp pianificato per Interview Scheduled, il completamento del colloquio o il timestamp di invio del feedback per Interview Completed, l'invio del feedback per Feedback Submitted, la creazione dell'offerta per Offer Created, lo stato di offerta inviata o estesa per Offer Extended, lo stato di offerta accettata per Offer Accepted, un evento registrato di avvio della verifica dei precedenti per Background Check Initiated, un evento di passaggio o avvio dell'onboarding per Onboarding Initiated, un esito di assunzione per Candidate Hired, un esito di offerta rifiutata per Offer Rejected e un esito di candidatura rifiutata o una transizione alla fase di rifiuto per Application Rejected.
Carichi il risultato trasformato in una tabella o vista di destinazione dedicata all'Event Log di ProcessMind. Mantenga gli eventi sorgente duplicati, salvo che una regola aziendale documentata li identifichi come duplicati tecnici. Se è necessaria la deduplicazione, deduplichi esclusivamente le chiavi di evento sorgente identiche, come identificativo della candidatura, nome dell'attività, timestamp dell'attività e identificativo del record sorgente.
Convalidi il risultato utilizzando i controlli riportati di seguito. Verifichi che tutte le colonne richieste siano presenti, che i timestamp siano validi, che ogni attività richiesta sia rappresentata quando esistono dati sorgente e che l'identificativo del caso sia univoco per candidatura. Esamini separatamente le candidature rifiutate, ritirate, archiviate e incomplete, così da evitare che i filtri rimuovano involontariamente esiti validi del processo.
Esporti o renda disponibile il risultato finale come CSV semplice oppure tramite una connessione al data warehouse supportata per il caricamento in ProcessMind. Mappi JobApplicationId come identificativo del caso, ActivityName come attività e ActivityTimestamp come timestamp dell'evento. Includa SourceSystem e LastDataUpdate, conservi gli Attributi consigliati, utilizzi un formato timestamp coerente, ad esempio ISO 8601 con informazioni sul fuso orario, e non faccia affidamento su ProcessMind per dedurre eventi assenti dal file.

Configurazione

Connettore e destinazione: utilizzi una piattaforma ETL in licenza con un connettore Greenhouse supportato e un data warehouse di destinazione accessibile al livello di trasformazione. Le funzionalità del connettore, i nomi degli oggetti, gli intervalli di aggiornamento e il supporto alla replica storica dipendono dalla piattaforma e dall'abbonamento selezionati.
Autorizzazione della sorgente: configuri le credenziali e le autorizzazioni Greenhouse richieste dal connettore. Verifichi che l'account autorizzato possa leggere i record delle candidature, la cronologia delle fasi o degli stati, i record dei colloqui, i feedback, le offerte e gli eventuali dati integrati relativi alle verifiche dei precedenti o all'onboarding utilizzati nella mappatura.
Oggetti replicati: selezioni tutti gli oggetti sorgente necessari per le 14 estrazioni degli eventi. Non abiliti soltanto la tabella corrente delle candidature se i cambiamenti storici di fase, le azioni relative ai colloqui, gli invii di feedback, le transizioni delle offerte o i passaggi successivi sono archiviati separatamente.
Intervallo di date: inizi con un periodo di 3-6 mesi per l'analisi operativa. Estenda l'intervallo quando misura l'intero ciclo di vita delle candidature, poiché le candidature create prima del periodo potrebbero raggiungere successivamente i colloqui, le offerte o gli esiti di assunzione.
Aggiornamento incrementale: conservi, quando disponibili, i timestamp di creazione, occorrenza e ultimo aggiornamento della sorgente. Configuri un aggiornamento ricorrente coerente con la latenza di reporting richiesta e utilizzi una piccola finestra di sovrapposizione per gestire record arrivati in ritardo o corretti.
Filtri: applichi esclusivamente filtri specifici dell'azienda documentati, come organizzazione, reparto, posizione, sede o data della candidatura. Non utilizzi filtri generici come Company Code o Document Type, a meno che tali campi siano effettivamente presenti nello schema Greenhouse replicato e siano richiesti dalla Sua configurazione.
Mappatura delle attività: mantenga una mappatura documentata dal tipo di evento, dalla fase, dallo stato o dal timestamp della sorgente a ciascun ActivityName. Configuri i valori esatti per revisione, screening telefonico, rifiuto, offerta, accettazione, verifica dei precedenti, onboarding ed esiti di assunzione in base ai valori utilizzati dalla Sua organizzazione.
Gestione dei valori null: consenta che RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource e OfferStatus siano null quando la sorgente non li fornisce. Gli identificativi e i timestamp obbligatori devono essere rifiutati o sottoposti a verifica quando mancanti.
Fusi orari: converta tutti i timestamp delle attività in un unico fuso orario di reporting, conservando il timestamp originale della sorgente quando è richiesta la tracciabilità. Si assicuri che LastDataUpdate rappresenti l'ora di aggiornamento o estrazione, non l'ora di occorrenza dell'attività.
Prestazioni: per dataset di grandi dimensioni, filtri le estrazioni della sorgente in base alle partizioni timestamp replicate, selezioni solo le colonne necessarie, utilizzi caricamenti incrementali e materializzi l'Event Log finale. Eviti di unire ripetutamente l'intera cronologia ai record correnti delle candidature senza identificativi indicizzati.
Conservazione dei dati: verifichi che la piattaforma ETL e l'accesso a Greenhouse conservino i record storici delle fasi, dei colloqui, dei feedback, delle offerte e degli esiti per il periodo selezionato. Le sole tabelle dello stato corrente non consentono di ricostruire in modo affidabile le attività storiche.
Mappatura in ProcessMind: configuri JobApplicationId come identificativo del caso, ActivityName come campo dell'attività e ActivityTimestamp come timestamp dell'evento. Si assicuri che il file esportato contenga una riga esplicita per ogni attività e non dipenda da transizioni dedotte.

a Query di esempio 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;

È pronto per iniziare?

Sfrutti appieno il potenziale dei dati relativi alle assunzioni. Inizi oggi stesso a utilizzare questo Template per semplificare il processo di recruiting e prendere decisioni basate sui dati.

Torna alla guida al miglioramento Scarica il Template

Semplifichi oggi stesso l'acquisizione di talenti in Greenhouse

Riduca oggi stesso del 30% il tempo del ciclo di assunzione e migliori l'esperienza dei candidati.

Inizi la prova gratuita

Nessuna carta di credito richiesta \b• Configurazione in 5 minuti

Il Suo Template dei dati per il recruiting e l'acquisizione di talenti

Il Suo Template dei dati per il recruiting e l'acquisizione di talenti

Attributi di recruiting e acquisizione dei talenti

Attività di recruiting e acquisizione dei talenti

Guide all'estrazione

Report Builder di Greenhouse per esportazioni CSV manuali

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite script Python con Greenhouse Harvest API

Passaggi

Configurazione

a Query di esempio python

Strumento ETL automatizzato con connettore Greenhouse

Passaggi

Configurazione

a Query di esempio config

È pronto per iniziare?

Semplifichi oggi stesso l'acquisizione di talenti in Greenhouse

Il Suo Template dei dati per il recruiting e l'acquisizione di talenti

Il Suo Template dei dati per il recruiting e l'acquisizione di talenti

Attributi di recruiting e acquisizione dei talenti

Attività di recruiting e acquisizione dei talenti

Guide all'estrazione

Report Builder di Greenhouse per esportazioni CSV manuali

Passaggi

Configurazione

a Query di esempio config

Estrazione tramite script Python con Greenhouse Harvest API

Passaggi

Configurazione

a Query di esempio python

Strumento ETL automatizzato con connettore Greenhouse

Passaggi

Configurazione

a Query di esempio config

È pronto per iniziare?

Semplifichi oggi stesso l'acquisizione di talenti in Greenhouse

La Sua privacy è importante