ads-test について
ads-testは、仮説の設計からサンプルサイズの推定、プラットフォーム別の設定、測定計画までを支援する広告A/Bテスト計画スキルです。Meta、Google、LinkedIn、TikTokで実験を設計するマーケター向けです。
主な機能
- 01テスト仮説の構造化
- 02サンプルサイズと期間の推定
- 03プラットフォーム別の設定案内
- 04成功基準と測定計画の定義
- 05テスト優先度とよくある問題の提示
活用シーン
- 01クリエイティブやオーディエンスの実験計画
- 02必要なトラフィックとテスト期間の推定
- 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)から着想を得ています。
プロセス
- ユーザーが何をテストしたいのかを把握します(クリエイティブ、オーディエンス、入札、ランディングページ)
- 以下のフレームワークを使って、構造化された仮説を作成します
- 必要なサンプルサイズと推定所要期間を計算します
- プラットフォームごとに適したテスト設定を提案します
- 成功基準と測定計画を定義します
仮説のフレームワーク
すべてのテストは、構造化された仮説から始める必要があります。
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:
| ベースライン CVR | 5% MDE | 10% MDE | 20% MDE | 30% MDE |
|---|---|---|---|---|
| 1% | 612,000 | 153,000 | 38,300 | 17,000 |
| 2% | 302,400 | 75,600 | 18,900 | 8,400 |
| 5% | 116,800 | 29,200 | 7,300 | 3,200 |
| 10% | 55,200 | 13,800 | 3,450 | 1,530 |
| 20% | 24,600 | 6,150 | 1,540 | 680 |
各バリアントあたり、信頼度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% |
|---|---|---|---|
| 100 | 189日 | 73日 | 35日 |
| 500 | 38日 | 15日 | 7日 |
| 1,000 | 19日 | 7日 | 4日* |
| 5,000 | 4日* | 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+ を通じてモジュール式のテスト変数(ターゲティング、クリエイティブ、予算、配置)をサポートしています
テスト対象(優先順位順)
影響度が高い項目(最初にテスト)
- クリエイティブのコンセプト(単なる色の変更ではなく、異なるメッセージの切り口)
- フック/最初の3秒(Meta、TikTok、YouTube の動画冒頭)
- オファーの構成(価格、割引の種類、無料トライアルの期間)
- ランディングページ(見出し、CTA、フォームの長さ)
- 入札戦略(tCPA、tROAS、コンバージョン数の最大化)
中程度の影響
- オーディエンスターゲティング(インタレスト vs 類似オーディエンス vs ブロード)
- 広告フォーマット(静止画 vs 動画 vs カルーセル)
- CTA ボタン(詳細を見る vs 登録する vs 今すぐ購入)
- キャンペーン構成(CBO vs ABO、統合 vs セグメント化)
影響度が低い項目(最後にテスト)
- 広告のスケジュール設定(時間帯、曜日)
- デバイスターゲティング(モバイル vs デスクトップ)
- 軽微なコピーのバリエーション(コンセプトを変えずに単語を置き換える)
よくあるテストの失敗を避ける
- 一度に多くの変数をテストする(明確な勝者を特定できない)
- テストを早く終わらせすぎる(統計的有意性に達する前に終了する)
- 通常とは異なる期間にテストする(休日、ローンチ、インシデント)
- 長さの異なる期間を比較する
- 学びを記録しない(組織的な知見を蓄積する)
- 大きな変更が必要なときに小さな変更をテストする(最適化 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]
コメント
Markdown 対応