AND / OR 연산자 - Pubrio Documentation

filter_conditions 는 요청 본문의 단일 옵션 배열입니다. 각 항목은 하나의 다중 값 필터를 기본 OR(“아무거나 일치”) 동작에서 AND(“전부 일치”) 로, 혹은 그 반대로 승격시킵니다. 나열되지 않은 필터는 기본값을 유지합니다.

스키마

{
  "filter_conditions": [
    { "key": "technologies", "operator": "and" },
    { "key": "verticals",    "operator": "or"  }
  ]
}

각 항목의 key 와 operator 는 모두 필수입니다. operator 만 있는 항목은 조용히 무시됩니다 — 전역 재정의 스위치는 없습니다.

왜 중요한가

기본 연산자가 OR 인 이유는 대부분의 잠재 고객 발굴 워크플로우가 넓은 도달을 원하기 때문입니다: “어느 한 국가의 사람들”、“어느 한 버티컬 태그가 붙은 회사들”. 정밀 타깃팅 — “Salesforce + HubSpot + Marketo 를 전부 사용” — 에는 AND 가 필요합니다. 잘못 선택했을 때의 비용:

AND 가 필요한데 OR: 응답이 과도하게 회수됩니다 — 한 태그만 일치하는 회사도 보입니다. 알아채기 쉽지만 결과 품질을 해칩니다.
OR 이 필요한데 AND: 응답이 부족하게 회수됩니다 — 다중 값 AND 필터는 보통 거의 0 행을 반환합니다. 실제 배열에 요청한 모든 값이 들어 있는 경우는 드물기 때문입니다. 알아채기 쉽고, 쿼리가 망가진 것처럼 보입니다.

내부적으로 엔진은 선택한 연산자를 네이티브 Postgres 배열 연산자로 컴파일합니다: OR 은 &&(중첩)、AND 는 @>(포함). 둘 다 인덱스 친화적이라, 비용 차이는 쿼리 지연이 아니라 결과 크기 에서 나타납니다.

지원 키

지원 키 집합은 호출하는 엔드포인트에 따라 다릅니다:

키	`/companies/search`	`/people/search`	`/companies/advertisements/search`	기본값	`and` 의 의미
`technologies`	✓	✓	—	OR	리스트의 모든 기술 보유
`categories`	✓	✓	—	OR	모든 카테고리 태그
`verticals`	✓	✓	—	OR	모든 버티컬 소속
`vertical_categories`	✓	✓	—	OR	모든 버티컬 카테고리 소속
`vertical_sub_categories`	✓	✓	—	OR	모든 버티컬 서브카테고리 소속
`keywords`	✓	✓	—	OR	설명에 모든 키워드 포함
`places`	✓	✓	—	OR	모든 장소에 위치
`exclude_places`	✓	✓	—	OR	모든 장소에서 제외
`advertisement_target_locations`	✓	—	—	OR	광고가 모든 국가 타깃 (회사 엔드포인트)
`advertisement_exclude_target_locations`	✓	—	—	OR	광고가 모든 국가 제외
`advertisement_search_terms`	✓	—	—	OR	광고 카피가 모든 용어 포함
`job_exclude_locations`	✓	—	—	OR	채용 공고가 모든 위치 제외
`social_media`	—	✓	—	OR	인물이 나열된 모든 SNS 보유
`target_locations`	—	—	✓	OR	광고가 모든 국가 타깃 (광고 엔드포인트)
`exclude_target_locations`	—	—	✓	OR	광고가 모든 국가 제외

위의 키들은 OpenAPI 의 각 *_filter_conditions 스키마(company_filter_conditions、people_filter_conditions、ads_filter_conditions)의 enum 배열을 미러합니다. 엔드포인트가 지원하지 않는 키를 보내면 조용히 무시됩니다.

레시피

모든 기술 사용 (회사)
아무 위치나 + 제외
다중 지역 광고 캠페인
다중 스택 회사의 인물

목표: Python、PostgreSQL、Kubernetes 를 전부 사용하는 회사 — 하나만이 아닙니다.

curl -X POST https://api.pubrio.com/companies/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "technologies": [37, 152, 408],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ],
    "per_page": 25,
    "page": 1
  }'

filter_conditions 항목을 빼면 검색 범위가 셋 중 어느 하나라도 로 확장됩니다.

목표: US、CA、GB 중 어느 한 국가 에 위치하지만 샌프란시스코는 절대 아닌 회사.locations 의 기본값은 이미 OR 이라 명시할 필요가 없습니다. exclude_places 는 독립적인 음의 필터를 처리합니다 — 재정의 불필요.

curl -X POST https://api.pubrio.com/companies/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "locations": ["US", "CA", "GB"],
    "exclude_places": ["San Francisco"],
    "per_page": 25,
    "page": 1
  }'

목표: EU 와 US 를 동시에 타깃팅하는 광고(다중 지역 캠페인) — 단일 시장 광고가 아닌. 전용 ads_filter_conditions 스키마의 target_locations 키를 사용합니다.

curl -X POST https://api.pubrio.com/companies/advertisements/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "target_locations": ["US", "DE", "FR"],
    "filter_conditions": [
      { "key": "target_locations", "operator": "and" }
    ],
    "start_dates": ["2026-01-01"],
    "end_dates":   ["2026-04-22"],
    "per_page": 25,
    "page": 1
  }'

광고 엔드포인트는 자체 ads_filter_conditions 스키마(작은 키 집합: target_locations、exclude_target_locations)를 사용합니다. /companies/search 와 /people/search 에서 재정의할 수 있는 키들은 여기에 적용되지 않습니다.

목표: Salesforce 와 HubSpot 을 둘 다 설치한 회사에서 일하는 인물 — 고전적인 CRM 교체 신호. 통합 엔진을 보여줍니다: 같은 technologies 키, 같은 연산자, 그러나 /people/search 에서.

curl -X POST https://api.pubrio.com/people/search \
  -H "Content-Type: application/json" \
  -H "pubrio-api-key: YOUR_API_KEY" \
  -d '{
    "people_titles": ["RevOps", "Sales Operations"],
    "technologies": [114, 287],
    "filter_conditions": [
      { "key": "technologies", "operator": "and" }
    ],
    "per_page": 25,
    "page": 1
  }'

흔한 실수

key 를 빠뜨리고 operator 만 보내기

전역 “기본 연산자” 토글은 없습니다. 모든 항목은 특정 필터를 지정해야 합니다:

// 무시됨 — key 가 없음
{ "filter_conditions": [{ "operator": "and" }] }

// 정확함 — technologies 필터만 재정의
{ "filter_conditions": [{ "key": "technologies", "operator": "and" }] }

항목들이 결합된다고 가정하기

항목들은 키별로 독립적인 재정의입니다 — 서로 연쇄되지 않습니다. technologies 와 verticals 를 함께 나열해도 둘 사이에 불 식이 만들어지지 않습니다. 각각이 자기 배열의 연산자만 설정합니다.필터 키 사이 의 결합은 항상 AND 입니다(모든 필터가 일치해야 합니다). filter_conditions 로 두 개의 다른 필터 차원을 OR-결합할 수는 없습니다. 진짜 “다른 필터들의 OR” 검색이 필요하다면 두 번 요청을 보내고 클라이언트 측에서 병합하세요.

긴 배열에 AND 사용

AND 는 column @> ARRAY[…] — 모든 값이 존재해야 합니다. 8 개 이상이 되면 거의 항상 0 행을 얻게 됩니다. 실세계 태깅이 희소하기 때문이죠. AND-재정의된 배열은 2-4 값으로 유지하고, 탐색 또는 카테고리 수준 필터링은 OR 로.

/people/search 회사 필터에서 잘못된 키

/people/search 에서 인물 API 이름은 company_places / company_locations 입니다. 그러나 filter_conditions[].key 안에서는 엔진 이름 — places、locations 을 써야 합니다. 리매핑은 filter_conditions 가 참조되기 전에 내부적으로 끝납니다.

// 재정의되지 않음 — 엔진은 "company_places" 를 필터 키로 인식하지 않음
{ "filter_conditions": [{ "key": "company_places", "operator": "and" }] }

// 정확함
{ "filter_conditions": [{ "key": "places", "operator": "and" }] }

완전한 리매핑 표는 인물 + 회사 필터 페이지에 있습니다.

의심될 때는 먼저 filter_conditions 를 생략하고 결과 수가 기대치와 맞는지 확인하세요. 기본 동작이 의도와 맞지 않는 필터에만 재정의를 추가하세요 — 요청 페이로드가 더 작아지고 디버깅도 쉬워집니다.

참고

필터 개요

멘탈 모델 — filter_conditions 가 첫 정거장이라면 여기서 시작하세요.

인물 + 회사 필터

/people/search 에 회사 필터를 겹쳐 사용하는 방법, 키 리매핑 포함.

회사 검색 레퍼런스

/companies/search 의 전체 요청 스키마(company_filter_conditions 포함).

인물 검색 레퍼런스

/people/search 의 전체 요청 스키마(people_filter_conditions 포함).

모니터

필터

​스키마

​왜 중요한가

​지원 키

​레시피

​흔한 실수

​참고

필터 개요

인물 + 회사 필터

회사 검색 레퍼런스

인물 검색 레퍼런스

스키마

왜 중요한가

지원 키

레시피

흔한 실수

참고