> Ciągłe doskonalenie procesów > Rekrutacja i pozyskiwanie talentów > Greenhouse > Szablon danych

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Greenhouse

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu rekrutacji i pozyskiwania talentów(21) Aktywności w procesie rekrutacji i pozyskiwania talentów(14) Instrukcje pobierania danych(3)

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Ten szablon pokazuje, jak zebrać odpowiednie dane o procesie rekrutacji i pozyskiwania talentów. Zawiera listę atrybutów do śledzenia, najważniejsze aktywności do zarejestrowania oraz wskazówki dotyczące pobierania tych informacji z systemu Greenhouse. Dzięki temu można przygotować dane potrzebne do analizy procesu.

Zalecane atrybuty do zebrania
Najważniejsze aktywności do śledzenia
Wskazówki dotyczące pobierania danych

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty procesu rekrutacji i pozyskiwania talentów

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby dokładnie analizować proces rekrutacji i pozyskiwania talentów w Greenhouse.

5 Wymagane 6 Zalecane 10 Opcjonalne

	Nazwa	Opis
	Aplikacja na stanowisko JobApplicationId	Unikalny identyfikator aplikacji kandydata na konkretne stanowisko.
Opis Identyfikator aplikacji na stanowisko jest podstawowym identyfikatorem case w analizie procesu rekrutacji. Łączy wszystkie powiązane działania, od złożenia aplikacji i wstępnej selekcji po rozmowy, oferty i ostateczną decyzję o zatrudnieniu. Dzięki temu można prześledzić cały przebieg rekrutacji każdego kandydata. W process mining ten atrybut służy do odtworzenia dokładnej ścieżki kandydata w lejku rekrutacyjnym. Umożliwia analizę wariantów procesu, czasu realizacji każdej aplikacji i miejsc, w których kandydaci rezygnują. Daje pełny obraz procesu rekrutacji dla każdej osoby aplikującej. Dlaczego to ważne To podstawowy identyfikator case, który łączy wszystkie zdarzenia rekrutacyjne dotyczące jednego kandydata. Pozwala analizować cały przebieg rekrutacji od początku do końca. Skąd pobrać Zwykle jest to klucz główny obiektu aplikacji. Szczegóły można znaleźć w dokumentacji API Greenhouse, w punkcie końcowym „Applications”, gdzie pole jest często określane jako „id” lub „application_id”. Przykłady 987654321098765432119876543212
	Nazwa działania ActivityName	Nazwa konkretnego działania lub etapu rekrutacji.
Opis Ten atrybut zapisuje nazwę każdego zdarzenia w procesie rekrutacji, na przykład „Otrzymano aplikację”, „Umówiono rozmowę kwalifikacyjną” lub „Zaakceptowano ofertę”. Z tych zdarzeń powstaje mapa procesu. Analiza kolejności i częstotliwości działań jest podstawą process mining. Pozwala zobrazować lejek rekrutacyjny, wskazać typowe ścieżki, wykryć odstępstwa od standardowego workflow i znaleźć wąskie gardła, w których proces się zatrzymuje. Można na przykład sprawdzić, ile aplikacji przechodzi z etapu „Przejrzano aplikację” do „Przeprowadzono rozmowę wstępną z osobą rekrutującą”. Dlaczego to ważne Ten atrybut określa etapy procesu rekrutacji, pozwala zobrazować jego przebieg oraz wykryć wąskie gardła i odstępstwa. Skąd pobrać Wartość jest często wyznaczana na podstawie zmian etapów aplikacji, statusów rozmów, zdarzeń dotyczących ofert lub innych rejestrowanych działań w Greenhouse. Może być potrzebna logika, która przekształci zdarzenia systemowe w ujednolicone nazwy działań. Przykłady Przejrzano aplikacjęPrzeprowadzono rozmowę kwalifikacyjnąPrzyjęto ofertęOdrzucenie aplikacji
	Znacznik czasu działania ActivityTimestamp	Dokładna data i godzina wystąpienia działania rekrutacyjnego.
Opis Znacznik czasu działania wskazuje dokładny moment wystąpienia zdarzenia w procesie rekrutacji. Stanowi podstawę analizy wyników i czasu trwania oraz określa chronologiczną kolejność działań dla każdej aplikacji. Ten znacznik jest niezbędny do obliczania KPI związanych z czasem, takich jak czas rekrutacji, czas od umówienia do przeprowadzenia rozmowy oraz czas oczekiwania na opinię po rozmowie. Analiza odstępów między działaniami pozwala mierzyć sprawność procesu, wykrywać opóźnienia i monitorować przestrzeganie umów o poziomie usług. Wspiera też dashboardy dotyczące wyników i wąskich gardeł. Dlaczego to ważne Ten znacznik czasu jest niezbędny do ustalania kolejności zdarzeń, obliczania czasu realizacji i analizy wyników procesu rekrutacji. Skąd pobrać Dostępny w różnych obiektach Greenhouse, na przykład jako „applied_at” w obiekcie Application, „created_at” w obiektach Offer lub znaczniki czasu w kanałach aktywności i dziennikach audytowych. Przykłady 2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-11-05T09:15:00Z
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu wskazujący, kiedy dane dotyczące tego zdarzenia zostały ostatnio odświeżone lub pobrane.
Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z systemu źródłowego. To pole metadanych informujące o aktualności danych w modelu process mining. Dzięki tej informacji użytkownicy wiedzą, jak aktualna jest analiza. Mogą uwzględnić opóźnienie w dostępności danych i sprawdzić, czy ich przepływ działa zgodnie z harmonogramem. Jeśli na przykład od ostatniej aktualizacji danych minęło kilka dni, wiadomo, że dashboardy nie pokazują najnowszych działań rekrutacyjnych. Dlaczego to ważne Informuje o aktualności danych i pozwala ocenić, czy analiza odzwierciedla bieżący stan procesu. Skąd pobrać Ten znacznik czasu jest generowany i dodawany do zbioru danych podczas procesu pobierania, przekształcania i ładowania danych (ETL). Przykłady 2023-11-20T02:00:00Z2023-11-21T02:00:00Z2023-11-22T02:00:00Z
	System źródłowy SourceSystem	Wskazuje system źródłowy, z którego pobrano dane.
Opis Ten atrybut określa źródło danych rekrutacyjnych. W tym procesie jego wartością będzie zawsze „Greenhouse”. Choć może się wydawać, że jest to stała wartość, jawne zapisywanie systemu źródłowego ma znaczenie dla zarządzania danymi, rozwiązywania problemów i sytuacji, w których dane są uzupełniane z innych systemów, na przykład HRIS. Pozwala ustalić pochodzenie danych i dbać o ich integralność w całym środowisku danych organizacji. Dlaczego to ważne Pozwala jednoznacznie ustalić pochodzenie danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji i obsługi danych z wielu źródeł. Skąd pobrać To stała wartość dodawana podczas pobierania i przekształcania danych, aby oznaczyć ich źródło. Przykłady Greenhouse
	Dział JobDepartment	Dział lub jednostka biznesowa, dla której prowadzi się rekrutację na dane stanowisko.
Opis Ten atrybut określa dział organizacji, na przykład „Inżynieria”, „Marketing” lub „Sprzedaż”, powiązany z zapotrzebowaniem na pracownika. Pozwala zestawiać i porównywać wskaźniki rekrutacyjne w różnych częściach firmy. Podział analizy według działów jest przydatny w dashboardach takich jak „Wyniki dotyczące czasu rekrutacji” i „Trendy wskaźnika akceptacji ofert”. Pomaga ustalić, czy w niektórych działach rekrutacja trwa dłużej, częściej odrzuca się oferty lub inaczej przestrzega procesu. Dzięki temu można wprowadzać usprawnienia dopasowane do potrzeb poszczególnych działów. Dlaczego to ważne Pozwala porównywać wyniki rekrutacji i przebieg procesu w różnych działach, ujawniając problemy systemowe i dobre praktyki. Skąd pobrać Zwykle dostępne jako standardowe lub niestandardowe pole obiektu Job w Greenhouse. Można je znaleźć w sekcji „departments” rekordu Job za pośrednictwem API. Przykłady InżynieriaZarządzanie produktemSprzedażMarketing
	Imię i nazwisko osoby rekrutującej RecruiterName	Imię i nazwisko osoby odpowiedzialnej za prowadzenie aplikacji na stanowisko.
Opis Ten atrybut wskazuje osobę rekrutującą przypisaną do konkretnej aplikacji lub zapotrzebowania na pracownika. Zwykle odpowiada ona za wstępną selekcję, koordynację rozmów i prowadzenie kandydata przez proces. Analiza procesu według osób rekrutujących pomaga ocenić indywidualne wyniki i rozkład obciążenia pracą. Dashboard „Obciążenie i sprawność pracy osób rekrutujących” wykorzystuje ten atrybut do obliczania takich miar jak liczba obsłużonych aplikacji i czas realizacji. Ułatwia wskazanie osób osiągających dobre wyniki, tych, które mogą potrzebować wsparcia, oraz nierównomiernego obciążenia zespołu pozyskiwania talentów. Dlaczego to ważne Przypisuje działania procesowe konkretnej osobie rekrutującej, co pozwala analizować jej wyniki, obciążenie pracą i sprawność. Skąd pobrać Dostępne w obiekcie Job w Greenhouse, zwykle w sekcji „hiring_team”, gdzie określa się role, takie jak „Recruiter”. Przykłady Alicja JohnsonRobert DavisMaria Garcia
	Nazwa stanowiska JobTitle	Nazwa stanowiska, na które aplikuje kandydat.
Opis Ten atrybut zawiera oficjalną nazwę stanowiska, na przykład „Starszy inżynier oprogramowania” lub „Menedżer ds. marketingu produktu”. Określa, na jakie stanowisko prowadzona jest rekrutacja. Analiza procesu według nazw stanowisk pomaga zrozumieć trudności związane z konkretnymi rolami. Na przykład dashboard „Wyniki dotyczące czasu rekrutacji” pokazuje, czy obsadzenie stanowisk seniorskich lub wymagających specjalistycznych kwalifikacji trwa dłużej. Atrybut ten pozwala też analizować wskaźniki akceptacji ofert dla różnych stanowisk, co może wskazać problemy z konkurencyjnością wynagrodzenia lub atrakcyjnością roli. Dlaczego to ważne Pozwala filtrować i porównywać wskaźniki rekrutacyjne dla konkretnych stanowisk oraz sprawdzać, jak złożoność lub rodzaj roli wpływa na wyniki procesu. Skąd pobrać To podstawowe pole obiektu Job w Greenhouse, często dostępne jako „name” podczas pobierania danych z punktu końcowego „jobs” za pośrednictwem API. Przykłady Starszy inżynier oprogramowaniaSpecjalista ds. sprzedażyProjektant UX/UI
	Status aplikacji ApplicationStatus	Końcowy wynik lub bieżący stan aplikacji na stanowisko.
Opis Ten atrybut określa status aplikacji, na przykład „Zatrudniony”, „Odrzucony” lub „Aktywny”. Wskazuje stan końcowy zakończonego procesu albo bieżący stan procesu, który nadal trwa. To ważny wymiar analizy wyników. Pozwala porównywać ścieżki kandydatów zatrudnionych i odrzuconych, co może ujawnić cechy skutecznych rekrutacji. Służy też do obliczania współczynników konwersji w dashboardzie „Cały lejek rekrutacyjny”, który pokazuje, jaki odsetek aplikacji kończy się zatrudnieniem. Dlaczego to ważne Określa wynik procesu rekrutacji i pozwala porównywać przebieg rekrutacji zakończonych zatrudnieniem z tymi, w których kandydat został odrzucony. Skąd pobrać Informacja znajduje się w obiekcie Application w Greenhouse i jest dostępna w polu „status” za pośrednictwem API. Przykłady ZatrudnionoOdrzuconoAktywna
	Status oferty OfferStatus	Bieżący status oferty pracy przedstawionej kandydatowi.
Opis Ten atrybut śledzi stan oferty, na przykład „Utworzona”, „Przedstawiona”, „Zaakceptowana” lub „Odrzucona”. Wskazuje wynik końcowych etapów procesu rekrutacji. Atrybut ten jest niezbędny w dashboardzie „Trendy wskaźnika akceptacji ofert” i powiązanym z nim KPI. Śledząc przejście od „Przedstawiono ofertę” do „Zaakceptowano ofertę” lub „Odrzucono ofertę”, firmy mogą ocenić, jak skutecznie finalizują rekrutację. Analiza według działu lub stanowiska może ujawnić problemy z konkurencyjnością wynagrodzenia, doświadczeniami kandydatów lub innymi czynnikami wpływającymi na ich decyzje. Dlaczego to ważne Śledzi wyniki ofert pracy. Jest niezbędny do obliczania KPI dotyczącego wskaźnika akceptacji ofert i ustalenia, jak go poprawić. Skąd pobrać Dostępne w obiekcie Offer w Greenhouse, powiązanym z aplikacją. Informację zawiera pole „status”. Przykłady ZaakceptowanoOdrzuconoWysłanaUtworzona
	Źródło aplikacji ApplicationSource	Kanał, za pośrednictwem którego wpłynęła aplikacja kandydata.
Opis Ten atrybut wskazuje źródło aplikacji na stanowisko, na przykład „LinkedIn”, „Polecenie pracownika”, „Strona kariery firmy” lub „Indeed”. Pozwala ocenić skuteczność różnych kanałów rekrutacyjnych. Dashboard „Skuteczność kanałów pozyskiwania kandydatów” opiera się na tym atrybucie. Analiza liczby aplikacji, czasu rekrutacji i liczby zatrudnień według źródła pomaga lepiej rozdysponować budżet i nakład pracy na rekrutację. Dane te pozwalają ustalić, które kanały dostarczają najlepszych kandydatów przy najmniejszym nakładzie, i wspierają KPI „Współczynnik konwersji według kanału pozyskiwania kandydatów”. Dlaczego to ważne Pomaga mierzyć skuteczność i zwrot z inwestycji w poszczególne kanały rekrutacyjne, ułatwiając podejmowanie decyzji o tym, gdzie kierować działania związane z pozyskiwaniem kandydatów. Skąd pobrać Dostępne w obiekcie Candidate w Greenhouse, powiązanym z aplikacją. Informację zawiera pole „source”. Przykłady LinkedInPolecenie pracownikaStrona kariery firmyIndeed
	Czas oczekiwania na opinię po rozmowie InterviewFeedbackTurnaroundTime	Czas od zakończenia rozmowy kwalifikacyjnej do przesłania opinii przez osobę prowadzącą rozmowę.
Opis Ta obliczana miara pokazuje, jak szybko zespół rekrutacyjny przekazuje opinie. Opóźnienia w ich przesyłaniu mogą znacznie wydłużyć rekrutację i pogorszyć doświadczenia kandydatów. Atrybut ten bezpośrednio wspiera dashboard „Analiza obiegu opinii po rozmowie” i KPI „Czas oczekiwania na opinię po rozmowie”. Oblicza się go jako różnicę czasu między działaniami „Rozmowa kwalifikacyjna zakończona” i „Przesłano opinię”. Monitorowanie tej miary pomaga wykrywać wąskie gardła wynikające z opóźnionego przekazywania opinii i przyspieszać podejmowanie decyzji. Dlaczego to ważne Mierzy sprawność przekazywania opinii po rozmowie, które często powoduje opóźnienia w rekrutacji. Skąd pobrać To pole obliczane na podstawie różnicy między znacznikiem czasu zdarzenia „Rozmowa kwalifikacyjna zakończona” a znacznikiem czasu zdarzenia „Przesłano opinię”. Przykłady 86400172800259200
	Czas zakończenia działania ActivityEndTime	Znacznik czasu wskazujący, kiedy zakończyło się działanie trwające przez określony czas.
Opis Ten atrybut zapisuje czas zakończenia działań trwających przez pewien okres, takich jak rozmowa kwalifikacyjna lub weryfikacja kandydata. Wiele działań jest natychmiastowych, ale w przypadku tych o mierzalnym czasie trwania warto zapisać zarówno początek, jak i koniec. Czas zakończenia jest niezbędny do dokładnego obliczania czasu realizacji lub trwania poszczególnych działań. Pozwala odróżnić oczekiwanie między etapami od czasu faktycznie poświęconego na zadanie. Można na przykład precyzyjniej ustalić, ile trwa sama rozmowa, a ile jej umówienie. Dlaczego to ważne Pozwala dokładnie obliczać czas realizacji działań i odróżniać czas aktywnej pracy od oczekiwania. Skąd pobrać Informacja może być dostępna w obiektach takich jak „scheduled_interview” w Greenhouse, które często zawierają zarówno godzinę rozpoczęcia, jak i zakończenia. W przypadku innych działań można ją wywnioskować ze znacznika czasu kolejnego działania. Przykłady 2023-10-27T15:35:10Z2023-11-05T10:15:00Z2023-11-10T11:00:00Z
	Czy działanie jest zautomatyzowane IsAutomated	Wskaźnik określający, czy działanie wykonał automatycznie system.
Opis Ten atrybut logiczny wskazuje, czy działanie wykonał użytkownik, czy automatyczna reguła systemowa. Przykłady działań automatycznych to wysyłanie wiadomości e-mail z automatyczną odpowiedzią lub odrzucanie kandydatów, którzy nie spełniają podstawowego kryterium selekcji. Analiza tego atrybutu pomaga ocenić poziom automatyzacji procesu rekrutacji. Można porównać sprawność i wyniki działań automatycznych oraz ręcznych, a także wskazać możliwości dalszej automatyzacji, która poprawi szybkość i spójność procesu. Dlaczego to ważne Pozwala odróżnić działania ręczne od automatycznych i analizować wpływ automatyzacji na sprawność procesu oraz jego wyniki. Skąd pobrać To nie jest standardowe pole, dlatego zwykle trzeba je wyznaczyć. Można je wnioskować na podstawie użytkownika przypisanego do działania, na przykład użytkownika „System”, lub na podstawie typów zdarzeń, o których wiadomo, że są automatyczne. Przykłady truefalse
	Czy proces jest zgodny IsCompliant	Obliczany wskaźnik określający, czy aplikacja przeszła przez standardowy, zdefiniowany proces rekrutacji.
Opis Ten atrybut logiczny jest wynikiem kontroli zgodności, która porównuje rzeczywistą kolejność działań dotyczących aplikacji ze zdefiniowanym wzorcowym modelem procesu. Oznacza przypadki odstępstw, na przykład pominięcie wymaganego etapu lub wykonanie działań w niewłaściwej kolejności. Atrybut ten jest podstawą dashboardu „Odstępstwa od zasad rekrutacji” oraz KPI „Zgodność procesu” i „Liczba naruszeń zgodności”. Filtrowanie przypadków niezgodnych z procesem pozwala ustalić, dlaczego dochodzi do odstępstw: z powodu niewystarczającego przeszkolenia, ograniczeń systemu czy uzasadnionych wyjątków. Pomaga to ujednolicić workflow i ograniczyć ryzyko naruszeń zgodności. Dlaczego to ważne Wskazuje odstępstwa od procesu, co pozwala mierzyć jego zgodność, dbać o przestrzeganie wymagań i ujednolicać workflow rekrutacyjny. Skąd pobrać To pole obliczane przez oprogramowanie process mining. Porównuje dane z dziennika zdarzeń ze zdefiniowanym modelem docelowym lub zestawem reguł biznesowych. Przykłady truefalse
	Etap rozmowy kwalifikacyjnej InterviewStageName	Konkretna nazwa lub rodzaj etapu rozmowy kwalifikacyjnej.
Opis Ten atrybut określa konkretny etap rozmowy kwalifikacyjnej, na przykład „Wstępna rozmowa z osobą rekrutującą”, „Rozmowa techniczna” lub „Ostatni etap”. Zapewnia dokładniejsze informacje niż ogólne działanie „Rozmowa kwalifikacyjna zakończona”. Analiza wskaźników dla poszczególnych etapów pozwala dokładniej wskazać wąskie gardła. Można na przykład precyzyjnie mierzyć „Odsetek kandydatów rezygnujących na poszczególnych etapach” i ustalić, czy kandydaci wycofują się częściej po rozmowie technicznej, czy po wstępnej selekcji. Te informacje pomagają wprowadzać konkretne usprawnienia w przebiegu rozmów. Dlaczego to ważne Zapewnia dokładniejszy obraz rozmów kwalifikacyjnych i pozwala analizować czas realizacji oraz odsetek rezygnacji na każdym etapie. Skąd pobrać Informacja jest częścią danych o planowaniu rozmów w Greenhouse. Obiekt „interviews” w aplikacji na stanowisko zawiera szczegóły dotyczące etapu rozmowy. Przykłady Wstępna rozmowa z osobą rekrutującąRozmowa z menedżerem ds. rekrutacjiOcena technicznaKońcowa rozmowa na miejscu
	Identyfikator kandydata CandidateId	Unikalny identyfikator kandydata, niezależny od konkretnej aplikacji.
Opis Identyfikator kandydata jednoznacznie wskazuje osobę w puli kandydatów, natomiast identyfikator aplikacji na stanowisko dotyczy jednej aplikacji na jedno stanowisko. Ta sama osoba może z czasem złożyć wiele aplikacji. Identyfikator aplikacji na stanowisko pełni funkcję identyfikatora case w tym widoku procesu, a identyfikator kandydata umożliwia inny rodzaj analizy. Można śledzić przebieg wielu aplikacji tej samej osoby, wskazywać osoby często aplikujące i analizować ich relacje z pulą kandydatów. Pozwala to spojrzeć na dane rekrutacyjne z perspektywy konkretnej osoby. Dlaczego to ważne Pozwala analizować wiele aplikacji tej samej osoby i szerzej ocenić jej zaangażowanie w proces rekrutacji na przestrzeni czasu. Skąd pobrać To klucz główny rekordu kandydata w Greenhouse, dostępny jako „id” w obiekcie Candidate za pośrednictwem API. Przykłady 123456123457123458
	Identyfikator stanowiska JobId	Unikalny identyfikator zapotrzebowania na pracownika lub ogłoszenia o pracę.
Opis Ten atrybut jest unikalnym identyfikatorem stanowiska, odrębnym od identyfikatora aplikacji. Wiele aplikacji może być powiązanych z tym samym identyfikatorem stanowiska. Identyfikator stanowiska pozwala agregować dane na poziomie zapotrzebowania na pracownika. Można na przykład analizować łączną liczbę aplikacji na konkretne stanowisko lub średni czas rekrutacji dla stanowisk tego samego rodzaju. Umożliwia grupowanie i analizowanie działań rekrutacyjnych związanych z jednym wolnym stanowiskiem. Dlaczego to ważne Umożliwia agregowanie i analizowanie wszystkich danych kandydatów dotyczących jednego wakatu, zapewniając widok skoncentrowany na zapotrzebowaniu rekrutacyjnym. Skąd pobrać To klucz główny rekordu oferty pracy w Greenhouse. W obiekcie Job jest dostępny jako „id” za pośrednictwem API. Przykłady 400123400124400125
	Imię i nazwisko menedżera ds. rekrutacji HiringManagerName	Imię i nazwisko menedżera ds. rekrutacji przypisanego do danego zapotrzebowania na pracownika.
Opis Ten atrybut wskazuje menedżera zespołu, w którym jest wolne stanowisko. Menedżer ds. rekrutacji jest ważną osobą w procesie. Często ocenia kandydatów, prowadzi rozmowy na późniejszych etapach i podejmuje ostateczną decyzję o zatrudnieniu. Analiza procesu według menedżerów ds. rekrutacji może ujawnić istotne zależności i wąskie gardła. Na przykład dashboard „Wąskie gardła w planowaniu rozmów” może pokazać, że opóźnienia często wynikają z ograniczonej dostępności konkretnych menedżerów. Pozwala to ustalić, kto potrzebuje szkolenia lub wsparcia, aby menedżerowie sprawnie uczestniczyli w rekrutacji. Dlaczego to ważne Wskazuje ważną osobę zaangażowaną w proces i pozwala analizować wąskie gardła oraz sprawność rekrutacji w odniesieniu do konkretnych menedżerów. Skąd pobrać Dostępne w obiekcie Job w Greenhouse, zwykle w sekcji „hiring_team”, gdzie określa się role, takie jak „Hiring Manager”. Przykłady Emily TranDavid ChenSophia Rodriguez
	Powód odrzucenia RejectionReason	Powód odrzucenia aplikacji kandydata.
Opis Ten atrybut zapisuje konkretny powód, dla którego kandydat nie przeszedł do kolejnego etapu. Przykłady: „Niedopasowanie do kultury organizacyjnej”, „Zbyt wysokie oczekiwania finansowe” lub „Wybrano lepiej wykwalifikowanego kandydata”. Analiza powodów odrzucenia dostarcza cennych informacji o procesie rekrutacji. Może ujawnić problemy, takie jak nieprecyzyjne opisy stanowisk, niekonkurencyjne wynagrodzenie lub powtarzające się braki kompetencyjne wśród kandydatów. Informacje te pomagają ulepszać strategie pozyskiwania kandydatów i ich doświadczenia, ponieważ pokazują, na których etapach najczęściej kończy się rekrutacja. Dlaczego to ważne Pokazuje, dlaczego kandydaci odpadają z lejka rekrutacyjnego, co pomaga dopracować opisy stanowisk, sposoby pozyskiwania kandydatów i kryteria selekcji. Skąd pobrać Dostępne w obiekcie Application po odrzuceniu aplikacji. API udostępnia obiekt „rejection_reason” ze szczegółami. Przykłady Brak wymaganych umiejętnościZbyt wysokie oczekiwania finansoweWybrano lepiej wykwalifikowanego kandydata
	Rekomendacja z formularza oceny ScorecardOverallRecommendation	Ogólna rekomendacja dotycząca zatrudnienia na podstawie wypełnionego formularza oceny rozmowy.
Opis Ten atrybut zapisuje końcową rekomendację osoby prowadzącej rozmowę, podaną w ustrukturyzowanym formularzu oceny. Typowe wartości to „Zdecydowanie tak”, „Tak”, „Nie” i „Zdecydowanie nie”. Dane te pomagają ocenić jakość i spójność rozmów kwalifikacyjnych. Można zestawić opinie z rozmów z faktycznymi wynikami rekrutacji i sprawdzić na przykład, czy kandydaci z lepszymi rekomendacjami są częściej zatrudniani. Atrybut ten stanowi też podstawę KPI „Wskaźnik wypełnienia formularzy oceny”, który mierzy wykorzystanie ustrukturyzowanych metod rekrutacji w organizacji. Dlaczego to ważne Łączy ustrukturyzowane opinie z rozmów z wynikami procesu i pomaga mierzyć wykorzystanie metod rekrutacji opartych na danych. Skąd pobrać Dostępne w obiekcie Scorecard powiązanym z zakończoną rozmową w Greenhouse. API udostępnia te informacje w punkcie końcowym „scorecards”. Przykłady Zdecydowanie nieNieTakZdecydowanie tak

Wymagane Zalecane Opcjonalne

Aktywności w procesie rekrutacji i pozyskiwania talentów

To najważniejsze kroki procesu i kamienie milowe, które warto rejestrować w dzienniku zdarzeń, aby dokładnie odkrywać przebieg procesu i usprawniać lejek rekrutacyjny.

7 Zalecane 7 Opcjonalne

	Działanie	Opis
	Odrzucenie aplikacji	Aplikacja kandydata została odrzucona na którymś etapie procesu. To najczęstszy niepomyślny wynik, który może wystąpić na dowolnym etapie.
Dlaczego to ważne To ważne zdarzenie końcowe przy analizie odpływu kandydatów z lejka rekrutacyjnego. Ustalenie, kiedy i dlaczego dochodzi do odrzuceń, pomaga wykryć nieefektywności procesu lub niedopasowane wymagania stanowiska. Skąd pobrać To jawne zdarzenie rejestrowane, gdy użytkownik odrzuca aplikację w Greenhouse. Często podawany jest powód odrzucenia, a dziennik aktywności zapisuje znacznik czasu. Rejestrowanie Rejestrowane na podstawie znacznika czasu odrzucenia aplikacji. Typ zdarzenia explicit
	Otrzymano aplikację	To zdarzenie rozpoczyna proces rekrutacji na dane stanowisko. Jest rejestrowane, gdy kandydat przesyła aplikację przez stronę kariery lub kanał pozyskiwania kandydatów albo gdy aplikacja zostaje ręcznie dodana do Greenhouse.
Dlaczego to ważne To główne zdarzenie rozpoczynające proces. Analiza czasu od tego zdarzenia do kolejnych etapów pozwala mierzyć czas rekrutacji i skuteczność kanałów pozyskiwania kandydatów. Skąd pobrać To jawne zdarzenie rejestrowane w Greenhouse podczas tworzenia aplikacji. Czas zdarzenia można ustalić na podstawie pola daty aplikacji lub znacznika czasu utworzenia obiektu aplikacji. Rejestrowanie Na podstawie znacznika czasu utworzenia rekordu aplikacji. Typ zdarzenia explicit
	Przekazano ofertę	Oficjalna oferta pracy została wysłana kandydatowi. To ważny etap kończący rozmowy i proces wyboru kandydata.
Dlaczego to ważne To działanie stanowi podstawę do obliczenia KPI odsetka przyjętych ofert. Rozpoczyna końcowy etap podejmowania decyzji przez kandydata. Skąd pobrać To jawne zdarzenie rejestrowane w Greenhouse, gdy status oferty zmienia się na „Wysłana” lub „Przekazana”. Obiekt oferty zawiera znaczniki czasu tych zmian statusu. Rejestrowanie Na podstawie znacznika czasu, gdy status oferty zostaje oficjalnie oznaczony jako wysłany. Typ zdarzenia explicit
	Przeprowadzono rozmowę kwalifikacyjną	Rozmowa z kandydatem się odbyła. Zdarzenie można ustalić na podstawie upływu zaplanowanego terminu rozmowy lub, dokładniej, momentu przekazania opinii po tej rozmowie.
Dlaczego to ważne To ważny etap w procesie kandydata. Stanowi punkt początkowy do pomiaru czasu przekazania opinii i przejścia do kolejnego etapu. Skąd pobrać Zwykle ustalane pośrednio. Można je określić na podstawie zaplanowanej godziny zakończenia rozmowy lub, dokładniej, znacznika czasu pierwszej opinii przekazanej po tej rozmowie. Rejestrowanie Ustalane na podstawie zaplanowanej godziny zakończenia rozmowy lub znacznika czasu późniejszego przekazania opinii. Typ zdarzenia inferred
	Przyjęto ofertę	Kandydat formalnie przyjął ofertę pracy. To ważny etap potwierdzający powodzenie rekrutacji, po którym zwykle rozpoczynają się działania przed zatrudnieniem, takie jak weryfikacja przeszłości kandydata.
Dlaczego to ważne To ważny etap potwierdzający powodzenie rekrutacji i istotny element KPI odsetka przyjętych ofert. Oznacza przejście od kandydata do przyszłego pracownika. Skąd pobrać To jawne zdarzenie rejestrowane w Greenhouse, gdy osoba rekrutująca zmienia status oferty na „Zaakceptowana” lub kandydat akceptuje ją elektronicznie. Rejestrowanie Rejestrowane na podstawie znacznika czasu zmiany statusu oferty na „Zaakceptowana”. Typ zdarzenia explicit
	Zaplanowano rozmowę kwalifikacyjną	W systemie zaplanowano rozmowę z kandydatem. Greenhouse integruje się z kalendarzami, dlatego zdarzenie jest zwykle rejestrowane w momencie potwierdzenia rozmowy.
Dlaczego to ważne To zdarzenie ma zasadnicze znaczenie przy analizie i wykrywaniu wąskich gardeł w planowaniu rozmów. Czas między nim a poprzednim etapem jest ważnym KPI efektywności rekruterów i koordynatorów. Skąd pobrać Dane pochodzą z funkcji planowania rozmów w Greenhouse. API udostępnia informacje o zaplanowanych rozmowach, w tym znaczniki czasu ich utworzenia. Rejestrowanie Rejestrowane podczas tworzenia wydarzenia dotyczącego rozmowy i powiązania go z aplikacją kandydata. Typ zdarzenia explicit
	Zatrudnienie kandydata	Kandydat pomyślnie przeszedł wszystkie kontrole przed zatrudnieniem i został oficjalnie oznaczony jako zatrudniony. To pomyślne zakończenie procesu rekrutacji.
Dlaczego to ważne To główny pomyślny wynik procesu. Czas od „Otrzymania zgłoszenia” do tego zdarzenia to całkowity czas rekrutacji, czyli ważny KPI dla rekrutacji. Skąd pobrać To jawne działanie w Greenhouse, w ramach którego osoba rekrutująca oznacza kandydata jako zatrudnionego na konkretnym stanowisku. Kandydat przechodzi w ten sposób ze statusu aktywnego do zatrudnionego. Rejestrowanie Rejestrowane na podstawie znacznika czasu działania „Oznacz jako zatrudnionego” w Greenhouse. Typ zdarzenia explicit
	Odrzucenie oferty	Kandydat formalnie odrzucił ofertę pracy. To niepomyślne zakończenie procesu, które następuje na późnym etapie rekrutacji.
Dlaczego to ważne Śledzenie tego wyniku jest ważne przy analizie wskaźnika akceptacji ofert. Częste odrzucenia mogą wskazywać na problemy z wynagrodzeniem, kulturą organizacyjną lub samym stanowiskiem. Skąd pobrać To jawne zdarzenie rejestrowane w Greenhouse, gdy status oferty zostaje zmieniony na „Odrzucona” lub „Odmówiono”. Obiekt oferty zawiera znacznik czasu tej zmiany. Rejestrowanie Rejestrowane na podstawie znacznika czasu zmiany statusu oferty na „Odrzucona”. Typ zdarzenia explicit
	Przejrzano aplikację	Rekruter lub menedżer ds. rekrutacji wstępnie ocenił aplikację kandydata. Zwykle można to ustalić na podstawie zmiany etapu lub statusu aplikacji z „Nowa” na aktywny etap oceny, na przykład „W trakcie oceny”.
Dlaczego to ważne Śledzenie tego etapu pomaga wykryć wąskie gardła podczas wstępnej selekcji i zmierzyć czas oczekiwania nowych aplikacji na rozpatrzenie. To punkt początkowy do obliczenia czasu planowania rozmowy. Skąd pobrać Ustalane na podstawie zmiany pola statusu aplikacji. Należy sprawdzić, czy status zmienił się z „Nowa” na „Do oceny”, i wykorzystać znacznik czasu tej zmiany. Rejestrowanie Ustalane na podstawie znacznika czasu zmiany statusu na „W trakcie oceny” lub podobny etap. Typ zdarzenia inferred
	Przekazano opinię	Osoba prowadząca rozmowę przesłała kartę oceny lub opinię o kandydacie. Ustrukturyzowany proces rekrutacyjny w Greenhouse wykorzystuje te informacje przy podejmowaniu decyzji, dlatego ich przekazanie jest osobnym rejestrowanym działaniem.
Dlaczego to ważne Terminowe przekazywanie opinii ma zasadnicze znaczenie dla dalszego prowadzenia kandydatów przez proces. To działanie pozwala analizować sprawność obiegu opinii i odsetek wypełnionych kart oceny. Skąd pobrać To jawne zdarzenie rejestrowane, gdy osoba prowadząca rozmowę przesyła kartę oceny przez Greenhouse. Obiekt Scorecards API zawiera znacznik czasu `submitted_at`. Rejestrowanie Na podstawie znacznika czasu przesłania karty oceny po rozmowie. Typ zdarzenia explicit
	Przeprowadzono wstępną rozmowę z rekruterem	Rekruter przeprowadził z kandydatem wstępną rozmowę telefoniczną lub inną rozmowę wprowadzającą. Zdarzenie jest często rejestrowane, gdy kandydat przechodzi do etapu „Rozmowa telefoniczna” w procesie rekrutacji.
Dlaczego to ważne To ważny etap kwalifikacji, który oznacza, że aplikacja przeszła wstępną selekcję dokumentów. Pomaga mierzyć obciążenie rekruterów i skuteczność wstępnej selekcji. Skąd pobrać Ustalane na podstawie znacznika czasu przeniesienia aplikacji do etapu „Rozmowa telefoniczna” lub z tego etapu w procesie rekrutacji w Greenhouse. Rejestrowanie Na podstawie historii etapów aplikacji, w szczególności momentu przejścia do etapu „Rozmowa telefoniczna”. Typ zdarzenia inferred
	Rozpoczęcie wdrożenia nowej osoby	Oficjalnie rozpoczęto wdrażanie nowej osoby do firmy. Często wiąże się to z przekazaniem danych z systemu rekrutacyjnego do systemu HRIS lub platformy onboardingowej.
Dlaczego to ważne Pozwala śledzić sprawność przekazania kandydata z rekrutacji do działu HR. Opóźnienia na tym etapie mogą pogorszyć doświadczenia nowej osoby, dlatego warto monitorować czas przekazania do wdrożenia. Skąd pobrać Może to być jawne zdarzenie, jeśli Greenhouse jest zintegrowany z systemem wdrożeniowym. W przeciwnym razie zdarzenie jest wnioskowane na podstawie znacznika czasu przeniesienia kandydata do końcowego etapu „Zatrudniony”, co uruchamia przekazanie. Rejestrowanie Wnioskowane na podstawie zmiany etapu lub wpisu integracji wskazującego na przekazanie danych do systemu HRIS. Typ zdarzenia inferred
	Rozpoczęcie weryfikacji kandydata	Rozpoczęto weryfikację kandydata, zwykle po zaakceptowaniu oferty. Zdarzenie może być zapisane jako zmiana etapu lub wywołanie integracji z usługą zewnętrzną.
Dlaczego to ważne To działanie ma znaczenie dla zgodności i monitorowania opóźnień w weryfikacji kandydatów przed zatrudnieniem. Pozwala analizować czas od zaakceptowania oferty do zakończenia wymaganych kontroli. Skąd pobrać Zdarzenie jest prawdopodobnie wnioskowane na podstawie przeniesienia kandydata do etapu „Weryfikacja kandydata” w procesie rekrutacji lub wpisu w dzienniku aktywności dotyczącego integracji z usługą weryfikacyjną. Rejestrowanie Wnioskowane na podstawie zmiany statusu na etap „Weryfikacja kandydata” lub wpisu API zintegrowanej usługi. Typ zdarzenia inferred
	Utworzono ofertę	Przygotowano oficjalną ofertę pracy, która może jeszcze wymagać wewnętrznej akceptacji. To formalna decyzja o złożeniu kandydatowi oferty.
Dlaczego to ważne To działanie oddziela decyzję o przygotowaniu oferty od jej przekazania kandydatowi. Pomaga analizować czas wewnętrznej akceptacji i wykrywać wąskie gardła, zanim oferta trafi do kandydata. Skąd pobrać Greenhouse ma osobny moduł ofert. Zdarzenie jest rejestrowane na podstawie znacznika czasu utworzenia obiektu oferty powiązanego z aplikacją. Rejestrowanie Rejestrowane podczas tworzenia rekordu oferty w systemie Greenhouse. Typ zdarzenia explicit

Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Greenhouse

Kroki

Zaloguj się na konto Greenhouse Recruiting.
Przejdź do sekcji Reports, klikając ikonę raportów (wyglądającą jak wykres słupkowy) na głównym pasku nawigacyjnym.
W dashboardzie Reports znajdź i kliknij „Essential Reports”. Podstawowym raportem do pobrania danych jest „All Applications”. Zawiera on pełny przegląd aplikacji i najważniejszych kamieni milowych.
Skonfiguruj raport „All Applications”. Kliknij przycisk „Columns” i wybierz wszystkie kolumny potrzebne do zebrania wymaganych atrybutów i znaczników czasu aktywności. Uwzględnij: 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.
Aby uwzględnić aktywności związane z rozmowami kwalifikacyjnymi, potrzebny będzie osobny raport. Wróć do „Essential Reports” i wybierz „Interview Details”.
Skonfiguruj raport „Interview Details”. W sekcji „Columns” wybierz co najmniej: Application ID, Interview Name, Scheduled Start i Scorecard Submitted At. Dzięki temu zostaną uwzględnione znaczniki czasu zaplanowania rozmowy i przesłania opinii.
W obu raportach ustaw odpowiedni zakres dat za pomocą filtrów. Często stosuje się filtr „Applied On” z wartością „All Time” lub określonym zakresem, na przykład ostatnich 6 miesięcy, aby uwzględnić odpowiednią grupę aplikacji.
Wygeneruj każdy raport, klikając przycisk „Update” lub „Generate”. Gdy raport się wyświetli, kliknij „Export to Excel”, aby pobrać dane jako plik CSV. Otrzymają Państwo dwa osobne pliki CSV.
Wyeksportowane pliki nie mają jeszcze formatu dziennika zdarzeń. Dane trzeba przekształcić za pomocą narzędzia takiego jak Python, R lub arkusz kalkulacyjny z funkcją przekształcania kolumn w wiersze, na przykład Power Query w Microsoft Excel.
Połącz dane z raportów „All Applications” i „Interview Details”, używając Application ID.
Dla każdej aplikacji utwórz osobny wiersz dla każdej wyeksportowanej kolumny z istotną datą. Na przykład wartość z kolumny „Applied On” staje się wartością „ActivityTimestamp” dla aktywności „Application Received”. Wartość z kolumny „Rejected On” tworzy aktywność „Application Rejected” i analogicznie należy postąpić z pozostałymi 14 wymaganymi aktywnościami. Kolumnę „Last Stage Change On” można wykorzystać do ustalenia aktywności takich jak „Application Reviewed” lub „Recruiter Screen Conducted”, jeśli nie ma osobnych znaczników czasu.
Przygotuj końcowy plik z wymaganymi kolumnami: JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate oraz zalecanymi atrybutami. Zapisz go jako jeden plik CSV do przesłania.

Konfiguracja

Podstawowe raporty: Dane należy pobrać, łącząc kilka raportów z sekcji Essential Reports w Greenhouse, przede wszystkim „All Applications” i „Interview Details”.
Najważniejsze kolumny (All Applications): Aby zebrać wszystkie potrzebne dane, wybierz między innymi kolumny Application ID, Candidate, Job, Department, Recruiter, Status, Source, Offer Status oraz odpowiednie kolumny z datami, w tym Applied On, Rejected On, Hired On, Offer Created On i Offer Accepted On.
Najważniejsze kolumny (Interview Details): Aby uwzględnić zdarzenia związane z rozmowami kwalifikacyjnymi, wybierz między innymi Application ID, Interview Name, Scheduled Start i Scorecard Submitted At.
Filtry zakresu dat: Zaleca się filtrowanie aplikacji według daty „Applied On” z okresu od 3 do 6 miesięcy. Pozwoli to uzyskać zbiór danych o odpowiedniej wielkości i zakresie. Dłuższy okres może wpłynąć na wydajność.
Wymagania wstępne: Osoba eksportująca dane musi mieć w Greenhouse uprawnienia do sekcji „Reports” i wglądu w dane kandydatów. Zwykle wymaga to roli „Job Admin” lub „Site Admin”.

Przykładowe zapytanie 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'

Kroki

Wymagania wstępne: uzyskanie klucza API Greenhouse
- Zaloguj się na konto Greenhouse z uprawnieniami deweloperskimi.
- Przejdź do Configure > Dev Center > API Credential Management.
- Kliknij „Create New API Key”.
- Podaj opis, na przykład „ProcessMind Extraction”.
- Wybierz typ „Harvest”.
- Przyznaj kluczowi wymagane uprawnienia. Co najmniej potrzebne są uprawnienia GET dla: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards i Users.
- Bezpiecznie skopiuj wygenerowany klucz API. Nie będzie można go ponownie wyświetlić.
Konfiguracja środowiska Python
- Upewnij się, że w systemie jest zainstalowany Python w wersji 3.6 lub nowszej.
- Zainstaluj wymagane biblioteki Python, uruchamiając w terminalu polecenia: pip install requests i pip install pandas.
Przygotowanie skryptu Python
- Skopiuj cały skrypt Python z sekcji „query” do nowego pliku, na przykład extract_greenhouse_logs.py.
- Zastąp symbol zastępczy YOUR_GREENHOUSE_API_KEY kluczem uzyskanym w kroku 1.
- Ustaw zmienną START_DATE_ISO, aby określić początek okresu pobierania danych. Przy pierwszym pobraniu zaleca się datę sprzed 3–6 miesięcy.
Dostosowanie mapowania etapów na aktywności
- Sprawdź słownik STAGE_TO_ACTIVITY w skrypcie.
- Słownik ten przypisuje nazwy etapów rekrutacji używanych w Greenhouse w Państwa firmie do standardowych nazw aktywności wymaganych przez process mining.
- Należy zaktualizować mapowanie zgodnie z konfiguracją Greenhouse w Państwa organizacji. Jeśli na przykład etap „Recruiter Screen” nazywa się „Initial Recruiter Chat”, trzeba odpowiednio zmienić słownik.
Uruchomienie skryptu pobierającego dane
- Otwórz terminal lub wiersz polecenia.
- Przejdź do katalogu, w którym zapisano extract_greenhouse_logs.py.
- Uruchom skrypt poleceniem: python extract_greenhouse_logs.py.
- Skrypt połączy się z API Greenhouse, pobierze i przetworzy dane, a następnie wyświetli informacje o postępie w konsoli.
Pobranie dziennika zdarzeń
- Po pomyślnym zakończeniu skrypt utworzy w tym samym katalogu plik greenhouse_event_log.csv.
- Ten plik CSV to gotowy dziennik zdarzeń z wymaganymi kolumnami i aktywnościami.
Obsługa przyrostowego pobierania danych
- Przy kolejnych uruchomieniach można ustawić zmienną START_DATE_ISO na znacznik czasu ostatniego udanego pobrania. Dzięki temu zostaną pobrane tylko nowe lub zaktualizowane rekordy, co przyspieszy proces.
Przesłanie danych do ProcessMind
- Wygenerowany plik greenhouse_event_log.csv można bezpośrednio przesłać do ProcessMind. Należy sprawdzić, czy nazwy kolumn w pliku są prawidłowo przypisane do pól w projekcie ProcessMind.

Konfiguracja

Uprawnienia klucza API: Klucz Harvest API musi mieć dostęp tylko do odczytu (GET) do następujących endpointów: Applications, Candidates, Jobs, Job Stages, Offers, Scorecards i Users. Brak wymaganych uprawnień spowoduje, że część danych o aktywnościach nie zostanie pobrana.
Filtr zakresu dat: Skrypt używa parametru updated_after (zmiennej START_DATE_ISO) do filtrowania aplikacji. Przy pierwszym pobraniu należy ustawić szerszy zakres, na przykład ostatnie 6 miesięcy. Przy kolejnych pobraniach przyrostowych warto podać znacznik czasu ostatniego udanego uruchomienia, aby skrócić czas przetwarzania.
Mapowanie etapów na aktywności: Słownik STAGE_TO_ACTIVITY w skrypcie ma zasadnicze znaczenie. Należy skonfigurować go zgodnie z etapami rekrutacji używanymi w Greenhouse w Państwa firmie, aby prawidłowo identyfikować aktywności takie jak „Recruiter Screen Conducted” i „Background Check Initiated”.
Limity liczby zapytań do API: Skrypt wprowadza krótką, stałą przerwę między zapytaniami do API, aby przestrzegać limitów Greenhouse, wynoszących około 20 zapytań na sekundę. Przy bardzo dużej ilości danych może być konieczne wydłużenie przerwy, aby uniknąć błędów połączenia.
Szczegółowość danych: Pobierane są zdarzenia ze znacznikami czasu i zmiany statusu. Skrypt nie pobiera szczegółowych treści, takich jak notatki z rozmów kwalifikacyjnych czy korespondencja e-mail, a jedynie metadane potwierdzające wystąpienie zdarzenia.

Przykładowe zapytanie 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.")

Kroki

Sprawdź, czy używana platforma ETL z licencją oferuje konektor Greenhouse i czy obsługuje obiekty Greenhouse lub replikowane zbiory danych zawierające aplikacje, historię etapów aplikacji, rozmowy kwalifikacyjne, opinie po rozmowach, oferty, zmiany statusu ofert, weryfikacje przeszłości kandydatów, przekazania do wdrożenia oraz wyniki rekrutacji. Nazwy obiektów różnią się w zależności od platformy, dlatego należy sprawdzić katalog konektorów i przeglądarkę schematów, zamiast zakładać nazwy tabel.
Utwórz połączenie ze źródłem Greenhouse na platformie ETL. Podaj dane uwierzytelniające Greenhouse, szczegóły autoryzacji, ustawienia replikacji i filtry specyficzne dla firmy. Postępuj zgodnie z udokumentowaną procedurą autoryzacji konektora i przyznaj tylko uprawnienia wymagane do odczytu wybranych danych rekrutacyjnych.
Skonfiguruj docelową hurtownię danych i włącz replikację obiektów źródłowych potrzebnych do utworzenia dziennika zdarzeń. Wybierz co najmniej obiekty zawierające aplikacje o pracę, historię statusów lub etapów aplikacji, rozmowy kwalifikacyjne, opinie po rozmowach, oferty, zmiany statusu ofert, zdarzenia związane z weryfikacją przeszłości kandydatów, przekazania do wdrożenia oraz wyniki rekrutacji. Jeśli wymagany obiekt jest niedostępny, opisz to ograniczenie i zgodnie z konfiguracją Greenhouse przypisz najbliższe obsługiwane źródło.
Ustaw początkowy zakres replikacji na wymagany okres analizy, zwykle poprzednie 3–6 miesięcy. Uwzględnij wcześniejszy okres, jeśli aplikacje mogły powstać przed wybranym zakresem, ale ich obsługa trwała w tym czasie. Skonfiguruj replikację przyrostową i zachowuj znaczniki czasu aktualizacji źródłowych, jeśli są dostępne.
Sprawdź zreplikowany schemat i zastąp wszystkie symbole zastępcze w zapytaniu rzeczywistymi nazwami schematu docelowego, tabel, kolumn, pól ze znacznikami czasu, identyfikatorów i wartości statusów udostępnianych przez konektor. Nie zakładaj, że zmiana etapu, rekord rozmowy kwalifikacyjnej, opinia, oferta, weryfikacja przeszłości, przekazanie do wdrożenia lub wynik rekrutacji są dostępne, jeśli nie występują w zreplikowanych danych.
Skonfiguruj zapytanie przekształcające jako sumę wyników jawnych zapytań pobierających zdarzenia. Każde z nich musi zwracać JobApplicationId, ActivityName, ActivityTimestamp, SourceSystem, LastDataUpdate, RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource i OfferStatus. Ujednolić strefę czasową znaczników czasu, odrzucić rekordy bez prawidłowego identyfikatora aplikacji lub znacznika czasu aktywności i zachować osobny wiersz dla każdego zdarzenia źródłowego odpowiadającego aktywności.
Zastosuj reguły mapowania zdarzeń. Dla aktywności Application Received użyj danych o utworzeniu lub przesłaniu aplikacji; dla Application Reviewed użyj jawnego etapu przeglądu lub zmiany statusu; dla Recruiter Screen Conducted użyj rekordu rozmowy z rekruterem lub skonfigurowanej zmiany etapu rozmowy telefonicznej; dla Interview Scheduled użyj potwierdzenia rozmowy lub zaplanowanego terminu; dla Interview Completed użyj informacji o zakończeniu rozmowy lub przesłaniu opinii; dla Feedback Submitted użyj informacji o przesłaniu opinii; dla Offer Created użyj informacji o utworzeniu oferty; dla Offer Extended użyj statusu wysłania lub przedstawienia oferty; dla Offer Accepted użyj statusu przyjęcia oferty; dla Background Check Initiated użyj zarejestrowanego zdarzenia rozpoczęcia weryfikacji; dla Onboarding Initiated użyj zdarzenia przekazania do wdrożenia lub jego rozpoczęcia; dla Candidate Hired użyj informacji o zatrudnieniu; dla Offer Rejected użyj informacji o odrzuceniu oferty; dla Application Rejected użyj informacji o odrzuceniu aplikacji lub zmianie etapu na odrzuconą.
Załaduj przekształcone dane do tabeli lub widoku docelowego przeznaczonego na dziennik zdarzeń ProcessMind. Zachowaj powielone zdarzenia źródłowe, chyba że udokumentowana reguła biznesowa określa je jako duplikaty techniczne. Jeśli deduplikacja jest wymagana, usuwaj wyłącznie identyczne zdarzenia źródłowe, na przykład o tym samym identyfikatorze aplikacji, nazwie aktywności, znaczniku czasu aktywności i identyfikatorze rekordu źródłowego.
Sprawdź wynik zgodnie z poniższymi kryteriami. Potwierdź, że są wszystkie wymagane kolumny, znaczniki czasu są prawidłowe, każda wymagana aktywność występuje tam, gdzie istnieją dane źródłowe, a identyfikator sprawy jest unikalny dla każdej aplikacji. Osobno sprawdź aplikacje odrzucone, wycofane, zarchiwizowane i niekompletne, aby filtrowanie nie usuwało prawidłowych wyników procesu.
Wyeksportuj lub udostępnij końcowy wynik jako płaski plik CSV albo przez obsługiwane połączenie z hurtownią danych, aby przesłać go do ProcessMind. Przypisz JobApplicationId do identyfikatora sprawy, ActivityName do aktywności, a ActivityTimestamp do znacznika czasu zdarzenia. Uwzględnij SourceSystem i LastDataUpdate, zachowaj zalecane atrybuty i używaj spójnego formatu znaczników czasu, na przykład ISO 8601 ze strefą czasową. Nie zakładaj, że ProcessMind odtworzy zdarzenia, których brakuje w pliku.

Konfiguracja

Konektor i miejsce docelowe: użyj platformy ETL z licencją, która obsługuje konektor Greenhouse i ma dostęp do hurtowni danych z warstwy przekształcania. Możliwości konektora, nazwy obiektów, częstotliwość odświeżania i obsługa replikacji historycznej zależą od wybranej platformy i subskrypcji.
Autoryzacja źródła: skonfiguruj dane uwierzytelniające Greenhouse i uprawnienia wymagane przez konektor. Sprawdź, czy autoryzowane konto może odczytywać rekordy aplikacji, historię etapów lub statusów, dane o rozmowach kwalifikacyjnych, opiniach, ofertach oraz dane o weryfikacji przeszłości lub wdrożeniu, jeśli są używane w mapowaniu.
Replikowane obiekty: wybierz wszystkie obiekty źródłowe wymagane do przygotowania 14 zestawów zdarzeń. Nie włączaj wyłącznie bieżącej tabeli aplikacji, jeśli historia zmian etapów, działania związane z rozmowami, przesłane opinie, zmiany statusów ofert lub przekazania do dalszych etapów są przechowywane osobno.
Zakres dat: zacznij od 3–6 miesięcy danych na potrzeby analizy operacyjnej. Rozszerz zakres przy pomiarze pełnego cyklu aplikacji, ponieważ aplikacje utworzone wcześniej mogą później przejść do etapu rozmów, ofert lub zatrudnienia.
Odświeżanie przyrostowe: zachowuj dostępne znaczniki czasu utworzenia, wystąpienia i ostatniej aktualizacji w źródle. Ustaw cykliczne odświeżanie zgodnie z wymaganą aktualnością raportów i uwzględnij krótki okres nakładania się danych, aby pobierać spóźnione lub skorygowane rekordy.
Filtry: stosuj wyłącznie udokumentowane filtry specyficzne dla firmy, na przykład dotyczące organizacji, działu, oferty pracy, lokalizacji lub daty aplikacji. Nie używaj ogólnych filtrów, takich jak Company Code lub Document Type, chyba że te pola rzeczywiście występują w zreplikowanym schemacie Greenhouse i są wymagane w danej konfiguracji.
Mapowanie aktywności: prowadź udokumentowane mapowanie typów zdarzeń źródłowych, etapów, statusów lub znaczników czasu na poszczególne wartości ActivityName. Skonfiguruj dokładne wartości dla przeglądu aplikacji, rozmowy telefonicznej, odrzucenia, oferty, jej przyjęcia, weryfikacji przeszłości, wdrożenia i zatrudnienia, zgodnie z nazewnictwem używanym w organizacji.
Obsługa pustych wartości: pola RecruiterName, JobDepartment, JobTitle, ApplicationStatus, ApplicationSource i OfferStatus mogą pozostać puste, jeśli źródło ich nie udostępnia. Brak wymaganych identyfikatorów lub znaczników czasu należy zgłosić do weryfikacji albo odrzucić rekord.
Strefy czasowe: przelicz wszystkie znaczniki czasu aktywności na jedną strefę raportowania, zachowując oryginalny znacznik czasu źródłowego, jeśli jest potrzebny do audytu. Pole LastDataUpdate powinno wskazywać czas odświeżenia lub pobrania danych, a nie czas wystąpienia aktywności.
Wydajność: w przypadku dużych zbiorów filtruj dane źródłowe według partycji znaczników czasu, wybieraj tylko wymagane kolumny, stosuj ładowanie przyrostowe i materializuj końcowy dziennik zdarzeń. Unikaj wielokrotnego łączenia pełnej historii z bieżącymi rekordami aplikacji bez indeksowanych identyfikatorów.
Przechowywanie danych: sprawdź, czy platforma ETL i dostęp do Greenhouse obejmują historyczne dane o etapach, rozmowach kwalifikacyjnych, opiniach, ofertach i wynikach za wybrany okres. Na podstawie samych tabel bieżącego stanu nie da się wiarygodnie odtworzyć wcześniejszych aktywności.
Mapowanie w ProcessMind: ustaw JobApplicationId jako identyfikator sprawy, ActivityName jako pole aktywności, a ActivityTimestamp jako znacznik czasu zdarzenia. Sprawdź, czy wyeksportowany plik zawiera osobny, jawny wiersz dla każdej aktywności i nie wymaga wnioskowania o zmianach.

Przykładowe zapytanie 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;

Gotowi do rozpoczęcia?

Wykorzystaj dane rekrutacyjne w praktyce. Skorzystaj z tego szablonu, aby usprawnić proces rekrutacji i podejmować decyzje na podstawie danych.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usprawnij pozyskiwanie talentów w Greenhouse

Skróć cykl rekrutacji o 30% i popraw doświadczenia kandydatów.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana • Konfiguracja zajmuje 5 minut

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Szablon danych dotyczących rekrutacji i pozyskiwania talentów

Atrybuty procesu rekrutacji i pozyskiwania talentów

Aktywności w procesie rekrutacji i pozyskiwania talentów

Instrukcje pobierania danych

Tworzenie raportów w Greenhouse i ręczny eksport do CSV

Kroki

Konfiguracja

Przykładowe zapytanie config

Pobieranie danych za pomocą skryptu Python i Greenhouse Harvest API

Kroki

Konfiguracja

Przykładowe zapytanie python

Zautomatyzowane narzędzie ETL z konektorem Greenhouse

Kroki

Konfiguracja

Przykładowe zapytanie config

Gotowi do rozpoczęcia?

Usprawnij pozyskiwanie talentów w Greenhouse