data-research

データリサーチ

未加工のリストを、標準化された見込み顧客リストに変換します。各行について、次の3つの問いに答えます。 このアカウントは対象か、今連絡する理由は何か、最初の一文に何を書くか。

ほとんどの場合、これはリスト作成ではありません。クライアントからCRMのエクスポート、スクレイピングしたシート、または古いキャンペーンファイルを受け取り、すでにあるデータを評価するのが仕事です。リストがまったくない場合は、まずデータを入手し（Apollo、Sales Navigator、ディレクトリのスクレイピングなど）、その後にこの作業を行います。

すべての基準となる区分

• シグナル ＝ 日付のある出来事です。いつの時点でも、コールドリストの約3～5％に当てはまります。連絡するタイミングを示します。
• データポイント ＝ スタック、業種、従業員数、該当する機能を社内で運用しているかどうかなど、変わることのない事実です。何を伝えるかを示します。

理由にはシグナルを1つ使い、メッセージを組み立てるためにデータポイントを1つ使います。シグナルがなければ、メッセージは一斉送信のように見えます。実際、一斉送信だからです。

リストの大半にシグナルがあると期待するのは、最もよくある計画上の誤りです。3～5％という割合は市場の実態であり、調整で解決する問題ではありません。

厳守事項

1. URLも日付もなければ、シグナルではありません。 推測で埋めるくらいなら何も書かないでください。証明できないシグナルは空欄より悪質です。調査したように見えるため、それをもとに誰かが手紙を書いてしまいます。
2. シグナルの情報源から、会社名ではなく会社のドメインを特定できる必要があります。 実際の実行結果では、会社の公式サイトから得られたシグナルは21件ですべて有効でした。一方、Googleで会社名を検索して得られた187件の精度は約40％でした（似た名前の別会社が返され続けました）。RedditとUpworkから得られた906件は、リストとの一致が0件でした。名前による照合や公開フォーラムは新たな見込み顧客を見つけるためのもので、すでにあるリストを検証するためのものではありません。
3. signal_dateには出来事が起きた日付を入力します。 チェックを実行した日付は、別の列に記録します。
4. 従業員数、取引規模、スタック、役職を決して捏造しないでください。 情報がない場合は、0点にして情報補完フラグを設定します。推測した数値が、誰かの頼りにする予測値になってしまいます。
5. 不適格となった行も削除しません。 理由を記載して、ファイルに残します。削除された行は、3か月後に再購入され、再調査されることになります。
6. 重複排除は会社単位ではなく、人物単位で行います。 1社につき2～3人の連絡先があるのは通常のことであり、望ましい状態です。
7. 最も強いシグナルを1つだけ採用し、合算しないでください。 シグナルが複数ある場合は、点数を上げるのではなく、同じランク内でアカウントの優先順位を上げます。
8. アンチシグナルは別ファイルに保存し、不適格なアカウントも含め、すべてのアカウントを対象に確認します。 そうしないと、実行時に不適格とされていない行だけが読み込まれ、除外された競合他社が再確認されず、除外フィルターが機能しなくなり、その競合他社がリストに戻ってしまいます。

パスの順序 — 最も安価な絞り込みから

順序は見た目だけの問題ではありません。各パスは行単位で課金されるため、行を減らす処理は、行ごとに費用がかかる処理より先に実行する必要があります。

パス 0 — 渡されたデータを監査します。 1円も使う前に行います。実際のリストでは、クライアントの列にあるメールアドレス131件のうち、会社独自のドメインを持つものは27件、別のドメインを持つものは76件で、メールアドレスではないものが19件ありました。「CRMに従業員数なし」として除外された行も確認してください。これはデータの欠落であり、不採用ではないため、リストに戻す必要があります。

パス 1 — 停止フィルター。 アンチICPと必須条件です。1つでも「いいえ」があれば停止し、完全性の確認はその後に行います。ここで不合格となる行に、検出の時間を費やしてはいけません。

パス 2 — プロファイル。 最も多く絞り込め、最も安価です。会社ごとにSERPを1回検索（会社名＋国、1ページ）すると、サービスの説明、ドメイン、ソーシャルページが得られます。596社の実行では合計約$1.5で、実用可能なセグメントは1.7倍になりました。リストの半数は会社名と役職名だけでは分類できなかったためです。通常クライアントが手作業で行うウェブ検証よりも安価です。

パス 3 — 従業員数。プロファイルの条件を通過した行のみ対象です。 会社のソーシャルページを主な情報源とし、エンリッチメントで範囲内を絞り込みます。1社あたり約$0.004～0.006です。ティアを設定するのは、数値が検証できた場合だけにしてください。ある188社のリストでは、情報源の従業員数区分の半数が誤っており、83社は記載された下限を下回っていました。

パス 4 と 5 — シグナルとデータポイント。signal-research に引き継ぎます。

これはリスト構築の段階ではなく、独立した工程であり、独自の費用体系で実行します。シグナルが発生するのはリストの3～5％である一方、データポイントはほぼすべての企業で取得できるため、両方を1回のクロールで収集しなければ採算が合いません。signal-research は、シグナルライブラリ、検出の段階的な手順（最も安価な一括ソースを最初に、次にアカウントごとの調査、最後に有料プラットフォーム）、証拠のルール、鮮度の期間、再スキャンのキューを管理します。

従業員数の確認後、メールアドレスの取得前にここで実行し、2つの情報ブロックを受け取ります。シグナルブロック（signal_type · signal_evidence_url · signal_date · signal_route …）と、データポイントブロック（datapoint_type · datapoint_detail）です。アカウントが振り分けられるキューや、最初のメッセージの根拠となる情報など、以降のすべての処理はこの2つのブロックに基づきます。

このスキル内で検出処理を再実装しないでください。実行全体のコストを左右するため、ここで繰り返す価値があるルールは1つです。情報源が会社名ではなく、会社のドメインに紐付いている必要があります。

パス 6 — メールアドレス。 ここまで残った行のみ対象です。waterfall-enrichment スキルを参照してください。

パス 7 — アカウントごとの2人目の連絡先（意思決定者と並ぶ推進者）。

各パスの後に、対象行数、得られた結果、費用、所要時間を記録します。成果が5％未満のパスは、そのように報告し、より大規模に繰り返してはいけません。

コストモデル — 「クレジット」ではなく実際の数値を使う

パス	典型的な単価	備考
SERPによるプロファイル	1社あたり約$0.0025	検索1回、1ページ
会社ページのスクレイピング	1社あたり$0.004～0.006	従業員数、説明、専門分野
サイトコンテンツのクロール	バッチ単位の料金	深さ1、URLをグロブで指定、約35件ずつのバッチ
求人情報	1件あたり約$0.005	スラッグとタイトルで絞り込み
メールアドレスのウォーターフォール	1人あたり約1.4クレジット	waterfall-enrichment を参照

実行を始める前に、費用を見積もります。2,000社のリストをすべてのパスに通す場合の費用は把握できるものであり、予想外の出費ではありません。

スコアリングに関する注意事項

ルーブリック自体には prospect-scoring を使用します。この段階は接触前なので、会話で初めてわかる情報はスコアに含めません（それは lead-scoring の対象で、このプロフィールを起点とします）。この段階で特に重視する点は3つです。

• 検証済みの数値のみでティアを決めます。 従業員数が未確認の場合、ティアのセルには「verify manually」と記載します。空欄にしたり、推測したりしてはいけません。
• カテゴリ全体が空の場合は正規化します。 元データに案件規模が含まれていることはほとんどありません。15点のカテゴリが構造上、全員0点になると、上限が下がり、最上位バンドに到達する人がいなくなります。数値は2つ保持します。単純合計と、実際にデータがあったカテゴリの割合です。2つ目の数値でバンドを決めます。ただし、データの信頼度が「中」以上の場合に限ります。そうしないと、2つの項目が埋まっているだけの行が完璧に見えてしまいます。
• 安全策。 重要カテゴリ（スタック適合性、地域、意思決定者へのアクセス）のそれぞれが最低基準を満たさない限り、アカウントを最上位バンドに入れません。満たさない場合は、1つ下のバンドにします。

45日以上掲載されている求人は、新着求人より強いシグナルです。まだ採用できていないことを示しています。求人が掲載中である限り、シグナルの鮮度を低下させないでください。

セグメンテーション

campaign = キュー × ペルソナ × ティア。1つのキャンペーンには、1つのテキストと、そのキャンペーン固有の統計情報を持たせます。

• キュー A — 日付が特定されたイベントです。イベントが続く限り有効です。最初に対応します。
• キュー B — シグナルが弱いものです。
• キュー D — シグナルがありません。冒頭文では、相手のウェブサイト上のデータポイントを取り上げます。

AとDを1つのキャンペーンに混在させると、平均値によって強いセグメントと弱いセグメントの両方が見えにくくなります。意思決定者と推進者は別々のキャンペーンにします。課題も質問も異なるためです。ペルソナマトリクスにない役職は、レビュー対象としてフラグを付け、独自のキャンペーンにします。

出力

フラットなCSVとし、ヘッダー行は1行、値は数式ではなく、列の上にグループ化された行は置きません。列が同一のファイルを2つ作成します。フィルタで除外したものとその理由をすべて含む全件データと、作業対象として選定したデータです。

列ブロックは、次の固定順序にします。

1. 会社 — row_id · company_name_raw · company_name_clean · domain · country · geo_bucket · city · industry
2. 除外フィルター — filter_geo · filter_size · filter_anti_icp · filter_result
3. 従業員数 — emp_enriched · emp_final · tier
4. 適合性 — fit_icp · fit_services · fit_score · fit_gate
5. シグナル — signal_type · signal_score · signal_route · signal_evidence_url · signal_date · signal_age_days · signal_summary · signal_2_type · signal_2_url
6. データポイント — datapoint_type · datapoint_detail
7. 現在の業務の根拠 — クライアント固有（許認可、入札、求人）
8. ソース管理 — match_method · channel_route · exclusion_reason · source_track
9. ウェブサイト — site_status · site_sectors · 続いてクライアント固有の項目（設備、ソフトウェア、業務量、社内チーム）
10. 連絡先 — person_first_name · person_last_name · person_title · person_linkedin · person_email · email_status
11. テキスト — angle · observation · guess · question · opener_style · text_gate · text_gate_reason · hook_source · hook_date
12. セグメンテーション — persona_role · campaign · contacts_at_company · persona_gap

ブロック7と9はクライアントごとに変わります。それ以外は固定です。

signal_summary は、変更せず冒頭の一文にそのまま使えるように記述します。具体的な対象、場所、日付を含めます。「8月5日時点で、2つの都市圏にコーディネーターの求人が5件掲載中」のように記載し、「急成長中」のような表現は避けます。

冒頭の一文を裏付ける確かな根拠がある場合に限り、text_gate = ok とします。それ以外の場合は、理由を添えて review とします。hook_source は必須です。これがない行は送信しません。

件数の基準

• シグナル主導型のキャンペーンには、読み取れる統計情報を得るために300行以上が必要です。
• データポイント主導型のキャンペーンには、500行以上が必要です。

これを下回る場合は、その旨を報告します。キャンペーンを埋められないデータベースは、きれいに整形したファイルの陰に隠すものではなく、データベースに関する発見事項です。

すでに対処済みの落とし穴

検出時の落とし穴（採用ページ、集約サイト、古い求人情報、逆の意味を持つ /partners ページ）は、それを処理する signal-research の担当です。このスキルで問題になるのは、データの扱いです。

• 形式が2種類あるテキスト形式の日付列では、max() や降順ソートをすると、何年も前の日付が返されることがあります。代わりに、文字列として最近の日付を指定して絞り込みます。
• テキスト形式で保存されたコスト列は、比較する前に数値に変換します。変換しないと、クエリは何も返さずに終わることがあります。
• プレースホルダーの日付（9999、3030）が、「due」／「end」／「final」列に含まれています。
• スクレイピング API に対して並列スレッドを実行すると、DNS エラーが発生します。バックオフを入れて再試行し、ジョブを再起動するのではなく、実行中のジョブを実行 ID で再開します。
• サイトごとのページ上限がないクローラーは、大規模サイト1つに予算を使い切ってしまいます。上限を設けないのではなく、ドメインをバッチに分けます。
• 同じ数値を示す2つの情報源（ページ数と明記された範囲）は、別々の列に保持します。統合すると、検証済みの数値と推定値を見分けられなくなります。

このスキルで行わないこと

シーケンスを作成すること・何かを送信すること・人をスコアリングすること（アカウント単位で処理します）・アカウントが重要そうだからという理由でシグナルを作り出すこと・失敗した行を削除すること