mcpField
A
ads-test

ads-test

github.com/hainrixzマーケティング・グロース10261 回インストール3 日前に更新
リポジトリ

ads-test について

ads-testは、仮説の設計からサンプルサイズの推定、プラットフォーム別の設定、測定計画までを支援する広告A/Bテスト計画スキルです。Meta、Google、LinkedIn、TikTokで実験を設計するマーケター向けです。

主な機能

  1. 01テスト仮説の構造化
  2. 02サンプルサイズと期間の推定
  3. 03プラットフォーム別の設定案内
  4. 04成功基準と測定計画の定義
  5. 05テスト優先度とよくある問題の提示

活用シーン

  1. 01クリエイティブやオーディエンスの実験計画
  2. 02必要なトラフィックとテスト期間の推定
  3. 03広告テスト開始前の指標設定

インストール

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

$npx skills add https://github.com/hainrixz/claude-ads --skill ads-test

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

詳細

A/B テストの設計と実験計画

OpenClaudia/openclaudia-skills(ab-test-setup)から着想を得ています。

プロセス

  1. ユーザーが何をテストしたいのかを把握します(クリエイティブ、オーディエンス、入札、ランディングページ)
  2. 以下のフレームワークを使って、構造化された仮説を作成します
  3. 必要なサンプルサイズと推定所要期間を計算します
  4. プラットフォームごとに適したテスト設定を提案します
  5. 成功基準と測定計画を定義します

仮説のフレームワーク

すべてのテストは、構造化された仮説から始める必要があります。

IF we [change/action]
THEN [metric] will [increase/decrease] by [estimated %]
BECAUSE [reasoning based on data or insight]

Example:
IF we replace polished product shots with UGC creator videos
THEN Meta CTR will increase by 25-40%
BECAUSE Andromeda prioritizes diverse creative formats and UGC consistently outperforms polished in 2025-2026 benchmarks
仮説の品質チェックリスト
  • テスト対象の変数は1つ(変更点を切り分ける)
  • 指標を具体的に定義する(「パフォーマンス」ではなく)
  • 効果量を推定して明記する(サンプルサイズの計算に必要)
  • 期間を定義する
  • 開始前に成功・失敗の基準を明確にする

統計的有意性の計算ツール

Required Sample Size (per variant):

n = (Z_alpha + Z_beta)^2 × 2 × p × (1-p) / MDE^2

Where:
- Z_alpha = 1.96 (for 95% confidence)
- Z_beta = 0.84 (for 80% power)
- p = baseline conversion rate
- MDE = minimum detectable effect (relative %)

Simplified lookup:
ベースライン CVR5% MDE10% MDE20% MDE30% MDE
1%612,000153,00038,30017,000
2%302,40075,60018,9008,400
5%116,80029,2007,3003,200
10%55,20013,8003,4501,530
20%24,6006,1501,540680

各バリアントあたり、信頼度95%、検出力80%

テスト期間の推定ツール

Duration = Required Sample Size / Daily Traffic per Variant

Minimum duration: 7 days (capture weekly patterns)
Maximum recommended: 28 days (avoid seasonal drift)
Learning phase: Google 7-14 days, Meta 3-7 days, LinkedIn 7-14 days

Inputs needed:
- Daily impressions or clicks
- Number of variants (2 = A/B, 3+ = multivariate)
- Baseline conversion rate
- Minimum detectable effect desired
期間の簡易推定
1日のクリック数CVR 2%、MDE 20%CVR 5%、MDE 20%CVR 10%、MDE 20%
100189日73日35日
50038日15日7日
1,00019日7日4日*
5,0004日*2日*1日*

*サンプル数が十分な場合でも、最低7日間を推奨します

プラットフォームごとのテスト設定

Meta の実験
  • Ads Manager > Experiments タブを使用します(広告セットを手動で複製しないでください)
  • オーディエンスの自動分割により、重複を防げます
  • 対応するテストの種類:A/B(クリエイティブ、オーディエンス、配置)、ホールドアウト、ブランド調査
  • Meta の Incremental Attribution(2025年4月)は、実際の因果的影響を測定する AI 搭載のホールドアウトテストを提供します
  • 予算:バリアント間で均等に分割します。各バリアントあたり最低100ドル/日を推奨します
  • 期間:通常7~14日です。Meta が信頼度95%で自動的に勝者を判定します
Google の実験
  • Campaign Experiments(カスタム実験)または Ad Variations を使用します
  • 既存のキャンペーンから実験を作成し、実験の種類を選択します
  • トラフィックの分割:最速で結果を得るには50/50を推奨します
  • 対応内容:入札戦略、広告コピー、ランディングページ、オーディエンス
  • 指標:開始前に主要指標(コンバージョン、CPA、ROAS)を選択します
  • 期間:14~30日を推奨します。入札テストは最低2週間必要です
LinkedIn の A/B テスト
  • Sponsored Content の Campaign Manager に組み込まれています
  • 変更する変数を1つに絞って広告セットを複製します
  • ターゲティング:同じオーディエンスセグメントを指定し、自動ローテーションを利用します
  • 最低予算:各バリアントあたり50ドル/日
  • 主要指標:CTR(ベンチマーク:0.44%超)、CPL、リードフォーム CVR(ベンチマーク:13%)
  • 期間:14~21日(LinkedIn は1日のボリュームが少ないため、より長いテスト期間が必要です)
TikTok のスプリットテスト
  • TikTok Ads Manager > Create A/B Test から利用できます
  • テストの種類:ターゲティング、入札、クリエイティブ
  • オーディエンスを自動分割し、混入を防ぎます
  • 最低7日間、推奨14日間
  • 予算:広告グループあたり最低20ドル/日
  • クリエイティブのテスト:フック(最初の2~3秒)を主要な変数として切り分けます
  • 2025年以降、TikTok の強化されたスプリットテストでは、Smart+ を通じてモジュール式のテスト変数(ターゲティング、クリエイティブ、予算、配置)をサポートしています

テスト対象(優先順位順)

影響度が高い項目(最初にテスト)
  1. クリエイティブのコンセプト(単なる色の変更ではなく、異なるメッセージの切り口)
  2. フック/最初の3秒(Meta、TikTok、YouTube の動画冒頭)
  3. オファーの構成(価格、割引の種類、無料トライアルの期間)
  4. ランディングページ(見出し、CTA、フォームの長さ)
  5. 入札戦略(tCPA、tROAS、コンバージョン数の最大化)
中程度の影響
  1. オーディエンスターゲティング(インタレスト vs 類似オーディエンス vs ブロード)
  2. 広告フォーマット(静止画 vs 動画 vs カルーセル)
  3. CTA ボタン(詳細を見る vs 登録する vs 今すぐ購入)
  4. キャンペーン構成(CBO vs ABO、統合 vs セグメント化)
影響度が低い項目(最後にテスト)
  1. 広告のスケジュール設定(時間帯、曜日)
  2. デバイスターゲティング(モバイル vs デスクトップ)
  3. 軽微なコピーのバリエーション(コンセプトを変えずに単語を置き換える)

よくあるテストの失敗を避ける

  • 一度に多くの変数をテストする(明確な勝者を特定できない)
  • テストを早く終わらせすぎる(統計的有意性に達する前に終了する)
  • 通常とは異なる期間にテストする(休日、ローンチ、インシデント)
  • 長さの異なる期間を比較する
  • 学びを記録しない(組織的な知見を蓄積する)
  • 大きな変更が必要なときに小さな変更をテストする(最適化 vs イノベーション)
  • 自動化プラットフォームの学習フェーズを無視する

出力形式

## A/B Test Plan

### Hypothesis
IF [change]
THEN [metric] will [direction] by [amount]
BECAUSE [reasoning]

### Test Design
| Parameter | Value |
|-----------|-------|
| Platform | [platform] |
| Test Type | [A/B / Multivariate] |
| Variable | [what's being changed] |
| Control | [current state] |
| Variant | [proposed change] |
| Primary Metric | [KPI] |
| Traffic Split | [50/50 / other] |

### Sample Size & Duration
| Metric | Value |
|--------|-------|
| Baseline CVR | [X%] |
| MDE | [X%] |
| Required Sample | [N per variant] |
| Daily Traffic | [N clicks/day] |
| Est. Duration | [X days] |
| Min Duration | 7 days |

### Success Criteria
- Winner declared at 95% confidence
- [Primary metric] improvement of [X%]+ sustained over [Y] days
- No negative impact on [secondary metric]

### Setup Instructions
[Platform-specific step-by-step]

コメント