인물 + 회사 필터

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`	네트워크별 SNS 핸들

인물이 일하는 회사 의 속성을 필터링 — /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`	매출 구간 (USD)
`company_locations`	회사 본사 국가 코드
`company_exclude_locations`	제외할 국가 코드
`company_places`	포함할 도시 / 지역 이름
`company_exclude_places`	제외할 도시 / 지역 이름
`companies`	특정 `domain_search_id`
`domains`	특정 회사 도메인
`company_linkedin_urls`	회사 LinkedIn URL

company_ 접두사는 위치/장소 필터에만 존재합니다. bare 이름 places / locations 가 이미 인물 의 주소에 사용되기 때문입니다. 그 외에는 모두 bare 회사 이름(technologies、company_technologies 가 아닙니다)을 씁니다.

4 단계로 쿼리 만들기

인물 술어 결정

정확히 누구? 직책, 직급, 부서, 국가. 이 레이어는 본문의 최상위 에 둡니다 — 정밀도는 보통 회사 술어가 담당합니다.

회사 술어 결정

어떤 회사에서 일해야 하는가? 산업, 규모, 설립 연도, 본사 국가, 기술 스택. 이것들은 company_filters: {...} 객체로 묶으면 어떤 키가 어느 레이어에 속하는지 명확해집니다.

filter_conditions 로 필터별 AND/OR 선택

정밀도가 필요한 다중 값 필터(예: “이 기술들을 전부 사용”)에는 company_filters 안의 filter_conditions 에 항목을 추가. 기본값은 OR.

요청 보내기

POST /people/search. 두 스타일 모두 허용되지만 company_filters: {...} 가 더 읽기 쉽고 Monitor 의 페이로드 형태와도 일치합니다.

완전한 예시

쿼리: 미국 본사이며 2015〜2023 년 설립、직원 100-5,000 명、Kubernetes 와 Docker 를 둘 다 사용하지만 샌프란시스코는 제외하는 중견 회사의 VP of Engineering 또는 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 가 회사 필터를 공유 엔진에 넘길 때, 위치/장소 키는 bare 이름으로 변경됩니다. 엔진과 filter_conditions[].key 가 실제로 보는 것이 이 bare 이름입니다:

보내는 이름 (인물 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 는 bare 이름을 사용합니다:

{
  "company_places": ["New York", "Boston"],
  "filter_conditions": [
    { "key": "places", "operator": "and" }
  ]
}

{ "key": "company_places", "operator": "and" } 는 조용히 무시됩니다 — 엔진은 접두사 붙은 이름을 인식하지 않습니다. filter_conditions 에서는 항상 엔진 이름을 참조하세요.

내부의 JOIN

어떤 회사 수준 필터든 추가하면 인물-회사 JOIN 이 LEFT JOIN 에서 INNER JOIN 으로 바뀝니다. 모든 인물 수준 필터를 만족해도 회사 정보가 확인되지 않는 인물은 결과에서 제외됩니다.

company_locations 나 technologies 를 추가하자마자 결과가 0 으로 떨어진다면, 기대하는 인물에 연결된 회사가 데이터셋에 있는지 확인하세요. 엔진은 이 지점에서 회수보다 정확성을 우선합니다 — 필터를 만족시키기 위해 회사를 만들어내지 않습니다.

응답에도 같은 JOIN 동작이 반영됩니다: 회사 필터를 하나라도 적용하면 반환되는 모든 인물에 채워진 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](자사 제품의 태그 ID)로 다시 실행하고 클라이언트 측에서 차집합을 구합니다.

다음 단계

filter_conditions

완전한 레퍼런스 — 모든 키, 모든 기본값, 복사 가능한 AND/OR 레시피.

필터 개요

통합 필터 엔진 뒤의 멘탈 모델.

인물 검색 레퍼런스

/people/search 의 전체 요청/응답 스키마.

회사 검색 레퍼런스

/companies/search 의 전체 요청/응답 스키마.

모니터

필터

인물

확장

한 본문, 두 파라미터 패밀리

4 단계로 쿼리 만들기

완전한 예시

키 리매핑 레퍼런스

내부의 JOIN

흔한 패턴

다음 단계

filter_conditions

필터 개요

인물 검색 레퍼런스

회사 검색 레퍼런스

​한 본문, 두 파라미터 패밀리

​4 단계로 쿼리 만들기

​완전한 예시

​키 리매핑 레퍼런스

​내부의 JOIN

​흔한 패턴

​다음 단계

filter_conditions

필터 개요

인물 검색 레퍼런스

회사 검색 레퍼런스

한 본문, 두 파라미터 패밀리

4 단계로 쿼리 만들기

완전한 예시

키 리매핑 레퍼런스

내부의 JOIN

흔한 패턴

다음 단계