filter_conditions はリクエストボディ上のオプションの配列です。各要素は、1 つの複数値フィルターをデフォルトの OR(「いずれかにマッチ」)から AND(「すべてにマッチ」)へ、あるいはその逆へと切り替えます。記載されていないフィルターはデフォルトのままです。
スキーマ
各要素の
key と operator はどちらも必須です。operator のみのエントリは黙って無視されます — グローバルなオーバーライド設定はありません。なぜ重要か
デフォルト演算子が OR なのは、多くのプロスペクティングが広い再現を求めるためです: 「いずれかの国の人物」「いずれかのバーティカルがタグ付けされた企業」。一方で、高精度のターゲティング — 「Salesforce + HubSpot + Marketo を すべて 使う」 — には AND が必要です。
選択を誤ったときのコスト:
- AND が欲しかったのに OR: 過剰再現になり、1 タグだけマッチした企業まで含まれてしまう。気づきやすいが結果品質を損ないます。
- OR が欲しかったのに AND: 再現不足になり、複数値の AND は実世界の配列にすべての要求値が揃わないため、ほぼ 0 行になることが多い。気づきやすく、クエリが壊れて見えます。
サポートされるキー
正確なキーセットは呼び出すエンドポイントによります:
場所フィルター(
places、exclude_places)、その他の exclude_* フィルター、および advertisement_search_terms は、常に列挙した値のいずれかにマッチします。求人検索とニュース検索は filter_conditions を受け付けず、リストフィルターは常に列挙した値のいずれかにマッチします。
レシピ
- 全テクノロジーを保有(企業)
- いずれかのロケーション + 除外
- マルチリージョン広告キャンペーン
- 複数スタック企業の人物
目標: Salesforce と HubSpot を 両方 使っている企業 — 片方だけではなく。
filter_conditions の要素を外せば、2 つの どちらか を含む検索に拡張されます。よくある間違い
key を忘れて operator だけ送る
key を忘れて operator だけ送る
グローバルな「デフォルト演算子」スイッチはありません。各エントリは具体的なフィルターを指定する必要があります:
エントリが組み合わさると思い込む
エントリが組み合わさると思い込む
エントリはキーごとに独立した上書きで、相互に連鎖しません。
technologies と verticals を両方並べても、両者の間にブール式は構築されません。各々が自分の配列の演算子を設定するだけです。フィルターキー間 の組み合わせは常に AND(全フィルターがマッチする必要)です。filter_conditions で異なるフィルター次元を OR 結合することはできません。本当に「異なるフィルターの OR」検索が必要なら、2 回リクエストを投げてクライアント側でマージしてください。長い配列で AND を使う
長い配列で AND を使う
AND は列挙したすべての値が存在することを要求します。8 件以上になるとほぼ常に 0 行になります。実世界のタグ付けは疎なため。AND オーバーライドの配列は 2〜4 値に抑え、探索的・カテゴリレベルのフィルタリングは OR で。
ロケーションまたは場所フィルターで AND を使う
ロケーションまたは場所フィルターで AND を使う
ロケーションと場所のフィルター(
locations、places、およびその company_ 付き・exclude_ 付きの形式)は、常に列挙した値のいずれかにマッチします。これらに対する filter_conditions のエントリは無視されます。関連項目
フィルター概要
メンタルモデル —
filter_conditions が初めての方はここから。人物 + 企業フィルター
/people/search に企業フィルターを重ねる方法、キー再マッピングを含む。企業検索リファレンス
/companies/search の完全なリクエストスキーマ(company_filter_conditions 含む)。人物検索リファレンス
/people/search の完全なリクエストスキーマ(people_filter_conditions 含む)。
