人员 + 公司筛选器

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

一个请求体,两类参数

/people/search 请求体在概念上分成两类筛选器。它们在 JSON 中处于同一层级,可以自由组合。

人员级
公司级

针对人员属性的筛选:

参数	说明
`people_titles`	职位(自由文本或 slug)
`management_levels`	`founder`、`c_suite`、`vp`、`director`、`manager` 等
`departments`	`master_engineering`、`master_sales` 等
`department_functions`	子部门 / 职能 slug
`people_locations`	人员所在国家代码
`people_groups`	已保存的群组 ID
`peoples`	指定的 `people_search_id`
`linkedin_urls`	人员 LinkedIn URL
`social_media`	各社交网络的账号

针对人员所在公司的筛选 — 与 /companies/search 同名,只有少数位置类键带 company_ 前缀:

参数	说明
`technologies`	公司使用的技术 slug ID
`categories`	类目 slug ID
`verticals`	垂直 slug ID
`vertical_categories`	垂直类目 slug ID
`vertical_sub_categories`	垂直子类目 slug ID
`keywords`	与公司描述匹配的自由文本关键词
`founded_dates`	成立年份区间,例:`[2015, 2023]`
`employees`	员工区间,例:`[[100, 500], [501, 1000]]`
`revenues`	收入区间(美元)
`company_locations`	公司总部所在国家代码
`company_exclude_locations`	要排除的国家代码
`company_places`	要包含的城市 / 地区名
`company_exclude_places`	要排除的城市 / 地区名
`companies`	指定的 `domain_search_id`
`domains`	指定的公司域名
`company_linkedin_urls`	公司 LinkedIn URL

company_ 前缀只在位置/地点类筛选上出现,因为裸名 places / locations 已被人员的地址字段占用。其他键都使用裸名(technologies,而不是 company_technologies)。

四步构建一个查询

确定人员条件

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

确定公司条件

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

按筛选器选定 AND/OR

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

发送请求

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
  }'

import requests

response = requests.post(
    "https://api.pubrio.com/people/search",
    headers={
        "Content-Type": "application/json",
        "pubrio-api-key": "YOUR_API_KEY",
    },
    json={
        "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,
    },
)
print(response.json())

const response = await fetch("https://api.pubrio.com/people/search", {
  method: "POST",
  headers: {
    "Content-Type": "application/json",
    "pubrio-api-key": "YOUR_API_KEY",
  },
  body: JSON.stringify({
    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,
  }),
});
console.log(await response.json());

键重映射参考

/people/search 把公司筛选器交给共享引擎时,位置/地点类键会被改写为裸名。引擎和 filter_conditions[].key 实际看到的是裸名:

你发送的字段(人员 API 名)	引擎看到的字段(公司 API 名)
`company_locations`	`locations`
`company_exclude_locations`	`exclude_locations`
`company_places`	`places`
`company_exclude_places`	`exclude_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 对象。

常见模式

基于账户的营销(ABM)

用固定的公司列表(companies 或 domains)做目标,再叠加人员级筛选,在每家公司里找到合适的购买者。

{
  "people_titles": ["VP Marketing", "CMO"],
  "management_levels": ["vp", "c_suite"],
  "company_filters": {
    "companies": ["67c4696b-…", "f1e2d3c4-…", "0a9b8c7d-…"]
  }
}

理想客户画像(ICP)发现

描述公司的形态,而不是具体账户。用区间和垂直 — 引擎会返回符合的人员。

{
  "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 的完整请求/响应结构。

监控

筛选器

人员

扩张

一个请求体,两类参数

四步构建一个查询

完整示例

键重映射参考

幕后的连接

常见模式

后续步骤

filter_conditions

筛选器概览

人员搜索参考

公司搜索参考

​一个请求体,两类参数

​四步构建一个查询

​完整示例

​键重映射参考

​幕后的连接

​常见模式

​后续步骤

filter_conditions

筛选器概览

人员搜索参考

公司搜索参考

一个请求体,两类参数

四步构建一个查询

完整示例

键重映射参考

幕后的连接

常见模式

后续步骤