UC-AI-002AILv4
Data Enrichment（CRM リード補完）
企業／人物情報を自動補完し、CRM やリードスコアリングの精度を上げる。
Data Enrichment
KPI 例
- 補完率
- 精度
- ROI
CRM リード補完では、最初から「完璧な 1 API」を期待するより、候補を見つける段階 と 既存レコードを深掘りする段階 を分けて考えるほうが実装しやすくなります。この学習サイトでは、Bright Data の Data Enrichment を Discover と Deep Lookup を組み合わせて理解する整理を採っています。
誰の課題か
- 営業チームへ渡す前に企業レコードの粒度をそろえたい RevOps 担当
- リードの所属企業や公式サイトを手作業で確認しているインサイドセールス
- 既存 CRM の空欄を埋めたいが、独自スクレイパを保守したくない開発チーム
重要なのは、取得できる属性を先に広げすぎないことです。営業フローで実際に使う列だけを先に決め、その列を埋めるための探索と深掘りを段階化します。
推奨製品セット
| 製品 | 役割 | 使いどころ |
|---|---|---|
| Data Enrichment | ユースケース全体のまとめ役 | CRM 補完パイプラインの設計単位 |
| Discover | 候補発見 | 企業、人物、連絡先の候補を広く探す |
| Deep Lookup | 詳細補完 | 見つけた候補に追加属性を付ける |
- 既存レコードが粗い場合は Discover から始めます。
- 会社ドメインや企業名が既にある場合は、Deep Lookup を先に検討したほうが効率的です。
最小実装イメージ
専用のペイロード仕様は製品更新の影響を受けやすいため、このページではアプリ側の最小パイプラインに絞って示します。Bright Data 側の具体的な入力項目は、実装時に各製品ドキュメントで確認してください。
import csv
def normalize_lead(row: dict) -> dict:
return {
"company_name": row.get("company_name", "").strip(),
"person_name": row.get("person_name", "").strip(),
"company_domain": row.get("company_domain", "").strip().lower(),
}
def choose_enrichment_stage(lead: dict) -> str:
if lead["company_domain"] or lead["company_name"]:
return "deep_lookup"
return "discover"
with open("crm_input.csv", newline="", encoding="utf-8") as src, open(
"crm_queue.csv", "w", newline="", encoding="utf-8"
) as dst:
reader = csv.DictReader(src)
writer = csv.DictWriter(
dst,
fieldnames=["company_name", "person_name", "company_domain", "stage"],
)
writer.writeheader()
for row in reader:
lead = normalize_lead(row)
lead["stage"] = choose_enrichment_stage(lead)
writer.writerow(lead)このキューをもとに、discover 対象と deep_lookup 対象を分けて呼び出します。実運用では 1 回の補完で全列を埋めようとせず、まず company_name、company_domain、role など必須列だけに絞るのが安全です。
運用ポイント
- API キー権限は最小権限で分けます。営業アプリが呼ぶキーと、管理者が製品設定に使うキーを共用しません。
- 正解が 1 つに定まらない属性は、上書きではなく候補として保持します。特に企業名ゆれや人物名の同姓同名は後段で確認が必要です。
- 補完前の元データを残し、どの列を Bright Data 由来で埋めたかを記録します。CRM の監査や再同期で差分追跡が必要になるためです。
- 個人情報を含む列は、取得目的と保持期間を先に決めます。大量に集めてから削る設計は避けます。
- リード補完は単発の成功率だけでなく、営業が使える行数、重複率、手動修正率で評価します。