gtm-workflow-enrich-network

GTM ワークフローでのネットワークのエンリッチメント

トリガー

コネクションまたはフォロワーのエンリッチメントワークフローを作成または変更する際に、このレシピを使用します。既存のワークフローの実行、スケジュール、デプロイ、アップグレード、削除は、直接 gtm-workflow に進みます。

スコープ

この Artifact SOP は、ネットワークのエンリッチメントワークフローを定めます。必須の依存関係である gtm-workflow が、生成コード、データベーステーブル、実行、スケジュール、デプロイ、共通ガードレールを管理します。構築する前にお読みください。このスキルはレシピを提供するものであり、別のランタイムや承認プロセスを導入するものではありません。

入力

ユーザーが提供するコネクションまたはフォロワーのソース、人物と企業のエンリッチメント機能、および gtm-workflow で必要となるワークスペースと実行設定です。データと実行の仕様については、レシピに従ってください。

役割

ユーザーはソースとエンリッチメントへのアクセスを提供または選択します。エージェントは利用可能な機能を確認し、このレシピを適用して gtm-workflow を通じて構築します。この依存関係が、会話ですでに与えられた承認も含め、権限、コスト、実行に関する判断を管理します。

手順

1. ソースが不明な場合は、**「コネクションまたはフォロワーは、どこから取得しますか？」**と尋ねます。CSV、既存のデータベース／テーブル、またはリストを取得するサービスを提示してください。ソースが提供済みであれば、この質問への回答は得られています。CSV が選択されているもののファイルが添付されていない場合は、次のように直接尋ねます。「コネクションまたはフォロワーの CSV をアップロードしてください。可能であれば、LinkedIn プロフィール URL、メールアドレス、またはプロバイダー ID を含めてください。名前だけでは特定できない場合があります。」回答やアップロードボタンは使わず、通常の添付ファイルを待ちます。エンリッチメントを選ぶ前に、識別子とアクセス権を確認します。リストを取得する場合、情報が不足しているときに限り、誰のネットワークか、どのプラットフォームか、コネクションかフォロワーかを確認します。
2. 希望が示されていない場合は、**「人物と企業のエンリッチメントには、どのサービスを使いますか？」**と尋ねます。既存の接続済みサービス、ユーザーが指定したサービス、または適切なサービスの検索支援を提示してください。直接プロバイダーとアグリゲーターはどちらも有効です。ソース取得、人物のエンリッチメント、企業のエンリッチメントには、それぞれ異なるサービスを使用できます。既定の質問、例、依存関係の一覧、生成されるスキャフォールドに、特定のベンダーを決して含めないでください。具体的なプロバイダー名は、ユーザーが指定した場合、または実際の候補が調査によって確認された場合に限り提示します。
3. 選択したサービスの最新ドキュメント、受け付ける識別子、現在の勤務先に関するフィールド、企業識別子、料金、ページネーション、認証を確認します。構築時にエンドポイントを特定し、実行時には処理の順序が明らかな場合、通常のプロバイダー呼び出し手順を使用します。アグリゲーターは、ドキュメントに記載された独自の API と認証情報を使用します。会話エージェントで接続済みツールが使えるからといって、ワークフロープロジェクトに必要な認証情報があるとは限りません。
4. 解決した動作を、ソース、人物と企業のエンリッチメント、確認済みのすべての現職、共有の People と Companies、実行上限を含む一文で説明します。結果を左右する不足事項のみ、一度に一つずつ質問してください。エンリッチメントだけの場合、ICP やペルソナについては質問しないでください。作成には gtm-workflow を使用し、実行に関する判断は通常どおり同ワークフローに委ねます。
5. レシピを構築します。gtm-workflow のリンクされたデータビューアーを使用し、永続化された入力、エンリッチメント済みの人物、重複を排除した企業のエンリッチメント、各人物の職歴、両方向のブラウジングを実装します。返されたすべての役職を保持します。企業のエンリッチメントに使用するのは、現職であることが確認された役職のみです。
6. 有料の実行前に、gtm-workflow を通じて、ソース → 人物 → 企業の全体のコストと認証情報を確認します。1 人のテストには、その人物について選択された現職の勤務先を含め、共通の予算上限を適用します。受け入れケースで検証し、人物と企業それぞれの結果と合計支出を報告します。

出力

ワークスペース全体で共有される People テーブルと Companies テーブルを使用した保存済みワークフロー、図、実行履歴、およびそのワークフローの人物とその人物の現在の会社に限定した Data ビューです。取得された役職はすべて本人に紐づいたまま保持されます。保留中の会社と、雇用主を特定できていないケースは区別されます。

例外

• このスキルと、その依存関係である gtm-workspace とともに gtm-workflow をインストールする必要があります。見つからない場合は、不足しているスキル名とインストールコマンドを示してください：npx skills add eliasstravik/gtm-skills -s gtm-workflow -s gtm-workspace -y。グローバルにインストールする場合は -g を追加します。依存関係が整ってから再開してください。ここでその手順を再作成しないでください。
• 名前だけのリストを有料の一括エンリッチメントに使用する前に、本人確認のステップを設けるか、より適切な入力を用意する必要があります。名前だけで人物や会社を統合しないでください。
• ソースにアクセス可能なエクスポート機能も取得機能もない場合は、ユーザーにソースを選んでもらう必要があります。フォロワーのリクエストは、コネクションや別のオーディエンスへの置き換えを許可するものではありません。
• 雇用状況が不明な場合は、不明のまま保持します。見出しに表示される雇用主が1社のみのプロバイダーでは、複数の職歴をすべて扱うレシピを実行できません。その制限を説明し、対応可能な代替案を提示するか、カバー範囲を縮小することについてユーザーの明示的な承認を得てください。
• スキルやワークフローの構築は、有料リストの取得やエンリッチメントの開始を許可するものではありません。実行について既に明示的な許可がある場合は、gtm-workflow が再確認なしで処理します。

QC

• ソースの提供を受けた、またはソースを尋ねたことを確認します。プロバイダーについて中立的に質問し、人物向けサービスと会社向けサービスが異なる可能性を考慮します。
• gtm-workflow を読み、そのライフサイクルの管理を担わせます。ワークフローはスコアリング用のペルソナや ICP を必要としません。
• 取得された役職をすべて保持します。現在の会社が異なる場合も、共通の作業リストと予算を使用し、役職数の上限は設けません。
• 複数の人物に共通する会社は、チャンクをまたぐ場合や実行が重複する場合も含め、同じ鮮度期間内では1つのIDと1回の有料ルックアップで扱います。
• 会社のルックアップに失敗した場合、人物を再エンリッチメントせずに再開できます。更新に失敗した場合も、最後に成功したプロフィールと関係性を保持します。
• ワークフローが機能すると宣言する前に、両方向の参照、ソースからの再開可能性、コストの上限、および受け入れ条件を確認します。

参考資料

実行とデータについてはレシピ、ユーザー向けの例についてはインタラクション、検証については受け入れ条件を参照してください。必須の依存関係：gtm-workflow。ワークスペースとインタラクションのルールも含まれます。