次のような場合に使用: ユーザーが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を含む）。次に、テスト対象の1つの変更を適用します。
ペイウォール変更（コピー、レイアウト、行動喚起（ボタン表記）、価格表示など）: これにはアプリがRevenueCat Paywallsを使用する必要があります。ペイウォールはオファーのオプション属性であり、対照群のオファーが持たない場合（paywall_idがnull）、新しく作成できます。それ以外の場合は、複製されたペイウォールをedit-paywall-aiで編集してください。目的の効果を測定するために必要な最小限の変更のみをリクエストし、結果のペイウォールを確認して検証してください。
価格、トライアル期間、または導入オファー（初回割引）の変更: これらはストア商品に存在するため、試験群のオファーは異なる商品が必要です。list-productsで適切な商品がすでに存在するかを確認してください。不足しているものだけを作成し、対応するストア側の商品も作成してください（revenuecat-store-stateスキルを参照）。次に、複製されたオファーのパッケージ内でそれらを置き換えます。detach-products-from-packageでコピーされた商品を削除し、attach-products-to-packageで新しい商品を追加してください。
まったく新しいペイウォール: include_paywall: falseでオファーを複製し、新しいオファーの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. Then apply the one change under test:
paywall_id is null). Otherwise, 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 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 による自動翻訳です。