アプリのリテンションレート（継続率）を改善するマジックナンバー分析のススメ

多くのモバイルアプリは継続して利用されることによって収益が最大化するように設計されています。そこで、重要視されている指標が「リテンションレート（継続率）」。
この記事では、リテンションレート改善のための最強の分析手法である「マジックナンバー分析」について、初心者でもすぐに実践できるように解説しました。アプリの収益最大化を支援するReproでは、マジックナンバー分析の分析は基本中の基本。私を含めて日本一マジックナンバー分析を繰り返してきたといっても過言ではないでしょう。実体験も交えながら、マジックナンバー分析の基本からHowまですべてをお伝えします。

アプリのマジックナンバー分析ってどんなもの？

そもそも、モバイルアプリのマジックナンバー分析とはどのようなものなのでしょうか。実は私自身、端的に表現するのに苦労するのですが、下記のような説明が適切だと思っています。

「一定期間内」「特定のイベント」……。汎用的な言葉にすると冗長でわかりづらいですね。これは、「マジックナンバー」という言葉に、「期間」「イベント」「回数」という3つの概念が包含されているから。とはいえ具体例を見るとすぐに納得できるはずです。

この例の場合、「一定期間内」が「1週間以内」、「特定のイベント」は「フォロー」、「実行回数」は「3回」。マジックナンバーはこれらを組み合わせたものなので、「1週間以内にフォローを3回」です。そして、「1週間以内にフォローを3回」を割り出すために行うのがマジックナンバー分析というわけです。

■マジックナンバーとマジックナンバー分析の意味

なおここではアプリマーケティングに解説のテーマを閉じているため、向上させる指標をリテンションレートに限定していますが、汎用的に用いる場合は、どのような指標でも構いません。下記のように言い換えることもできます。

リテンションレート（継続率）って？マジックナンバー分析をする前のおさらい

この記事の本題である具体的な分析手法に入る前に、もうひとつだけ前提のおさらいをさせてください。リテンションレート（継続率）についてです。

リテンションレートとは「期間A内にサービスを利用したユーザーの何％が、以降の期間B内にリピート利用をしたのかを示す指標」で、計算式は以下の通りです。

期間のスコープは通常、日、週、月の3種類で、それぞれに日次リテンションレート（Daily Retention Rate・DRR）、週次リテンションレート（Weekly Retention Rate・WRR）、月次リテンションレート（Monthly Retention Rate・MRR）と呼ばれています。これも言葉だけではわかりづらいので図にしてみましょう。すぐに理解できるはずです。

日次リテンションレート（Daily Retention Rate・DRR）

特定の「日」にサービスを利用したユーザーの何％が、○日後の時点でもリピート利用をしているかを示す。

■日次リテンションレートの例

週次リテンションレート（Weekly Retention Rate・WRR）

特定の「週」にサービスを利用したユーザーの何％が、○週後の時点でもリピート利用をしているかを示す。

月次リテンションレート（Monthly Retention Rate・MRR）

特定の「月」にサービスを利用したユーザーの何％が、○月後の時点でもリピート利用をしているかを示す。

リテンションレート（継続率）とは？

リテンションレート（継続率）の基本や、リテンションレート（継続率）を高める方法について解説しています。
⇒ リテンションレートについての解説を詳しく見る

マジックナンバー分析の基本原則

さてここからは、マジックナンバー分析の具体的な手法について解説していきましょう。マジックナンバー分析を始める前には、以下の3点を明確にしておく必要があります。これはマジックナンバー分析を実施する際の基本原則ともいえるものです。しっかりと覚えておいてください。

【原則1】分析対象期間から外部要因やトレンドを排除する

アプリのマジックナンバー分析のカギとなるのはリテンションレート。リテンションレートは期間比較の指標であるため、外部要因やトレンドの影響を受けやすいという側面があります。

致し方ない部分はあるものの、可能な限り外部要因やトレンドの影響が少ない期間を対象として分析することをおすすめします。

【原則2】サービスに合わせて分析対象期間のスコープを選ぶ

前述の通り、リテンションレートのスコープは日次、週次、月次のおおむね3つに分かれています。分析するサービスのユーザー行動をイメージして、スコープを決めてください。

例えば、マンガアプリのように毎日利用してもらうことを理想とするアプリであれば、日次リテンションレートを中心にしながら、副次的に週次リテンションレートも分析する形がよいでしょう。クレジットカードアプリのように、月に一度の決済日周辺で使われるケースが多いアプリなら、月次リテンションレートを分析するという具合です。

【原則3】分析対象とするイベントとその実行回数を決めておく

すべてのイベントの実行回数を網羅的に分析するのは現実的ではありません。ノイズが多く発生し、結論を見誤る可能性もあります。多くのユーザーに発生するアプリの主要イベントをピックアップしたうえで、実行回数も3回程度を上限に分析を始めることをおすすめします。

マジックナンバー分析の具体的な手法とツール

結論からいうと、マジックナンバー分析に特別な専用ツールは必要ありません。下のような形でイベントと実行回数、そしてリテンションレートを整理できるものであれば、どんな手法を使っても大丈夫です。

A列はマジックナンバーとなる可能性のある、「イベント名と実行回数」、B列は「ベースとなる期間（期間A）にA列の行動をしたユーザー数」、C列は「B列のユーザーのうち、期間Bにリピートをしたユーザー数」、D列はそれぞれのリテンションレートです。

例えば、3行目は
期間A内に25,300ユーザーがアプリ起動を2回完了しており、そのうちの13,464ユーザーが期間B内にアプリを再度利用した
という意味になります。

【手法1】SQLでデータを抽出・整形する

マジックナンバー分析をする際の最も一般的な方法はSQLの活用だと思います。膨大な数のユーザー行動ログを記録したデータベースから、必要なデータだけを自由に抽出し、整形できるからです。

よくあるデータベースを想定して、月次リテンションレートを算出するクエリを書いてみました。ベースとなる期間（期間A）を「2024年1月31日15時00分から、2024年2月29日14時59分」、リテンションレートの計測期間（期間B）を「2024年2月29日15時00分から、2024年3月31日14時59分」とし、期間中にアプリを少なくとも一度起動（app_launch）したユーザーの数とリテンションレートを求めています。

WITH base_user as (
  SELECT
    user_id
    , event_name
  FROM
    table_A
  WHERE
    track_date between "2024-01-31T15:00:00.000Z" and "2024-02-29T14:59:00.000Z" 
    AND event_name = "app_launch"
)
, retention_user as (
  SELECT
    user_id
    , event_name
  FROM
    table_A
  WHERE
    track_date between "2024-02-29T15:00:00.000Z" and "2024-03-31T14:59:00.000Z"
    AND event_name = "app_launch"
)
SELECT
  base_user.event_name as base_event
  , COUNT(distinct base_user.user_id) as base_user_count
  , COUNT(distinct retention_user.user_id) as retention_user_count
  , CONCAT(round(100 * count(distinct retention_user.user_id) / count(distinct base_user.user_id), 2),'%') as retention_rate
FROM
  base_user
    LEFT OUTER JOIN
  retention_user
    ON
  base_user.user_id = retention_user.user_id
  GROUP BY 1

【手法2】GA4でデータを抽出・整形する

「SQLなんて扱えない」と思った人もご安心ください。アプリの分析をGA4で行っていて、必要なイベントを取得しているなら、GA4でも簡単にマジックナンバー分析ができます。ポイントは「コホートデータ探索」と「セグメント」の活用。下のような形で、リテンションレートを計測できるため、マジックナンバー分析もすぐに実践できます。

詳しい分析方法は後日、解説する予定なので楽しみにしておいてください。

成功事例から学ぶマジックナンバー分析の活用方法

マジックナンバー分析を利用したアプリの改善事例も紹介しておきましょう。アプリの種類やイベント名、数値などはすべてダミーサンプルですが、行ったことと成果は実際のものです。ぜひ参考にしてください。

とある音楽系アプリで、新規ユーザーの翌週のリテンションレートが伸び悩んでいました。これを改善することを目的にマジックナンバー分析を行ったときのことです。分析結果を見たところ、アプリを初めて起動した週に2回以上プレイリスト再生をしているユーザーのリテンションレートが大きく上昇することが確認できました。

つまり、「アプリを初回起動した週にプレイリスト再生を2回以上」がマジックナンバーだったということです。

■マジックナンバー分析の結果（表）

なお、マジックナンバー分析の結果は、縦軸を「リテンションレート」、横軸を「ベース期間のユーザー数」にした散布図で確認することをおすすめします。そうすると、通常は右肩下がりのトレンドラインを形成します。このラインから上方に外れているデータがマジックナンバーとなる可能性が高いからです。

■マジックナンバー分析の結果（散布図）

ちなみに、掲載しているデータは各イベントの実行回数を2回に絞っていますが、実際に行う場合には、実行回数を3回程度に設定するのがおすすめです。

マジックナンバーがわかればあとはそれを実現するための施策を実施するのみです。このケースではプッシュ通知やアプリ内メッセージを利用して、プレイリスト再生を2回以上行ってもらうための施策に取り組みました。結果、初回起動ユーザーの翌週リテンションレートが、未配信群比で110％改善しました。

■マジックナンバー分析の結果を活かした施策例

マジックナンバー分析の注意点

「マジックナンバー分析の基本原則」で紹介した3つの原則を守り、データさえ抽出できれば、マジックナンバー分析はさほど難しいものではありません。ただし、1点だけ注意すべきポイントがあります。それは継続率とイベントの実行回数の因果関係を読み誤ってしまう可能性があること。マジックナンバー分析は前述の通り、

なのですが、データだけを見ると「イベント実行によってリテンションレートが高まっている」のか、「リテンションレートが高いユーザーだからこそ、そのイベントを実行している」のかがわからないのです。

最終的には分析担当者が、マジックナンバーとして「適切なユーザー行動か」を想像して判断する必要があるのですが、ここでは因果関係が逆になりやすいパターンをふたつ挙げておきます。

極端に利用ユーザーが少ないイベントに対する分析

コアな機能を活用しているヘビーユーザーである可能性があります。ヘビーユーザーはそもそもリテンションレートが高い（因果関係が逆）ので、マジックナンバーとして取り扱うのは不適切です。散布図で見たときに、左側にプロットされるイベントにその傾向があるので注意が必要です。

「アプリ起動」イベントに対する分析

マジックナンバー分析の対象とするイベントに「アプリ起動」を含めるケースがあります。しかし、「1週間にアプリ起動を3回するユーザーはリテンションレートが高い」「だから、たくさん起動するような施策を打とう」のような短絡的な分析はNGです。

アプリをたくさん起動してくれているユーザーには起動したい理由があったはずなのです。意味もなくアプリを起動しているわけではありません。なぜアプリを起動しているのか、どんな状況や機能、モチベーションがアプリ起動に繋がっているのかを深掘りすることが大切です。

「まずは分析してみる」がスタート

マジックナンバー分析は、分析対象とするイベントを見極めることが重要です。最初のうちは、ノイズばかりで意味のある結果が見えてこなかったり、必要以上に時間がかかってしまったりすることもあるかもしれません。しかし、しらみつぶしに分析をしながら、失敗を繰り返すのも大切なことです。その繰り返しは、アプリの成長のキードライバーを探し出す作業なのですから。

慣れてくると、リテンションレートを向上させそうなイベントがなんとなく見えるようになってきます。つまり、アプリの成長を促す要素を肌で感じ取れるようになってくるということ。マジックナンバー分析は、アプリを成長させるだけでなく、自分自身をアプリマーケターとしてワンランク上に連れて行ってくれる作業ともいえるのです。