Skip to main content
filter_conditions はリクエストボディ上のオプションの配列です。各要素は、1 つの複数値フィルターをデフォルトの OR(「いずれかにマッチ」)から AND(「すべてにマッチ」)へ、あるいはその逆へと切り替えます。記載されていないフィルターはデフォルトのままです。

スキーマ

各要素の keyoperator はどちらも必須です。operator のみのエントリは黙って無視されます — グローバルなオーバーライド設定はありません。

なぜ重要か

デフォルト演算子が OR なのは、多くのプロスペクティングが広い再現を求めるためです: 「いずれかの国の人物」「いずれかのバーティカルがタグ付けされた企業」。一方で、高精度のターゲティング — 「Salesforce + HubSpot + Marketoすべて 使う」 — には AND が必要です。 選択を誤ったときのコスト:
  • AND が欲しかったのに OR: 過剰再現になり、1 タグだけマッチした企業まで含まれてしまう。気づきやすいが結果品質を損ないます。
  • OR が欲しかったのに AND: 再現不足になり、複数値の AND は実世界の配列にすべての要求値が揃わないため、ほぼ 0 行になることが多い。気づきやすく、クエリが壊れて見えます。
内部的には、選んだ演算子は Postgres ネイティブの配列演算子にコンパイルされます: OR なら &&(オーバーラップ)、AND なら @>(包含)。どちらもインデックスに優しく、コストの違いはクエリ遅延ではなく 結果サイズ に現れます。

サポートされるキー

正確なキーセットは呼び出すエンドポイントによります:
上記のキーは OpenAPI 各 *_filter_conditions スキーマの enum(company_filter_conditionspeople_filter_conditionsads_filter_conditions)を反映しています。エンドポイントが対応しないキーを送っても黙って無視されます。

レシピ

目標: Python、PostgreSQL、Kubernetes を すべて 使っている企業 — 1 つだけではなく。
filter_conditions の要素を外せば、3 つの いずれか を含む検索に拡張されます。

よくある間違い

グローバルな「デフォルト演算子」スイッチはありません。各エントリは具体的なフィルターを指定する必要があります:
エントリはキーごとに独立した上書きで、相互に連鎖しません。technologiesverticals を両方並べても、両者の間にブール式は構築されません。各々が自分の配列の演算子を設定するだけです。フィルターキー間 の組み合わせは常に AND(全フィルターがマッチする必要)です。filter_conditions で異なるフィルター次元を OR 結合することはできません。本当に「異なるフィルターの OR」検索が必要なら、2 回リクエストを投げてクライアント側でマージしてください。
AND は column @> ARRAY[…] — すべての値が必要です。8 件以上になるとほぼ常に 0 行になります。実世界のタグ付けは疎なため。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 含む)。