コホート分析

Adaptyのコホートは、次のような重要な疑問に答えるために設計されています。

コホートが黒字転換するのはいつか？
特定のコホートのアプリ収益はいくらか？
有料ユーザー獲得に使える広告費の上限はいくらか？
広告費を回収するまでにどのくらいかかるか？

コホートは、SDKとストア通知を通じて収集したアプリデータを使用して機能するため、追加の設定は不要です。

更新回数または日数によるコホート

コホートは更新回数または日数で分析できます。このコントロールによってカラムの見出しが変わり、それに応じて分析のアプローチも変わります。日別のトラッキングは、予算管理や支払いタイムラインの把握に役立ちます。特に、消耗型アイテムや買い切り購入など、サブスクリプション以外のプロダクトのトラッキングに有効です。このモードでは、2つの主な要因により、テーブルセルの青色が列の中央付近に集中する傾向があります。1つ目は、日別でコホートを表示することで、短期間プロダクトに関連する支払いを早期に確認できる点です（リニューアルビューでは、これらは月次・年次のリニューアルと一緒にグループ化されます）。2つ目は、遅延支払いが分布パターンに影響する点で、一部のユーザーが予定より遅れて支払いを行うことがあります。 更新回数ベースのトラッキングは、日付を考慮せずに1回の支払いから次の支払いへとコホートの継続率とチャーンを表示します。遅延して支払ったユーザー（数ヶ月遅れる場合もあります）は、該当するサブスクリプション期間の数に追加されます。このアプローチはカレンダー上の収益状況を反映するものではありませんが、コホートの継続率とチャーンを分析してユーザー行動からインサイトを得るには非常に便利です。

どちらか使いやすいモードを選ぶか、より多くの結論やアイデアを得るために両方を活用してください。

Adapty がコホートを構築する仕組み

更新回数によるコホートを例に、テーブルがどのように形成されるかを見ていきましょう。コホートの構築には、アプリのインストール数とトランザクション（購入）の 2 つの指標を使用します。コホートの各行は特定の時間間隔（1 日から 1 年）を表します。各行は、その期間中にアプリをインストールし、サブスクリプションを有効化または永続アクセス・買い切り購入を行ったユーザー数から始まります。各列は、そのperiodにサブスクリプションを更新したユーザー数を示します。M3は「月3」を意味し、その時点までに3回連続で更新したサブスクライバーを表します。W7は「週7」、Y2は「年2」を意味します。コホートにはP2と表示される場合もあります。PはサブスクリプションのPeriod（期間）を表し、同一コホート内に更新期間が異なる複数のプロダクトが存在する場合に、W/M/Yの代わりに表示されます。

コホートの値の差を強調するために、グラデーションカラーを使用しています。数値が大きいほど、より濃い色で表示されます。以下の画像は、典型的なコホートの例です。

このコホートは週次プロダクトのデータのみを表示しています（マーク #1）。
手数料を除外せず、収益を絶対値で表示しています（マーク #2）。
対象期間は過去6ヶ月で、コホートの長さは1ヶ月です（マーク #3）。
Total 行（マーク #4）は各期間の累積値を表示します。Total 行の最初のセルにある $442K は、タイムフレーム終了までのすべての月（11月、12月など）における第1期間（サブスクリプション開始）の収益を合計したものです。Total セルには、期間全体でアプリをインストールしたユーザー数が表示されます。
Nov 2023 行の最初の列（マーク #5）は、Nov 2023 にアプリをインストールしたユーザーによる第1期間（サブスクリプション開始）の収益 $37.7K を示しています。Nov 2023 にアプリをインストールしたユーザー数（95,129 人）はヘッダー列に表示されています。 Nov 2023 行の2列目は、Nov 2023 にアプリをインストールしたユーザーの第2週（2週目に更新されたサブスクリプション）の収益 $8,77K を示しています。
テーブルには、Total revenue、ARPU、ARPPU、ARPAS が表示されています（マーク #6）。これらの詳細については、この記事の少し後で説明します。
テーブル右側の Columns ドロップダウンフィールドで、表示する列を設定できます（マーク #7）。
テーブル右上（マーク #8）には、特定のコホート分析におけるストアの手数料および税計算を選択するドロップダウンフィールドもあります。Adapty がストアの手数料と税を計算する方法については、この記事で詳しく説明しています。ドロップダウンから対応するオプションを選択すると、収益データがそれに基づいて再計算されます。
テーブルの右側には、予測収益（Predicted Revenue）と予測 LTV（Predicted LTV）が表示されています（マーク #9）。Predicted Revenue フィールドは特定の期間内にサブスクライバーコホートが生み出す総収益の予測値を示し、Predicted LTV フィールドはコホート内の各ユーザーの期待価値を表します。

Annotated cohort table with numbered marks

コホートの任意のセルにカーソルを合わせると、その期間の詳細な指標を確認できます。

背景に斜線が入っているセルはまだ完了していない期間を示しており、値が今後増加する可能性があります。

コホートの長さと期間

テーブルの表示内容は、2つの時間設定で決まります。

Time frame — 対象となる日付の範囲です。テーブル上部のカレンダーで設定します。
Cohort length — 各行の粒度です。日・週・月・四半期・年から選べます。月単位にすると、各行がインストール1か月分に対応します。

この2つは独立して動作します。たとえば、Time frame を6か月、Cohort length を月単位にすると6行のテーブルになります。Time frame を1年、Cohort length を週単位にすると52行になります。

フィルター、指標、コホートセグメント、CSV エクスポート

メイン記事: アナリティクスのコントロール

デフォルトでは、Adapty はすべての購入データを使用してコホートを構築します。プロダクトの期間、特定のプロダクト、国、ストア、ペイウォール、セグメント、アトリビューションデータでフィルタリングできます。

コントロールパネルの右側には、コホートデータを CSV にエクスポートするボタンがあります。エクスポートしたファイルは Excel や Google スプレッドシートで開いたり、独自の分析システムにインポートしたりできます。コホートに表示できる指標は、Subscriptions、Payers、Revenue、ARPU、ARPPU、ARPASの6つです。絶対値として表示することも、コホート開始時点からの相対的な変化として表示することもできます。

サブスクリプション数、支払いユーザー数、総収益、ARPU、ARPPU、ARPAS

サブスクリプション数は、選択した期間内にコホートが行ったアクティブなサブスクリプション、永続アクセス購入、および非サブスクリプション購入の合計数です。この指標を追跡することで、ユーザーの行動や提供内容の効果を把握できます。得られたインサイトをもとに、プロダクト戦略の改善、マーケティング施策のターゲティング、収益源の最適化に役立てることができます。 Payers（支払者）とは、コホート内で購入を行ったユーザーの総数です。この指標を使うと、収益に貢献しているユニークユーザーの数を把握できます。アプリ内課金（非サブスクリプション）が多いアプリでは、プロダクト提供の真の広がりを示す指標として役立ちます。幅広いユーザー層が購入しているのか、それとも少数のリピーターが収益を支えているのかを確認できます。支払者数を把握することで、顧客エンゲージメントの評価、ターゲットマーケティングの計画、収益戦略の最適化に役立てることができます。 Total revenue（総収益） は、選択した期間（2022年11月25日〜2023年5月24日）内に特定のコホートから積み上げられた収益です。特定のコホートのユーザーからどれだけの収益を得たかを把握し、ROASを算出するのに役立ちます。たとえば、2022年9月の広告費が$10,000で、2022年9月コホートの総収益が$30,000であれば、ROAS=3:1となります。 ARPU（ユーザー1人あたりの平均収益）は、総収益をユニークユーザー数で割って算出します。例：収益60,000ドル ÷ 5,000ユーザー = ARPU 12ドル。インストール単価（CPI）と比較することで、マーケティングキャンペーンの効果を把握できます。

ARPPU（課金ユーザー1人あたりの平均収益）は、総収益をユニーク課金ユーザー数で割って算出します。例：収益60,000ドル ÷ 1,000課金ユーザー = ARPPU 60ドル。課金ユーザー1人が平均してどれだけの収益をもたらしているかを把握するのに役立ちます。 ARPAS（Average Revenue Per Active Subscriber）は、アクティブなサブスクリプション1人あたりの平均収益です。総収益 ÷ アクティブなサブスクライバー数で計算されます。ここでいうサブスクライバーとは、トライアル期間またはサブスクリプションを有効化したユーザーを指します。$60,000の収益 ÷ 1,500人のサブスクライバー = $40のARPAS。

手数料と税金

コホート分析における収益計算の重要な側面として、ストアの手数料と税金（ユーザーのストアアカウントの国によって異なる場合があります）が挙げられます。Adapty は現在、コホート分析において App Store と Play Store の両方で手数料・税金の計算をサポートしています。 Adapty が分析内で税金と手数料をどのように計算するかについての詳細は、ドキュメントをご参照ください。

収益と手取り額

収益（Revenue）と手取り額（Proceeds）はどちらも金額に関する指標です。収益は売上総額、手取り額は売上純額と考えるとわかりやすいでしょう。収益は App Store / Google Play ストアの手数料を差し引く前の金額であり、手取り額は手数料を差し引いた後の金額です。そのため、手取り額は常に収益よりも少なくなります。

実際に差し引かれる手数料は、Small Business Program（15%）などのプログラムへの適用資格、長期サブスクリプションの優遇レート（1年以上の更新後は15%）、国別レート、標準レート（最大30%）など、複数の要因によって異なります。 Adaptyは、顧客が行うすべての取引に対して適用される手数料率を自動的に算出し、それに基づいて収益を計算します。手数料率の決定方法の詳細については、ストア手数料と税金のドキュメントをご覧ください。

返金の処理

コホート指標に共通する2つのルールがあります。

返金は元の購入日ではなく、返金が発生した日に記録されます。返金がコホートに影響するのは、その返金日が選択した期間内に含まれる場合のみです。
返金によってユーザーがコホートから除外されることはなく、インストール数も変わりません。コホートへの所属はユーザーのインストール時点で確定します。

これらのルールに加え、返金の影響は指標とビューモードによって異なります。使用するモードの列を下方向に読み進めてください。

指標	更新回数別	日数別
インストール数（コホートサイズ）	影響なし。ユーザーは元のコホートに残る。	「更新回数別」と同じ。
サブスクリプション	返金済みのサブスクリプションも引き続きカウントされる。	返金によりそのサブスクリプションがカウントから除外される。
支払いユーザー数	返金済みの支払いユーザーも引き続きカウントされる。	他に成功した支払いがある場合でも、返金によりそのユーザーがカウントから除外される。
収益	返金額は、元の支払いがカウントされていた更新期間の列から差し引かれる。	返金額は、返金日以降から差し引かれる。
ARPU	収益 ÷ インストール数。返金により収益が下がるが、インストール数は変わらない。	「更新回数別」と同じ。
ARPPU	収益 ÷ 支払いユーザー数。返金により収益と支払いユーザー数の両方が下がる可能性があるため、ARPPUは収益単独の場合よりも大きく変動することがある。	「更新回数別」と同じ。
ARPAS	収益 ÷ アクティブサブスクライバー数。返金により収益が下がるが、サブスクライバー数は変わらない。	「更新回数別」と同じ。
リテンション	影響なし。トライアルおよび購入イベントをカウントするものであり、返金はカウントしない。	「更新回数別」と同じ。
払い戻しは、有効な収益計算モードに関係なく、払い戻された金額を収益から差し引きます。

コンバージョン率とARPPU

返金はインストール数ベースのコンバージョン率に影響しません。インストール数は変わらないためです。課金ユーザーベースのコンバージョン率は異なります。返金は by days ビューではコンバージョン率を下げますが、by renewals ビューでは影響しません。 renewals ビューでは、Revenue 列と Payers 列はそれぞれ1期間分のデータのみを表示します。一方、ARPPU 列は異なります。各 ARPPU セルは、コホートの最初の期間からその列の期間までのすべてを合算します。つまり、常に複数の期間をまとめて扱い、さらに返金済みユーザーを除外します。そのため、1期間の Revenue をその期間の支払いユーザー数で割っても、表示されている ARPPU を再現することはできません。

例：あるユーザーが2月にアプリをインストールしてサブスクリプションを購入し、その後4月に全額返金を受けた場合。2月コホートを by days で表示すると：

時間軸：2月〜3月（返金がウィンドウに入る前）：ユーザーは有料ユーザー1名としてカウントされ、収益は全額含まれます。
時間軸：2月〜6月（返金がウィンドウに入った後）：ユーザーは有料ユーザー0名としてカウントされ、収益は0になります。

どちらの時間軸でも、2月のインストール数とリテンションは変わりません。

指標が返金を処理する方法では、MRR、収益チャート、データエクスポートにわたって同じルールを比較しています。

予測：収益とLTV

予測収益は、コホート作成後の選択した期間内に、課金ユーザーのコホートが生み出すと見込まれる収益の合計推定値です。コホートの予測LTVに、コホート内の課金ユーザーの予測数を掛け合わせて算出されます。たとえば、予測LTVが$50でコホート内の課金ユーザーが100人の場合、予測収益は$5,000となります。 予測 LTV とは、課金ユーザー 1 人あたりの推定ライフタイムバリューであり、コホート作成後の選択期間内に各課金ユーザーが生み出すと期待される平均収益を表します。

この予測は、過去のコホート継続率パターンに基づいており、十分な履歴データがある場合はアプリ固有のデータを使用し、そうでない場合はアプリをまたいだ平均値を使用します。Adapty の予測モデルの詳細については、予測のドキュメントをご参照ください。 Adapty のコホートは、アプリ内のユーザー行動と財務パフォーマンスについて詳細なインサイトを提供します。更新回数または日数に基づいてコホートを分析することで、コホートが収益化するタイミングの把握、収益のトラッキング、ユーザーあたりの平均収益の算出、広告費用の回収にかかる時間の把握が可能になります。カスタマイズ可能なフィルター、指標、エクスポートオプションにより、Adapty はデータに基づいた意思決定をサポートし、ユーザー獲得とマネタイズ戦略を最適化してアプリの成功を最大化します。