performance-analyzer

パフォーマンス分析

インフルエンサーキャンペーンの表面的な指標にとどまらず、成果を目標・ベンチマークと比較して評価し、プラットフォーム・クリエイター・コンテンツを順位付けし、エンゲージメントの質とセンチメントを読み取り、コンバージョンをアトリビューションし、学びを順位付けしてまとめます。

分野横断（有料広告）： このツールは、チャネル横断の有料広告スコアカード／異常検出の視点としても機能します。アカウント全体の指標を目標・ベンチマークと比較して集計し、その結果を ad-test-designer（何をテストするか）と paid-measurement-loop（何を振り返るか）に活用できます。有料広告の実行結果は memory/ad/performance-analyzer/ に保存してください。

クイックスタート

Analyze performance of [campaign name] influencer campaign

1つのキャンペーン内でクリエイターを比較します。

Compare performance of these influencers from [campaign]: @handle1, @handle2, @handle3

スキルの契約

• 読み取るもの：キャンペーン名と期間、プラットフォーム標準の分析データ（リーチ、ビュー、エンゲージメント）、インフルエンサーが提供したレポートやスクリーンショット、ウェブサイト／GAのトラフィックおよびコンバージョンデータ、売上およびプロモーションコードの利用データ、目標値、ベンチマーク、提供されている場合は事前登録済みの判定ルール／結果確認期間、任意の簡易キャンペーントラッカーとその evidence_refs、および roi-calculator ですでに算出されたROI／ROASの成果物。明示的な上流の不透明な creator_ref または検証済みクリエイターレジストリの集約IDを再利用します。生のハンドル名／名前／URL／プロバイダーIDは一時的な検索入力に限り、保存されるIDにはなりません。クリエイターごとのベースラインは、認可された成果物または検証済みレジストリのリンクによって該当する参照が解決される場合に限り、memory/creators/<aggregate-id>.md から取得します。生のロケーターからパスを導出してはなりません。
• 書き込むもの：デフォルトでは、パフォーマンス分析をインラインで返します。現在のフォークされていないトラッカー状態の成果物によって measured または closed が確認できる場合は、ステップ8の簡潔なキャンペーン振り返りカードを、該当するキャンペーン、クリエイター、測定契約、判定ルールに紐付けて含めます。分析とカードを一緒に memory/influencer/performance-analyzer/YYYY-MM-DD-<campaign>.md に保存するのは、WARMへの保存が明示的に正確に認可された場合に限ります。保存する表、見出し、エビデンス、引き継ぎには creator_ref と不透明なソース参照を使い、生のハンドル名、名前、プロフィールURL、メールアドレス、プロバイダーIDは使用しません。
• 昇格するもの：別途、明示的に正確な認可を受けた場合に限り、長期的に有効な、エビデンスに裏付けられたキャンペーン事実（検証済みの指標結果、および説明的な形式／プラットフォームとの関連性）を memory/hot-cache.md に昇格します。ROI／ROASの値は、常に対応する正確な roi-calculator の成果物に紐付けます。振り返りカードの定性的な renew | retest | retire | unknown 判定、その根拠、次の仮説、制限事項はWARMに留め、レジストリの事実として昇格することはありません。このスキルはクリエイターレジストリへの提案を行いません。クリエイター行がクローズされた後も、既存の境界により、担当ワークフローが別途認可を受けて提案できるのは、エビデンスに裏付けられた 実際の料金、署名済みの権利期間／有効期限、または 測定済みのパフォーマンスベースライン に限られます。それが正式な情報になるかどうかを決めるのは、creator-registry だけです。
• 完了条件：
  • 中核指標を、ソース日付と互換性のある目標値／ベンチマークと比較します。文脈が欠けている、または互換性がない場合は Unknown／NOT_SCORED とし、根拠のない /10 スコアや形容詞による判定を作りません。
  • クリエイター／プラットフォーム／コンテンツの順位付けは、指標、互換性のある期間／基準、完全な候補集合、事前登録済みの判定ルールが明示されている場合に限って行います。説明的な関連性と因果関係の仮説は、明確に分けて示します。
  • コンバージョンでは、カウント対象の区分が重複排除され、相互排他的である単一の明示的なアトリビューションモデルを使用します。重複するプロモーション／UTM／直接流入の観測値は照合エビデンスとして扱い、モデル化された影響はカウント合計に含めず、推定値として扱います。
  • 現在の measured または closed 状態が検証済みの場合、次のサイクルについて求められた各判定に、キャンペーン／クリエイター／状態／測定／判定ルールの参照、エビデンスに裏付けられた根拠、evidence_refs、次回キャンペーンの仮説、未解決の制限事項を含む、対象範囲に紐付いたキャンペーン振り返りカードを付けます。判定に十分なエビデンスがない場合は unknown とし、状態が欠落している、またはフォークされている場合はカードを作成しません。
• 主な次のスキル：roi-calculator — 測定済みのパフォーマンスを金額ベースのリターンに変換します。

引き継ぎの概要

skill-contract.md §Handoff Summary Format に記載された標準形式で出力します。

データソース

このファミリーでは、リアルタイムの連携は不要です（Tier 1）。スキルは、プラットフォームのエクスポートデータ、インフルエンサーレポートのスクリーンショット、GA の数値、プロモコードの利用件数など、提供された入力のみで動作し、対応フィールドを分析します。入力が不足していても、部分的な記述的分析は妨げられません。ただし、入力に依存するスコア、判定、順位、因果関係の説明、アトリビューション合計、意思決定については、値を補完せずに Unknown／NOT_SCORED／NEEDS_INPUT となります。

コネクターによって作業を迅速化できる場合は、スキルが ~~ プレースホルダーで示します。

• ~~social platform analytics — 投稿ごとのネイティブなリーチ／エンゲージメント／動画指標。
• ~~web analytics — サイトのトラフィック、クリックスルー、サイト内コンバージョンのデータ。

測定済みの YouTube 投稿パフォーマンス（無料キー）：キャンペーンコンテンツが YouTube にある場合、python3 "${CLAUDE_PLUGIN_ROOT}/scripts/connectors/youtube.py" videos @creator --limit 20 を実行すると、キャンペーン期間中の動画ごとの実際の視聴回数／高評価数／コメント数を取得できます。クリエイターからのスクリーンショットのエクスポートを待たずに、プラットフォームの指標を測定済みの値として取得できます。どちらのラベルも正確に使い分けてください。API の数値は「測定済み」、クリエイター提供の数値は「ユーザー提供」であり、表示上の丸めやタイミングによって、両者が正当に食い違う場合があります。無料の YOUTUBE_API_KEY。詳細は scripts/connectors/README.md を参照してください。

• ~~ecommerce / sales platform — 売上、注文、AOV、プロモコードの利用件数。
• ~~influencer database — 比較用の過去のクリエイターベンチマーク。

実行にプレースホルダーは不要です。カテゴリーごとの検証済みの無料／キー不要なデータ取得方法については、CONNECTORS.md を参照してください。

手順

以下の手順は、依存関係を考慮してひと続きで実行してください。各入力テンプレートは references/analysis-templates.md にあります。情報を受け取ったら Step 2 のシェルを作成します。ただし、Step 2 の Conversions、Revenue、またはそれらに依存する率／コストを入力または公開する前に、Step 7 を実行してください。これらのフィールドには Step 7 で照合した集計値を記載する必要があります。そうでない場合は Unknown/NEEDS_INPUT のままにしてください。

1. パフォーマンスデータの収集 — キャンペーン／期間／インフルエンサー／プラットフォームと、利用可能なソース（ネイティブ分析、インフルエンサーのレポート、ウェブ分析、売上、プロモコード）を記録します。テンプレート：ステップ 1。
2. 主要指標の分析 — リーチ、インプレッション、エンゲージメント、ER、動画再生数、クリック数、プロモコード利用数、コンバージョン、売上を、互換性のあるソース日付付きの目標／ベンチマークと比較します。フィールドごとの比較状態を出力し、集計スコアや形容詞による評価を作り出さないでください。テンプレート：ステップ 2。
3. プラットフォーム別の分析 — 互換性のあるリーチ／ER／クリック／コンバージョン／CPA の期間でプラットフォームを比較し、観察された違いを示します。説明は、設計された比較によって裏付けられる場合を除き、別途「仮説」と明記してください。テンプレート：ステップ 3。
4. クリエイター別の分析 — 不透明な creator_ref を使用し、宣言したルールの下で比較可能な行のみを順位付けします。ROI/ROAS は、引用元が示された roi-calculator の成果物からのみ取得し、ここでは計算しないでください。また、観察されたコンテンツの構成要素と因果関係に関する仮説を分けてください。継続／再テスト／終了の判断は、Retro の判断ゲートを通じてのみ行います。テンプレート：ステップ 4。
5. コンテンツパフォーマンスの分析 — 互換性のある露出基準とアトリビューション基準の下で、形式／テーマを比較します。観察された関連性の高低を示し、提供された設計が測定プロトコルを満たす場合に限り、フック／メッセージ／ビジュアルを因果的または「勝ちパターン」として説明してください。テンプレート：ステップ 5。
6. エンゲージメントの質の分析 — エンゲージメントを種類／意図ごとに分類し、根拠のあるコメント感情分析を行い、購入意向のシグナルを明らかにします。型付きの観察結果または Unknown を使用し、提供された評価基準、入力、計算がない場合は /10 の品質スコアを出力しないでください。テンプレート：ステップ 6。
7. コンバージョンとアトリビューションの分析 — 観察されたファネルを図示し、宣言済みのアトリビューションモデルを 1 つ使用します。イベントを重複排除して相互に排他的な計上バケットに分類し、プロモ／UTM／直接流入の重複は照合の根拠として保持し、推定影響は計上合計の外側で報告します。テンプレート：ステップ 7。
8. インサイトと推奨事項の作成 — 根拠に裏付けられた観察事項を 3～5 件、別途明記した仮説、範囲を限定した次のテストを作成します。クリエイターに関する判断が求められている場合は、検証済みの現行かつフォークされていないトラッカー状態の成果物により、該当するキャンペーン／クリエイターが measured または closed であり、対応する測定契約と判断ルールの参照情報が提供されていることが証明される場合に限り、クリエイターごとに簡潔な Campaign Retro Card を 1 枚追加します。ステージ文字列だけでは該当しません。renew | retest | retire | unknown のみを使用します。テンプレート：ステップ 8。

クリエイター／形式／プラットフォームを実際の勝者と呼ぶ前に、measurement-protocol.md にある比較可能性、スコープの完全性、事前登録ルール、有意性の基準を満たしてください。満たせない場合は Keep-testing または NOT_RANKED とします。構造化スコアが必要な場合は、star-benchmark.md に基づき、次元ごとに STAR 分析（Suitability／Trust／Appeal／Return の各次元の評価）を適用し、財務入力は Return（R）の計算のため roi-calculator に渡します。このスキルは入力を提供しますが、ROI/ROAS または SQS を計算しません（SQS は creator-content-auditor のゲートが計算します）。

Retro Card では、比較可能な測定済みのエビデンスが重大な未解決の制約なしに事前登録済みの判断ルールを満たす場合に限り renew を使用します。妥当性はあるものの結論が出ていない、または修正可能なテストには retest を使用し、測定済みのエビデンスまたは文書化された厳格な制約が宣言済みの停止ルールを満たす場合に限り retire を使用します。それ以外は unknown を使用します。この運用上の判断は STAR の次元、SQS、または creator-content-auditor の判定ではありません。これらを模倣したり、引き継いだりしないでください。 承認された WARM 保存の後、保存された分析/カード参照を該当するトラッカーの行の evidence_refs に追加するために、campaign-planner へのハンドオフを提案してください。トラッカーの編集には独自の明示的な承認が必要であり、カードもこのスキルも stage を進めません。また、カードの証拠参照と仮説を伴う明示的な次サイクルのハンドオフとして fit-scorer を提案してください。自動的に呼び出さないでください。また、Retro の判断を STAR/SQS の評決に変換しないでください。

例

ユーザー: 「10 人のクリエイター向けの、日付付きの夏向けスキンケアのエクスポートを分析してください。不透明なクリエイター参照、以下の指標/目標テーブル、クリエイター別およびプラットフォーム別の結果、1 つの重複排除されたアトリビューションモデル、完了した有意性の読み取りが含まれています。ROI は roi-calculator の成果物 roi-ref-01 から取得します。」

出力 (抜粋 — 完全版は references/analysis-templates.md にあります):

# Summer Skincare Campaign Performance Analysis — illustrative export-backed read

| Metric | Result | Target | Status |
|--------|--------|--------|--------|
| Total Reach | 2.4M | 2M | ✅ +20% |
| Engagement Rate | 4.2% | 3.5% | ✅ +20% |
| Conversions | 1,847 | 2,000 | ⚠️ -8% |
| Revenue | $142,500 | $150,000 | ⚠️ -5% |
| ROAS (from `roi-ref-01`) | 2.8:1 | 3:1 | ⚠️ -7% |

**Top 3**: the three `creator_ref` rows that clear the declared ranking and significance rule, using only comparable metrics in the export.
**Key learning**: report the export-backed TikTok/Instagram delta only if the comparison windows and attribution bases match; otherwise mark it Keep-testing.
**Recommendation**: renew/drop and reallocation calls remain conditional on the predeclared decision rule rather than invented from the campaign count alone.

参考資料

• references/analysis-templates.md — 8 つの記入式ステップテンプレートと、完全な実例。
• skill-contract.md — 共有コントラクトとハンドオフ形式。
• state-model.md — メモリ階層と保存パスの規約。
• CONNECTORS.md — コネクターカテゴリごとの、検証済みの無料/キー不要データレシピ。
• measurement-protocol.md — 事前登録された読み戻しウィンドウ、アウトカム単位、アルファ、実用的効果の境界、多重性/逐次方針、ガードレール、意思決定の責任者。統計的フラグと実用的フラグを別々に報告してください。決定論的な Calculated 証拠には experiment.py を使用し、普遍的な p 値/リフトのルールで代用したり、ビジネス上のアクションをヘルパーに帰属させたりしないでください。
• references/star-benchmark.md の STAR ベンチマーク — 構造化されたスコアが必要な場合のスコアリングアーキテクチャ。
• 姉妹スキル: roi-calculator](../roi-calculator/SKILL.md)、report-generator、fit-scorer、campaign-planner。

次に最適なスキル

第一候補: roi-calculator — 測定されたパフォーマンスを、ドル単位の ROI、結果あたりのコスト、回収計算に変換します。

代替候補 (同じ Report ファミリー):

• report-generator — 分析を正式なステークホルダー向けレポートにまとめます。
• fit-scorer — 実績が証明されたパフォーマーを、次のラウンドのクリエイタースコアリングにフィードバックします。

終了に関する注記: 訪問済みセットを維持してください。セッション中にすでにスキルが呼び出されている場合は、再実行せずに停止し、チェーン完了を報告してください。チェーンは最大深度 3 ホップに制限してください。その後に結果が結論不能である場合は、継続するのではなく、未解決のループをユーザーに提示してください。