revenuecat-charts

RevenueCat のチャートにアクセスする

RevenueCat のチャートを取得する際は、次のワークフローに従います。

1. get-chart-options-schema を使って、チャートで利用可能なオプションを確認します。
2. 適切なオプションを指定して get-chart-data を使い、チャートデータを取得します。
3. データを分析します。複雑な計算にはスクリプトを使います。

rc CLI（revenuecat-cli スキルを参照）を使う場合は、rc charts list でチャート一覧を表示し、rc charts options <chart> でスキーマを確認し、rc charts show <chart> でデータを取得します。

一般に、コンテキストがいっぱいにならないよう、まず期間を指定して大きめの解像度から始め、その後絞り込みます。

1. get-chart-options-schema でチャートのオプションを確認する

• get-chart-data を呼び出す前に、各チャートの信頼できる情報源として get-chart-options-schema を扱います。このツールは、チャートでサポートされている resolutions、filters、segments、user_selectors を返します。このツールは必ず "realtime": true を指定して呼び出してください。その後の get-chart-data 呼び出しでは、ここで返された文字列 ID をそのまま使用する必要があります。
• filters は、後で get-chart-data で条件を指定できるディメンションです。
  • 各フィルターには、次の項目があります。
    • 後でフィルターの name として使用する id。
    • 有効な値の選び方を示す value_mode。
      • inline_enum は、返された options のいずれかの id を使用することを意味します。list-products、list-offerings、list-apps など、対応するリスト取得ツールを使って、ユーザーが指定した名前をまず解決してください。
      • inferred_standard は、value_source にある ISO 国コードなどの標準コードを使用することを意味します。
      • dynamic は、プロジェクトで観測されたデータに基づく値を使用することを意味し、値は完全に一致する必要があります。
  • スキーマで有効な値として示されていない限り、表示名、ストアの商品 ID、バンドル ID、推測した値を渡さないでください。
• segments は、segment を使って後で get-chart-data でグループ化するディメンションです。
  • セグメントのエントリーには、使用するディメンションの id が直接示されています。チャートがそのディメンションでグループ化し、出力にすべての値を表示するため、セグメント値は一覧表示されません。
  • フィルターとセグメントはチャートごとに別のリストなので、フィルター可能なディメンションがセグメント化も可能だと決めつけないでください。たとえば、conversion_to_paying では product_id と offering_identifier をフィルターとして使用できますが、セグメントとしては使用できない場合があります。
• user_selectors は、チャートが返す指標や期間を変更する、チャート固有の切り替えオプションです。各セレクターは、get-chart-data の selectors JSON オブジェクトに渡すセレクター ID をキーとしており、通常、許可されるオプション ID とデフォルト値が含まれます。たとえば、revenue チャートでは revenue_type（revenue、revenue_net_of_taxes、proceeds）を使用する場合があり、コンバージョンチャートでは conversion_timeframe を使用し、デフォルトは 7_days です。結果を提示する際は、デフォルト以外のセレクターの選択肢を明示してください。
• resolutions には、サポートされている時間粒度と、get-chart-data で使用する文字列 ID が一覧表示されます。後で get-chart-data を呼び出す際は、必ずこれらの解像度 ID（たとえば、日単位は "0"、月単位は "2"）のいずれかを渡す必要があります。

2. get-chart-data でチャートデータを取得する

日付と解像度の選択

• 週、月、四半期で表した相対的な期間（「過去2週間」「先月」など）は曖昧です。今日が2026-07-31（金曜日）の場合、「過去2週間」は、7月18日～31日（直近14日間）、7月12日～25日（直近の完全な2週間）、または7月19日～31日（直近の完全な1週間と現在の週）を意味する可能性があります。各解釈に具体的な日付を添えて、どの期間を指すのかユーザーに確認してください。日付がすでに特定されている場合、つまり日付が明示されている場合、日数で期間が示されている場合、「前暦月」のように暦上の完全な期間を指定する表現が使われている場合、または以前に確認済みの場合は、質問を省略してください。
• 日付範囲は開始日と終了日を含みます（start_date と end_date は範囲に含まれます）。「過去 N 日間」は直近の期間を指し、終了日は今日、開始日は今日から N-1 日前です。
• 各期間には、start_date にかかわらず、その期間を含む暦期間（週、月、四半期）の初日がラベルとして付けられます。週の開始日はプロジェクトで設定された曜日（例：日曜日または月曜日）なので、週のラベルはプロジェクトごとに異なります。期間の開始日または終了日が期間の途中にある場合、ラベルが指定した日付と一致しない部分的な区分が返されます。直近の期間を指定する場合は、データが要求した日付を正確にカバーするよう、日単位の解像度を優先してください。合計のみが必要な場合は aggregate を使用します。
• 結果を提示する際は、問い合わせた開始日と終了日を明記し、最初または最後の区分のラベルは使わないでください。たとえば、7月18日～31日を週単位（日曜日始まり）で問い合わせると、7月12日、19日、26日というラベルの区分が返されます。「7月12日～7月26日」ではなく、「7月18日～7月31日」と伝えてください。

get-chart-data の呼び出し

• 常に "realtime": true を設定し、開始日、終了日、解像度 ID を指定してください。
• 常に、そのチャートについて事前に取得した get-chart-options-schema のガイドラインに従ってください。
• 複数のプロジェクトにまたがる質問では、プロジェクトごとに get-chart-data を1回呼び出し、約10～20件ずつ並列バッチで実行してください。バッチが大きすぎると API のレート制限に達するおそれがあります。各バッチでレート制限された呼び出しがないか確認し、制限されたものだけを再実行してください。1回ずつ順番に呼び出す方法に切り替えないでください。
• 使用可能な filters を使って出力を絞り込んでください。これは {"name": "<filter id>", "values": ["<value id>", ...]} 形式の JSON エンコードされた配列です。
  • 1つのエントリー内の値は OR 条件、エントリー間は AND 条件になります。例：米国または英国の App Store の収益： "[{\"name\": \"store\", \"values\": [\"app_store\"]}, {\"name\": \"country\", \"values\": [\"US\", \"GB\"]}]"。
  • フィルター名ごとにエントリーは1つだけ使用してください。同じ名前を繰り返すと、先のエントリーが暗黙的に置き換えられます（結合されません）。フィルター値にカンマを含めることはできません。
• 使用可能な selectors を使ってチャートを設定してください。これはセレクター ID とオプション ID を対応付ける JSON エンコードされたオブジェクトです。例："{\"revenue_type\": \"proceeds\"}"。省略したセレクターにはデフォルト値が適用されます。レスポンスでは、適用された値が user_selectors に含まれます。
• segment を使って、セグメント化可能なディメンション ID の一部で出力をグループ化できます。
  • セグメント化すると出力サイズが増えることに注意してください。より粗い解像度にする、日付範囲を短くする、limit_num_segments を使う（値の上位 N 件を残し、残りを「その他」にまとめる）、またはセグメントごとの合計のみが必要な場合に aggregate を使うことで、レスポンスを小さくできます。
• 合計や平均など、要約のみを求める質問（例：「Q1 の収益合計」）には aggregate を使用してください。生データを取得して自分で計算するよりも、こちらを優先してください。segment と組み合わせると、セグメントごとの簡潔な要約（例：国別の平均）が返されます。出力では values が空になり、summary にはそれらの集計結果のみが含まれます。
• 出力を特定の通貨単位に換算するには、currency を指定してください（レスポンスの yaxis_currency を参照）。

get-chart-data の出力の読み方

• measures には、チャートが返す指標（表示名、単位、説明）が一覧表示されます。ほとんどのチャートは複数の指標を返します。たとえば、revenue は売上、トランザクション数、広告インプレッション数を返す場合があります。
• values は、{cohort, measure, value, incomplete} 形式のポイントを格納したフラットな配列です。セグメント別の場合は、segment も含まれます。cohort は期間の開始を示す Unix タイムスタンプです。measure と segment は、それぞれ measures 配列と segments 配列のインデックスです。最初のセグメントは通常 "is_total": true です。ほかのセグメントと合計しないでください。
• summary には、指標の表示名ごとの total と average が格納されます。セグメント別の場合は、セグメントごとにネストされます。
• incomplete: true のポイントは部分期間を表します。対象となるのは、現在の期間と、start_date が期間の途中にあたる場合の最初の期間です（expand_periods のデフォルトは false です）。トレンド分析や比較分析からは除外し、結果を提示する際にはその旨を明記してください。時点チャート（MRR、アクティブ数、トライアル数）では expand_periods は無視されます。これらの値は期間境界時点のスナップショットであり、部分期間になることはありません。
• annotations には、ユーザーがダッシュボードに追加した日付付きのメモ（リリース、ローンチ、実験など）が一覧表示されます。データの変動を説明する際は、これらを確認してください。
• 無効なフィルター、セグメント、またはセレクター値を指定すると、対応する ID の一覧を含むメッセージとともに 400 parameter_error が返されます。このエラーが発生した場合、推測して再試行するのではなく、オプションのスキーマを読み直してください。

3. データを分析する

• セグメント別のレスポンスには Total セグメントが含まれます。また、limit_num_segments の上限を超えたセグメントは、上位 N 個以外が Other セグメントにまとめられます。基準値には Total を使用し、自分でセグメントを合計しないでください。
• 増加率、セグメント構成比、複数の呼び出し間での数値の統合など、チャート出力の複雑な計算には、数値を見ながら推論するのではなく、スクリプト（jq や短い Python スクリプトなど）を使用してください。
• 最新の期間には不完全のフラグが付いている場合があります。その旨を明示せずに、完全な期間と比較しないでください。
• 指標が変動した原因を推測する前に、まず利用可能なユーザー注釈を確認してください。
• コホートチャートは、初回確認時点からの累積期間内の数値を測定します。この期間はセレクター（コンバージョンチャートでは conversion_timeframe、実現 LTV チャートでは customer_lifetime）で選択し、1 回の呼び出しにつき 1 つの期間を指定します。結果を提示する際は期間を明記し、コホートを比較する際は期間を一定にしてください。

指標の解釈

サブスクリプションアプリは、次の4つの要素によって成り立っています。

• 獲得：アプリに新たに訪れる顧客の数
• コンバージョン：その顧客のうち、トライアルや有料プランに移行する数
• 継続：顧客がどれくらいの期間利用を続けるか
• 再活性化：以前のユーザーをどのように呼び戻すか

アプリの収益の純増減は、これらの要素が組み合わさった結果です。アドバイスをする際は、問題を誤って診断しないよう、必ずベンチマークデータを使用してください。

一般的なガイドライン：

• ユーザーが挙げた指標について、RevenueCat にはデータがないと伝える前に、該当しそうなチャートを選び、オプションを確認するために get-chart-options-schema を呼び出してから、get-chart-data を呼び出し、その periods / measures を確認してください。見慣れない名前は、チャート内の期間や指標を表していることがよくあります（スキーマだけではそれらは一覧表示されません）。get-benchmarks にない場合は、同業他社のパーセンタイル範囲がないという意味であり、その値を算出できないという意味ではありません。
• 確認したうえで、ツールに該当するものがない場合や、解釈によって数値に大きな違いが出る場合は、指標の定義をユーザーに確認してください。定義を推測してはいけません。
• 複雑な質問では、必要なデータ取得の範囲を慎重に絞ってください。まず概要レベルのチャートを確認し、あらゆる切り口のデータを取得するのではなく、どの商品、ストア、国について知りたいのかをユーザーに確認してください。
• データツールを使用する際、日付範囲の開始日と終了日はどちらも範囲に含まれます。データを「直近 N 日分」求められた場合は、この点を考慮し、終了日を今日、開始日を今日より (N-1) 日前にしてください。
• 役立つ場合は、RevenueCat のチャートへのリンクを提示してください（以下の「ダッシュボード URL 形式」セクションを参照）。フィルター、セグメント、日付範囲などを含む具体的なリンクを提示してください。たとえば、直近3か月の収益を尋ねられた場合は、通常の収益チャートではなく、直近3か月のカスタム日付範囲を指定し、revenue_type セレクターを proceeds に設定した収益チャートへのリンクを提示してください。
• 予測、見通し、またはランレートについて回答する場合は、チャートを取得する前に revenuecat-forecasting スキルを読み込んでください。

収益

• 追加の指定なしに一般的な収益額を尋ねられた場合は、総収益（税金とストア手数料を含む収益）をデフォルトとし、その旨を明記してください。

獲得

• アプリがファネル上部でどれだけ顧客を獲得しているかを把握するには、「新規顧客」チャートを使用してください。
• 「新規顧客」を国や Apple Ads のディメンションでセグメントすると、獲得状況の把握に役立つことがあります。
  • RevenueCat の Apple Ads 統合では、キャンペーン、広告グループ、キーワードなどのアトリビューションディメンション情報が設定されます。
  • 開発者は、予約済みの顧客属性を使用して、顧客ごとにこれらのアトリビューションディメンションを手動で設定することもできます。
• 明示的なアトリビューションフィルターの結果がゼロでも、それをもって、より広いチャネルにユーザーやアクティビティがまったくないと判断してはいけません。たとえば、attribution_source = Organic は、その値が明示的にタグ付けされたユーザーのみを意味します。タグ付けされていないユーザーや、すべてのオーガニック／非課金ユーザーは含まれません。
• アトリビューションデータが少ない、または欠落している場合は、そのことを明確に伝えてください。特定のチャネルから来たと推測せず、「アトリビューションなし」または「明示的なタグ付けなし」と表現してください。

コンバージョン

コンバージョンの定義は、アプリが使用しているモデルによって異なる場合があります。トライアルを開始した後にサブスクリプションへ移行する場合もあれば、ユーザーを直接サブスクリプションに誘導する場合もあります。

• Initial Conversion チャートを使うと、選択したコンバージョン期間内にサブスクリプションまたはトライアルを開始した新規顧客の割合を確認できます。
• Conversion to Paying チャートを使うと、選択したコンバージョン期間内に支払いを行った新規顧客の割合を確認できます。
• Initial Conversion（トライアルまたはサブスクリプションを開始）と Conversion to Paying（支払いを実施）は、異なるイベントを測定します。一方を他方の代わりとして使ったり、両者の値を比較したりしないでください。
• さらに、New Trials チャートを見ることで、無料トライアルを利用しているかどうかを判断できます。
• Trial Conversion Rate チャートは、トライアルコンバージョンのパフォーマンスだけを把握するのに役立ちます。
• フィルターを適用したチャートでも、分母はすべての新規顧客のままです。たとえば、Conversion to Paying を特定の product_id でフィルターすると、その商品のコンバージョン率ではなく、すべての新規顧客のうちその商品にコンバージョンした割合が表示されます。フィルターを適用した結果を提示する際は、この注意点を明記してください。

リテンション

• Churn チャートでは、各期間にアクティブなサブスクライバー基盤のうち何％が失われたかを確認できます。異なる期間が混在しているため、解釈やベンチマークが難しい場合があります。
• さまざまな商品の長期的なリテンションを把握したい場合は、Subscription Retention チャート、または retained_subscriptions 指標を使った Cohort Explorer チャートを確認してください。この指標は、時間の経過に伴ってアクティブなまま（つまり、期限切れになっていない）だったサブスクリプションの数を返します。
• サブスクリプションのライフサイクルのどの時点で解約されるか（つまり、自動更新がオフになるか）を把握するには、Cohort Explorer で subscriptions_set_to_renew 指標を使ってください。
• Subscription Retention チャートでは、各コホートの期間ごとの更新数と、事前に計算された率（「Month N」／「Month N rate」列）が表示されます。1つの期間を見ることで、「一度更新した割合はどれくらいか」といった問いに答えられます。最初の更新は、プランの長さに対応する期間です（月額プランでは Month 1、年額プランでは Year 1）。1回の分析でプランの長さを1種類に絞るには product_duration でフィルターし、商品の変更や再サブスクリプションを除外するには subscription_type を new に設定してフィルターしてください。コホートがまだ十分な期間を経ていない期間は未完了として報告されます。ゼロとして解釈しないでください。

再アクティベーション

• 再アクティベーションを正しく把握する唯一の方法は、MRR Movement チャートと Resubscription MRR を確認することです。

指標の変動を調査する

指標の変化（収益の減少、トライアルの減少、コンバージョンの急増など）について説明が必要な場合は、回答する前に次の順序で確認してください。

1. 変動を定量化します。 チャートのデータを取得し、変化の規模と時期を確認します。
2. 設定を確認します。 オファリング、パッケージ、製品、ペイウォール、実験は指標には表示されないため、チャートから推測してはいけません。回答でこれらのいずれかに言及する場合は、この実行中に調べてください。「可能性が高い」「確認する価値があります」といった留保や、「確認しましょうか？」という申し出をしても、推測が許容されるわけではありません。次の確認はすべて必須であり、いずれかを選ぶものではありません。
   • list-experiments を status="stopped" と status="running" で実行します。変化の時期近くに実験が停止していた場合は、自分で get-experiment-results を呼び出して、どのバリアントが勝ったかを確認してください。ユーザーに確認を促してはいけません。
   • expand を指定せず（既定のページ数は 20 です）、limit: 100 で list-offerings を実行します（実際のプロジェクトでは既定の 20 件に収まらないことがほとんどです。部分的なページを根拠に、現在のオファリングはないと結論づけてはいけません）。次に、is_current の ID を指定して get-offering を expand: ["package.product"] とともに実行します。get-offering では package と package.product を指定します。list-offerings で使われる items. 接頭辞は付けません。paywall_id: null のオファリングには RevenueCat のペイウォールがありません。ペイウォールについて助言する前に revenuecat-paywall-design を読み込んでください。
   • 製品が販売終了、利用不可、または販売されなくなったと述べる前に get-product-store-state を実行します。ストアの状態は平易な言葉で報告し、生のフィールド名は使わないでください。
   • 実験とオファリングで説明できない場合は、ペイウォールの変更を確認するために list-paywalls を実行します。
3. アノテーションを確認します。 チャートのレスポンスにある annotations フィールドを確認してください。
4. その後でのみ仮説を立てます。 事実としてではなく、仮説として提示してください。設定に関する未検証の推測は、結論ではなく、ツール呼び出しの不足です。

手順 2 を省略してはいけません。list-experiments または list-offerings をこの実行中に呼び出さずに、「オファリングから削除された」や「実験がロールアウトされた」と書こうとしている場合は、いったん止めて、まず呼び出してください。呼び出した結果、変化を説明できない場合（対象期間が現在の設定より前である、または何も変更されていないなど）は、仕組みを作り上げるのではなく、その旨を明確に述べてください。「データから X が起きたことは分かりますが、利用可能な設定情報から理由を特定することはできません」は妥当な回答です。対象期間が古いために結論が出ない場合でも、それは呼び出しを省略する理由にはなりません。

母集団と分母

率が表すのは、その分母に含まれる母集団だけです。率を提示する前に、それが質問の対象とする母集団であることを確認してください。

• 分母の大部分を一つのセグメントが占める場合、混合率が表すのはアプリ全体ではなく、そのセグメントです。質問の対象となる母集団で絞り込んで再度クエリし、その数値を最初に示しつつ、混合率も併記してください。
• 分母が過大または代表性に欠けると述べながら、率を根拠として提示してはいけません。 留保を付けるのではなく、フィルターを使って再度クエリしてください。
• フィルター適用後の数値は、自分で報告してください。フィルター適用後のチャートをユーザーに確認するよう勧めてはいけません。

分析の比較

• 比較する対象を揃えてください。比較する2つの数値は、同じチャートと指標から取得し、コンバージョン期間とコホートの定義も同一でなければなりません。意図的に期間ごとの比較を行う場合を除き、日付範囲も揃えてください。
• 比較の片側の指標はあるものの、もう片側の指標がない場合は、比較する前に同じチャートと設定で不足している側をクエリしてください。別のチャートの値で代用しないでください。一致する値を取得できない場合は、各数値をチャート名と指標名を明記して個別に提示し、差や比率に関する主張はしないでください。
• 「{segment} ユーザーの状況はどうですか？」のような自由形式の質問では、セグメントのみの指標で終わらせないでください。指定されたセグメントと、主要なコンバージョン指標または収益品質指標の全体／フィルターなしのベースラインを取得し、そのベースラインと比較してパフォーマンスを評価してください。ベースラインと比較せずに、セグメントを「健全」「パフォーマンスが低い」などと評価しないでください。
• 新規顧客でフィルターしたコホートの収益やコンバージョンを、すべてのコホートと更新を含むアプリ全体の収益と比較しないでください。一致するベースラインを取得できない場合は、その旨を伝え、パフォーマンスの傾向に関する主張は避けてください。
• 2つの指標が食い違っていることについてユーザーが疑問を持っている場合は、その差を説明する前に、それぞれの指標が何を数えているかを伝えてください。一方が他方の部分集合である場合に限り、2つの指標は連動します。

誤り — 異なるチャートを1つの見出しにまとめています。

国	有料ユーザーへのコンバージョン（14日）
US	26.3%（これは初回コンバージョンです）
PL	2.1%（これは有料ユーザーへのコンバージョンです）

正しい — 指標ごとに列を分け、各列の値はすべて同じチャート、指標、設定から取得します。

国	初回コンバージョン（14日）	有料ユーザーへのコンバージョン（14日）
US	26.3%	9.6%
PL	4.3%	2.1%

チャートダッシュボードのリンク

RevenueCat ダッシュボードのチャートへの共有可能なリンクを生成します。

リンクの作成

チャートのリンクは、指定のダッシュボード URL 形式に従い、get-chart-data の呼び出しが以前に成功したことを確認したうえで作成する必要があります。

0. このチャートに対する get-chart-data の呼び出しが以前に成功していない場合は、まず上記の RevenueCat チャートのクエリワークフローに従ってください。
1. ベースとなる URL からリンクを作成します。 https://app.revenuecat.com/projects/{project_id}/charts/{chart_name}。
2. range パラメーターを追加して日付範囲を指定します。これは必須です。
3. resolution パラメーターを追加して解像度を指定します。デフォルト値をそのまま使わないでください。
4. フィルターがあれば、filter パラメーターとして追加します。
5. セグメントを使用する場合は、segment パラメーターとして追加します。
6. 必要に応じて、チャート固有のセレクターを追加します。
7. すべての値を URL エンコードします（スペース → +、コロン → %3A など）。

ダッシュボード URL 形式

重要：次の構造をそのまま使用してください。

https://app.revenuecat.com/projects/{project_id}/charts/{chart_name}?range={range_value}

• {project_id} — 短い 16 進数 ID（例：56965ae1）です。完全な proj56965ae1 ではありません。
• {chart_name} — get-chart-data で使用したものと同じチャート名です（revenue、churn、mrr、conversion_to_paying など）。
• プロジェクト ID はクエリパラメーターではなく、パスに指定します。

正しい例：

https://app.revenuecat.com/projects/56965ae1/charts/revenue?range=Custom%3A2025-11-16%3A2026-02-13

誤り — 次の形式は使用しないでください：

https://app.revenuecat.com/charts/revenue?project=proj56965ae1&chart_start=...&chart_end=...

クエリパラメーター

range パラメーター — 必須

range パラメーターは日付範囲を指定します。形式は {preset}:{start_date}:{end_date} で、start_date と end_date は YYYY-MM-DD 形式です。プリセットには Custom を使用します。

必ずこの形式を使用してください — start_date、end_date、chart_start、chart_end の各パラメーターは使用しないでください。注：各要素の間の : は %3A として URL エンコードする必要があります。

例：range=Custom%3A2025-01-01%3A2025-12-31

resolution パラメーター

値	意味
0	日単位の粒度
1	週単位の粒度
2	月単位の粒度
3	四半期単位の粒度
4	年単位の粒度

segment パラメーター

データを分類するディメンションです。get-chart-data リクエストで使用したディメンション ID をそのまま指定してください。

• country — 国別
• store — アプリストア別（App Store、Play Store など）
• product_id — プロダクト識別子別
• platform — プラットフォーム別（iOS、Android など）
• offering_identifier — オファリング別

セグメントはチャートごとに異なります。そのチャートの get-chart-data 呼び出しで正常に使用できたセグメントのみをリンクしてください。

filter パラメーター

フィルターは、内容が {dimension}%3A%3D%3A{value} の個別のクエリ filter パラメーターとして渡します。get-chart-data リクエストで使用したディメンション名を指定してください。

ディメンション	例
country	filter=country%3A%3D%3AUS
store	filter=store%3A%3D%3Aapp_store
product_id	filter=product_id%3A%3D%3Aprodbb68905d98
platform	filter=platform%3A%3D%3AiOS

同じディメンションか複数のディメンションかにかかわらず、複数のフィルターを使用する場合は、複数の filter クエリパラメーターを含めてください。同じディメンションのフィルターを複数渡すと OR 演算が行われ、異なるディメンションのフィルターを渡すと AND 演算が行われます。

チャート固有のセレクター

セレクターは、get-chart-data の selectors 引数で使用するものと同じ名前と値で、個別のクエリパラメーターとして渡します。参考例（正確な値は get-chart-data で確認してください）：

• revenue_type（収益チャート）— revenue、revenue_net_of_taxes、または proceeds
• conversion_timeframe（コンバージョンチャート）— 0_days、3_days、7_days、14_days、30_days、 または unbounded
• customer_lifetime（実現 LTV チャート）— 7_days、14_days、30_days、3_months から 24_months まで、または unbounded

API パラメーターとダッシュボードパラメーターの対応

API パラメーターからダッシュボード URL に変換する場合：

API パラメーター	ダッシュボードパラメーター
start_date + end_date	range=Custom%3A{start}%3A{end}（Custom プリセットを使用）
segment	segment
filters（JSON 配列）	個別の filter クエリパラメーター
selectors（JSON オブジェクト）	個別のクエリパラメーター

例：リンクの作成

ユーザーの要望：「過去 90 日間の収益チャートを国別に分類し、米国とドイツに絞り込む」

日付を計算します。今日が 2026-02-13 の場合、90 日前は 2025-11-16 です。

https://app.revenuecat.com/projects/56965ae1/charts/revenue?range=Custom%3A2025-11-16%3A2026-02-13&segment=country&filter=country%3A%3D%3AUS&filter=country%3A%3D%3ADE

ユーザーの要望：「2025 年 8 月から現在までのチャーンチャート」

https://app.revenuecat.com/projects/56965ae1/charts/churn?range=Custom%3A2025-08-01%3A2026-02-13

プロジェクト ID の取得

プロジェクト ID は、すべてのプロジェクトとその ID を一覧表示する list-projects ツールで確認できます。

• ツールは proj で始まる ID を返します。例：proj56965ae1
• ダッシュボード URL では proj の接頭辞を取り除きます — パスには 56965ae1 のみを使用してください