mcpField
A
ads-audit

ads-audit

github.com/agricidanielマーケティング・グロース10.5k4.2k 回インストール2 週間前に更新
リポジトリ

ads-audit について

ads-auditは、指定したプラットフォームの有料広告を監査するスキルです。証拠を追跡できる所見やレポートを必要とするチーム向けに、スキーマ検証と決定論的なスコアリングを行い、データ不足や処理失敗も明示します。

主な機能

  1. 01バージョン管理されたJSON監査バンドル
  2. 02証拠の正規化と出典追跡
  3. 03プラットフォーム別ワーカーの並列実行
  4. 04スキーマ検証と決定論的スコアリング
  5. 05プラットフォーム横断の所見統合
  6. 06網羅率と不足データを含むレポート

活用シーン

  1. 01複数の広告プラットフォームの監査
  2. 02証拠不足やワーカー失敗の追跡
  3. 03根拠に基づく優先アクション計画の作成

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/agricidaniel/claude-ads --skill ads-audit

インストール後、Claude Code で/ads-auditを入力して読み込まれたか確認します。

詳細

有料広告監査

まずバージョン管理された JSON 監査バンドルを作成し、そのバンドルから人間向けの成果物を生成します。文章のみのワーカーレポートを集約したり、必須のワーカー、ソース、入力、またはコントロールが不足しているプラットフォームの網羅性を主張したりしないでください。

手順

  1. メインの ads 運用契約と思考フレームワークを読みます。
  2. ビジネスの背景、対象期間、通貨、タイムゾーン、リクエストされたプラットフォーム、スコープ、利用可能なデータ、プライバシー分類を含む実行マニフェストを作成します。
  3. エクスポート、スクリーンショット、手動入力の指標、または認証済みの読み取りをアカウントスナップショットに正規化します。ソースの系譜を保持し、不足しているフィールドを明示します。
  4. アクティブなプラットフォームを特定します。リクエストされたものの非アクティブ、またはデータがないプラットフォームについては、黙ってスキップせずに確認します。
  5. 選択した各プラットフォームの機能マニフェスト、コントロールレジストリ、日付付きソースエントリ、ベンチマーク、該当するポリシー資料を読み込みます。
  6. プラットフォームごとのワーカーとクロスプラットフォームのワーカーを並列で実行します。
  7. すべての結果を共通の所見スキーマに照らして検証します。一時的な障害は 1 回再試行し、それ以外の障害はすべて、復旧のヒントとともに記録します。
  8. 決定論的なスコアリングを実行します。プロンプト内でスコアを計算または修正しないでください。
  9. 計測、予算、クリエイティブ、ランディングページ、実験、ポリシー、規制上のリスクに関するシステム的な所見を統合します。
  10. 1 つの不可分な実行バンドルを書き込み、リクエストされたレポートを生成します。
  11. バンドルの完全性、引用、プライバシー、生成結果の整合性を確認します。

プラットフォームワーカー

選択したプラットフォームごとに専用のワーカーを使用します。

  • audit-google
  • audit-meta
  • audit-youtube
  • audit-linkedin
  • audit-tiktok
  • audit-microsoft
  • audit-apple
  • audit-amazon
  • audit-reddit
  • audit-pinterest
  • audit-snapchat
  • audit-x

入力が存在する場合に限り、クロスプラットフォームのワーカーを追加します。

  • トラッキングとアトリビューション。
  • クリエイティブとランディングページの品質。
  • 予算、配信ペース、財務的な実行可能性。
  • プラットフォームポリシー、プライバシー、規制。

必須のワーカー結果

プラットフォームまたはクロスプラットフォームの各ワーカーは、1 つのタスクにつき正規プラットフォームを 1 つ扱い、audit-worker-result v1 オブジェクトを正確に 1 つ返します。クロスプラットフォームの領域は scope に記載し、platform には引き続き、ワーカーが証拠を評価したプラットフォームを指定します。

{
  "schema_version": "1.0.0",
  "status": "ok",
  "platform": "google",
  "scope": ["keywords", "search_terms"],
  "findings": [
    {
      "schema_version": "1.0.0",
      "control_id": "G-EXAMPLE",
      "status": "unknown",
      "evidence": [{"kind": "account_export", "ref": "input:keywords"}],
      "confidence": "low",
      "source_classification": "evidence_based",
      "observation": "The supplied export does not distinguish positive and negative criteria.",
      "diagnosis": "Keyword inventory completeness cannot be established.",
      "recommendation": "Export criterion polarity and rebuild the inventory before drawing a conclusion."
    }
  ],
  "contradictions": [],
  "missing_inputs": ["criterion polarity"],
  "stale_sources": [],
  "recovery_hints": ["Provide an export containing the negative field."]
}

すべてのエンベロープフィールドは必須です。インストール済みの audit-worker-result v1 スキーマに照らして検証してください。所見には正規の Finding v1 フィールドを使用し、コントロールの重大度はレジストリに保持します。代替の result、severity、evidence_refs フィールド、null の推奨事項、文章のみのワーカーレポート、または追加のエンベロープフィールドは受け入れないでください。

完全性ルール

  • complete：リクエストされた必須ワーカーがすべて有効な結果を返し、スコア対象のすべてのプラットフォームで通常の証拠網羅率が満たされています。
  • provisional：必須ワーカーはすべて結果を返していますが、1 つ以上のプラットフォームで証拠網羅率が 60〜79％であるか、重要ではない証拠が古くなっています。
  • partial：必須のプラットフォームまたはクロスプラットフォームのワーカーが失敗したか、省略されています。
  • insufficient_evidence：リクエストされたプラットフォームの網羅率が 60％未満です。

機能の認知度をアカウントの健全性の代わりにしないでください。任意、ベータ、プレミアム、対象外、または利用不可の機能は、機会リストに含め、スコア対象外とします。

各任意機能または利用に制限のある機能について、まずアカウント、市場、目的、アクセスの適格性を確認します。利用できない、または対象外の場合は、適格性の判定結果を含め、健全性スコアに影響しない unscored_opportunity を記録します。ベータ機能を利用できないという理由だけで健全性を減点するリクエストは拒否してください。

必須ワーカーの失敗と重み付け

認証またはワーカーに失敗しても、独立して正常に処理できるプラットフォームの分析は停止しませんが、バンドル全体のステータスは partial になります。失敗したプラットフォーム、欠落しているエビデンス、復旧のヒントを記録し、そのプラットフォームのヘルススコアは付与しないでください。ポートフォリオの健全性からその重みを除外してください。ゼロを割り当てたり、古い過去の重みを保持したり、分母に含めたりしてはいけません。再正規化する重みは、正常にスコアリングされた比較可能なプラットフォーム間に限ります。妥当性を説明できる残りの重みが得られない場合は、重みを捏造せず、ポートフォリオの健全性を提示しないでください。

例：Amazon の認証を除き、全プラットフォームの監査に成功した場合は、他のプラットフォームの処理を続け、Amazon を失敗／データ欠落としてマークし、Amazon の重みを除外して、バンドルに partial のラベルを付けます。完了したと表現してはいけません。

統合の境界

最終バンドルでは、次の層を分けてください。

  1. アカウントデータによって直接裏付けられる観察結果。
  2. 観察結果から推測される診断と、その確信度。
  3. 担当者、優先度、工数、期待される効果、成功指標を含む推奨事項。
  4. 提案された変更。メインの変更ゲートを通過するまでは、下書きのままにします。

一律の一時停止、入札、予算、学習フェーズ、アトリビューション、機能採用のルールを指示しないでください。コンバージョンまでの遅延、サンプルサイズ、目的、利益率、成熟度、適格性、地域、ポリシーの状況を考慮してください。

出力

実行ディレクトリには、次のファイルが含まれます。

  • manifest.json
  • account-snapshot.json
  • audit.json
  • action-plan.json
  • report.md
  • オプションの report.html と report.pdf

レポートには、プラットフォームの健全性とエビデンスの網羅率、規制上のリスク、全体に共通する所見、矛盾、欠落データ、優先順位付けされたアクション、測定計画が含まれます。認証情報、顧客の生リスト、外部コンテンツに含まれる非公開の指示、宣伝用のフッター、裏付けのない完了の主張は含まれません。

コメント

Markdown 対応