Skip to main content
filter_conditions 是请求体中的一个可选数组。每条记录将一个多值筛选器从默认的 OR(“匹配任一”)行为升级为 AND(“匹配全部”),或反之。未列出的筛选器保持默认。

结构

每条记录的 keyoperator 都是必填项。仅含 operator 的记录会被静默忽略 — 没有”全局覆盖”开关。

为什么重要

默认操作符是 OR,因为多数潜客挖掘工作流都需要广覆盖:“位于任何这些国家的人”、“标签包含任何这些垂直的公司”。但当目标是高精度时 — “同时使用 Salesforce + HubSpot + Marketo” — 你需要 AND。 写错操作符的代价:
  • 想要 AND 却用了 OR: 响应过度召回 — 你会看到只命中一个标签的公司,而不是整个组合。容易发现,影响结果质量。
  • 想要 OR 却用了 AND: 响应召回不足 — 多值 AND 筛选通常返回近零行,因为现实中的数组很少同时包含所有请求值。容易发现,看起来像查询出错。
底层上,引擎会把你选择的操作符编译为原生 Postgres 数组操作符:OR 用 &&(重叠),AND 用 @>(包含)。两者都对索引友好,所以差异主要在结果数,而不是查询时延。

支持的键

具体支持的键集取决于你调用的端点:
上述键映射 OpenAPI 中各 *_filter_conditions 模式的 enum 数组(company_filter_conditionspeople_filter_conditionsads_filter_conditions)。在某个端点上发送不支持的键会被静默忽略。

配方

目标: 同时使用 Python、PostgreSQL、Kubernetes 的公司 — 而不是只用其中一个。
去掉 filter_conditions 那条记录,搜索范围会扩展到三者中任意一个

常见错误

没有”全局默认操作符”开关。每条记录都必须指定具体的筛选器:
每条记录都是相互独立的按键覆盖 — 不会相互链式组合。同时列出 technologiesverticals 不会在二者之间形成布尔表达式;每条只是设置自己那个数组的操作符。跨筛选键的组合方式始终是 AND(每个筛选器都必须命中)。无法通过 filter_conditions 让两个不同的筛选维度做 OR 组合。如果需要真正的”不同筛选器之间 OR”搜索,请发起两次请求并在客户端合并结果。
AND 是 column @> ARRAY[…] — 所有值都必须存在。一旦数组超过 8 个元素,几乎总会返回零行,因为现实中的标签很稀疏。AND 覆盖的数组保持在 2-4 个值;探索性或类目级筛选用 OR。
/people/search 中,人员 API 的字段名是 company_places / company_locations。但在 filter_conditions[].key 内部必须使用引擎名placeslocations。重映射在引擎读取 filter_conditions 之前已完成。
完整的重映射表见 人员 + 公司筛选器 页面。
拿不准时,先省略 filter_conditions,再对照预期检查结果数。只为默认行为不符合意图的筛选器添加覆盖 — 这能让请求体更小、更易调试。

另请参阅

筛选器概览

心智模型 — 如果 filter_conditions 是你的第一站,请从这里开始。

人员 + 公司筛选器

如何在 /people/search 上叠加公司筛选,包括键的重映射。

公司搜索参考

/companies/search 的完整请求结构(包含 company_filter_conditions)。

人员搜索参考

/people/search 的完整请求结构(包含 people_filter_conditions)。