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

​
一个请求体,两类参数

/people/search 请求体在概念上分成两类筛选器。它们在 JSON 中处于同一层级,可以自由组合。
针对人员属性的筛选:
参数说明
people_titles职位(自由文本或 slug)
management_levelsfounder、c_suite、vp、director、manager 等
departmentsmaster_engineering、master_sales 等
department_functions子部门 / 职能 slug
people_locations人员所在国家代码
people_groups已保存的群组 ID
peoples指定的 people_search_id
linkedin_urls人员 LinkedIn URL
social_media各社交网络的账号
company_ 前缀只在位置/地点类筛选上出现,因为裸名 places / locations 已被人员的地址字段占用。其他键都使用裸名(technologies,而不是 company_technologies)。

​
四步构建一个查询

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。 
curl -X POST https://api.pubrio.com/people/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "people_titles": ["VP of Engineering", "CTO"],

    "company_filters": {
      "company_locations": ["US"],
      "company_exclude_places": ["San Francisco"],
      "founded_dates": [2010, 2024],
      "employees": [[100, 500], [501, 1000], [1001, 5000]],
      "technologies": ["Kubernetes", "Docker"],
      "is_enable_similarity_search": true
    },

    "per_page": 25,
    "page": 1
  }'

​
键重映射参考

/people/search 把公司筛选器交给共享引擎时,位置/地点类键会被改写为裸名。引擎和 filter_conditions[].key 实际看到的是裸名:
你发送的字段(人员 API 名)引擎看到的字段(公司 API 名)
company_locationslocations
company_exclude_locationsexclude_locations
company_placesplaces
company_exclude_placesexclude_places
technologies、verticals、vertical_categories、vertical_sub_categories、categories、keywords、founded_dates、employees、revenues原样透传
这就是为什么公司级位置在 filter_conditions[].key 中要用裸名: 
{
  "company_places": ["New York", "Boston"],
  "filter_conditions": [
    { "key": "places", "operator": "and" }
  ]
}
{ "key": "company_places", "operator": "and" } 会被静默忽略 — 引擎不识别带前缀的名称。在 filter_conditions 中始终引用引擎名。

​
幕后的连接

只要添加任何公司级筛选器,人员到公司的连接就会从 LEFT JOIN 切换为 INNER JOIN。即便人员匹配所有人员级筛选,只要其归属公司无法识别,也会被排除。
如果你一加上 company_locations 或 technologies 结果就掉到零,请检查你的数据集中是否真的存在该批人员对应的公司。引擎在此宁可正确也不召回 — 它绝不会为了满足筛选而臆造公司。
响应中也能看到这一连接行为:一旦应用了任何公司筛选器,每条返回的人员都会带有完整的 company 对象。

​
常见模式

用固定的公司列表(companies 或 domains)做目标,再叠加人员级筛选,在每家公司里找到合适的购买者。
{
  "people_titles": ["VP Marketing", "CMO"],
  "management_levels": ["vp", "c_suite"],
  "company_filters": {
    "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
  }
}
描述公司的形态,而不是具体账户。用区间和垂直 — 引擎会返回符合的人员。
{
  "people_titles": ["Head of Engineering"],
  "company_filters": {
    "verticals": [12, 47],
    "company_locations": ["US", "CA"],
    "founded_dates": [2015, 2023],
    "employees": [[51, 200], [201, 500]],
    "filter_conditions": [
      { "key": "verticals", "operator": "and" }
    ]
  }
}
在使用特定技术栈的公司中找到购买者。technologies 上的 AND 是典型覆盖。
{
  "people_titles": ["RevOps", "Sales Operations"],
  "departments": ["master_sales"],
  "company_filters": {
    "technologies": [114, 287, 452],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ]
  }
}
找到使用竞品产品(某项技术)但未使用你产品(通过 categories 排除或独立筛选轮次)的公司中的决策者。
{
  "people_titles": ["VP Sales"],
  "management_levels": ["vp"],
  "company_filters": {
    "technologies": [287]
  }
}
再用 technologies: [114](你的产品的 tag ID)重跑,在客户端做差集。

​
后续步骤

filter_conditions

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

筛选器概览

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

人员搜索参考

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

公司搜索参考

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