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

Il template dei dati per la selezione e l’acquisizione dei talenti

Greenhouse

Attributi per la selezione e l’acquisizione dei talenti(21) Attività di selezione e acquisizione dei talenti(14) Guide all’estrazione(3)

Il template dei dati per la selezione e l’acquisizione dei talenti

Questo template offre indicazioni complete per raccogliere i dati necessari all’analisi del processo di selezione e acquisizione dei talenti. Descrive gli attributi essenziali da monitorare, le attività principali da registrare e come estrarre queste informazioni da Greenhouse. Seguendo il template, potrà creare una base dati adatta a 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 per la selezione e l’acquisizione dei talenti

Questi sono i campi dati consigliati da includere nell’event log per analizzare in modo completo il processo di selezione e acquisizione dei talenti in Greenhouse.

5 Obbligatorio 6 Consigliato 10 Facoltativo

	Nome	Descrizione
	Candidatura per una posizione JobApplicationId	Identificativo univoco della candidatura di una persona a una specifica posizione.
Descrizione L’ID della candidatura per una posizione è il riferimento fondamentale per analizzare il processo di selezione e funge da ID del caso univoco. Collega tutte le attività correlate, dall’invio iniziale e dalla valutazione ai colloqui, alle offerte e alla decisione finale di assunzione. Consente così di ricostruire l’intero percorso di ogni persona candidata, dall’inizio alla fine. Nel Process Mining, questo attributo serve a ricostruire il percorso esatto seguito da ciascuna persona candidata nell’iter di selezione. Consente di analizzare le varianti del processo, i tempi di ciclo per candidatura e i punti di abbandono, offrendo un quadro chiaro dell’intero processo di selezione per ogni singola candidatura. Perché è importante È l’ID del caso essenziale che collega tutti gli eventi di selezione relativi a una singola candidatura e consente di analizzare l’intero percorso di assunzione, dall’inizio alla fine. Dove reperirli In genere è la chiave primaria di un oggetto candidatura. Consultare la documentazione dell’API di Greenhouse per l’endpoint «Applications», spesso indicato come «id» o «application_id». Esempi 987654321098765432119876543212
	Data e ora dell’attività ActivityTimestamp	Data e ora esatte in cui si è svolta l’attività di selezione.
Descrizione La data e ora dell’attività indica il momento esatto in cui si è verificato un evento nel processo di selezione. Costituisce la base temporale per tutte le analisi delle prestazioni e delle durate e definisce l’ordine cronologico delle attività per ogni candidatura. Questo dato è essenziale per calcolare tutti i KPI temporali, come il tempo di assunzione, il tempo di ciclo per la pianificazione dei colloqui e il tempo necessario per ricevere il feedback sui colloqui. Analizzando il tempo trascorso tra le diverse attività, le organizzazioni possono misurare l’efficienza, individuare ritardi e verificare il rispetto degli accordi sui livelli di servizio. In questo modo si alimentano direttamente le Dashboard dedicate alle prestazioni e ai colli di bottiglia. Perché è importante Questo dato è fondamentale per ordinare gli eventi, calcolare i tempi di ciclo e analizzare le prestazioni del processo di selezione. Dove reperirli È disponibile in diversi oggetti di Greenhouse, ad esempio come «applied_at» nell’oggetto Application, «created_at» negli oggetti Offer oppure nei dati temporali dei feed delle attività e dei registri di audit. Esempi 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	Nome dell’attività ActivityName	Nome della specifica attività o fase di selezione che si è verificata.
Descrizione Questo attributo registra il nome di ogni evento del processo di selezione, ad esempio «Candidatura ricevuta», «Colloquio pianificato» o «Offerta accettata». Costituisce la sequenza di eventi che compone la mappa del processo. Analizzare la sequenza e la frequenza di queste attività è fondamentale nel Process Mining. Consente di visualizzare il percorso di selezione, individuare i percorsi più comuni, rilevare le deviazioni dal flusso di lavoro standard e identificare i colli di bottiglia in cui il processo si blocca. Ad esempio, permette di monitorare quante candidature passano da «Candidatura esaminata» a «Colloquio con il recruiter svolto». Perché è importante Questo attributo definisce le fasi del processo di selezione e consente di visualizzare il flusso del processo e individuare colli di bottiglia e deviazioni. Dove reperirli Spesso si ricava mappando le modifiche delle fasi della candidatura, gli stati dei colloqui, gli eventi relativi alle offerte o altre azioni verificabili in Greenhouse. Potrebbe essere necessario applicare una logica per convertire gli eventi di sistema in nomi di attività standardizzati. Esempi Candidatura esaminataColloquio svoltoOfferta accettataCandidatura rifiutata
	Sistema di origine SourceSystem	Identifica il sistema di registrazione da cui sono stati estratti i dati.
Descrizione Questo attributo specifica l’origine dei dati di selezione. Per questo processo, il valore sarà sempre «Greenhouse». Anche se può sembrare un dato statico, registrare esplicitamente il sistema di origine è fondamentale per la governance dei dati, la risoluzione dei problemi e i casi in cui i dati vengono arricchiti con informazioni provenienti da altri sistemi, come un sistema informativo per le risorse umane (HRIS). Chiarisce la provenienza dei dati e contribuisce a mantenerne l’integrità nell’intero patrimonio informativo dell’organizzazione. Perché è importante Garantisce la tracciabilità della provenienza dei dati, fondamentale per la governance, la convalida e la gestione dei dati provenienti da più fonti. Dove reperirli È un valore statico da aggiungere durante l’estrazione e la trasformazione dei dati per indicarne l’origine. Esempi Greenhouse
	Ultimo aggiornamento dei dati LastDataUpdate	Data e ora dell’ultimo aggiornamento o dell’ultima estrazione dei dati relativi a questo evento.
Descrizione Questo attributo registra la data e l’ora dell’ultima estrazione dei dati dal sistema di origine. È un campo di metadati che indica quanto sono aggiornati i dati nel modello di Process Mining. Questa informazione consente agli utenti di capire quanto è aggiornata l’analisi. Aiuta a gestire le aspettative sui ritardi di disponibilità dei dati ed è fondamentale per verificare che la pipeline dei dati venga eseguita secondo la pianificazione. Ad esempio, se l’«Ultimo aggiornamento dei dati» risale a diversi giorni prima, gli utenti sanno che le Dashboard non riflettono le attività di selezione più recenti. Perché è importante Indica quanto sono aggiornati i dati e aiuta gli utenti a capire se l’analisi riflette lo stato più recente del processo. Dove reperirli Questo dato temporale viene generato e aggiunto al set di dati durante il processo di estrazione, trasformazione e caricamento (ETL). Esempi 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	Fonte della candidatura ApplicationSource	Canale attraverso cui è stata ricevuta la candidatura.
Descrizione Questo attributo registra la provenienza di una candidatura, ad esempio «LinkedIn», «Segnalazione di un dipendente», «Sito web dell’azienda» o «Indeed». Consente di valutare l’efficacia dei diversi canali di selezione. La Dashboard «Efficacia dei canali di ricerca» si basa interamente su questo attributo. Analizzando per fonte il volume delle candidature, il tempo di assunzione e il tasso di assunzione, le organizzazioni possono ottimizzare gli investimenti e le attività di selezione. Questi dati aiutano a capire quali canali permettono di trovare con maggiore efficienza le persone candidate più qualificate e supportano direttamente il KPI «Tasso di conversione dei canali di ricerca». Perché è importante Aiuta a misurare l’efficacia e il ritorno sull’investimento dei diversi canali di selezione, consentendo di decidere sulla base dei dati dove concentrare le attività di ricerca. Dove reperirli Disponibile nell’oggetto Candidate di Greenhouse, collegato all’oggetto Application. L’informazione è contenuta nel campo «source». Esempi LinkedInSegnalazione di un dipendentePagina Lavora con noi dell’aziendaIndeed
	Nome del recruiter RecruiterName	Nome del recruiter responsabile della gestione della candidatura.
Descrizione Questo attributo identifica il recruiter assegnato a una specifica candidatura o richiesta di assunzione. In genere, questa persona si occupa della valutazione iniziale, del coordinamento dei colloqui e dell’avanzamento della candidatura nel processo. Analizzare il processo per recruiter è fondamentale per comprendere le prestazioni individuali e la distribuzione del carico di lavoro. La Dashboard «Carico di lavoro ed efficienza dei recruiter» utilizza questo attributo per calcolare metriche come il volume di attività e i tempi di ciclo per recruiter. Aiuta a individuare chi ottiene i risultati migliori, chi potrebbe aver bisogno di ulteriore supporto e come distribuire il carico di lavoro in modo equilibrato nel team di selezione. Perché è importante Associa le attività del processo a un recruiter specifico e consente di analizzare le prestazioni individuali, il carico di lavoro e l’efficienza. Dove reperirli Disponibile nell’oggetto Job di Greenhouse, in genere nella sezione «hiring_team», che specifica ruoli come «Recruiter». Esempi Alice JohnsonRobert DavisMaria Garcia
	Reparto della posizione JobDepartment	Reparto o unità aziendale per cui si sta cercando una persona da assumere.
Descrizione Questo attributo specifica il reparto dell’organizzazione, ad esempio «Ingegneria», «Marketing» o «Vendite», associato alla richiesta di assunzione. Consente di aggregare e confrontare le metriche di selezione tra le diverse aree dell’azienda. Segmentare l’analisi per reparto è fondamentale per Dashboard come «Prestazioni del tempo di assunzione» e «Andamento del tasso di accettazione delle offerte». Aiuta a individuare eventuali reparti con cicli di assunzione più lunghi, tassi di rifiuto delle offerte più elevati o livelli diversi di conformità del processo. Queste informazioni consentono di intervenire in modo mirato e migliorare il processo in base alle esigenze specifiche di ciascun reparto. Perché è importante Consente di confrontare le prestazioni della selezione e le variazioni del processo tra i reparti, facendo emergere problemi sistemici o pratiche efficaci. Dove reperirli In genere è disponibile come campo standard o personalizzato nell’oggetto Job di Greenhouse. Tramite API, si trova nella sezione «departments» di un record Job. Esempi IngegneriaGestione del prodottoVenditeMarketing
	Stato dell’offerta OfferStatus	Stato attuale di un’offerta di lavoro presentata a una persona candidata.
Descrizione Questo attributo registra lo stato di un’offerta di lavoro, con valori come «Creata», «Presentata», «Accettata» o «Rifiutata». È un indicatore chiave delle fasi finali del processo di selezione. Questo attributo è essenziale per la Dashboard «Andamento del tasso di accettazione delle offerte» e per il relativo KPI. Monitorando il passaggio da «Offerta presentata» a «Offerta accettata» o «Offerta rifiutata», le aziende possono misurare la propria capacità di concludere positivamente il processo con le persone candidate. L’analisi per reparto o titolo della posizione può far emergere informazioni sulla competitività della retribuzione, sull’esperienza delle persone candidate o su altri fattori che influenzano la decisione. Perché è importante Registra l’esito delle offerte di lavoro, un dato fondamentale per calcolare il KPI del tasso di accettazione delle offerte e capire come migliorarlo. Dove reperirli Disponibile nell’oggetto Offer di Greenhouse, collegato a un oggetto Application. L’informazione è contenuta nel campo «status». Esempi AccettataRifiutataInviataCreata
	Stato della candidatura ApplicationStatus	Esito finale o stato attuale della candidatura per una posizione.
Descrizione Questo attributo indica l’esito di una candidatura, ad esempio «Assunta», «Rifiutata» o «Attiva». Rappresenta lo stato finale 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 delle persone assunte con quelli delle persone non selezionate, facendo emergere le caratteristiche dei percorsi conclusi con successo. Serve inoltre a calcolare i tassi di conversione nella Dashboard «Percorso complessivo di selezione», che mostra la percentuale di candidature che si conclude con un’assunzione. Perché è importante Definisce l’esito del processo di selezione e consente di confrontare i percorsi delle persone assunte con quelli delle persone non selezionate. Dove reperirli Questa informazione è disponibile nel campo «status» dell’oggetto Application in Greenhouse, tramite API. Esempi AssuntaRifiutataAttiva
	Titolo della posizione JobTitle	Titolo della posizione per cui la persona candidata ha presentato la candidatura.
Descrizione Questo attributo contiene il titolo ufficiale della posizione, ad esempio «Ingegnere software senior» o «Responsabile del marketing di prodotto». Fornisce informazioni essenziali sul ruolo da ricoprire. Analizzare i processi di selezione per titolo della posizione è fondamentale per comprendere le difficoltà specifiche dei diversi ruoli. Ad esempio, la Dashboard «Prestazioni del tempo di assunzione» utilizza questo attributo per mostrare se occorre più tempo per coprire posizioni senior o altamente specializzate. Aiuta inoltre ad analizzare i tassi di accettazione delle offerte per le diverse posizioni e a valutare la competitività della retribuzione o l’attrattiva del ruolo. Perché è importante Consente di filtrare e confrontare le metriche di selezione per ruoli specifici e di capire come le prestazioni del processo variano in base alla complessità o alla tipologia della posizione. Dove reperirli È un campo principale dell’oggetto Job in Greenhouse, spesso disponibile come «name» quando si interroga l’endpoint «jobs» tramite API. Esempi Ingegnere software seniorResponsabile commercialeProgettista UX/UI
	Attività automatizzata IsAutomated	Indicatore che specifica 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. Tra le attività automatizzate rientrano, ad esempio, l’invio di e-mail di risposta automatiche o il rifiuto automatico delle candidature che non superano una domanda di valutazione iniziale. Analizzare questo attributo aiuta a comprendere il livello di automazione del processo di selezione. Consente di confrontare l’efficienza e gli esiti delle fasi automatizzate con quelli delle fasi manuali e di individuare opportunità per aumentare l’automazione e migliorare la rapidità e la coerenza del processo. Perché è importante Aiuta a distinguere le attività manuali da quelle automatizzate e consente di analizzare l’impatto dell’automazione sull’efficienza e sugli esiti del processo. Dove reperirli Questa informazione non è un campo standard e in genere deve essere ricavata. 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	Indicatore calcolato che specifica se la candidatura ha seguito il processo di selezione standard 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 presentano deviazioni, ad esempio quando vengono saltate fasi obbligatorie o le attività vengono svolte nell’ordine sbagliato. È un attributo fondamentale per la Dashboard «Deviazioni dalla conformità nel processo di selezione» e supporta i KPI «Tasso di conformità del processo» e «Numero di violazioni della conformità». Filtrando i casi non conformi, le organizzazioni possono indagare sulle cause delle deviazioni, che potrebbero dipendere da formazione insufficiente, limiti dei sistemi o eccezioni necessarie. Questo aiuta a standardizzare i flussi di lavoro e a ridurre i rischi di non conformità. Perché è importante Individua le deviazioni del processo, un aspetto fondamentale per misurare la conformità del processo, garantire la conformità e standardizzare i flussi di lavoro di selezione. Dove reperirli È un campo calcolato generato dal software di Process Mining, che confronta i dati dell’Event Log con un modello obiettivo definito o con un insieme di regole aziendali. Esempi truefalse
	Fase del colloquio InterviewStageName	Nome o tipologia specifica della fase del colloquio.
Descrizione Questo attributo specifica la fase del processo di colloquio, ad esempio «Colloquio con il recruiter», «Colloquio tecnico» o «Colloquio finale». Offre un livello di dettaglio maggiore rispetto a un’attività generica come «Colloquio completato». Analizzando le metriche di ogni singola fase del colloquio, le organizzazioni possono individuare colli di bottiglia più specifici. Ad esempio, è possibile misurare con precisione il «Tasso di abbandono delle persone candidate per fase» e capire se le candidature vengono ritirate più spesso dopo il colloquio tecnico o dopo la valutazione iniziale. Questo livello di dettaglio è fondamentale per migliorare in modo mirato l’esperienza dei colloqui. Perché è importante Offre una visione più dettagliata del processo di colloquio e consente di analizzare i tempi di ciclo e i tassi di abbandono per ogni singola fase. Dove reperirli Questa informazione fa parte dei dati di pianificazione dei colloqui in Greenhouse. L’oggetto «interviews» di una candidatura contiene i dettagli della fase del colloquio. Esempi Colloquio con il recruiterColloquio con il responsabile delle assunzioniValutazione tecnicaColloquio finale in sede
	ID della persona candidata CandidateId	Identificativo univoco della persona candidata, indipendente da una singola candidatura.
Descrizione L’ID della persona candidata identifica in modo univoco una persona nel bacino di talenti, mentre l’ID della candidatura per una posizione si riferisce a una singola candidatura per una specifica posizione. Nel tempo, la stessa persona può presentare più candidature. L’ID della candidatura per una posizione funge da ID del caso per questa specifica vista del processo, mentre l’ID della persona candidata consente un altro tipo di analisi. Può essere utilizzato per seguire il percorso di una persona attraverso più candidature, individuare chi si candida spesso e analizzare nel complesso il rapporto con il bacino di talenti. Offre una prospettiva dei dati di selezione incentrata sulla persona. Perché è importante Consente di analizzare più candidature della stessa persona e offre una visione più ampia del suo coinvolgimento nel tempo. Dove reperirli È la chiave primaria di un record relativo a una persona candidata in Greenhouse ed è disponibile come «id» nell’oggetto Candidate tramite API. Esempi 123456123457123458
	ID della posizione JobId	Identificativo univoco della richiesta di assunzione o dell’annuncio.
Descrizione Questo attributo è l’ID univoco della posizione, distinto dall’ID della candidatura. Più candidature possono essere associate allo stesso ID della posizione. L’ID della posizione 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 tutte le posizioni di una tipologia simile. Permette di raggruppare e analizzare le attività di selezione 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 reperirli È la chiave primaria di un record di posizione lavorativa in Greenhouse, disponibile come 'id' nell’oggetto Job tramite API. Esempi 400123400124400125
	Motivo del rifiuto RejectionReason	Motivo indicato per il rifiuto della candidatura.
Descrizione Questo attributo registra il motivo specifico per cui la candidatura non è proseguita. Alcuni esempi sono «Non in linea con la cultura aziendale», «Aspettative retributive troppo elevate» o «Sono state selezionate persone più qualificate». Analizzare i motivi dei rifiuti fornisce indicazioni preziose sul processo di selezione. Può far emergere problemi come descrizioni delle posizioni non adeguate, retribuzioni non competitive o lacune ricorrenti nelle competenze delle persone candidate. Queste informazioni sono particolarmente utili per migliorare le strategie di ricerca e l’esperienza delle persone candidate, individuando i punti in cui il processo di selezione si interrompe più spesso. Perché è importante Fornisce indicazioni qualitative sui motivi per cui le candidature vengono escluse, aiutando a perfezionare le descrizioni delle posizioni, le attività di ricerca e i criteri di valutazione. Dove reperirli Disponibile nell’oggetto Application quando la candidatura viene rifiutata. L’API fornisce un oggetto «rejection_reason» con i dettagli. Esempi Competenze richieste non presentiAspettative retributive troppo elevateSelezionata una persona più qualificata
	Nome del responsabile delle assunzioni HiringManagerName	Nome del responsabile delle assunzioni per la richiesta di assunzione associata.
Descrizione Questo attributo identifica il responsabile del team con una posizione aperta. È una figura chiave nel processo, spesso coinvolta nella valutazione delle candidature, nei colloqui delle fasi successive e nella decisione finale di assunzione. Analizzare il processo per responsabile delle assunzioni può far emergere schemi ricorrenti e colli di bottiglia. Ad esempio, la Dashboard «Colli di bottiglia nella pianificazione dei colloqui» potrebbe mostrare che alcuni ritardi dipendono spesso dalla disponibilità di specifici responsabili. L’analisi aiuta a individuare esigenze di formazione o supporto, affinché i responsabili partecipino al processo di selezione in modo efficiente. Perché è importante Identifica una figura chiave e consente di analizzare i colli di bottiglia o le efficienze del processo associati a specifici responsabili delle assunzioni. Dove reperirli Disponibile nell’oggetto Job di Greenhouse, in genere nella sezione «hiring_team», che specifica ruoli come «Hiring Manager». Esempi Emily TranDavid ChenSophia Rodriguez
	Ora di fine dell’attività ActivityEndTime	Data e ora in cui si è conclusa un’attività di durata misurabile.
Descrizione Questo attributo registra l’ora di completamento delle attività che si svolgono in un intervallo di tempo, come un colloquio o una verifica dei precedenti. Anche se molte attività sono istantanee, per quelle di durata misurabile è utile registrare sia l’ora di inizio sia quella di fine. L’ora di fine è fondamentale per calcolare con precisione il tempo di elaborazione o la durata di specifiche attività. Aiuta a distinguere il tempo di attesa tra le fasi dal tempo effettivamente dedicato a un’attività. Ad esempio, consente di analizzare con maggiore precisione la durata effettiva dei colloqui, separandola dal tempo necessario per pianificarli. Perché è importante Consente di calcolare con precisione i tempi di elaborazione delle attività e di distinguere il tempo di lavoro effettivo dai tempi di attesa nel processo. Dove reperirli Questa informazione potrebbe essere disponibile in oggetti come «scheduled_interview» di Greenhouse, che spesso includono sia l’ora di «start» sia quella di «end». Per le altre attività, potrebbe essere necessario dedurla dall’ora dell’attività successiva. Esempi 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	Raccomandazione nella scheda di valutazione ScorecardOverallRecommendation	Raccomandazione complessiva per l’assunzione formulata nella scheda di valutazione di un colloquio completato.
Descrizione Questo attributo registra la raccomandazione finale del selezionatore nella scheda strutturata del colloquio. I valori tipici sono «Assolutamente sì», «Sì», «No» e «Assolutamente no». Questi dati sono fondamentali per valutare la qualità e la coerenza del processo di colloquio. Aiutano a mettere in relazione i feedback dei colloqui con gli esiti effettivi delle assunzioni e a rispondere a domande come «Le persone candidate che ricevono raccomandazioni più positive vengono assunte più spesso?». Sono inoltre alla base del KPI «Tasso di completamento delle schede di valutazione», che misura l’adozione di pratiche di selezione strutturate nell’organizzazione. Perché è importante Collega i feedback strutturati dei colloqui agli esiti del processo e aiuta a misurare l’adozione di pratiche di selezione basate sui dati. Dove reperirli Disponibile nell’oggetto Scorecard associato a un colloquio completato in Greenhouse. L’API fornisce questa informazione tramite l’endpoint «scorecards». Esempi Assolutamente noNoSìAssolutamente sì
	Tempo di risposta al feedback del colloquio InterviewFeedbackTurnaroundTime	Tempo trascorso tra la conclusione di un colloquio e l’invio del feedback da parte del selezionatore.
Descrizione Questa metrica calcolata misura la tempestività del gruppo di selezionatori. I ritardi nell’invio del feedback possono rallentare notevolmente il processo di assunzione e compromettere l’esperienza della persona candidata. Questo attributo supporta direttamente la Dashboard «Analisi del ciclo di feedback dei colloqui» e il KPI «Tempo di risposta al feedback del colloquio». Si calcola come differenza tra l’ora delle attività «Colloquio completato» e «Feedback inviato». Monitorare questa metrica aiuta a individuare i colli di bottiglia dovuti a feedback tardivi e favorisce decisioni più rapide. Perché è importante Misura l’efficienza del ciclo di feedback successivo al colloquio, una causa frequente di ritardi nel processo di assunzione. Dove reperirli È un campo calcolato, ottenuto sottraendo l’ora dell’evento «Colloquio completato» da quella dell’evento «Feedback inviato». Esempi 86400172800259200

Obbligatorio Consigliato Facoltativo

Attività di selezione e acquisizione dei talenti

Queste sono le fasi e i traguardi principali da registrare nell’event log per individuare con precisione il processo e ottimizzare il percorso di selezione.

7 Consigliato 7 Facoltativo

	Attività	Descrizione
	Candidatura ricevuta	Questa attività segna l’inizio del processo di selezione per una specifica candidatura. Viene registrata quando un candidato invia la propria candidatura tramite il sito dedicato alle opportunità di lavoro o un canale di ricerca, oppure quando viene inserita manualmente in Greenhouse.
Perché è importante È l’evento di inizio principale del processo. Analizzare il tempo che intercorre tra questa attività e le successive è essenziale per misurare il tempo necessario per assumere e l’efficacia dei canali di ricerca. Dove reperirli È un evento esplicito registrato in Greenhouse al momento della creazione di una candidatura. La data della candidatura o la data e ora di creazione dell’oggetto candidatura forniscono il momento dell’evento. Acquisizione Ricavato dalla data e ora di creazione del record della candidatura. Tipo di evento explicit
	Candidatura rifiutata	La candidatura della persona è stata rifiutata in una fase del processo. È l’evento conclusivo negativo più comune e può verificarsi in qualsiasi fase.
Perché è importante È un evento conclusivo fondamentale per analizzare i tassi di abbandono nelle diverse fasi della selezione. Capire quando e perché le candidature vengono rifiutate aiuta a individuare inefficienze nel processo o requisiti del ruolo non adeguati. Dove reperirli È un evento esplicito registrato quando un utente rifiuta la candidatura in Greenhouse. Spesso è accompagnato dal motivo del rifiuto e l’ora viene registrata nel registro delle attività. Acquisizione Registrato in base all’ora dell’azione di rifiuto della candidatura. Tipo di evento explicit
	Colloquio pianificato	Nel sistema è stato pianificato un colloquio con il candidato. Greenhouse si integra con i calendari, quindi l’evento viene in genere registrato esplicitamente quando il colloquio è confermato.
Perché è importante Questo evento è fondamentale per analizzare e individuare i colli di bottiglia nella pianificazione dei colloqui. Il tempo tra questo evento e il passaggio precedente è un KPI importante per misurare l’efficienza di recruiter e coordinatori. Dove reperirli Registrato tramite la funzione di pianificazione dei colloqui di Greenhouse. L’API fornisce i dati sui colloqui pianificati, compresa la data e ora di creazione. Acquisizione Registrato quando viene creato un evento di colloquio e associato alla candidatura. Tipo di evento explicit
	Colloquio svolto	Il colloquio con il candidato si è svolto. Spesso lo si deduce dal trascorrere dell’orario pianificato oppure, con maggiore affidabilità, dall’invio del feedback relativo al colloquio.
Perché è importante Questa attività è una tappa importante nel percorso del candidato. Costituisce il punto di partenza per misurare i tempi di invio del feedback e il passaggio alla fase successiva. Dove reperirli In genere si deduce dai dati disponibili. Può essere ricavato dall’orario di fine del colloquio pianificato o, con maggiore precisione, dalla data e ora del primo feedback inviato per quel colloquio. Acquisizione Si deduce dall’orario di fine del colloquio pianificato o dalla data e ora dell’invio del feedback successivo. Tipo di evento inferred
	Offerta accettata	Il candidato ha accettato formalmente l’offerta di lavoro. È una tappa fondamentale per il successo della selezione e in genere dà avvio alle attività successive, come i controlli dei precedenti.
Perché è importante È una tappa fondamentale per il successo della selezione e un elemento chiave del KPI del tasso di accettazione delle offerte. Segna il passaggio da candidato a futuro dipendente. Dove reperirli Si tratta di un evento esplicito registrato in Greenhouse quando lo stato dell’offerta viene aggiornato a «Accettata», dal recruiter oppure tramite l’accettazione elettronica della persona candidata. Acquisizione Registrato in base all’ora in cui lo stato dell’offerta passa ad «Accettata». Tipo di evento explicit
	Offerta inviata	L’offerta di lavoro ufficiale è stata inviata al candidato. È una tappa fondamentale, che segna il completamento del processo di colloquio e selezione.
Perché è importante Questa attività costituisce la base per calcolare il KPI del tasso di accettazione delle offerte. Segna l’inizio della fase decisionale finale per il candidato. Dove reperirli È un evento esplicito registrato in Greenhouse quando lo stato dell’offerta passa a «Inviata» o «Presentata». L’oggetto dell’offerta contiene le date e le ore di queste modifiche di stato. Acquisizione Registrato tramite la data e ora in cui l’offerta viene contrassegnata ufficialmente come inviata. Tipo di evento explicit
	Persona candidata assunta	La persona candidata ha superato tutti i controlli preassuntivi ed è stata ufficialmente contrassegnata come assunta. Questo evento segna il completamento positivo e la conclusione del processo di candidatura.
Perché è importante È il principale esito positivo del processo. Il tempo che intercorre tra «Candidatura ricevuta» e questo evento corrisponde al tempo complessivo di assunzione, un KPI fondamentale per la selezione. Dove reperirli In Greenhouse, il recruiter esegue un’azione esplicita per contrassegnare la persona candidata come assunta per una posizione specifica. In questo modo, la persona passa dallo stato di candidata attiva a quello di assunta. Acquisizione Registrato in base all’ora dell’azione «Contrassegna come assunta» in Greenhouse. Tipo di evento explicit
	Avvio dell’inserimento in azienda	È ufficialmente iniziato l’inserimento della nuova risorsa in azienda. Spesso questo passaggio comporta il trasferimento dei dati dal sistema di selezione a un sistema informativo per le risorse umane (HRIS) o a una piattaforma di inserimento.
Perché è importante Consente di monitorare l’efficienza del passaggio dalla selezione alle risorse umane. Eventuali ritardi possono compromettere l’esperienza della nuova risorsa, perciò è fondamentale monitorare il tempo necessario per il passaggio all’inserimento in azienda. Dove reperirli Può essere un evento esplicito se Greenhouse è integrato con un sistema di inserimento. In caso contrario, si deduce dall’ora in cui la persona candidata viene spostata alla fase finale «Assunta», che attiva il passaggio. Acquisizione Deducibile da una modifica della fase o da un registro di integrazione che segnala il passaggio a un sistema informativo per le risorse umane (HRIS). Tipo di evento inferred
	Avvio della verifica dei precedenti	È stata avviata una verifica dei precedenti della persona candidata, in genere dopo l’accettazione dell’offerta. L’avvio può essere registrato come modifica di una fase specifica oppure come attivazione di un’integrazione con un servizio di terze parti.
Perché è importante Questa attività è importante ai fini della conformità e per monitorare i ritardi nelle verifiche preassuntive. Consente di analizzare il tempo che intercorre tra l’accettazione dell’offerta e il completamento dei controlli necessari. Dove reperirli Probabilmente si deduce dal passaggio della persona candidata alla fase «Verifica dei precedenti» nella pipeline di selezione oppure da un registro delle attività relativo a un’integrazione per le verifiche. Acquisizione Deducibile da una modifica dello stato alla fase «Verifica dei precedenti» o da un registro API di un servizio integrato. Tipo di evento inferred
	Candidatura esaminata	Un recruiter o un responsabile delle assunzioni ha effettuato una prima revisione della candidatura. In genere, l’attività si deduce dal passaggio della candidatura dallo stato «Nuova» a una fase di revisione attiva, come «In revisione».
Perché è importante Il monitoraggio aiuta a individuare i colli di bottiglia nella fase iniziale di selezione e a misurare il tempo necessario perché le nuove candidature vengano prese in carico. È il punto di partenza per calcolare il tempo di ciclo della pianificazione dei colloqui. Dove reperirli Si deduce da una modifica del campo dello stato della candidatura. Si cercano i passaggi dallo stato «Nuova» allo stato «In revisione», utilizzando la data e ora della modifica. Acquisizione Si deduce dalla data e ora del passaggio allo stato «In revisione» o a una fase simile. Tipo di evento inferred
	Colloquio iniziale con il recruiter svolto	Un recruiter ha svolto una prima telefonata o conversazione con il candidato. Spesso l’attività viene registrata quando il candidato passa alla fase «Colloquio telefonico» nel processo di selezione.
Perché è importante È una tappa fondamentale della valutazione, che indica che la candidatura ha superato la prima selezione dei documenti. Aiuta a misurare il carico di lavoro dei recruiter e l’efficacia della selezione iniziale. Dove reperirli Si deduce dalla data e ora in cui la candidatura viene spostata dentro o fuori dalla fase «Colloquio telefonico» nel processo di selezione di Greenhouse. Acquisizione Ricavato dalla cronologia delle fasi della candidatura, in particolare dal passaggio alla fase «Colloquio telefonico». Tipo di evento inferred
	Feedback inviato	Un intervistatore ha inviato la scheda di valutazione o il feedback sul colloquio con un candidato. Il processo di selezione strutturato di Greenhouse si basa su queste informazioni per prendere decisioni, quindi l’invio è un’azione distinta e registrata.
Perché è importante La tempestività del feedback è fondamentale per far avanzare i candidati. Questa attività consente di analizzare l’efficienza del ciclo di feedback e il tasso di completamento delle schede di valutazione. Dove reperirli È un evento esplicito registrato quando un intervistatore invia una scheda di valutazione tramite Greenhouse. L’oggetto Scorecards dell’API contiene la data e ora `submitted_at`. Acquisizione Registrato tramite la data e ora di invio della scheda di valutazione del colloquio. Tipo di evento explicit
	Offerta creata	È stata preparata un’offerta di lavoro ufficiale, che potrebbe essere in attesa di approvazione interna. Questo evento segna la decisione formale di presentare un’offerta al candidato.
Perché è importante Questa attività distingue la decisione di formulare un’offerta dal suo invio. Aiuta ad analizzare i tempi di approvazione interna e i colli di bottiglia prima che l’offerta arrivi al candidato. Dove reperirli Greenhouse dispone di un modulo dedicato alle offerte. Si tratta di un evento esplicito, ricavato dalla data e ora 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	La persona candidata ha rifiutato formalmente l’offerta di lavoro. È un evento conclusivo negativo che si verifica nelle fasi finali del processo di selezione.
Perché è importante Monitorare questo esito è fondamentale per analizzare il tasso di accettazione delle offerte. Se l’evento si verifica spesso, potrebbero esserci problemi legati alla retribuzione, alla cultura aziendale o al ruolo. Dove reperirli Si tratta di un evento esplicito registrato in Greenhouse quando lo stato dell’offerta viene aggiornato a «Rifiutata» o «Declinata». L’oggetto dell’offerta include l’ora della modifica dello stato. Acquisizione Registrato in base all’ora in cui lo stato dell’offerta passa a «Rifiutata». Tipo di evento explicit

Consigliato Facoltativo

Guide all’estrazione

Come ottenere i dati da Greenhouse

Passaggi

Acceda al Suo account Greenhouse Recruiting.
Apra la sezione Reports facendo clic sull’icona dei report, raffigurata come 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 dei relativi traguardi.
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à. Includa: 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, è necessario 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 saranno disponibili i timestamp della pianificazione e dell’invio del feedback.
Per entrambi i report, imposti l’intervallo di date appropriato tramite i filtri. Un filtro comune è 'Applied On', impostato su 'All Time' oppure su un intervallo specifico, ad esempio gli ultimi 6 mesi, per includere un gruppo di candidature pertinente.
Generi ciascun report facendo clic sul pulsante 'Update' o 'Generate'. Quando il report è visualizzato, faccia clic su 'Export to Excel' per scaricare i dati in un file CSV. Otterrà così due file CSV distinti.
I file esportati non sono ancora in formato event log. È necessario trasformarli con uno strumento come Python o R, oppure con un foglio di calcolo dotato di funzioni per annullare la pivot, come Power Query di Microsoft Excel.
Unisca i dati dei report 'All Applications' e 'Interview Details' utilizzando Application ID come chiave.
Per ogni candidatura, crei una riga distinta per ciascuna colonna di data pertinente esportata. Per esempio, il valore della colonna 'Applied On' diventa 'ActivityTimestamp' per un’attività denominata 'Application Received'. Il valore di 'Rejected On' genera 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 il file finale in un unico CSV da caricare.

Configurazione

Report principali: l’estrazione combina i dati di 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 come 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 come Application ID, Interview Name, Scheduled Start e Scorecard Submitted At.
Filtri per intervallo di date: si consiglia di filtrare le candidature in base alla data 'Applied On', considerando un periodo da 3 a 6 mesi, così da ottenere un insieme di dati pertinente e gestibile. Intervalli più lunghi possono incidere sulle prestazioni.
Prerequisiti: chi 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'.

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 una chiave API Greenhouse
- Acceda al Suo account Greenhouse con autorizzazioni di sviluppatore.
- Vada a Configure > Dev Center > API Credential Management.
- Faccia clic su "Create New API Key".
- Inserisca una descrizione, ad esempio "Estrazione ProcessMind".
- Selezioni "Harvest" come tipo.
- Conceda alla chiave le autorizzazioni necessarie. Come minimo, servono autorizzazioni GET per: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards e Users.
- Copi la chiave API generata e la conservi in modo sicuro. Non sarà possibile visualizzarla di nuovo.
Configurare l’ambiente Python
- Verifichi che sul sistema sia installato Python 3.6 o una versione successiva.
- Installi le librerie Python necessarie eseguendo nel terminale i comandi: pip install requests e pip install pandas.
Preparare 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 scegliere una data compresa tra 3 e 6 mesi fa.
Personalizzare la mappatura delle fasi e delle attività
- Riveda il dizionario STAGE_TO_ACTIVITY nello script.
- Questo dizionario associa i nomi delle fasi di selezione specifiche della Sua azienda in Greenhouse ai nomi standard delle attività richiesti per il Process Mining.
- È necessario aggiornare questa mappatura in base alla configurazione Greenhouse specifica della Sua organizzazione. Per esempio, se la fase 'Recruiter Screen' è denominata 'Initial Recruiter Chat', aggiorni il dizionario di conseguenza.
Eseguire lo script di estrazione
- Apra un terminale o il prompt dei comandi.
- Raggiunga la cartella 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 Greenhouse, recupererà i dati, li elaborerà e mostrerà gli aggiornamenti sullo stato dell’operazione nella console.
Recuperare l’event log
- Al termine dell’esecuzione, nella stessa cartella verrà creato un file denominato greenhouse_event_log.csv.
- Questo file CSV è l’event log finale, con le colonne e le attività richieste.
Gestire 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 e l’elaborazione sarà più rapida.
Caricare i dati in ProcessMind
- Il file greenhouse_event_log.csv generato è pronto per essere caricato direttamente in ProcessMind. Verifichi che i nomi delle colonne del file siano mappati 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 comportano l’assenza dei dati relativi ad alcune attività.
Filtro per intervallo di date: lo script utilizza il parametro updated_after (variabile START_DATE_ISO) per filtrare le candidature. Per la prima estrazione, imposti un intervallo ampio, ad esempio gli ultimi 6 mesi. Per i caricamenti incrementali successivi, imposti il timestamp dell’ultima esecuzione completata correttamente, così da migliorare le prestazioni.
Mappatura delle fasi e delle attività: il dizionario STAGE_TO_ACTIVITY nello script è fondamentale. Deve essere configurato in modo da rispecchiare con precisione le fasi di selezione specifiche della Sua azienda in Greenhouse e identificare correttamente attività come 'Recruiter Screen Conducted' e 'Background Check Initiated'.
Limiti di frequenza dell’API: lo script include una breve pausa fissa tra le richieste API per rispettare i limiti di frequenza 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 riguarda eventi con timestamp e cambiamenti di stato. Non acquisisce contenuti dettagliati come le note dei colloqui o le comunicazioni e-mail, ma solo i metadati che attestano il verificarsi di un evento.

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 uso includa un connettore Greenhouse e che questo supporti gli oggetti Greenhouse o i dati replicati relativi a candidature, cronologia delle fasi delle candidature, colloqui, feedback sui colloqui, offerte, cambiamenti di stato delle offerte, controlli dei precedenti, passaggi all’inserimento e risultati delle assunzioni. I nomi degli oggetti variano a seconda della piattaforma: consulti il catalogo dei connettori 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. Segua la procedura di autorizzazione documentata per il connettore e conceda solo le autorizzazioni necessarie per leggere i dati di selezione scelti.
Configuri un data warehouse di destinazione e abiliti la replica degli oggetti sorgente necessari per creare l’event log. Come minimo, selezioni gli oggetti che espongono le candidature, lo stato o la cronologia delle fasi, i colloqui, il feedback sui colloqui, le offerte, i cambiamenti di stato delle offerte, gli eventi relativi ai controlli dei precedenti, i passaggi all’inserimento e i risultati delle assunzioni. Se un oggetto necessario non è disponibile, documenti il limite e mappi la sorgente supportata più simile 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 osservazione precedente se alcune candidature potrebbero essere state create prima dell’intervallo selezionato ma aver fatto progressi al suo interno. Configuri la replica incrementale e conservi i timestamp di aggiornamento della sorgente, se disponibili.
Esamini lo schema replicato e sostituisca ogni segnaposto nella query con lo schema di destinazione effettivo, i nomi di tabelle e colonne, i campi timestamp, gli identificativi e i valori di stato esposti dal connettore. Non presuma che siano disponibili cambiamenti di fase, record di colloqui o feedback, offerte, controlli dei precedenti, passaggi all’inserimento o risultati delle assunzioni, a meno che non siano 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. Uniformi i timestamp su un unico fuso orario, rimuova i record privi di un identificativo valido della candidatura o di un timestamp dell’attività e mantenga 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 colloquio con il selezionatore o una transizione configurata alla fase di colloquio telefonico per Recruiter Screen Conducted; la 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 proposta per Offer Extended; lo stato di offerta accettata per Offer Accepted; un evento registrato di avvio del controllo dei precedenti per Background Check Initiated; un passaggio o un evento di avvio dell’inserimento per Onboarding Initiated; un esito di assunzione per Candidate Hired; un esito di offerta rifiutata per Offer Rejected; un esito di candidatura respinta 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, a meno che una regola aziendale documentata non li identifichi come duplicati tecnici. Se è necessario deduplicare, elimini solo gli eventi sorgente identici, ad esempio quelli con lo stesso identificativo della candidatura, nome dell’attività, timestamp dell’attività e identificativo del record sorgente.
Convalidi il risultato con i controlli indicati di seguito. Verifichi che siano presenti tutte le colonne richieste, che i timestamp siano validi, che ogni attività richiesta sia rappresentata quando esistono dati sorgente e che l’identificativo del caso sia univoco per ogni candidatura. Esamini separatamente le candidature respinte, ritirate, archiviate e incomplete, per evitare che i filtri eliminino involontariamente esiti validi del processo.
Esporti o renda disponibile il risultato finale come file CSV semplice o tramite una connessione 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, mantenga 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 con licenza, dotata di un connettore Greenhouse supportato e di 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 scelti.
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, il feedback, le offerte e gli eventuali dati integrati relativi ai controlli dei precedenti o all’inserimento utilizzati nella mappatura.
Oggetti replicati: selezioni tutti gli oggetti sorgente necessari per le 14 estrazioni degli eventi. Non abiliti solo la tabella delle candidature correnti se la cronologia delle fasi, le attività dei colloqui, l’invio del feedback, i passaggi delle offerte o i trasferimenti ai processi successivi sono archiviati separatamente.
Intervallo di date: inizi con un periodo da 3 a 6 mesi per l’analisi operativa. Lo estenda quando misura l’intero ciclo di vita delle candidature, poiché quelle create prima del periodo potrebbero arrivare in seguito ai colloqui, alle offerte o all’assunzione.
Aggiornamento incrementale: conservi, se disponibili, i timestamp di creazione, occorrenza e ultimo aggiornamento della sorgente. Configuri aggiornamenti ricorrenti in base alla latenza richiesta per i report e includa un breve intervallo di sovrapposizione per i record arrivati in ritardo o corretti.
Filtri: applichi solo filtri documentati e specifici dell’azienda, ad esempio per 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 richiesti dalla configurazione.
Mappatura delle attività: mantenga una mappatura documentata tra il tipo di evento, la fase, lo stato o il timestamp sorgente e ciascun ActivityName. Configuri i valori esatti per revisione, colloquio telefonico, rifiuto, offerta, accettazione, controllo dei precedenti, inserimento e assunzione in base a quelli utilizzati dall’organizzazione.
Gestione dei valori nulli: consenta che RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource e OfferStatus siano null quando la sorgente non li fornisce. Se mancano identificativi o timestamp obbligatori, rifiuti i record o ne verifichi la causa.
Fusi orari: converta tutti i timestamp delle attività in un unico fuso orario per i report, conservando il timestamp originale della sorgente quando è necessario garantire la tracciabilità. Verifichi che LastDataUpdate indichi l’ora di aggiornamento o estrazione, non quella in cui si è verificata l’attività.
Prestazioni: per insiemi di dati di grandi dimensioni, filtri le estrazioni sorgente in base alle partizioni dei timestamp replicati, 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, del feedback, delle offerte e degli esiti per il periodo selezionato. Le sole tabelle con lo stato corrente non consentono di ricostruire in modo affidabile le attività passate.
Mappatura in ProcessMind: configuri JobApplicationId come identificativo del caso, ActivityName come campo dell’attività e ActivityTimestamp come timestamp dell’evento. Verifichi che il file esportato contenga una riga esplicita per ogni attività e non dipenda da transizioni dedotte.

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 a iniziare?

Sfrutti appieno il potenziale dei dati sulle assunzioni. Inizi a usare questo template oggi stesso per rendere più efficiente il processo di selezione e prendere decisioni basate sui dati.

Torna alla guida al miglioramento

Scarica il template

Renda più efficiente oggi l’acquisizione dei talenti in Greenhouse

Riduca del 30% il tempo di ciclo delle assunzioni e migliori oggi l’esperienza dei candidati.

Inizi la prova gratuita

Non è richiesta la carta di credito • Configurazione in 5 minuti

Il template dei dati per la selezione e l’acquisizione dei talenti

Il template dei dati per la selezione e l’acquisizione dei talenti

Attributi per la selezione e l’acquisizione dei talenti

Attività di selezione e acquisizione dei talenti

Guide all’estrazione

Generatore di report Greenhouse per l’esportazione manuale di file CSV

Passaggi

Configurazione

Query di esempio config

Estrazione tramite script Python con l’API Greenhouse Harvest

Passaggi

Configurazione

Query di esempio python

Strumento ETL automatizzato con connettore Greenhouse

Passaggi

Configurazione

Query di esempio config

È pronto a iniziare?

Renda più efficiente oggi l’acquisizione dei talenti in Greenhouse