コンタクトおよび企業エンリッチメント:データソース+プロキシインフラストラクチャ

データエンリッチメントは、すでに保有しているレコードのギャップを埋めます。各エンリッチメントタイプに必要なもの、データの出所、そしてプロキシインフラストラクチャが果たす役割について解説します。

データエンリッチメントとは、すでに保有しているレコードに情報を追加するプロセスである。名前と業務用メールアドレスを持つリードが届いたとき、エンリッチメントはその会社の業種、規模、所在地、技術情報、さらには担当者の役職や役職レベルを追加する。CRM内に名前だけの取引先が存在する場合、エンリッチメントはそのドメイン、従業員数の区分、直近の採用状況を追加する。

これはリストビルディングとは異なる。リストビルディングは何もないところからレコードを作成するものであり、その内容はWebスクレイピングを用いたB2Bリードデータベースの構築で扱っている。エンリッチメントは手元にあるものを起点に、それをより有用にするものであり、その結果の質はどの単一のデータプロバイダーよりも、マッチングとソーシングの判断にはるかに大きく左右される。

4種類のエンリッチメント

種類	フィールドの例	典型的なソース
ファーモグラフィック	業種、規模区分、収益区分、所在地、所有形態	登記情報、企業のWebサイト、ライセンスプロバイダー
テクノグラフィック	企業が使用するツールやプラットフォーム	Webサイトのソースとヘッダー、公開DNSレコード、求人情報、パートナーディレクトリ
コンタクト	役職、役職レベル、部門、業務用連絡先情報	企業のWebサイト、専門ディレクトリ、ライセンスプロバイダー
インテントとアクティビティ	採用、ローンチ、資金調達、リサーチ行動	求人情報、ニュース、レビューおよび比較サイト

多くのチームはまずファーモグラフィックを必要とする。これがルーティングとスコアリングを左右するからだ。コンタクトエンリッチメントはコンプライアンス上の負荷が最も大きい。インテントシグナルは最も早く価値を失う。これについてはインテントシグナルのスクレイピングによるセールスインテリジェンスの強化で扱っている。

結合キーがすべてを決める

エンリッチメントは、データの問題である前にマッチングの問題である。付加されるすべての値の質は、あなたのレコードとソース側のレコードとの結びつきの強さに依存する。

**企業ドメインは最良のキーである。**ほとんどのソースで共有されており、曖昧になることはめったにない。企業名だけでエンリッチメントを行うと、似た名前の企業同士で自信満々に誤ったマッチングが生じる。

**メールドメインは人物を企業に対応付ける。**ただし一つ大きな例外がある。フリーメールドメインは誰にも対応付けられない。個人アドレスしか持たないリードは、そのアドレスだけでは企業レベルでエンリッチできない。

登記識別子は、それを保有している場合には権威あるものとなり、特に法人格や子会社について有効である。

すべてのエンリッチ済みフィールドにマッチ信頼度を保存し、ルーティングや価格設定を左右するフィールドには低信頼度のマッチを書き込まないようにする。取引先の業種を誤って記載することは、空欄にしておくよりも悪い。

エンリッチメントデータはどこから来るのか

ソース	強み	弱み
ファーストパーティデータ	正確で、同意済みで、自社に特化している	自社に情報を伝えた人しかカバーしない
公開Web	最新で、範囲が広く、レコードあたりのコストが安い	収集基盤と解析処理が必要
企業登記情報	法的事実について権威がある	範囲が狭く、商業的シグナルがない
ライセンスプロバイダー	統合が速く、カバー範囲が広い	コスト、ソーシングの不透明さ、鮮度のばらつき

最も強力な体制はこの4つすべてを組み合わせる。ファーストパーティデータは存在する限りどこでも勝り、登記情報は法的事実を確定させ、ライセンスプロバイダーは広さを迅速に埋め、公開Web収集は鮮度と、どのプロバイダーも販売していない特定のシグナルを供給する。

ベンダーのソーシングはベンダー自身のリスクであると同時に、あなた自身のリスクでもある。プロバイダーが自社のコンタクトデータの出所とその根拠を説明できない場合、その不確実性はあなたがそのデータを使用した時点であなたに移る。

ウォーターフォール型エンリッチメント

フィールドごとに一つのソースを信頼するのではなく、決められた順序でソースを実行し、十分な信頼度でフィールドが埋まった時点で停止する。

ファーストパーティデータを確認する。
**権威あるソースに問い合わせる。**登記情報など、そのソースが管轄するフィールドについて。
**企業自身の公開情報から収集する。**これは通常、企業自身についての最も新しい記述である。
残ったギャップについてはライセンスプロバイダーに頼る。

どのソースが各フィールドを埋めたかを記録する。そのうえで、ソースごとではなくフィールドごとに優先順位を定義する。法的名称については登記情報が優先され、製品説明については通常企業のWebサイトが優先され、現在の採用状況については求人情報が優先される。ソース同士が許容範囲を超えて食い違う場合は、どちらか一方を黙って選ぶのではなく、両方を保持して矛盾にフラグを立てる。

プロキシインフラが適合する場面、適合しない場面

ライセンスプロバイダーや公式APIはプロキシを必要としない。キーを使って直接呼び出せばよい。リードジェネレーションとエンリッチメント全体におけるプロキシインフラのより広範な位置づけについては、B2Bリードジェネレーションのためのレジデンシャルプロキシを参照。

公開Webソースについては、大規模な収集全般と同じ理由でプロキシが必要になる。

企業のWebサイトは、小規模で独立したサイトが多数存在する。通常のトラフィックをブロックすることはめったにないが、1つのアドレスからの大量アクセスはスロットリングを招き、地域によって異なる内容を配信するサイトもある。

登記情報とディレクトリはレート制限があり、地域限定の場合もあり、多くは一貫したセッションを必要とする形でページネーションを行っている。

求人情報は地域でフィルタリングされているため、ある地域の採用シグナルはその地域から収集する必要がある。詳しくは求人ボードデータと労働市場インテリジェンスを参照。

Shifterのゲートウェイでは、市場とセッションはp.shifter.io:443に対する認証情報の中で設定される。

customer-USERNAME-country-fr-sid-enrich-registry-03-ttl-600:PASSWORD

sidを使って1つの出口を保持することは、ページネーションのある登記情報検索に適している。省略するとリクエストごとにローテーションされ、これは多数の独立した企業ホームページを取得するのに適している。このトレードオフについては固定型と回転型のレジデンシャルプロキシで扱っている。

JavaScriptでコンテンツをレンダリングするサイトについては、抽出ルールを通じて構造化されたJSONを返すWebスクレイピングAPIを使えば、解析処理とブラウザ処理が不要になり、成功したレスポンスに対してのみ課金される。この出力を確実に取り込む方法についてはWebスクレイピング APIデータをSQLに移行するで扱っている。

テクノグラフィック検出、正直に言うと

技術に関する指標は公開シグナルから得られる。スクリプトタグとページソース、レスポンスヘッダー、メールやドメイン検証エントリなどの公開DNSレコード、パートナーディレクトリ、求人情報に記載されたツール名などだ。

これらはそれぞれを事実としてではなく、信頼度を伴う証拠として扱うべきだ。企業がツールへの支払いをやめた後もタグが残っていることはよくある。1件の求人情報での言及は、旧式のシステムを指している可能性がある。2つ以上の独立したシグナルが一致している方が、1つだけよりもはるかに信頼できる。

鮮度

エンリッチ済みデータは異なる速度で劣化する。企業名やドメインは何年も安定しているが、従業員数や技術は数か月で変化し、役職や連絡先情報は最も速く変化する。

単一のスケジュールではなく、トリガーに基づいて再エンリッチを行う。営業がレコードに触れたとき、シグナルが変化を示唆したとき、そして各フィールドの劣化速度に合わせた定期サイクルで実施する。フィールドごとに観測日を保存すれば、鮮度の低下が可視化される。

コンタクトエンリッチメントにおけるコンプライアンス

人物のレコードをエンリッチすることは、その人の個人データを処理することであり、ソースが公開されていたからといって義務が軽くなるわけではない。一般的な指針として、そして自社の顧問弁護士の助言を得たうえで:

**目的とフィールドを限定する。**文書化された目的が必要とするものだけを追加する。個人の電話番号、個人のソーシャルプロフィール、自宅住所はB2Bエンリッチメントには含まれない。
**透明性を保つ。**本人以外のソースから個人データを取得した場合、GDPRは一般に、遅くとも最初の接触時までに本人に通知することを求めている。
**オプトアウトと削除を伝播させる。**抑制措置はエンリッチメントキャッシュと、エンリッチ済みデータを受け取ったすべてのシステムに届かなければならない。さもないと、次のエンリッチメント実行で削除されたはずのものが静かに復元されてしまう。
**ベンダーを把握する。**プロバイダーのソーシングに関するデューデリジェンスは、自社のアカウンタビリティの一部である。

より広い枠組みについてはレジデンシャルプロキシとGDPRコンプライアンスを参照。

エンリッチメントの測定

指標	わかること
マッチ率	十分な信頼度でソースレコードにリンクされたレコードの割合
フィールドごとの充足率	カバレッジが薄い箇所
チェック済みサンプルにおける正確性	埋められた値が正しいかどうか
矛盾率	ソース同士がどれくらいの頻度で食い違うか
フィールドごとの鮮度	再エンリッチのしきい値を過ぎたデータの割合
エンリッチ済みレコードあたりのコスト	失敗した検索や低信頼度の検索を含めた実際の経済性

正確性はチームが省略しがちな指標であり、それでいて最も重要な指標である。四半期ごとにランダムサンプルを手作業で確認すること。

よくある質問

データエンリッチメントとは何か。

すでに保有しているレコードに他のソースからの属性を追加することである。例えば取引先に業種、規模、技術情報を追加したり、コンタクトに役職や役職レベルを追加したりすることである。

データエンリッチメントにプロキシは必要か。

公開Web収集の場合にのみ必要である。ライセンスプロバイダーと公式APIは直接呼び出す。

どのエンリッチメントを最初に行うべきか。

ファーモグラフィックである。ルーティング、スコアリング、セグメンテーションを左右するからだ。コンタクトエンリッチメントはその後であり、最も注意が必要である。

なぜ当社のエンリッチメントは値が行ったり来たり変わり続けるのか。

たいていの場合、異なる値を持つ2つのソースがあり、優先順位のルールがないことが原因である。フィールドごとに優先順位を定義し、最後に書き込まれたものが勝つ状態にするのではなく、矛盾にフラグを立てること。

結論

エンリッチメントの質は、単一のソースからではなく、データを取り巻く判断から生まれる。信頼できる結合キー、すべてのフィールドにおけるマッチ信頼度、ファーストパーティと権威あるソースを優先するウォーターフォール、フィールドごとの優先順位ルール、そして属性ごとに追跡される鮮度である。

エンリッチメントが公開Webに触れる場面ではプロキシインフラを使用し、ライセンス済みソースは直接呼び出し、コンタクトエンリッチメントは文書化された目的の範囲内に留め、オプトアウトをすべてのコピーに届くようにすること。製品についての詳細はリードジェネレーション向けレジデンシャルプロキシページを、料金については料金ページを参照。