> Folyamatos folyamatfejlesztés > Toborzás és tehetségszerzés > Greenhouse > Adatsablon

Adatsablon a toborzáshoz és a tehetségszerzéshez

Greenhouse

← Vissza a folyamatfejlesztési útmutatóhoz

A toborzás és a tehetségszerzés attribútumai(21) A toborzás és a tehetségszerzés tevékenységei(14) Útmutatók az adatok kinyeréséhez(3)

Adatsablon a toborzáshoz és a tehetségszerzéshez

Ez a sablon útmutatást ad ahhoz, hogy milyen adatokat gyűjtsön a toborzási és tehetségszerzési folyamathoz. Bemutatja a követendő attribútumokat, a rögzítendő fő tevékenységeket, valamint azt, hogyan nyerheti ki ezeket az adatokat a Greenhouse rendszerből. A sablon segítségével megteremtheti a folyamat elemzéséhez szükséges adatalapot.

Javasolt attribútumok
Követendő fő tevékenységek
Útmutató az adatok kinyeréséhez

Most ismerkedik az eseménynaplókkal? Tudja meg, hogyan készíthet process mining eseménynaplót.

Sablon letöltése

A toborzás és a tehetségszerzés attribútumai

Ezeket az adatmezőket érdemes felvenni az eseménynaplóba, hogy részletesen elemezhesse a Greenhouse-ban zajló toborzási és tehetségszerzési folyamatot.

5 Kötelező 6 Javasolt 10 Nem kötelező

	Név	Leírás
	Állásra jelentkezés JobApplicationId	Egy adott állásra benyújtott egyetlen jelöltjelentkezés egyedi azonosítója.
Leírás Az állásra jelentkezés azonosítója a toborzási folyamat elemzésének alapja, ez szolgál egyedi esetazonosítóként. Összekapcsolja a jelentkezéshez tartozó összes tevékenységet, az első benyújtástól és előszűréstől az interjúkon és ajánlatokon át a végső felvételi döntésig. Így minden jelölt útja az elejétől a végéig áttekinthető. A process mining ezt az attribútumot használja annak rekonstruálására, hogy az egyes jelöltek pontosan milyen útvonalon haladnak végig a felvételi folyamaton. Segítségével elemezhetők a folyamatváltozatok, az egyes jelentkezések átfutási ideje és a kiesési pontok. Így minden jelentkezőnél jól láthatóvá válik a teljes toborzási folyamat. Miért fontos? Ez az azonosító kapcsolja össze egy jelölt összes toborzási eseményét, így a teljes felvételi folyamat elejétől a végéig elemezhető. Hol szerezhető be? Ez általában a jelentkezési objektum elsődleges kulcsa. A Greenhouse API „Applications” végpontjának dokumentációjában keresse az „id” vagy „application_id” mezőt. Példák 987654321098765432119876543212
	Tevékenység időbélyege ActivityTimestamp	A toborzási tevékenység pontos dátuma és időpontja.
Leírás A tevékenység időbélyege pontosan jelzi, mikor történt egy esemény a toborzási folyamatban. Ez adja az időtartam- és teljesítményelemzés alapját, és megmutatja az egyes jelentkezésekhez tartozó tevékenységek időrendi sorrendjét. Az időbélyeg nélkülözhetetlen az időalapú KPI-k, például a felvételi idő, az interjú időpont-egyeztetési ideje és az interjú utáni visszajelzés átfutási ideje kiszámításához. A tevékenységek közötti idő elemzésével mérhető a hatékonyság, feltárhatók a késedelmek, és nyomon követhető a szolgáltatási szintű megállapodások betartása. Ez közvetlenül támogatja a teljesítményt és a szűk keresztmetszeteket bemutató dashboardokat. Miért fontos? Az időbélyeg szükséges az események sorrendbe rendezéséhez, az átfutási idők kiszámításához és a toborzási folyamat teljesítményének elemzéséhez. Hol szerezhető be? A Greenhouse különböző objektumaiban található meg, például az Application objektum „applied_at” mezőjében, az Offer objektumok „created_at” mezőjében, illetve a tevékenységfolyamok és auditnaplók időbélyegeiben. Példák 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	Tevékenység neve ActivityName	A toborzási folyamatban végrehajtott konkrét tevékenység vagy elért szakasz neve.
Leírás Ez az attribútum rögzíti a toborzási folyamat egyes eseményeinek nevét, például „Application Received”, „Interview Scheduled” vagy „Offer Accepted”. Ezek az események alkotják a folyamattérképen megjelenő eseménysort. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segít megjeleníteni a felvételi folyamatot, feltárni a gyakori útvonalakat, észrevenni az eltéréseket a szokásos munkafolyamattól, valamint azonosítani azokat a szűk keresztmetszeteket, ahol elakad a folyamat. Például nyomon követhető, hány jelentkezés jut el az „Application Reviewed” lépéstől a „Recruiter Screen Conducted” lépésig. Miért fontos? Ez az attribútum határozza meg a toborzási folyamat lépéseit. Segítségével megjeleníthető a folyamat menete, és azonosíthatók a szűk keresztmetszetek, valamint az eltérések. Hol szerezhető be? Ezt gyakran a Greenhouse-ban rögzített jelentkezési szakaszváltások, interjúállapotok, ajánlati események vagy más ellenőrizhető műveletek alapján állítják elő. A rendszereseményeket szabványos tevékenységnevekre átalakító logikára lehet szükség. Példák Jelentkezés áttekintveInterjú lezajlottAjánlat elfogadvaJelentkezés elutasítva
	Adatok utolsó frissítése LastDataUpdate	Az időbélyeg azt mutatja, mikor frissítették vagy nyerték ki utoljára az esemény adatait.
Leírás Ez az attribútum rögzíti, mikor kérdezték le utoljára az adatokat a forrásrendszerből. Metaadatként jelzi, mennyire frissek az adatok a process mining modellben. Segít a felhasználóknak megérteni, mennyire aktuális az elemzés. Tájékoztat az adatok késéséről, és fontos annak ellenőrzéséhez, hogy az adatfolyamat a tervek szerint fut-e. Ha például az „Adatok utolsó frissítése” több napja történt, a felhasználók tudják, hogy a dashboardok még nem mutatják a legutóbbi toborzási tevékenységeket. Miért fontos? Jelzi az adatok frissességét, így a felhasználók láthatják, hogy az elemzés a folyamat legutóbbi állapotát mutatja-e. Hol szerezhető be? Ezt az időbélyeget az adatkinyerés, -átalakítás és -betöltés (ETL) során hozzák létre, majd hozzáadják az adatkészlethez. Példák 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	Forrásrendszer SourceSystem	Megadja, melyik nyilvántartó rendszerből származnak a kinyert adatok.
Leírás Ez az attribútum jelzi a toborzási adatok forrását. Ennél a folyamatnál az értéke minden esetben „Greenhouse”. Bár ez az érték állandónak tűnhet, a forrásrendszer rögzítése fontos az adatirányítás és a hibakeresés szempontjából, valamint akkor is, ha az adatokat más rendszerekből, például HRIS-ből származó információkkal egészítik ki. Egyértelművé teszi az adatok eredetét, és segít megőrizni az adatok megbízhatóságát a szervezet különböző rendszereiben. Miért fontos? Egyértelművé teszi az adatok eredetét, ami elengedhetetlen az adatirányításhoz, az ellenőrzéshez és a több forrásból származó adatok kezeléséhez. Hol szerezhető be? Ez egy állandó érték, amelyet az adatkinyerés és -átalakítás során kell hozzáadni az adatok forrásának megjelöléséhez. Példák Greenhouse
	Ajánlat állapota OfferStatus	A jelöltnek tett állásajánlat aktuális állapota.
Leírás Ez az attribútum az állásajánlat állapotát követi, például „Created”, „Extended”, „Accepted” vagy „Rejected”. A toborzási folyamat utolsó szakaszainak fontos mutatója. Ez az attribútum elengedhetetlen az „Ajánlatelfogadási arány alakulása” dashboardhoz és az ahhoz tartozó KPI-hoz. A „Offer Extended” állapottól az „Offer Accepted” vagy „Offer Rejected” állapotig követhető, hogy a vállalatok milyen eredményesen tudják lezárni a jelöltek felvételét. A szervezeti egység vagy a munkakör szerinti elemzésből következtetni lehet a javadalmazás versenyképességére, a jelölti tapasztalatra és a jelöltek döntését befolyásoló más tényezőkre. Miért fontos? Nyomon követi az állásajánlatok eredményét. Ez szükséges az ajánlatelfogadási arány KPI kiszámításához és az arány javításának megértéséhez. Hol szerezhető be? A Greenhouse Offer objektumában érhető el, amely egy Application objektumhoz kapcsolódik. Ezt az információt a „status” mező tartalmazza. Példák ElfogadvaElutasítvaElküldveLétrehozva
	Állás szervezeti egysége JobDepartment	Az a szervezeti egység vagy üzletág, amelynek a pozícióját betöltik.
Leírás Ez az attribútum megadja az álláshoz tartozó szervezeti egységet, például az „Engineering”, „Marketing” vagy „Sales” részleget. Lehetővé teszi a toborzási mutatók összesítését és összehasonlítását a vállalat különböző területei között. A szervezeti egység szerinti bontás fontos a „Felvételi idő alakulása” és az „Ajánlatelfogadási arány alakulása” dashboardokhoz. Segít feltárni, hogy egyes részlegeknél hosszabb-e a felvételi folyamat, gyakoribbak-e az ajánlat-visszautasítások, vagy eltérő-e a folyamatok megfelelősége. Ezek alapján az egyes részlegek igényeihez igazított beavatkozások és folyamatfejlesztések tervezhetők. Miért fontos? Lehetővé teszi a toborzási teljesítmény és a folyamatok eltéréseinek összehasonlítását a szervezeti egységek között, így feltárhatók a rendszerszintű problémák és a bevált gyakorlatok. Hol szerezhető be? A Greenhouse Job objektumában általában alapértelmezett vagy egyéni mezőként érhető el. API-n keresztül a Job rekord „departments” szakaszában található. Példák MérnökségTermékmenedzsmentÉrtékesítésMarketing
	Jelentkezés állapota ApplicationStatus	Az állásra jelentkezés végső eredménye vagy aktuális állapota.
Leírás Ez az attribútum a jelentkezés állapotát jelzi, például „Hired”, „Rejected” vagy „Active”. Befejezett folyamat esetén a végállapotot, folyamatban lévő jelentkezésnél pedig az aktuális állapotot mutatja. Ez fontos szempont az eredmények elemzésénél. Segítségével összehasonlíthatók a felvett és az elutasított jelöltek folyamatútvonalai, ami feltárhatja a sikeres jelentkezések jellemzőit. Az „Általános toborzási tölcsér” dashboard konverziós arányainak kiszámításához is használható, így látható, a jelentkezések hány százalékából lesz felvétel. Miért fontos? Meghatározza a toborzási folyamat eredményét, így összehasonlíthatók a sikeres, felvétellel végződő és a sikertelen, elutasítással végződő jelölti folyamatok. Hol szerezhető be? Ez az információ a Greenhouse Application objektumának „status” mezőjében érhető el az API-n keresztül. Példák FelvéveElutasítvaAktív
	Jelentkezés forrása ApplicationSource	Az a csatorna, amelyen keresztül a jelölt jelentkezése beérkezett.
Leírás Ez az attribútum rögzíti az állásra jelentkezés forrását, például a „LinkedIn”, „Employee Referral”, „Company Website” vagy „Indeed” csatornát. Megmutatja, mennyire eredményesek az egyes toborzási csatornák. A „Toborzási csatornák eredményessége” dashboard teljes egészében erre az attribútumra épül. A jelentkezések számának, a felvételi időnek és a felvételi aránynak a forrás szerinti elemzésével optimalizálható a toborzási marketingre fordított költség és munka. Az adatok segítenek megválaszolni, mely csatornákon érkeznek a legjobb jelöltek a leghatékonyabban, és közvetlenül támogatják a „Toborzási csatornák konverziós aránya” KPI-t. Miért fontos? Segít mérni a különböző toborzási csatornák eredményességét és megtérülését, így adatok alapján dönthet arról, melyik csatornára érdemes több erőforrást fordítani. Hol szerezhető be? A jelentkezéshez kapcsolódó Greenhouse Candidate objektumban érhető el. Ezt az információt a „source” mező tartalmazza. Példák LinkedInMunkatársi ajánlásVállalati karrieroldalIndeed
	Munkakör megnevezése JobTitle	Annak a pozíciónak a megnevezése, amelyre a jelölt jelentkezett.
Leírás Ez az attribútum tartalmazza a létszámigény hivatalos megnevezését, például „Senior Software Engineer” vagy „Product Marketing Manager”. Kontextust ad a betöltendő munkakörről. A munkakör szerinti elemzés segít megérteni az adott szerepkörre jellemző nehézségeket. A „Felvételi idő alakulása” dashboard például megmutatja, hogy a vezető vagy speciális szaktudást igénylő pozíciók betöltése tovább tart-e. A különböző munkakörök ajánlatelfogadási aránya is elemezhető, ami képet ad a javadalmazás versenyképességéről és a pozíció vonzerejéről. Miért fontos? Lehetővé teszi az egyes munkakörökhöz tartozó toborzási mutatók szűrését és összehasonlítását, így láthatóvá válik, hogyan függ a folyamat teljesítménye az állás összetettségétől vagy típusától. Hol szerezhető be? Ez a Greenhouse Job objektumának egyik alapmezője, amely az API „jobs” végpontján keresztül gyakran „name” néven érhető el. Példák Senior szoftvermérnökÜgyfélkapcsolati vezetőUX/UI-tervező
	Toborzó neve RecruiterName	Az állásra jelentkezés kezeléséért felelős toborzó neve.
Leírás Ez az attribútum azonosítja az adott állásra vagy létszámigényre kijelölt toborzót. Általában ő végzi az előszűrést, egyezteti az interjúkat, és végigvezeti a jelöltet a folyamaton. A toborzók szerinti elemzés segít megérteni az egyéni teljesítményt és a munkaterhelés eloszlását. A „Toborzói munkaterhelés és hatékonyság” dashboard ezt az attribútumot használja a toborzónkénti áteresztőképesség és átfutási idők kiszámításához. Segít azonosítani a kiemelkedő teljesítményű munkatársakat, felismerni, kinek van szüksége további támogatásra, és kiegyensúlyozni a tehetségszerző csapat munkaterhelését. Miért fontos? Az egyes tevékenységeket egy adott toborzóhoz rendeli, így elemezhető az egyéni teljesítmény, a munkaterhelés és a hatékonyság. Hol szerezhető be? A Greenhouse Job objektumában érhető el, jellemzően a „hiring_team” szakaszban, ahol olyan szerepkörök szerepelnek, mint a „Recruiter”. Példák Alice JohnsonRobert DavisMaria Garcia
	Állásazonosító JobId	A létszámigény vagy az álláshirdetés egyedi azonosítója.
Leírás Ez az attribútum magát az állást azonosítja egyedileg, és különbözik a jelentkezés azonosítójától. Több jelentkezés is kapcsolódhat ugyanahhoz az állásazonosítóhoz. Az állásazonosítóval a létszámigény szintjén összesíthetők az adatok. Elemezhető például, hány jelentkezés érkezett egy adott állásra, vagy mennyi az azonos típusú pozíciók átlagos felvételi ideje. Segítségével egyetlen nyitott pozíció köré csoportosíthatók és elemezhetők a toborzási tevékenységek. Miért fontos? Lehetővé teszi az egy álláshirdetéshez kapcsolódó összes jelöltadat összesítését és elemzését, így a betöltendő pozícióra összpontosító nézetet ad. Hol szerezhető be? Ez a Greenhouse-ban az állásrekord elsődleges kulcsa, amely az API-n keresztül a Job objektum „id” mezőjeként érhető el. Példák 400123400124400125
	Automatizált IsAutomated	Jelzi, hogy a tevékenységet automatikusan hajtotta-e végre a rendszer.
Leírás Ez a logikai attribútum jelzi, hogy egy tevékenységet felhasználó vagy automatizált rendszerszabály hajtott-e végre. Automatizált tevékenység lehet például az automatikus válaszlevél küldése vagy az alapvető előszűrési kérdésre nem megfelelő választ adó jelöltek automatikus elutasítása. Az attribútum elemzésével felmérhető, milyen mértékben automatizált a toborzási folyamat. Összehasonlítható az automatizált és a manuális lépések hatékonysága és eredménye, valamint azonosíthatók a további automatizálási lehetőségek a gyorsaság és a következetesség javítására. Miért fontos? Elkülöníti a manuális és az automatizált tevékenységeket, így elemezhető, hogyan hat az automatizálás a folyamat hatékonyságára és eredményére. Hol szerezhető be? Ez nem szabványos mező, ezért általában származtatni kell. Az érték kikövetkeztethető a tevékenységhez rendelt felhasználóból, például egy „System” felhasználóból, vagy olyan eseménytípusokból, amelyekről ismert, hogy automatizáltak. Példák truefalse
	Elutasítás indoka RejectionReason	A jelölt jelentkezésének elutasításakor megadott indok.
Leírás Ez az attribútum rögzíti, miért nem jutott tovább a jelölt a folyamatban. Ilyen indok lehet például: „Nem illik a vállalati kultúrához”, „Túl magas fizetési elvárás” vagy „Másik, képzettebb jelöltet választottunk”. Az elutasítási indokok elemzése értékes visszajelzést ad a toborzási folyamatról. Rávilágíthat például a pontatlan állásleírásokra, a nem versenyképes javadalmazásra vagy a jelöltek visszatérő készséghiányaira. Az információ segít javítani a jelöltkeresési stratégiát és a jelölti tapasztalatot azáltal, hogy feltárja, hol akadnak el leggyakrabban a jelentkezések. Miért fontos? Megmutatja, miért esnek ki a jelöltek a felvételi folyamatból, így pontosíthatók az állásleírások, a jelöltkeresés és az előszűrés szempontjai. Hol szerezhető be? Az elutasított jelentkezéshez tartozó Application objektumban érhető el. Az API részleteket tartalmazó „rejection_reason” objektumot biztosít. Példák Nem rendelkezett a szükséges készségekkelTúl magas fizetési elvárásKépzettebb jelöltet választottak
	Értékelőlapon adott ajánlás ScorecardOverallRecommendation	A befejezett interjú értékelőlapján szereplő összesített felvételi ajánlás.
Leírás Ez az attribútum az interjúztató strukturált értékelőlapon megadott végső ajánlását rögzíti. Az értékek jellemzően „Strong Yes”, „Yes”, „No” vagy „Strong No”. Ezek az adatok fontosak az interjúztatási folyamat minőségének és következetességének értékeléséhez. Segítségükkel összevethető az interjúztatói visszajelzés a tényleges felvételi eredményekkel, például megválaszolható, hogy a határozottabb ajánlást kapó jelölteket gyakrabban veszik-e fel. Ez az attribútum a strukturált felvételi gyakorlat szervezeten belüli elterjedtségét mérő „Értékelőlap-kitöltési arány” KPI alapja is. Miért fontos? Összekapcsolja a strukturált interjú-visszajelzést a folyamat eredményével, és segít mérni az adatalapú felvételi gyakorlatok elterjedtségét. Hol szerezhető be? A Greenhouse-ban a befejezett interjúhoz kapcsolódó Scorecard objektumban található. Az API a „scorecards” végponton keresztül biztosítja ezt az információt. Példák Határozott nemNemIgenHatározott igen
	Felvételi vezető neve HiringManagerName	Az adott létszámigényhez tartozó felvételi vezető neve.
Leírás Ez az attribútum azonosítja a nyitott pozíciót kínáló csapat vezetőjét. A felvételi vezető fontos szereplő a folyamatban: gyakran részt vesz a jelöltek értékelésében, a későbbi interjúkban és a végső felvételi döntésben. A felvételi vezető szerinti elemzés fontos mintákat és szűk keresztmetszeteket tárhat fel. Az „Interjúidőpont-egyeztetés szűk keresztmetszetei” dashboard például megmutathatja, ha a késedelmek gyakran egyes vezetők időbeosztásával függnek össze. Az elemzés segít felismerni, hol van szükség képzésre vagy támogatásra, hogy a vezetők hatékonyan vehessenek részt a felvételi folyamatban. Miért fontos? Azonosítja a folyamat egyik fontos szereplőjét, így elemezhetők az egyes felvételi vezetőkhöz kapcsolódó szűk keresztmetszetek és hatékonysági tényezők. Hol szerezhető be? A Greenhouse Job objektumában érhető el, jellemzően a „hiring_team” szakaszban, ahol olyan szerepkörök szerepelnek, mint a „Hiring Manager”. Példák Emily TranDavid ChenSophia Rodriguez
	Interjú utáni visszajelzés átfutási ideje InterviewFeedbackTurnaroundTime	Az interjú befejezése és az interjúztató visszajelzésének beküldése között eltelt idő.
Leírás Ez a számított mutató az interjúztatók válaszadási gyorsaságát méri. A visszajelzés késedelmes beküldése jelentősen lassíthatja a felvételi folyamatot, és ronthatja a jelölti tapasztalatot. Ez az attribútum közvetlenül támogatja az „Interjú-visszajelzési folyamat elemzése” dashboardot és az „Interjú utáni visszajelzés átfutási ideje” KPI-t. Kiszámításához az „Interview Completed” és a „Feedback Submitted” tevékenység időbélyege közötti különbséget kell venni. A mutató nyomon követésével feltárhatók a lassú visszajelzésből eredő szűk keresztmetszetek, és gyorsabb döntéshozatalra ösztönözhetők az érintettek. Miért fontos? Az interjú utáni visszajelzési folyamat hatékonyságát méri, amely gyakran okoz késedelmet a felvételi folyamatban. Hol szerezhető be? Ez egy számított mező. Az „Interview Completed” esemény időbélyegét ki kell vonni a „Feedback Submitted” esemény időbélyegéből. Példák 86400172800259200
	Interjúszakasz InterviewStageName	Az interjúszakasz pontos neve vagy típusa.
Leírás Ez az attribútum az interjúfolyamat adott szakaszát jelöli, például „Recruiter Screen”, „Technical Interview” vagy „Final Round”. Részletesebb képet ad, mint az általános „Interview Completed” tevékenység. Az egyes interjúszakaszok mutatóinak elemzésével pontosabban azonosíthatók a szűk keresztmetszetek. Például nagy pontossággal mérhető a jelöltek szakaszonkénti kiesési aránya, így kiderül, hogy a jelöltek inkább a technikai interjú vagy az első előszűrés után lépnek-e vissza. Ez a részlet fontos az interjúztatási tapasztalat célzott javításához. Miért fontos? Részletesebb képet ad az interjúfolyamatról, így az egyes interjúl lépések átfutási ideje és a kiesési arány is elemezhető. Hol szerezhető be? Ez az információ a Greenhouse interjúidőpont-egyeztetési adatai között található. Az állásra jelentkezés „interviews” objektuma tartalmazza az interjúszakasz részleteit. Példák Toborzói előszűrésInterjú a felvételi vezetővelTechnikai felmérésHelyszíni záróforduló
	Jelöltazonosító CandidateId	A jelölt egyedi azonosítója, amely nem egyetlen jelentkezéshez kötődik.
Leírás A jelöltazonosító a tehetségállomány egy adott személyét azonosítja, míg az állásra jelentkezés azonosítója egyetlen állásra benyújtott jelentkezéshez tartozik. Egy jelölt idővel több állásra is jelentkezhet. Az adott folyamatelemzésben az állásra jelentkezés azonosítója szolgál esetazonosítóként, a jelöltazonosítóval azonban más típusú elemzés is végezhető. Nyomon követhető vele a jelölt útja több jelentkezésen keresztül, azonosíthatók a gyakran jelentkezők, és elemezhető a tehetségállománnyal fennálló teljes kapcsolat. Így a toborzási adatok személyre szabottabb nézetben vizsgálhatók. Miért fontos? Lehetővé teszi ugyanazon jelölt több jelentkezésének elemzését, így átfogóbb képet ad a jelölt időbeli aktivitásáról. Hol szerezhető be? Ez a Greenhouse jelöltrekordjának elsődleges kulcsa. Az API Candidate objektumában „id” néven érhető el. Példák 123456123457123458
	Megfelel a folyamatnak IsCompliant	Számított jelző, amely megmutatja, hogy a jelentkezés a meghatározott, szabványos felvételi folyamat szerint haladt-e.
Leírás Ez a logikai attribútum egy megfelelőségi ellenőrzés eredménye. Az állásra jelentkezés tényleges tevékenységsorát egy előre meghatározott ideális folyamatmodellel hasonlítja össze. Jelzi az eltéréseket, például ha kimarad egy kötelező lépés, vagy a tevékenységek nem a megfelelő sorrendben történnek. Ez az attribútum alapvető a „Felvételi folyamat megfelelőségi eltérései” dashboardhoz, és támogatja a „Folyamatmegfelelési arány” és a „Megfelelőségi szabálysértések száma” KPI-kat. A nem megfelelő esetek szűrésével megvizsgálható, miért történnek eltérések: hiányos képzés, rendszerkorlátok vagy szükséges kivételek miatt. Ez segít egységesíteni a munkafolyamatokat és csökkenteni a megfelelési kockázatokat. Miért fontos? Feltárja a folyamat eltéréseit, ami fontos a folyamatkövetés méréséhez, a megfelelés biztosításához és a felvételi munkafolyamatok egységesítéséhez. Hol szerezhető be? Ez a process mining szoftver által előállított számított mező. Az eseménynapló adatait egy meghatározott célmodellel vagy üzleti szabályrendszerrel hasonlítja össze. Példák truefalse
	Tevékenység befejezési ideje ActivityEndTime	Az időbélyeg azt mutatja, mikor ért véget egy időtartammal rendelkező tevékenység.
Leírás Ez az attribútum rögzíti az időtartammal rendelkező tevékenységek, például egy interjú vagy háttérellenőrzés befejezési idejét. Sok tevékenység egy pillanat alatt lezajlik, de a mérhető időtartamúaknál érdemes a kezdési és befejezési időt is rögzíteni. A befejezési idő szükséges az adott tevékenység tényleges feldolgozási idejének vagy időtartamának pontos kiszámításához. Így elkülöníthető a lépések közötti várakozás és a feladat elvégzésére fordított idő. Például pontosabban elemezhető, mennyi ideig tart maga az interjú, és mennyi idő szükséges az időpont egyeztetéséhez. Miért fontos? Lehetővé teszi a tevékenységek feldolgozási idejének pontos kiszámítását, így elkülöníthető a tényleges munkavégzés és a folyamat tétlen várakozási ideje. Hol szerezhető be? Ez az információ elérhető lehet a Greenhouse „scheduled_interview” objektumában, amely gyakran a kezdési és befejezési időt is tartalmazza. Más tevékenységeknél a következő esemény időbélyegéből kell következtetni a befejezésre. Példák 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z

Kötelező Javasolt Nem kötelező

A toborzás és a tehetségszerzés tevékenységei

Ezeket a folyamatlépéseket és mérföldköveket érdemes rögzíteni az eseménynaplóban, hogy pontosan feltárhassa és optimalizálhassa a felvételi folyamatot.

7 Javasolt 7 Nem kötelező

	Tevékenység	Leírás
	Ajánlat elfogadva	A jelölt hivatalosan elfogadta az állásajánlatot. Ez fontos sikermérföldkő, amely általában elindítja a felvétel előtti további tevékenységeket, például a háttérellenőrzést.
Miért fontos? Ez fontos sikermérföldkő és az ajánlatelfogadási arány KPI egyik alapvető eleme. Azt jelzi, hogy a jelöltből leendő munkatárs lesz. Hol szerezhető be? Ez egy kifejezett esemény, amely akkor kerül rögzítésre a Greenhouse-ban, amikor az ajánlat állapota „Accepted” értékre változik. Ezt a toborzó állíthatja be, vagy a jelölt elektronikus elfogadása is kiválthatja. Rögzítés Az ajánlat állapotának „Accepted” értékre változtatásakor rögzített időbélyeg alapján. Eseménytípus explicit
	Ajánlat elküldve	A hivatalos állásajánlatot elküldték a jelöltnek. Ez fontos mérföldkő, amely az interjú- és kiválasztási folyamat lezárását jelzi.
Miért fontos? Ez a tevékenység az ajánlatelfogadási arány KPI kiszámításának alapja. Jelzi a jelölt végső döntési szakaszának kezdetét. Hol szerezhető be? A Greenhouse-ban kifejezetten rögzített esemény, amely akkor keletkezik, amikor az ajánlat állapota „Sent” vagy „Extended” értékre változik. Az ajánlatobjektum tartalmazza az állapotváltozások időbélyegeit. Rögzítés Az ajánlat hivatalos elküldését jelző állapot időbélyegéből rögzítve. Eseménytípus explicit
	Interjú lezajlott	A jelölttel lefolytatták az interjút. Ez gyakran az ütemezett időpont elmúltából állapítható meg, de megbízhatóbban jelzi, ha az interjúhoz visszajelzést küldenek be.
Miért fontos? Ez a tevékenység fontos mérföldkő a jelölt útján. Kiindulópontként szolgál a visszajelzés leadásáig eltelt idő és a következő szakaszba lépés méréséhez. Hol szerezhető be? Általában következtetéssel állapítható meg. Levezethető az ütemezett interjú befejezési időpontjából, de pontosabban az adott interjúhoz elsőként beküldött visszajelzés időbélyegéből. Rögzítés Az ütemezett interjú befejezési időpontjából vagy az azt követő visszajelzés beküldésének időbélyegéből állapítható meg. Eseménytípus inferred
	Interjú ütemezve	A jelölttel folytatandó interjút ütemezték a rendszerben. A Greenhouse naptárintegrációkat kínál, ezért az esemény általában kifejezetten rögzül az interjú megerősítésekor.
Miért fontos? Ez az esemény elengedhetetlen az interjúütemezési folyamat szűk keresztmetszeteinek elemzéséhez és azonosításához. Az esemény és az előző lépés között eltelt idő fontos KPI a toborzók és koordinátorok hatékonyságának méréséhez. Hol szerezhető be? A Greenhouse interjúütemezési funkciójából rögzítve. Az API adatokat szolgáltat az ütemezett interjúkról, többek között a létrehozásuk időbélyegéről. Rögzítés Akkor kerül a naplóba, amikor létrejön egy interjúesemény, és hozzárendelik a jelölt jelentkezéséhez. Eseménytípus explicit
	Jelentkezés beérkezett	Ez a tevékenység jelöli egy adott álláspályázat toborzási folyamatának kezdetét. Akkor rögzül, amikor a jelölt karrieroldalon vagy jelöltkeresési csatornán keresztül jelentkezik, illetve amikor kézzel rögzítik a Greenhouse-ban.
Miért fontos? Ez a folyamat első eseménye. Az ettől a tevékenységtől a többiig eltelt idő elemzése elengedhetetlen a felvételi idő és a jelöltkeresési csatornák eredményességének méréséhez. Hol szerezhető be? A Greenhouse-ban az alkalmazás létrehozásakor kifejezetten rögzített esemény. Az esemény időpontját az Application Date mező vagy az alkalmazásobjektum létrehozási időbélyege adja meg. Rögzítés Az alkalmazásrekord létrehozási időbélyegéből rögzítve. Eseménytípus explicit
	Jelentkezés elutasítva	A jelölt jelentkezését a folyamat valamely pontján elutasították. Ez a leggyakoribb sikertelen lezáró esemény, és bármelyik szakaszban bekövetkezhet.
Miért fontos? Ez fontos lezáró esemény a felvételi tölcsérből kiesők arányának elemzéséhez. Ha megérti, mikor és miért történnek az elutasítások, feltárhatja a folyamat hiányosságait és az állás követelményeinek esetleges eltéréseit. Hol szerezhető be? Ez egy kifejezett esemény, amely akkor kerül rögzítésre, amikor egy felhasználó elutasítja a jelentkezést a Greenhouse-ban. Gyakran az elutasítás indoka is szerepel, a tevékenységnapló pedig rögzíti az időbélyeget. Rögzítés A jelentkezés elutasításakor végrehajtott művelet időbélyege alapján rögzítve. Eseménytípus explicit
	Jelölt felvéve	A jelölt sikeresen teljesítette az összes munkába állás előtti ellenőrzést, és hivatalosan felvették. Ez a jelentkezési folyamat sikeres lezárása és végső eseménye.
Miért fontos? Ez a folyamat elsődleges sikeres kimenetele. A „Application Received” eseménytől eddig eltelt idő a teljes felvételi idő, amely fontos toborzási KPI. Hol szerezhető be? Ez egy kifejezett művelet a Greenhouse-ban: a toborzó egy adott állásra felvettként jelöli meg a jelöltet. Ezzel az aktív jelöltek közül a felvettek közé kerül. Rögzítés A Greenhouse-ban végrehajtott „Mark as Hired” művelet időbélyege alapján rögzítve. Eseménytípus explicit
	Ajánlat létrehozva	Elkészült a hivatalos állásajánlat tervezete, amely még belső jóváhagyásra várhat. Ez jelzi azt a hivatalos döntést, hogy ajánlatot tesznek a jelöltnek.
Miért fontos? Ez a tevékenység elkülöníti az ajánlattételről szóló döntést az ajánlat jelöltnek történő kiküldésétől. Segít elemezni a belső jóváhagyás idejét és az ajánlat jelöltnek való elküldése előtti szűk keresztmetszeteket. Hol szerezhető be? A Greenhouse külön modullal rendelkezik az ajánlatok kezelésére. Ez kifejezetten rögzített esemény, amelyet az alkalmazáshoz kapcsolódó ajánlatobjektum létrehozási időbélyege jelez. Rögzítés Az ajánlatrekord Greenhouse-beli létrehozásakor kerül a naplóba. Eseménytípus explicit
	Ajánlat visszautasítva	A jelölt hivatalosan visszautasította az állásajánlatot. Ez a folyamat késői szakaszában bekövetkező sikertelen lezáró esemény.
Miért fontos? Ennek a kimenetelnek a nyomon követése fontos az ajánlatelfogadási arány elemzéséhez. Ha gyakran fordul elő, az a javadalmazással, a vállalati kultúrával vagy magával a munkakörrel kapcsolatos problémára utalhat. Hol szerezhető be? Ez egy kifejezett esemény, amely akkor kerül rögzítésre a Greenhouse-ban, amikor az ajánlat állapota „Rejected” vagy „Declined” értékre változik. Az ajánlat objektuma az állapotváltozás időbélyegét is tartalmazza. Rögzítés Az ajánlat állapotának „Rejected” értékre változásakor rögzített időbélyeg alapján. Eseménytípus explicit
	Beléptetés elindítva	Hivatalosan is megkezdődött az új munkatárs vállalati beléptetése. Ehhez gyakran át kell adni az adatokat a toborzási rendszerből egy HRIS- vagy beléptetési platformnak.
Miért fontos? A toborzás és a HR közötti átadás hatékonyságát méri. Az itt jelentkező késedelem ronthatja az új munkatárs tapasztalatait, ezért fontos nyomon követni a beléptetési átadás idejét. Hol szerezhető be? Ez kifejezett eseményként is rögzíthető, ha a Greenhouse össze van kapcsolva egy beléptetési rendszerrel. Ennek hiányában abból az időbélyegből következtethető ki, amikor a jelölt a végső „Hired” szakaszba kerül, és ezzel elindul az átadás. Rögzítés Szakaszváltásból vagy a HRIS felé történő átadást jelző integrációs naplóból következtethető ki. Eseménytípus inferred
	Háttérellenőrzés elindítva	Megkezdődött a jelölt háttérellenőrzése, jellemzően az ajánlat elfogadása után. Ezt rögzítheti egy külön szakaszváltás, vagy egy külső szolgáltatást indító integrációs esemény.
Miért fontos? Ez a tevékenység fontos a megfelelés szempontjából, és segít nyomon követni a munkába állás előtti ellenőrzések késedelmét. Megmutatja, mennyi idő telik el az ajánlat elfogadása és a szükséges ellenőrzések befejezése között. Hol szerezhető be? Az esemény valószínűleg abból következtethető ki, hogy a jelölt a felvételi folyamat „Background Check” szakaszába kerül, vagy a háttérellenőrzési integrációhoz kapcsolódó tevékenységnaplóból. Rögzítés A „Background Check” szakaszra váltásból vagy egy integrált szolgáltatás API-naplójából következtethető ki. Eseménytípus inferred
	Jelentkezés áttekintve	A toborzó vagy a felvételi vezető elvégezte a jelölt jelentkezésének első áttekintését. Ez általában abból állapítható meg, hogy az alkalmazás szakasza vagy állapota „New” értékről aktív áttekintési szakaszra, például „In Review” értékre változik.
Miért fontos? Ennek nyomon követésével feltárhatók az előszűrés szűk keresztmetszetei, és mérhető, mennyi idő telik el, mire az új jelentkezésekkel foglalkozni kezdenek. Ez az interjúütemezési ciklusidő kiszámításának kiindulópontja. Hol szerezhető be? Az alkalmazás állapotmezőjének változásából állapítható meg. Keresse a „New” állapotból „Review” állapotba történő változást, és használja a változás időbélyegét. Rögzítés Az „In Review” vagy hasonló szakaszra váltás időbélyegéből állapítható meg. Eseménytípus inferred
	Toborzói előszűrés elvégezve	A toborzó elvégezte a jelölttel folytatott első telefonos előszűrést vagy beszélgetést. Ezt a tevékenységet gyakran az jelzi, hogy a jelölt a felvételi folyamat „Phone Screen” szakaszába kerül.
Miért fontos? Ez fontos minősítési mérföldkő, amely azt jelzi, hogy a jelentkezés túljutott az első, önéletrajz alapján végzett szűrésen. Segít mérni a toborzók munkaterhelését és az előszűrés eredményességét. Hol szerezhető be? Az alkalmazás Greenhouse-beli álláspályázati folyamatának „Phone Screen” szakaszba történő áthelyezésekor vagy onnan való továbblépésekor rögzített időbélyegből állapítható meg. Rögzítés Az alkalmazás szakaszelőzményeiből származik, különösen a „Phone Screen” szakaszba lépés időpontjából. Eseménytípus inferred
	Visszajelzés beküldve	Az interjúztató beküldte a jelölt interjújára vonatkozó értékelőlapot vagy visszajelzést. A Greenhouse strukturált felvételi folyamata erre támaszkodik a döntéshozatal során, ezért ez különálló, naplózott művelet.
Miért fontos? A visszajelzés időben történő leadása elengedhetetlen ahhoz, hogy a jelöltek továbbléphessenek. Ez a tevékenység segít elemezni a visszajelzési folyamat hatékonyságát és az értékelőlapok kitöltési arányát. Hol szerezhető be? Kifejezetten rögzített esemény, amely akkor keletkezik, amikor az interjúztató értékelőlapot küld be a Greenhouse-ban. A Scorecards API objektuma tartalmazza a `submitted_at` időbélyeget. Rögzítés Az interjú értékelőlapja beküldésének időbélyegéből rögzítve. Eseménytípus explicit

Javasolt Nem kötelező

Útmutatók az adatok kinyeréséhez

Adatok kinyerése a Greenhouse-ból

Lépések

Jelentkezzen be a Greenhouse Recruiting-fiókjába.
A fő navigációs sávon kattintson a jelentések ikonjára, amely egy oszlopdiagramra hasonlít, majd nyissa meg a Reports részt.
A Reports dashboardon keresse meg és nyissa meg az „Essential Reports” részt. Az adatok kinyeréséhez elsősorban az „All Applications” jelentésre lesz szüksége. Ez a jelentés átfogó képet ad a jelentkezésekről és a fontos mérföldkövekről.
Állítsa be az „All Applications” jelentést. Kattintson a „Columns” gombra, majd jelölje ki a szükséges attribútumok és tevékenységi időbélyegek rögzítéséhez szükséges oszlopokat. Ezeket mindenképpen vegye fel: 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.
Az interjúkkal kapcsolatos tevékenységek rögzítéséhez külön jelentésre lesz szüksége. Lépjen vissza az Essential Reports részhez, és válassza az „Interview Details” jelentést.
Állítsa be az „Interview Details” jelentést. A „Columns” résznél legalább ezeket az oszlopokat jelölje ki: Application ID, Interview Name, Scheduled Start és Scorecard Submitted At. Ezek az időbélyegek az interjúk ütemezését és a visszajelzések beküldését mutatják.
Mindkét jelentésnél állítsa be a megfelelő dátumtartományt a szűrőkkel. Gyakori megoldás az „Applied On” szűrő „All Time” értékre állítása, vagy egy adott időszak, például az elmúlt 6 hónap kiválasztása, hogy a releváns jelentkezések kerüljenek be.
Kattintson az „Update” vagy „Generate” gombra a jelentések elkészítéséhez. Amikor megjelenik a jelentés, kattintson az „Export to Excel” gombra az adatok CSV-fájlként való letöltéséhez. Így két külön CSV-fájlt kap.
Az exportált fájlok még nem eseménynapló-formátumúak. Az adatokat át kell alakítania egy eszközzel, például Python vagy R használatával, illetve egy olyan táblázatkezelővel, amely támogatja az oszlopok sorokká alakítását, például a Microsoft Excel Power Queryvel.
Egyesítse az „All Applications” és az „Interview Details” jelentés adatait az Application ID mező alapján.
Minden jelentkezéshez hozzon létre külön sort minden releváns exportált dátumoszlophoz. Például az „Applied On” oszlop értéke legyen az „Application Received” tevékenység „ActivityTimestamp” értéke. A „Rejected On” oszlop értéke az „Application Rejected” tevékenységet hozza létre, és így tovább mind a 14 szükséges tevékenységnél. A „Last Stage Change On” oszlop alapján következtethet olyan tevékenységekre, mint az „Application Reviewed” vagy a „Recruiter Screen Conducted”, ha nincs hozzájuk külön időbélyeg.
A végső, átalakított fájlban szerepeljenek a következő oszlopok: JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, valamint az ajánlott attribútumok. Mentse a fájlt egyetlen CSV-ként, amely feltölthető.

Konfiguráció

Elsődleges jelentések: Az adatok kinyeréséhez a Greenhouse Essential Reports részében található több jelentést kell egyesíteni, elsősorban az „All Applications” és az „Interview Details” jelentést.
Fő oszlopok (All Applications): A szükséges adatok rögzítéséhez jelölje ki például az Application ID, Candidate, Job, Department, Recruiter, Status, Source és Offer Status oszlopokat, valamint az összes releváns dátumoszlopot, köztük az Applied On, Rejected On, Hired On, Offer Created On és Offer Accepted On mezőket.
Fő oszlopok (Interview Details): Az interjúesemények rögzítéséhez jelölje ki például az Application ID, Interview Name, Scheduled Start és Scorecard Submitted At oszlopokat.
Dátumtartomány-szűrők: Érdemes az „Applied On” dátum alapján 3–6 hónapra szűrni, hogy az adathalmaz kezelhető és releváns maradjon. A hosszabb időszak ronthatja a teljesítményt.
Előfeltételek: Az exportot végző felhasználónak rendelkeznie kell a Greenhouse Reports részéhez és a jelöltadatokhoz szükséges jogosultságokkal. Ehhez általában „Job Admin” vagy „Site Admin” szerepkör szükséges.

Példa-lekérdezés 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'

Lépések

Előfeltétel: Greenhouse API-kulcs beszerzése
- Jelentkezzen be a Greenhouse-fiókjába fejlesztői jogosultságokkal.
- Nyissa meg a Configure > Dev Center > API Credential Management menüpontot.
- Kattintson a „Create New API Key” gombra.
- Adjon meg egy leírást, például „ProcessMind Extraction”.
- Típusként válassza a „Harvest” lehetőséget.
- Adja meg a kulcsnak a szükséges jogosultságokat. Legalább a következőkhöz kell GET-jogosultság: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards és Users.
- Másolja ki biztonságosan a létrehozott API-kulcsot. Később már nem fogja tudni megtekinteni.
Python-környezet beállítása
- Ellenőrizze, hogy a rendszerén a Python 3.6-os vagy újabb verziója van-e telepítve.
- Telepítse a szükséges Python-könyvtárakat a következő parancsok futtatásával a terminálban: pip install requests és pip install pandas.
A Python-szkript előkészítése
- Másolja a „query” részben megadott teljes Python-szkriptet egy új fájlba, például extract_greenhouse_logs.py néven.
- Cserélje le a YOUR_GREENHOUSE_API_KEY helyőrzőt az 1. lépésben beszerzett kulcsra.
- Módosítsa a START_DATE_ISO változót a kinyerési időszak kezdő dátumának megadásához. Első betöltéskor az aktuális dátum előtti 3–6 hónapos kezdő dátum ajánlott.
A szakaszok és tevékenységek megfeleltetésének beállítása
- Ellenőrizze a szkriptben a STAGE_TO_ACTIVITY szótárat.
- Ez a szótár rendeli hozzá a Greenhouse-ban használt, vállalatspecifikus felvételi szakaszok nevét a process mininghoz szükséges egységes tevékenységnevekhez.
- A megfeleltetést a szervezet Greenhouse-beállításaihoz KÖTELEZŐ igazítania. Ha például a „Recruiter Screen” szakasz neve „Initial Recruiter Chat”, ennek megfelelően módosítsa a szótárat.
Az adatok kinyerésére szolgáló szkript futtatása
- Nyisson meg egy terminált vagy parancssort.
- Lépjen abba a könyvtárba, ahová az extract_greenhouse_logs.py fájlt mentette.
- Futtassa a szkriptet a következő paranccsal: python extract_greenhouse_logs.py.
- A szkript csatlakozik a Greenhouse API-hoz, lekéri és feldolgozza az adatokat, majd állapotüzeneteket ír a konzolra.
Az eseménynapló letöltése
- Sikeres futtatás után a szkript a greenhouse_event_log.csv nevű fájlt hozza létre ugyanabban a könyvtárban.
- Ez a CSV-fájl a szükséges oszlopokkal és tevékenységekkel formázott végleges eseménynapló.
Növekményes betöltések kezelése
- A következő futtatásoknál módosítsa a START_DATE_ISO változót az utolsó sikeres kinyerés időbélyegére. Így csak az új vagy módosult rekordokat tölti le, ami gyorsítja a folyamatot.
Feltöltés a ProcessMindba
- A létrehozott greenhouse_event_log.csv fájl közvetlenül feltölthető a ProcessMindba. Ellenőrizze, hogy a fájl oszlopnevei megfelelően megfeleltethetők-e a ProcessMind-projekt mezőinek.

Konfiguráció

API-kulcs jogosultságai: A Harvest API-kulcsnak csak olvasási (GET) hozzáféréssel kell rendelkeznie a következő végpontokhoz: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards és Users. Ha a jogosultságok nem elegendők, egyes tevékenységek adatai hiányozni fognak.
Dátumtartomány-szűrő: A szkript az updated_after paraméterrel (a START_DATE_ISO változóval) szűri a jelentkezéseket. Első kinyeréskor használjon hosszabb időszakot, például az elmúlt 6 hónapot. A későbbi növekményes betöltéseknél a teljesítmény javítása érdekében állítsa be az utolsó sikeres futtatás időbélyegét.
Szakaszok és tevékenységek megfeleltetése: A szkriptben található STAGE_TO_ACTIVITY szótár beállítása elengedhetetlen. A Greenhouse-ban használt, vállalatspecifikus felvételi szakaszokhoz kell igazítania, hogy a rendszer helyesen azonosítsa például a „Recruiter Screen Conducted” és a „Background Check Initiated” tevékenységet.
API-hívások korlátozása: A szkript az API-kérések között rövid, rögzített szünetet tart, hogy betartsa a Greenhouse korlátozásait, amelyek másodpercenként körülbelül 20 kérést engednek. Nagy adatmennyiségnél előfordulhat, hogy a kapcsolódási hibák elkerülése érdekében módosítania kell ezt a szünetet.
Adatok részletessége: A kinyerés az időbélyeggel ellátott eseményekre és állapotváltozásokra összpontosít. Nem rögzít részletes tartalmakat, például interjújegyzeteket vagy e-mail-váltásokat, csak az események bekövetkezésére vonatkozó metaadatokat.

Példa-lekérdezés 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.")

Lépések

Ellenőrizze, hogy az Ön által licencelt ETL-platform rendelkezik-e Greenhouse-összekötővel, és az támogatja-e a jelentkezéseket, a jelentkezési szakaszok előzményeit, az interjúkat, az interjú-visszajelzéseket, az ajánlatokat, az ajánlatok állapotváltozásait, a háttérellenőrzéseket, a beléptetési átadásokat és a felvételi eredményeket tartalmazó Greenhouse-objektumokat vagy replikált adathalmazokat. Az objektumok neve platformonként eltérhet, ezért a táblanevek feltételezése helyett használja az összekötő-katalógust és a sémaböngészőt.
Hozza létre a Greenhouse-forráskapcsolatot az ETL-platformon. Adja meg a Greenhouse-hitelesítő adatokat, az engedélyezési adatokat, a replikációs beállításokat és a környezetéhez szükséges vállalatspecifikus szűrőket. Kövesse az összekötő dokumentált engedélyezési folyamatát, és csak a kiválasztott toborzási adatok olvasásához szükséges jogosultságokat adja meg.
Állítson be céladattárházat, és engedélyezze az eseménynapló összeállításához szükséges forrásobjektumok replikációját. Legalább a következőket válassza ki: állásjelentkezések, jelentkezési állapotok vagy szakaszelőzmények, interjúk, interjú-visszajelzések, ajánlatok, ajánlatállapot-változások, háttérellenőrzési események, beléptetési átadások és felvételi eredmények. Ha egy szükséges objektum nem érhető el, dokumentálja a korlátozást, és a Greenhouse-beállítások alapján rendelje hozzá a legközelebbi támogatott forrást.
Állítsa be a kezdeti replikációs időszakot az elemzéshez szükséges tartományra, jellemzően az előző 3–6 hónapra. Vegyen fel korábbi időszakot is, ha a jelentkezések a kiválasztott időszak előtt jöttek létre, de azon belül haladtak tovább. Állítsa be a növekményes replikációt, és őrizze meg a forrás frissítési időbélyegeit, ha rendelkezésre állnak.
Vizsgálja meg a replikált sémát, és cseréljen le minden helyőrzőt a lekérdezésben az összekötő által ténylegesen elérhető cél-sémára, táblanevekre, oszlopnevekre, időbélyegmezőkre, azonosítókra és állapotértékekre. Ne feltételezze, hogy a szakaszváltás, az interjú, a visszajelzés, az ajánlat, a háttérellenőrzés, a beléptetési átadás vagy a felvételi eredmény adatai rendelkezésre állnak, ha nem szerepelnek a replikált adatok között.
Állítsa be az átalakító lekérdezést explicit eseménykinyerések uniójaként. Minden kinyerésnek a következő mezőket kell visszaadnia: JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource és OfferStatus. Egységesítse az időbélyegek időzónáját, távolítsa el az érvényes jelentkezésazonosító vagy tevékenységi időbélyeg nélküli rekordokat, és minden tevékenységet jelentő forráseseményhez őrizzen meg egy sort.
Alkalmazza az események megfeleltetési szabályait. Az Application Received tevékenységhez használja a jelentkezés létrehozásának vagy beküldésének adatait; az Application Reviewed tevékenységhez egyértelmű felülvizsgálati szakaszt vagy állapotváltást; a Recruiter Screen Conducted tevékenységhez toborzói előszűrési rekordot vagy beállított telefonos előszűrési szakaszváltást; az Interview Scheduled tevékenységhez az interjú visszaigazolását vagy ütemezett időpontját; az Interview Completed tevékenységhez az interjú befejezését vagy a visszajelzés beküldésének időpontját; a Feedback Submitted tevékenységhez a visszajelzés beküldését; az Offer Created tevékenységhez az ajánlat létrehozását; az Offer Extended tevékenységhez az ajánlat elküldését vagy kiterjesztett állapotát; az Offer Accepted tevékenységhez az elfogadott ajánlat állapotát; a Background Check Initiated tevékenységhez rögzített háttérellenőrzés-indítási eseményt; az Onboarding Initiated tevékenységhez beléptetési átadási vagy indítási eseményt; a Candidate Hired tevékenységhez felvételi eredményt; az Offer Rejected tevékenységhez visszautasított ajánlatot; az Application Rejected tevékenységhez pedig elutasított jelentkezési eredményt vagy elutasítási szakaszváltást.
Töltse be az átalakított eredményt a ProcessMind eseménynaplójának fenntartott cél-táblájába vagy nézetébe. Tartsa meg a duplikált forráseseményeket, kivéve, ha dokumentált üzleti szabály alapján technikai duplikátumnak minősülnek. Ha deduplikálásra van szükség, csak az azonos forrásesemény-kulcsú rekordokat vonja össze, például ha megegyezik a jelentkezésazonosító, a tevékenység neve, a tevékenység időbélyege és a forrásrekord-azonosító.
Az alábbi ellenőrzésekkel validálja az eredményt. Győződjön meg róla, hogy minden szükséges oszlop szerepel, az időbélyegek érvényesek, minden szükséges tevékenység megjelenik, ha van hozzá forrásadat, és az esetazonosító jelentkezésenként egyedi. Vizsgálja meg külön az elutasított, visszavont, archivált és hiányos jelentkezéseket, hogy a szűrés ne távolítson el véletlenül érvényes folyamatkimeneteleket.
Exportálja vagy tegye elérhetővé a végső eredményt egyszerű CSV-fájlként vagy a ProcessMindba való feltöltést támogató adattárházi kapcsolaton keresztül. A JobApplicationId mezőt rendelje az esetazonosítóhoz, az ActivityName mezőt a tevékenységhez, az ActivityTimestamp mezőt pedig az esemény időbélyegéhez. Vegye fel a SourceSystem és LastDataUpdate mezőket, tartsa meg az ajánlott attribútumokat, használjon egységes időbélyeg-formátumot, például időzónát is tartalmazó ISO 8601-et, és ne számítson arra, hogy a ProcessMind kikövetkezteti a fájlból hiányzó eseményeket.

Konfiguráció

Összekötő és célrendszer: Használjon licencelt ETL-platformot, amely támogatott Greenhouse-összekötővel és az átalakítási réteg számára elérhető céladattárházzal rendelkezik. Az összekötő képességei, az objektumnevek, a frissítési időközök és az előzmények replikációjának támogatása a választott platformtól és előfizetéstől függ.
Forrásengedélyezés: Állítsa be az összekötőhöz szükséges Greenhouse-hitelesítő adatokat és jogosultságokat. Ellenőrizze, hogy az engedélyezett fiók hozzáfér-e a jelentkezési rekordokhoz, a szakasz- vagy állapotelőzményekhez, az interjúrekordokhoz, a visszajelzésekhez, az ajánlatokhoz, valamint a megfeleltetésben használt integrált háttérellenőrzési vagy beléptetési adatokhoz.
Replikált objektumok: Válassza ki a 14 eseménykinyeréshez szükséges összes forrásobjektumot. Ne csak az aktuális jelentkezési táblát replikálja, ha a korábbi szakaszváltásokat, interjútevékenységeket, visszajelzéseket, ajánlatállapot-változásokat vagy további átadásokat külön tárolják.
Dátumtartomány: Működési elemzéshez kezdje 3–6 hónappal. A teljes jelentkezési életciklus méréséhez bővítse az időszakot, mert a korábban létrehozott jelentkezések később juthatnak el az interjúig, az ajánlatig vagy a felvételig.
Növekményes frissítés: Őrizze meg a forrás létrehozási, bekövetkezési és utolsó frissítési időbélyegeit, ha rendelkezésre állnak. Állítson be a szükséges jelentési késéshez igazodó rendszeres frissítést, és hagyjon rövid átfedési időszakot a késve érkező vagy javított rekordoknak.
Szűrők: Csak dokumentált, vállalatspecifikus szűrőket alkalmazzon, például szervezet, részleg, állás, helyszín vagy jelentkezési dátum alapján. Ne használjon általános szűrőket, például Company Code vagy Document Type mezőt, kivéve, ha ezek ténylegesen szerepelnek a replikált Greenhouse-sémában, és a beállításaihoz szükségesek.
Tevékenységek megfeleltetése: Tartson fenn dokumentált megfeleltetést a forrásesemény típusa, szakasza, állapota vagy időbélyege és az egyes ActivityName értékek között. A felülvizsgálathoz, telefonos előszűréshez, elutasításhoz, ajánlathoz, elfogadáshoz, háttérellenőrzéshez, beléptetéshez és felvételi eredményhez a szervezet által használt pontos értékeket állítsa be.
Null értékek kezelése: A RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource és OfferStatus mezők értéke lehet null, ha a forrás nem tartalmazza őket. A kötelező azonosítók és időbélyegek hiányát utasítsa el vagy vizsgálja ki.
Időzónák: Az összes tevékenységi időbélyeget alakítsa át egyetlen jelentési időzónára. Ha az auditálhatóság megköveteli, őrizze meg az eredeti forrás-időbélyeget is. A LastDataUpdate a frissítés vagy kinyerés időpontját jelölje, ne a tevékenység bekövetkezését.
Teljesítmény: Nagy adathalmazoknál szűrje a forrásadatokat a replikált időbélyeg-partíciók alapján, csak a szükséges oszlopokat válassza ki, használjon növekményes betöltést, és materializálja a végső eseménynaplót. Ne kapcsolja össze ismételten a teljes előzményt az aktuális jelentkezési rekordokkal indexelt azonosítók nélkül.
Adatmegőrzés: Ellenőrizze, hogy az ETL-platform és a Greenhouse-hozzáférés megőrzi-e a kiválasztott időszakra vonatkozó szakasz-, interjú-, visszajelzés-, ajánlat- és eredményrekordokat. A csak aktuális állapotot tartalmazó táblákból nem lehet megbízhatóan rekonstruálni a korábbi tevékenységeket.
ProcessMind-megfeleltetés: A JobApplicationId mezőt állítsa be esetazonosítóként, az ActivityName mezőt tevékenységmezőként, az ActivityTimestamp mezőt pedig esemény-időbélyegként. Ellenőrizze, hogy az exportált fájl minden tevékenységhez külön sort tartalmaz, és nem támaszkodik kikövetkeztetett állapotváltásokra.

Példa-lekérdezés 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;

Kezdheti?

Hozza ki a legtöbbet a felvételi adataiból. Használja ezt a sablont már ma, hogy egyszerűsítse a toborzási folyamatot, és adatok alapján hozza meg döntéseit.

Vissza a folyamatfejlesztési útmutatóhoz

Sablon letöltése

Egyszerűsítse a tehetségszerzést a Greenhouse-ban

Csökkentse 30%-kal a felvételi ciklus idejét, és javítsa a jelöltek tapasztalatait.

Próbálja ki ingyen

Bankkártya nem szükséges \b• Beállítás 5 perc alatt

Adatsablon a toborzáshoz és a tehetségszerzéshez

Adatsablon a toborzáshoz és a tehetségszerzéshez

A toborzás és a tehetségszerzés attribútumai

A toborzás és a tehetségszerzés tevékenységei

Útmutatók az adatok kinyeréséhez

Greenhouse Report Builder kézi CSV-exporthoz

Lépések

Konfiguráció

Példa-lekérdezés config

Adatok kinyerése Python-szkripttel a Greenhouse Harvest API-n keresztül

Lépések

Konfiguráció

Példa-lekérdezés python

Automatizált ETL-eszköz Greenhouse-összekötővel

Lépések

Konfiguráció

Példa-lekérdezés config

Kezdheti?

Egyszerűsítse a tehetségszerzést a Greenhouse-ban