次のような場合に使用: ユーザーがRevenueCat（売上管理プラットフォーム）の実験（A/Bテスト：2つのバージョンを比較する検証）の作成、準備、設定、またはその実験で提示する複数のバージョンや支払い画面の準備、実験の開始・一時停止・再開・終了をRevenueCat MCPの実験ツールを使って行いたいと依頼した場合
Use when the user asks to create, prepare, or set up a RevenueCat experiment (A/B test), to prepare its variant offerings or paywalls, or to start, pause, resume, or stop an experiment via the RevenueCat MCP experiment tools
RevenueCatの実験では、2～4種類のオファー（商品提供内容）を比較します。offering_aはコントロール（基準となる提供内容）で、offering_b～offering_dがトリートメント（試験対象の提供内容）です。実験に登録された顧客には、プロジェクト現在の提供内容の代わりに、割り当てられたバージョンの提供内容が配信されます。実験の設定とは、バージョンごとに1つの提供内容を準備してから、実験をドラフト状態で作成することです。
各ツールの正確なパラメータ（入力項目）についてはMCP ツールスキーマを参照してください。create-experimentスキーマには、利用可能な実験タイプと推奨される主要指標（測定方法）および補助指標も記載されています。
テスト対象の1つの側面以外はバージョン間で同じに保ちます。そうしないと、結果がどの変更によるものなのか特定できません。たとえば、低い定期購読価格の影響を測定する場合、両バージョンのペイウォール（購入画面）デザインとパッケージは同じにして、商品の価格だけを変えます。
コントロール。 コントロール版が「本番環境で現在実施されているもの」である場合、現在のオファーを（list-offeringsで確認できるis_current）offering_a_idとしてそのまま渡し、複製しないでください。コントロール自体が本番環境から変更される必要がある場合だけ複製してください。
トリートメント。 まずlist-offeringsで、トリートメントが配信すべき内容に合致するオファーが既に存在するかどうか確認し、複製する代わりにそれを再利用します。存在しない場合は、それに最も近いオファー（通常はコントロール）の複製から始めます。duplicate-offeringはパッケージ（および同じ既存商品を添付）をコピーし、ソースのオファーがペイウォールを持つ場合はそれを新しい未公開ドラフトとしてもコピーします。新しいオファーとそのpaywall_idが返されます。source_paywall_version: publishedを渡して、ドラフト編集の途中段階ではなく、本番環境で顧客が見るペイウォールをトリートメントがコピーするようにしてください。ソースペイウォールが一度も公開されていない場合このコマンドは失敗するため、その場合だけデフォルト（draft）を使用してください。その後、テスト対象の1つの変更を加えます：
ペイウォールの変更（デザイン、レイアウト、ボタン、価格表示など）：これはアプリがRevenueCat Paywallsを使用している必要があります。ペイウォールはオファーのプロパティとして使用できます。コントロールオファーにペイウォールがない場合（paywall_idがnull）、アプリはコードで独自にペイウォールをレンダリング（描画）するため、ペイウォール変更はRevenueCatを通さずアプリ側で行う必要があります。ユーザーに通知してください。そうでない場合は、revenuecat-paywall-designを読み込み、複製されたペイウォールをedit-paywall-aiで編集します。目的の効果を測定するために必要最小限の変更だけをリクエストし、結果のペイウォールを見て検証してください。
価格、試用期間、または導入オファー（初期優遇条件）の変更：これらはストア商品にあるため、トリートメントのオファーは異なる商品が必要です。list-productsで適切な商品が既に存在するか確認し、不足しているもののみ作成してください（revenuecat-store-stateスキルも参照）。その後、複製されたオファーのパッケージ内でそれらをスワップ（入れ替え）します。コピーされた商品をdetach-products-from-packageで外し、新しい商品をattach-products-to-packageで添付します。
完全に新しいペイウォール：include_paywall: falseを指定してオファーを複製し、revenuecat-paywall-designを読み込んで、新しいオファーのoffering_idを指定してcreate-paywall-aiを呼び出します。そうすると生成されたドラフトがそれに直接添付されます。ペイウォールとオファーは1対1の関係です。どちらか一方が既にペアになっている場合、attach-offering-to-paywallは失敗します。間違ったペアリングはdetach-offering-from-paywallで解除します（必要に応じて先にペイウォールを未公開にしてください）。
トリートメントペイウォールを公開します。 複製または新規作成されたペイウォールは未公開ドラフトであり、バージョンは公開版のみを配信します。前のステップで新しいペイウォールが作成された場合は、実験開始前に各トリートメントペイウォールをpublish-paywallで公開してください。これは積極的公開を避けるルールの例外ですが、安全です。トリートメントオファーは現在のオファーではないため、実験が登録を開始するまで顧客がそのペイウォールを見ることはありません。
create-experimentでドラフトを作成します。表示名、enrollment_percentage（登録率）、バージョンのオファーID、experiment_type、仮説に合致するprimary_metric（主要指標）とsecondary_metrics（補助指標）、enrollment_mode（only_newを使用。ユーザーが既存顧客を明示的に含めたい場合を除く）、およびターゲティングと注記を指定します。作成しても実験は開始されません。ドラフトはupdate-experimentで調整できます。
開始前に、各バージョンを検証してください。トリートメントペイウォールは公開済み、パッケージは意図した商品を含む、新しい商品はストアで利用可能な状態であることを確認します。
start-experiment ：実際の顧客の登録を開始します。ユーザーの明示的な確認を得てからのみ実行してください。pause-experiment ：登録を停止しますが、登録済み顧客には引き続きバージョンが配信され、データ収集も続きます。resume-experiment ：登録を再開します。stop-experiment ：終了です。登録済み顧客はデフォルトのオファーにフォールバック（自動切り替え）され、実験は再開できません。実験実行中に結果を解釈するには、revenuecat-experiment-analysisスキルを使用してください。
A RevenueCat experiment compares two to four offerings: offering_a (the control) against offering_b–offering_d (the treatments). Enrolled customers are served their variant's offering instead of the project's current offering. Setting up an experiment means preparing one offering per variant, then creating the experiment as a draft.
Refer to the MCP tool schemas for the exact parameters of each tool; the create-experiment schema also lists the available experiment types with their recommended primary and secondary metrics.
Keep the variants identical except for the one aspect under test, otherwise results cannot be attributed to the change. For example, when measuring the impact of a lower subscription price, both variants should share the same paywall design and packages, differing only in the price of the products.
Control. When the control variant is "what production does today", pass the current offering (is_current in list-offerings) directly as offering_a_id — do not duplicate it. Duplicate only when control itself needs changes relative to production.
Treatments. First check with list-offerings whether an offering already exists that matches what the treatment should serve, and reuse it instead of duplicating. Otherwise, start each treatment from a duplicate of the offering closest to it (usually the control offering). duplicate-offering copies the packages (attaching the same existing products) and, if the source offering has a paywall, also copies it as a new unpublished draft; it returns the new offering, including its new paywall_id. Pass source_paywall_version: published so the treatment copies the paywall customers see in production rather than unfinished draft edits; this fails when the source paywall was never published, so use the default (draft) only then. Then apply the one change under test:
paywall_id is null), the app renders its own paywall in code, so the paywall change has to be made in the app rather than through RevenueCat; tell the user. Otherwise, load revenuecat-paywall-design and edit the duplicated paywall with edit-paywall-ai. Request only the minimum changes required to measure the desired effect, and verify the result by looking at the resulting paywall.list-products whether suitable products already exist; create only the missing ones and their store counterparts (see the revenuecat-store-state skill). Then swap them into the duplicated offering's packages: detach the copied products with detach-products-from-package, then attach the new ones with attach-products-to-package.include_paywall: false, then load revenuecat-paywall-design and call create-paywall-ai with the new offering's offering_id so the generated draft is attached to it directly. A paywall and an offering pair 1:1 — attach-offering-to-paywall fails if either side is already paired; undo a wrong pairing with detach-offering-from-paywall (unpublish the paywall first if it is published).Publish treatment paywalls. A duplicated or newly created paywall is an unpublished draft, and a variant only serves the published version. If new paywalls were created in previous steps, publish each treatment paywall with publish-paywall before the experiment starts. This is the exception to the rule against proactive publishing, and it is safe: the treatment offering is not the current offering, so no customer sees the paywall until the experiment starts enrolling.
Create a draft with create-experiment: display name, enrollment_percentage, the variant offering IDs, experiment_type, a primary_metric (plus secondary_metrics) matching the hypothesis, enrollment_mode (only_new unless the user explicitly wants to include existing customers), and any targeting and notes. Creating never starts the experiment. Adjust a draft with update-experiment.
Before starting, verify each variant: treatment paywalls are published, packages contain the intended products, and any new products are available on the stores.
start-experiment begins enrolling real customers — only run it with the user's explicit confirmation.pause-experiment stops enrollment but keeps serving enrolled customers their variant and keeps collecting data.resume-experiment continues enrollment.stop-experiment is terminal: enrolled customers fall back to the default offering and the experiment can never be restarted.To interpret results once the experiment is running, use the revenuecat-experiment-analysis skill.
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。