Methodology
Last updated: 2026-10-23.
We read public sources every day, store what we observe with the time we observed it, and derive events from those observations with fixed rules. This page gives the rules, how dates work, and where the data is thin. The sources themselves are listed on Data sources.
From observations to events
- Observations are what a source shows on a day: the open jobs of an employer board, a published notice, a store's installed apps, a review page's counts. They are stored as read, with the source and the time.
- Events are changes between observations that pass a rule (table below). Every company is keyed by its registrable website domain, so events from different sources about the same company line up.
- Each event has a stable id built from its type, domain, key and day: the same change always gets the same id, so a re-run never creates a duplicate.
- Each event carries its
evidence: the numbers and labels it rests on (counts, baselines, notice id, value), never a person.
| Event | From | Rule |
|---|---|---|
hiring_up / hiring_down | Employer job boards | Open jobs against a 7-day baseline (boards that can be compared) and a 28-day baseline (same number of boards). The baseline must have at least 10 open jobs, and the change must be at least 5 jobs and 20%. One event per window and week. |
new_country | Employer job boards | First open job in a country where the company had none. |
new_function | Employer job boards | First open job in a department or function the company had no jobs in. |
ats_switch | Employer job boards | The company’s jobs move from one applicant tracking system to another. |
pay_first_seen | Job ads | The first open job of the company that states a pay range. |
tech_added / tech_removed | Job ads | A tool named in at least 2 open job ads (one ad is often boilerplate); removed when a tool seen for at least 7 days is no longer named. |
shop_app_installed / shop_app_removed | Store scans | An app or tool appears on, or disappears from, the store. |
review_velocity | Review panels | At least 10 new reviews in 7 days and at least 2× the weekly average of the last 28 days. |
rating_change | Review panels | The stated rating moves by at least 0.1 over 28 days (7 days while the history is shorter). |
tender_awarded | Contract award notices | An award notice whose winner is matched to a company domain by its name. The event date is the publication day of the notice. |
register_registration / register_bankruptcy / register_restructuring / register_liquidation / register_dissolution | Company registers (NO, FI, FR) | A dated status change recorded by the official register or its gazette (FR: BODACC). The event date is the date the register gives. |
name_change / hq_moved / sector_change | Company registers | The register records a new company name, a new registered address or a new activity code. |
capital_increase / capital_decrease / headcount_band_change | Company registers | The register records a change of share capital or of the employee size band. |
accounts_filed | Company registers | Annual accounts filed with the register (FR: BODACC notice). |
business_sale | Company registers (FR: BODACC) | A published sale or transfer of a business (fonds de commerce). |
eu_grant_won | EU research grants (CORDIS) | The company is a participant in a signed EU research grant; the amount is its EU contribution. |
Point in time: occurredAt and observedAt
occurredAtis the day the change happened, as far as the source shows it (for a tender, the publication day).observedAtis the moment our pipeline first held the data that shows it. It is written once and never rewritten.- A backtest that uses only events with
observedAtat or before a date sees exactly what a customer could have seen on that date. There is no look-ahead in the stream. - Records loaded in a backfill (older tenders, the archive panel) keep their original publication or capture date, and their
observedAtis the day we loaded them. Filter onoccurredAtfor history, onobservedAtfor point-in-time tests.
Provisional and coverage flags
- Our daily collection of jobs, pay, store and review data started on 2026-10-21. Nothing before that day is an observation of ours.
- An event is
provisionalwhile the history behind its baseline is shorter than 28 days. Useprovisional=falseon the API to leave such events out. - The per-company route and the feed return up to 90 days of events. A company score is not published before 2026-12-20, when the history is long enough.
- Tender rows carry quality flags:
no_fx(no EUR rate for the currency),mixed_currencyandvalue_outlier(values above EUR 50 bn are placeholders and are dropped). Winner names that could name a private person are withheld and counted inwinners_withheld. - Every API answer carries an
as_ofdate and its source, so the age of each fact is explicit.
History and its limits
Tenders
EU TED notices go back to 2023-10-25, the day the eForms standard became mandatory; earlier notices use a different format and are not included. Other tender sources start later, from the dates we began reading them. National notices that copy a TED notice are marked as duplicates so each procedure is listed once. Winner-to-domain matching is by company name: a winner we cannot match stays in the notice but makes no company event.
Hiring history panel
- Monthly figures before our own collection come from the Common Crawl web archive since February 2023: one row per job board and crawl, with the capture time (
observedAt) and the day the crawl was published (availableAt, the first day the value was knowable). - The archive is sparse by nature: it holds what its crawler picked. Whole systems or boards can be missing from a crawl. Missing months stay missing; we do not interpolate. Each row has a
coverageFlag:list(the job list),redirect,job_pages_onlyornone. - A board total marked incomplete is a lower bound (one page of a list, a filtered view). The lifecycle count of jobs open between first and last capture is revised as later crawls arrive: read it as a trend index, not an exact count.
- Boards that no longer exist are included where the archive holds them, to limit survivorship bias.
Changes to the rules
The thresholds on this page are the ones the pipeline uses. When a rule changes, this page changes with it and shows the new date at the top.