跳转到主要内容
POST /people/search 现在接受 POST /companies/search 支持的所有公司筛选器。无需先查公司、收集 ID,再喂给第二次人员查询 — 一次请求覆盖两层。

一个请求体,两类参数

/people/search 请求体在概念上分成两类筛选器。它们在 JSON 中处于同一层级,可以自由组合。
针对人员属性的筛选:
在 /people/search 的顶层,公司位置和地点筛选器带有 company_ 前缀;裸名 locations / places 在此不被接受,并会在 metadata.ignored_fields 中列出。其他键都使用裸名(technologies,而不是 company_technologies)。在 company_filters 内部,两种写法都可以。

四步构建一个查询

1

确定人员条件

具体是哪些人?职位、级别、部门、国家。这层放在请求体的顶层 — 精度通常由公司条件承担。
2

确定公司条件

他们必须任职于哪些公司?行业、规模、成立年份、总部国家、技术栈。把这些归到一个 company_filters: {...} 对象里,这样每个键属于哪一层一目了然。
3

按筛选器选定 AND/OR

任何需要精度的多值筛选器(例:“同时使用这些技术”),在 company_filters 内部 的 filter_conditions 中加一条记录。默认是 OR。
4

发送请求

POST /people/search。两种风格都接受,但 company_filters: {...} 更易读,也与 Monitor 的载荷结构一致。

完整示例

需求:位于美国、成立于 2015 至 2023 年、员工 100-5000、同时使用 Kubernetes 和 Docker、但总部不在旧金山的中型公司中的工程副总裁或 CTO。

键重映射参考

在 /people/search 上,公司位置和地点类键带有 company_ 前缀。它们与公司搜索中的名称对应如下: filter_conditions 的键从不带前缀 — 请使用 technologies、verticals、keywords 以及支持的键中列出的其他名称。位置和地点筛选器始终匹配任一列出的值。

没有公司的人员

只要添加任何公司级筛选器,结果就仅限于已关联可识别公司的人员。没有关联公司的人员会被排除,即便其匹配所有人员级筛选。
如果你一加上 company_locations 或 technologies 结果就掉到零,请检查你预期的人员是否关联了公司。
一旦应用了任何公司筛选器,每条返回的人员都会带有完整的 company 对象。

常见模式

用固定的公司列表(companies 或 domains)做目标,再叠加人员级筛选,在每家公司里找到合适的购买者。
描述公司的形态,而不是具体账户。用区间和垂直 — 引擎会返回符合的人员。
在使用特定技术栈的公司中找到购买者。technologies 上的 AND 是典型覆盖。
找到使用竞品产品(某项技术)但未使用你产品(通过 categories 排除或独立筛选轮次)的公司中的决策者。
再用 technologies: [114](你的产品的 tag ID)重跑,在客户端做差集。

后续步骤

filter_conditions

完整参考 — 每个键、每个默认值,可复制的 AND/OR 配方。

筛选器概览

统一筛选引擎背后的心智模型。

人员搜索参考

/people/search 的完整请求/响应结构。

公司搜索参考

/companies/search 的完整请求/响应结构。
最后修改于 2026年9月28日