niche-signal-discovery

ニッチなシグナルの発見

クイックスタート

npm install -g deepline
# Fallback for secure sandboxes: mkdir -p "$HOME/.local" && npm config set prefix "$HOME/.local" && export PATH="$HOME/.local/bin:$PATH" && npm install -g deepline --registry https://code.deepline.com/api/v2/npm/
deepline auth register --wait auto
deepline auth wait --timeout 120 # completes Cowork/browser approval; no-op if already connected
deepline auth status
deepline -h

顧客の意思決定を裏付ける証拠を見つけます。スコアリングには、承認済みのルール、または個別に評価済みのモデルを使用してください。フレーズの一致や出現率の比率だけでは、スコアリングの重み付けは行えません。

タスク	参照先
フレーズや購買者の言葉遣いを見つける	キーワードカタログ、購買者の言葉遣いに関する調査
スコアを作成または監査する	スコアリングの提供
ルールをテストする、または結果を評価する	テストと評価
成果物に基づくスコアカードを作成する	スコアカード作成パターン
異議のある特徴やルーティングをデバッグする	スコアリングの診断
テクノロジーを検証する	テクノロジーの証拠
人員配置や需要を見積もる	キャパシティの証拠

収集を始める前に deepline-gtm を、作成を始める前に deepline-plays を読んでください。ワークスペース、現在のプロバイダースキーマ、料金を確認します。1〜2行を対象にパイロットを実施し、生成された出力が品質ゲートを通過してから、承認済みの予算内で規模を拡大してください。エクスポートと領収書は、永続的なプロジェクトディレクトリに保管します。スコアを再計算する際は、収集済みの証拠を再利用してください。

ワークフロー

1. プロダクト、判定日、予測期間、対象集団、分析単位、求められる出力を定義します。有料でデータを収集する前に、実行可能なモデルと、同等性評価のための独立した期待スコア、または予測評価のための過去のエビデンスと未使用のラベルを特定します。前提条件が不足している場合、そのテストは保留のままにします。承認された調査は引き続き実施できます。適合度、エンゲージメント、対応能力、カバレッジは分けて扱います。要求された次元のみを使用します：account_fit、account_engagement、lead_fit、lead_engagement。統合された優先順位付けポリシーでは、各構成要素を維持します。
2. ID、親グループ、相反する結果を解決します。特徴量を選択する前に、時系列と親グループに基づいて探索用データと検証用データを分割します。要求された対象集団全体を維持します。オープンなアカウントや無作為に選んだ代替候補の結果は不明であり、類似企業は成約ではありません。新規獲得、更新、拡大を分けて扱います。
3. 関連する公開情報源を幅広く調べ、ワークフロー、課題、役割、システム、反例を調査します。確認された買い手の表現と情報源の URL をたどります。ラベルを使わずに探索用ドキュメントを分析した後、根拠と照らし合わせて概念と別名を確認します。まれな候補や結論の出ない候補も残します。レポートの文章や結果の要約はコーパスから除外します。
4. 品質ゲートでデータ収集を確認します。リフトを示す前に、情報源と結果別にカバレッジを報告します。カバレッジのみを使うモデルと比較し、両方の結果について観測データが十分にある特徴量を評価します。欠損値の補完や欠損フラグの除外でも、収集バイアスが符号化される場合があります。失敗、一部取得、空の結果を区別します。
5. 各特徴量が何を測定しているか確認します。レビューは通話ではなく、求人掲載は採用ではありません。また、ソフトウェアへの言及やポータルへのリンクは、インストールの証拠にはなりません。Google のレビュー、Yelp、トラフィックの推定値、サイトマップの件数は分けて扱います。代理指標を実際の測定値と照合して検証します。接触前の適合度評価から、AE のディスカバリー、商談、結果に関するフィールドを除外します。すべての入力が判定日時点で利用可能だったことを示す証拠を求めます。現在のエンリッチメントでは、過去の予測を検証できません。
6. 検証前に、抽出ルール、別名、モデル、参照アーティファクトを固定します。特徴選択、欠損値補完、チューニングはトレーニング用フォールド内で行います。スコアリングの落とし穴とシグナルの解釈に従います。試したすべてのモデルと、失敗した比較を記録します。ホールドアウトを再利用してルールを改良すると、そのホールドアウトは消費されます。
7. スコアリングでは、ID を解決して行をエンリッチし、要求された出力を返す、検証済みの Play を納品します。スコアリングの納品に従い、テストと評価を完了します。既存の出力との同等性と、予測の有用性を個別に証明します。スコアを付けられない行は、理由とともに未スコアのままにします。ライブエンリッチメントの要件に対して、キャッシュ済みのリプレイを納品しても一部の納品にしかなりません。
8. レポートテンプレートを使い、ワークスペースごとに読みやすいレポートを 1 つ納品します。ターゲティングに関する調査結果、順位付けされたアカウント、スコアリングルール、実行可能な Play、評価結果をそのレポートにまとめ、完全な表と生のエビデンスは末尾でリンクします。裏付けられている状態を次のいずれかで明記します：research_only、replay_only、exploratory_end_to_end、validated_for_named_use_case。昇格には、既存のルールと単純なベースラインに対する未使用の評価、不確実性の推定値、明示されたビジネス受容基準が必要です。選択した成約やパーセンタイルの割り当てだけでは、有用性を立証できません。

入力とコマンド

CSV 列：domain,status,website,jobs。省略可能な列：account_id,parent_id,split,known_at,scored_at。ステータス：won|lost|lookalike|unlabeled。同じデータソースを保持しながら、繰り返し観測されたデータを統合します。明示的なコホートルールで競合するラベルを解決してください。重複するドメインをすべて破棄してはいけません。

新しい作業には、オプトインの *_v2.py ヘルパーを使用してください。バージョン指定のないスクリプトは、既存のインターフェースを維持します。バージョンを切り替える前に、利用側を明示的に更新してください。

python3 scripts/analyze_signals_v2.py --input accounts.csv --discover-phrases \
  --max-phrases 500 --min-phrase-accounts 2 --output candidates.json

python3 scripts/analyze_signals_v2.py --input accounts.csv \
  --keywords keywords.json --tools tools.json --job-roles roles.json \
  --partition discovery --evidence-limit 12 --output discovery.json

マイナーは、発見アカウントからの2～5語の n-gram を使用し、データソースとフレーズ長の多様性を確保します。ラベルと検証ドキュメントは無視します。否定を理解したり、同義語を生成したりすることはできません。一致、不一致、買い手／売り手の文脈、誤った企業に関するテキストを確認してください。ラベル付きの希少フレーズを抽出する場合は、--min-phrase-accounts 1 を使用してください。切り捨てが発生した場合は報告し、必要に応じて上限を引き上げてください。

設定では、カテゴリを文字列のリスト、または {"name":"concept","aliases":["phrase","explicit stem*"]} に対応付けます。文字列はフレーズ境界が完全一致する場合にマッチします。役割は職種名にマッチします。業務内容にはキーワードの概念を使用してください。

検証には --partition validation --manifest frozen.json が必要です。マニフェストには、タイムゾーン情報を含む frozen_at と、keywords,tools,job_roles の analyzer_sha256、config_sha256 ハッシュが含まれます。スコアリングの前に凍結してください。各行では known_at <= scored_at が必要で、known_at は含まれるすべてのソースが利用可能になった最新時刻を反映する必要があります。スクリプトではタイムスタンプの来歴を検証できません。接触前のスコアリングには、納品契約に定められた、より厳格なカットオフを使用してください。

V2 は signals[]、statistics、method、config_sha256、scoring_eligible:false を返します。その指標は勝率の上昇率ではなく、Jeffreys 補正済みの P(feature|won)/P(feature|lost) です。Wilson 信頼区間は有病率を示します。Fisher の p 値と BH／BY の q 値は、その実行で設定された検定を対象とします。これらはアカウントが独立していることを前提としており、親アカウントによるクラスタリング、選択バイアス、開示されていない反復実験は補正しません。検証パーティションでの実行も含め、出力は探索的なものです。

ソースアダプター

• ウェブサイト：{"data":{"results":[{"url":"...","title":"...","text":"..."}]}}、pages、テキスト／Markdown の直接レコード、および既知の toolResponse.rawV2/raw ラッパー。
• 求人：{"result":{"listings":[{"title":"...","description":"...","url":"..."}]}}、jobs[].job_details、job_listings、JSON:API の data[].attributes。
• ソース ID と日付を保持してください。新しい形式を追加するたびに、フィクスチャとアダプターを追加してください。未対応または不正なペイロードは失敗します。
• 求人配列が空の場合、そのクエリで返されたレコードがないことを意味します。フィルターと上限は保持してください。ウェブサイトのスクレイピング結果が空の場合、網羅状況は不明です。どちらの場合も、人員配置、現在の求人、または事業特性が存在しないことの証明にはなりません。
• 名前付きの website/jobs ヘッダーは自動検出されます。従来の位置指定列には、明示的なインデックスが必要です。重複したヘッダー、無効なラベル、解決されていない混合結果はエラーになります。

検証

受け入れ基準については、テストと評価に従ってください。実行可能な評価スイートは、このスキルの変更とは別に提供されます。実装のリプレイ、ライブエンリッチメント、予測検証を区別し、前提条件が不足している場合は報告してください。

顧客のルール、事例、証憑は公開済みスキルの外に保管してください。実証済みのシグナルは仮説として扱ってください。任意の連絡先情報には、現行の GTM ワークフローと重複排除／見込み客開拓のガイダンスを使用してください。ローカルの連絡先ヘルパーは候補リストをエクスポートするだけです。LinkedIn のスラッグから名前を推測したり、ドメインの一致をメールアドレスの確認とみなしたりしないでください。