데이터 보강(enrichment)은 이미 보유한 레코드에 정보를 추가하는 프로세스입니다. 리드가 이름과 업무용 이메일과 함께 들어오면, 보강은 회사의 산업, 규모, 위치, 기술 스택을 추가하고, 때로는 담당자의 역할과 직급도 추가합니다. CRM에 이름만 있는 계정이 존재한다면, 보강은 도메인, 직원 수 구간, 최근 채용 현황을 추가합니다.
이는 무(無)에서 레코드를 생성하는 리스트 구축과는 구별됩니다. 그 부분은 웹 스크래핑으로 B2B 리드 데이터베이스 구축하기에서 다룹니다. 보강은 이미 가진 것에서 시작해 더 유용하게 만드는 작업이며, 그 결과물의 품질은 단일 데이터 제공업체보다 매칭과 소싱 결정에 훨씬 더 크게 좌우됩니다.
네 가지 보강 유형
| 유형 | 예시 필드 | 일반적인 출처 |
|---|---|---|
| 기업 정보(Firmographic) | 산업, 규모 구간, 매출 구간, 위치, 소유 구조 | 등록기관, 회사 웹사이트, 라이선스 제공업체 |
| 기술 정보(Technographic) | 회사가 사용하는 도구 및 플랫폼 | 웹사이트 소스와 헤더, 공개 DNS 레코드, 채용 공고, 파트너 디렉터리 |
| 연락처(Contact) | 역할, 직급, 부서, 업무용 연락처 정보 | 회사 웹사이트, 전문 디렉터리, 라이선스 제공업체 |
| 인텐트 및 활동(Intent and activity) | 채용, 출시, 자금 조달, 리서치 행동 | 채용 공고, 뉴스, 리뷰 및 비교 사이트 |
대부분의 팀은 기업 정보를 먼저 필요로 하는데, 이는 라우팅과 스코어링을 좌우하기 때문입니다. 연락처 보강은 컴플라이언스 부담이 가장 큽니다. 인텐트 신호는 가장 빠르게 가치를 잃는데, 이는 세일즈 인텔리전스를 위한 인텐트 신호 스크래핑에서 다룹니다.
조인 키(join key)가 모든 것을 결정한다
보강은 데이터 문제이기 전에 매칭 문제입니다. 추가되는 모든 값은 당신의 레코드와 출처의 레코드 사이의 연결 고리만큼만 정확합니다.
회사 도메인이 가장 좋은 키입니다. 대부분의 출처에서 공유되며 모호성이 드뭅니다. 회사명만으로 보강하면 이름이 비슷한 회사들 사이에서 확신에 찬 오매칭이 발생합니다.
이메일 도메인은 담당자를 회사에 매핑하지만, 한 가지 큰 예외가 있습니다. 무료 이메일 도메인은 누구에게도 매핑되지 않습니다. 개인 주소를 가진 리드는 그 주소만으로는 회사 수준에서 보강할 수 없습니다.
등록기관 식별자는 보유하고 있는 경우 특히 법인체와 자회사에 대해 권위 있는 정보원이 됩니다.
모든 보강된 필드에 매칭 신뢰도를 저장하고, 라우팅이나 가격 결정을 좌우하는 필드에는 신뢰도가 낮은 매칭을 기입하지 않도록 하십시오. 계정에 잘못된 산업 정보가 있는 것은 비어 있는 것보다 나쁩니다.
보강 데이터의 출처
| 출처 | 강점 | 약점 |
|---|---|---|
| 퍼스트파티 데이터 | 정확하고 동의를 받았으며 당신에게 특화됨 | 당신에게 알려준 사람들만 커버 |
| 공개 웹 | 최신이고 범위가 넓으며 레코드당 저렴함 | 수집 인프라와 파싱이 필요함 |
| 사업자 등록기관 | 법적 사실에 대해 권위 있음 | 범위가 좁음; 상업적 신호 없음 |
| 라이선스 제공업체 | 통합이 빠르고 커버리지가 넓음 | 비용, 불투명한 소싱, 신선도 편차 |
가장 강력한 구성은 네 가지를 모두 결합합니다. 퍼스트파티 데이터는 존재하는 곳이라면 어디서든 최우선이고, 등록기관은 법적 사실을 확정하며, 라이선스 제공업체는 범위를 빠르게 채우고, 공개 웹 수집은 신선도와 어떤 제공업체도 판매하지 않는 구체적 신호를 공급합니다.
벤더의 소싱은 그들의 리스크이자 당신의 리스크이기도 합니다. 제공업체가 연락처 데이터의 출처와 근거를 설명하지 못한다면, 그 불확실성은 당신이 그것을 사용할 때 당신에게로 이전됩니다.
워터폴 보강(Waterfall enrichment)
필드마다 하나의 출처를 신뢰하는 대신, 정해진 순서로 출처를 실행하고 충분한 신뢰도로 필드가 채워지면 멈춥니다.
- 퍼스트파티 데이터를 확인합니다.
- 등록기관 등 권위 있는 출처에 질의하여 해당 출처가 관장하는 필드를 확인합니다.
- 회사 자체의 공개 정보를 수집합니다. 이는 대개 자기 자신에 대한 가장 최신의 설명입니다.
- 남은 공백은 라이선스 제공업체로 대체합니다.
각 필드를 채운 출처를 기록하십시오. 그런 다음 출처별이 아니라 필드별로 우선순위를 정의하십시오. 법정 명칭은 등록기관이 우선하고, 제품 설명은 대개 회사 웹사이트가 우선하며, 현재 채용 현황은 채용 공고가 우선합니다. 출처들이 허용 오차를 넘어 서로 다를 경우, 하나를 조용히 선택하지 말고 둘 다 보관하며 충돌을 표시하십시오.
프록시 인프라가 적합한 곳, 그리고 적합하지 않은 곳
라이선스 제공업체와 공식 API는 프록시가 필요하지 않습니다. 키를 사용해 직접 호출하면 됩니다. 리드 생성과 보강 전반에 걸친 프록시 인프라의 더 넓은 활용 사례는 B2B 리드 생성을 위한 레지덴셜 프록시에서 다룹니다.
공개 웹 출처는 대규모 수집이 그러하듯 프록시가 필요합니다.
회사 웹사이트는 대부분 작고 독립적인 사이트입니다. 일반적인 트래픽을 차단하는 경우는 드물지만, 한 주소에서의 대량 요청은 스로틀링을 유발하며, 일부는 지역별로 다르게 응답합니다.
등록기관과 디렉터리는 속도 제한이 있고 때로는 지역적이며, 많은 경우 일관된 세션이 필요한 방식으로 결과를 페이지네이션합니다.
채용 공고는 지역별로 필터링되므로, 특정 지역의 채용 신호는 그 지역에서 수집해야 합니다. 채용 게시판 데이터와 노동 시장 인텔리전스를 참고하십시오.
Shifter 게이트웨이에서는 시장과 세션이 p.shifter.io:443에 대한 자격 증명 안에서 설정됩니다:
customer-USERNAME-country-fr-sid-enrich-registry-03-ttl-600:PASSWORDsid로 하나의 종료 지점을 유지하는 것은 페이지네이션이 있는 등록기관 조회에 적합합니다. sid를 생략하면 요청마다 로테이션되는데, 이는 독립적인 여러 회사 홈페이지를 가져오는 데 적합합니다. 이 트레이드오프는 고정 vs 로테이팅 레지덴셜 프록시에서 다룹니다.
JavaScript로 콘텐츠를 렌더링하는 사이트의 경우, 추출 규칙을 통해 구조화된 JSON을 반환하는 웹 스크래핑 API는 파싱과 브라우저 작업을 없애주며 성공적인 응답에 대해서만 비용을 청구합니다. 이 출력을 안정적으로 저장하는 방법은 웹 스크래핑 API 데이터를 SQL로 옮기기에서 다룹니다.
기술 정보 탐지, 정직하게
기술 지표는 공개 신호에서 나옵니다: 스크립트 태그와 페이지 소스, 응답 헤더, 메일 및 도메인 인증 항목 같은 공개 DNS 레코드, 파트너 디렉터리, 채용 공고에 명시된 도구들입니다.
각각을 사실이 아니라 신뢰도가 있는 증거로 취급하십시오. 회사가 도구 사용료를 더 이상 지불하지 않는데도 남아 있는 태그는 흔합니다. 한 채용 공고에서의 언급은 레거시 시스템일 수 있습니다. 두 개 이상의 독립적인 신호가 일치하는 것이 하나의 신호보다 훨씬 신뢰할 만합니다.
신선도
보강된 데이터는 서로 다른 속도로 노후화됩니다. 회사명과 도메인은 수년간 안정적이고, 직원 수와 기술은 몇 달 안에 변하며, 역할과 연락처 정보가 가장 빠르게 변합니다.
단일 일정이 아니라 트리거에 따라 재보강하십시오: 영업팀이 레코드를 다룰 때, 신호가 변화를 시사할 때, 그리고 각 필드의 노후화 속도에 맞춘 주기적 사이클로 말입니다. 필드별로 관측 날짜를 저장하여 오래된 정도가 눈에 보이도록 하십시오.
연락처 보강에 대한 컴플라이언스
담당자의 레코드를 보강하는 것은 그들의 개인 데이터를 처리하는 것이며, 출처가 공개된 것이었다고 해서 그 의무가 줄어들지 않습니다. 일반적인 지침으로서, 그리고 자체 법률 자문과 함께 참고하십시오:
- 목적과 필드를 제한하십시오. 문서화된 목적이 필요로 하는 것만 추가하십시오. 개인 전화번호, 개인 소셜 프로필, 자택 주소는 B2B 보강에 속하지 않습니다.
- 투명하게 하십시오. 개인 데이터를 본인이 아닌 출처로부터 취득한 경우, GDPR은 일반적으로 늦어도 최초 접촉 시점에 본인에게 알릴 것을 요구합니다.
- 거부 의사와 삭제를 전파하십시오. 억제 조치(suppression)는 보강 캐시와 보강된 데이터를 받은 모든 시스템에 도달해야 하며, 그렇지 않으면 다음 보강 실행 시 삭제된 것이 조용히 복원됩니다.
- 벤더를 파악하십시오. 제공업체의 소싱에 대한 실사는 당신 자신의 책무성의 일부입니다.
더 넓은 틀은 레지덴셜 프록시와 GDPR 준수에서 다룹니다.
보강 측정하기
| 지표 | 알려주는 것 |
|---|---|
| 매칭률 | 충분한 신뢰도로 출처 레코드에 연결된 레코드의 비율 |
| 필드별 충족률 | 커버리지가 얇은 부분 |
| 검증된 샘플의 정확도 | 채워진 값이 옳은지 여부 |
| 충돌률 | 출처들이 얼마나 자주 불일치하는지 |
| 필드별 신선도 | 재보강 임계값을 넘긴 데이터의 양 |
| 보강된 레코드당 비용 | 실패하거나 신뢰도가 낮은 조회를 포함한 실제 경제성 |
정확도는 팀들이 건너뛰기 쉬운 지표이지만, 가장 중요한 것입니다. 분기마다 무작위 샘플을 수작업으로 확인하십시오.
자주 묻는 질문
데이터 보강이란 무엇인가요?
이미 보유한 레코드에 다른 출처의 속성을 추가하는 것으로, 예를 들어 계정에 산업, 규모, 기술을 추가하거나 연락처에 역할과 직급을 추가하는 것입니다.
데이터 보강에 프록시가 필요한가요?
공개 웹 수집에만 필요합니다. 라이선스 제공업체와 공식 API는 직접 호출합니다.
어떤 보강을 먼저 해야 하나요?
기업 정보입니다. 라우팅, 스코어링, 세그멘테이션을 좌우하기 때문입니다. 연락처 보강은 그 후이며 가장 많은 주의가 필요합니다.
왜 우리 보강 데이터의 값이 계속 오락가락하나요?
보통 우선순위 규칙 없이 서로 다른 값을 가진 두 출처 때문입니다. 필드별로 우선순위를 정의하고, 마지막에 쓴 값이 이기도록 두는 대신 충돌을 표시하십시오.
결론
보강 품질은 단일 출처가 아니라 데이터를 둘러싼 결정에서 나옵니다: 신뢰할 수 있는 조인 키, 모든 필드에 대한 매칭 신뢰도, 퍼스트파티와 권위 있는 출처를 우선하는 워터폴, 필드별 우선순위 규칙, 그리고 속성별로 추적되는 신선도입니다.
보강이 공개 웹에 닿는 곳에서는 프록시 인프라를 사용하고, 라이선스 출처는 직접 호출하며, 연락처 보강은 문서화된 목적 안에서 유지하고 거부 의사가 모든 사본에 도달하도록 하십시오. 제품 관점은 리드 생성을 위한 레지덴셜 프록시 페이지에서, 요금은 가격 페이지에서 확인할 수 있습니다.