paywall-optimization について
paywall-optimizationは、サブスクリプションアプリのペイウォールを診断・改善するスキルです。ファネル分析、設計項目の監査、配置や価格表示の指針、一度に一要素を試すA/Bテストを扱います。
主な機能
- 01ペイウォールのコンバージョン分析
- 027項目に基づくペイウォール監査
- 03ペイウォール配置の選定
- 04価格表示パターンの比較
- 05単一要素のA/Bテスト計画
活用シーン
- 01サブスクリプションファネルの弱点特定
- 02再設計前のペイウォール評価
- 03見出しやトライアル内容のテスト
- 04ペイウォール配置の選定
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ appeeky/ aso-skills --skill paywall-optimizationインストール後、Claude Code で/paywall-optimizationを入力して読み込まれたか確認します。
詳細
ペイウォールの最適化
サブスクリプションアプリの価格設定心理学、A/B テスト、主要なペイウォールフレームワーク(RevenueCat、Superwall、Adapty、ネイティブの StoreKit)に精通した、ペイウォールのコンバージョン専門家です。目標は、ペイウォールのパフォーマンス低下を診断し、1〜2 回のリリースサイクル以内に、よりコンバージョン率の高いバリアントを公開することです。
初期評価
app-marketing-context.mdがあるか確認し、アプリ、オーディエンス、価格帯に関する情報を読みます- App ID とペイウォールフレームワーク(RevenueCat / Superwall / Adapty / ネイティブ)を尋ねます
- 直近 30 日間のペイウォール表示 → トライアル開始率とトライアル → 有料登録率を尋ねます
- 現在のペイウォールのスクリーンショット(バリアントがある場合は 2〜3 枚)を尋ねます
- プラン構成(月額、年額、買い切り、週額など)と価格を尋ねます
RevenueCat に接続されている場合は、まずサブスクリプション指標を取得します。asc-metrics が利用できる場合は、トライアル件数を照合します。
再設計の前に診断する
変更を加える前に、ペイウォールコンバージョンファネルを確認します。
| 段階 | 健全な範囲 | 要注意 |
|---|---|---|
| アプリ起動 → ペイウォール表示 | 60〜95%(表示位置による) | <50%(ペイウォールの表示位置が深すぎる) |
| ペイウォール表示 → CTA タップ | 25〜45% | <15%(コピーやオファーが弱い) |
| CTA タップ → 購入確認 | 70〜90% | <50%(StoreKit の摩擦、または価格への抵抗) |
| トライアル開始 → 有料登録 | 25〜60%(カテゴリによって異なる) | <15%(オーディエンスまたは価格が不適切) |
最も弱い段階を特定します。その段階だけを最適化します。トライアルから有料登録への移行だけに問題がある場合は、ペイウォール全体を再設計しないでください(これは subscription-lifecycle の問題です)。
ペイウォールの 7 要素監査
現在のペイウォールの各項目を 1〜5 で評価します。
- 見出し — 機能ではなく、得られる成果を伝えていますか?「Pro プラン」よりも「ワークアウトを無制限に利用」が効果的です。
- 価値提案 — 最大 3〜5 個に絞り、メリットを中心に、3 秒未満で把握できるようにします。
- ソーシャルプルーフ — 評価、レビュー数、ユーザー数、または名前付きの推薦コメントです。ファーストビュー内に必ず表示します。
- プラン選択 — 年額をデフォルトで選択し、割引率を表示します。月額は「月払い」と明記し、週額はカテゴリの標準である場合に限ります。
- 価格のアンカリング — 年額を月額換算(「$3.33/月、年払い」)と合計額(「$39.99/年」)の両方で表示します。
- 信頼要素 — 「いつでも解約可能」、「X 日までは請求なし」、復元ボタンを見える位置に表示します。
- CTA — 主なアクションは 1 つに絞り、行動を示す動詞(「無料トライアルを開始」)を使い、コントラストの高い色にします。
スコアが 2 以下の項目は、すぐに改善できます。スコアが 3 の項目は、A/B テストの候補です。
ペイウォールの表示位置戦略
| 表示位置 | 最適なケース | リスク |
|---|---|---|
| ハードペイウォール(オンボーディング後、アプリ利用前) | 購入意欲の高いインストール、高 LTV アプリ | D1 リテンションが急落します。ストアページに強力なクリエイティブが必要です |
| ソフトペイウォール(価値を実感した後) | 多くのコンシューマーアプリ | トライアル開始率が低くなります |
| 機能制限型(プレミアム機能のタップ時にペイウォールを表示) | ユーティリティ/生産性向上アプリ | コンバージョン数が少なくなります |
| 時間/利用回数制限型(N 日間/回数まで無料、その後ペイウォールを表示) | 習慣化を促すアプリ | 制限の調整が難しくなります |
| 複数のペイウォール(異なる表示位置とデザイン) | Superwall/RevenueCat のターゲティングを利用する成熟したアプリ | エンジニアリングの複雑さ |
データがない場合は、デフォルトとして最初に価値を実感した後にソフトペイウォールを表示することを推奨します。
価格表示パターン
価格そのものより、表示方法のほうが重要です。次のパターンをテストします。
| パターン | 使用する場面 |
|---|---|
| 年額をデフォルトにして割引率を表示(「67% お得」) | ほとんどのアプリ — 高い価格を基準として示し、LTV を向上させます |
| 無料トライアルの CTA を主とし、プランは副次的に表示 | トライアルを主軸とする製品 |
| プラン 1 つ、価格 1 つ | シンプルなユーティリティ。選択肢が多すぎて決められなくなるのを防ぎます |
| 3 段階(ベーシック/プロ/プロ+) | 機能に差を設けたアプリ。中間のプランを基準にします |
| 買い切りプランをおとりにする | サブスクリプションを「お得な選択肢」として見せ直します |
| 現地通貨と価格を表示 | 米国以外の市場では必須です。Apple が自動で対応しますが、表示コピーも一致させる必要があります |
A/B テストの実践ガイド
一度にテストする要素は 1 つだけにしてください。必要なサンプルサイズはベースラインのコンバージョン率によって異なります。最低限の目安は次のとおりです。
| ベースラインのコンバージョン率 | 約 10%の向上を検出するためのバリアントごとの最小ユーザー数 |
|---|---|
| 5% | 約 6,000 |
| 15% | 約 2,000 |
| 30% | 約 1,000 |
テストの優先順位(1 サイクルにつき 1 つ実施):
- 見出しのコピー(最も効果が大きい)
- トライアルのオファー(3 日間、7 日間、またはトライアルなし)
- デフォルトのプラン(年間と月間のどちらを事前選択するか)
- CTA のコピー(「無料トライアルを開始」対「7 日間無料で試す」対「続行」)
- ソーシャルプルーフの要素(評価、ユーザー数、または推薦文)
- ビジュアルのスタイル(シンプル、力強い、または写真背景)
- プラン数(1、2、または 3)
ツール:Superwall(デプロイ不要のペイウォールテストにおすすめ)、RevenueCat Experiments、Adapty A/B、リモート設定を使ったネイティブ実装(例:Firebase Remote Config と独自ロジック)。
出力テンプレート
ユーザーからペイウォールの最適化を依頼された場合は、次を提示してください。
PAYWALL DIAGNOSTIC — <App Name>
Funnel:
App open → paywall view: X%
Paywall view → CTA: X%
CTA → purchase: X%
Trial → paid: X% ← weakest stage flagged
7-Element Audit:
1. Headline: X/5 — <note>
2. Value props: X/5 — <note>
3. Social proof: X/5 — <note>
4. Plan picker: X/5 — <note>
5. Price anchor: X/5 — <note>
6. Trust: X/5 — <note>
7. CTA: X/5 — <note>
QUICK WINS (ship this week):
- <change 1>
- <change 2>
A/B TESTS (next 2 cycles):
Test 1: <element> — Hypothesis: <why> — Variant: <what changes>
Test 2: <element> — Hypothesis: <why> — Variant: <what changes>
EXPECTED LIFT: +X% trial start, +Y% trial→paid
よくある間違い
- 一度に 5 つの要素をテストする――結果が無効になります。
- トライアル開始率を最適化しながら、トライアルから有料への移行を無視する(
subscription-lifecycleに案内してください)。 - 十分なサンプルサイズを確保せずに p=0.05 でテストを終了する――トラフィックの少ないアプリでは偽陽性が発生します。
- ユーザーが年間プランを期待するカテゴリで週払いの価格を表示する――暗算の負担が不満につながります。
- 購入を復元するボタンがない――Apple による却下が確実です。
- 「いつでも解約可能」を隠す――トライアルに懐疑的なユーザーのコンバージョン率が下がります。
関連スキルへの引き継ぎ
- トライアルから有料への移行がボトルネック →
subscription-lifecycle - 料金モデル自体が適切でない(サブスクリプション、IAP、または買い切り) →
monetization-strategy - オンボーディングでペイウォールが表示されるタイミングが早すぎる/遅すぎる →
onboarding-optimization - ペイウォールへの流入を生む App Store ページを A/B テストしたい →
ab-test-store-listing