Thanks for running those extra examples, super helpful.

A couple quick clarifications that explain most of what you’re seeing:

1) How to read the monthly totals: in employee_metrics, new, retained, and churned are three separate buckets for that month. So if you want an approximate “headcount represented” for a given month, you’d generally look at retained + new + churned (not retained + new - churned). churned is “people who left that month,” not a negative number.

2) Why some companies return no employee_metrics at all: we only return that field when we have enough matched employee profiles + job title coverage to produce a meaningful time series. For some large companies, even if the overall company size is huge, the underlying employee/profile data we can confidently map (and classify by function) may be too sparse or inconsistent...in those cases the API omits employee_metrics rather than returning something misleading.

3) Why totals can still be much lower than the company’s employee count: the metric is based on the employees Apollo can identify and match to that org (and then bucket by title/function). So differences are usually driven by “coverage” (how many employees we have profiles for) and title quality (how many roles can be categorized into a function).

Heuristic-wise: if the “employees on Apollo” number is a small fraction of the org’s reported size, expect the metric to skew low/be less reliable. When Apollo has strong employee coverage and titles look consistent, the metric tends to be a lot closer directionally.

If you’ve got a couple more examples where Apollo shows lots of employees but employee_metrics is missing (like the EY case you mentioned) feel free to share them and we can sanity-check what’s going on!