会社情報
採用情報
お問い合わせ
Article

アプリのリテンション率を60%改善する施策10選

高田晃太郎
アプリのリテンション率を60%改善する施策10選

業界横断の公開データでは、モバイルアプリの平均D7リテンションはおよそ10〜15%、D30は2〜6%に収れんする¹²とされます。カテゴリ差は大きいものの³、実務の現場では、計測の是正とUX・通信層の改善を組み合わせたプロダクトほど、D30の底上げが再現的に観測されやすいという傾向があります。逆に、通知やA/Bテストを単発で行うだけでは効果が散発的に留まり、半年スパンで平均化すると改善は小幅にとどまることが少なくありません。つまり、測る→分ける→価値を早く届ける→継続の摩擦を減らす→検証するという流れを、チームの標準作業に組み込めるかが分水嶺になります。ここでは、その流れを10の実践策に落とし込み、コード例と指標まで一気通貫で解説します。なお、「60%改善」は達成可能性のある目標として掲げていますが、最終的な成果はカテゴリや流入品質、開発体制に強く依存します。

計測とセグメンテーションがすべての土台

リテンション改善の前提は、イベント設計とコホート分析が日常的に回ることです。ここでのD1/D7/D30は「初回価値体験（Aha moment）を基点とした1/7/30日目の再訪率」を指し、コホートは「同日に初回価値体験を迎えたユーザー群」です。登録やAha moment（ユーザーが価値を実感した瞬間）、主要機能の活性イベント、収益イベントを時系列で捕捉し、D1/D7/D30のコホートを分けて追うと、どこで失速しているかが明確になります⁴。重要なのは、イベント命名の標準化と、匿名IDと会員IDのシームレスな突合です。計測の段差が消えるだけで、開発施策の優先度がブレなくなります。

イベント設計とコホート計測をコードから固める

クライアント側でのイベント送出は失敗や重複が起きやすく、品質がそのまま分析精度に跳ねます。Androidではワーカーを用意し、永続キューと再送を入れて欠測を抑えます。以下はKotlinでのイベント送信スケルトンです。

import android.content.Context
import kotlinx.coroutines.CoroutineScope
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.launch
import kotlinx.coroutines.withContext
import java.util.UUID

class AnalyticsClient(private val ctx: Context, private val transport: Transport) {
    suspend fun logEvent(name: String, props: Map<String, Any>) {
        val payload = mapOf(
            "event" to name,
            "props" to props,
            "anonymous_id" to Device.id(ctx),
            "ts" to System.currentTimeMillis()
        )
        withContext(Dispatchers.IO) {
            EventStore.enqueue(payload)
            flush()
        }
    }

    private suspend fun flush(maxRetry: Int = 3) {
        var attempt = 0
        while (attempt < maxRetry) {
            val batch = EventStore.nextBatch(100)
            if (batch.isEmpty()) return
            val ok = transport.send(batch)
            if (ok) {
                EventStore.ack(batch)
                attempt = 0
            } else {
                attempt++
                backoff(attempt)
            }
        }
    }

    private suspend fun backoff(attempt: Int) {
        val delayMs = (Math.min(30_000, (500 * Math.pow(2.0, attempt.toDouble())))).toLong()
        kotlinx.coroutines.delay(delayMs)
    }
}

集計側では、初回価値体験イベントを基点にD1/D7/D30を測ります。BigQuery上の簡易コホート集計例を示します。

-- events(user_id, event_name, event_time)
WITH first_use AS (
  SELECT user_id, MIN(event_time) AS first_ts
  FROM events
  WHERE event_name = 'aha_moment'
  GROUP BY user_id
),
cohort AS (
  SELECT e.user_id,
         DATE(first_ts) AS cohort_date,
         DATE_DIFF(DATE(e.event_time), DATE(first_ts), DAY) AS day_offset
  FROM events e
  JOIN first_use f USING(user_id)
)
SELECT cohort_date,
       COUNT(DISTINCT IF(day_offset = 1, user_id, NULL)) / COUNT(DISTINCT user_id) AS d1,
       COUNT(DISTINCT IF(day_offset = 7, user_id, NULL)) / COUNT(DISTINCT user_id) AS d7,
       COUNT(DISTINCT IF(day_offset = 30, user_id, NULL)) / COUNT(DISTINCT user_id) AS d30
FROM cohort
GROUP BY cohort_date
ORDER BY cohort_date DESC;

この水準が安定して出せると、施策の効果検出力が高まり、少ないトラフィックでも有意差が取りやすくなります。

行動セグメントで価値導線を出し分ける

同じ初回体験でもユーザーの「したいこと」は異なります。閲覧中心・投稿中心・購入中心といったセグメントをリアルタイムに推定し、ホーム面の導線とメッセージを差し替えると、初週の活性イベント発火率が上がり、D7に寄与しやすくなります。サーバー推定が難しければ、クライアントで簡易なスコアリングを行い、Remote Configでレイアウトを出し分ける方法が現実的です。

初回体験と復帰フローの最適化

オンボーディングは短く、価値は早く、権限は文脈のあるタイミングで求める。基本に忠実でありながら、ここに最も伸びしろがあります。匿名利用から登録へは、Deferred Deep Link（インストール前のタップ文脈をインストール後に引き継ぐ仕組み）とSSO/パスキー（端末組み込みの認証で素早く安全にサインイン）を活用すると摩擦が目に見えて減ります⁵。

SSO/パスキーで登録摩擦を最小化する

iOSでのSign in with Appleとパスキーの実装は、1画面で認証を完結させられるため離脱を抑えます。SwiftUIの簡易例を示します。

import SwiftUI
import AuthenticationServices

struct SignInView: View {
    var body: some View {
        VStack {
            SignInWithAppleButton(.signIn, onRequest: { req in
                req.requestedScopes = [.fullName, .email]
            }, onCompletion: handle)
            .signInWithAppleButtonStyle(.black)
            .frame(height: 48)
        }
    }

    func handle(result: Result<ASAuthorization, Error>) {
        switch result {
        case .success(let auth):
            guard let credential = auth.credential as? ASAuthorizationAppleIDCredential else { return }
            // send to backend, link anonymous id
            Api.link(credential: credential) { ok in
                // proceed
            }
        case .failure(let err):
            // show retry / fallback
            print(err.localizedDescription)
        }
    }
}

AndroidではApp Linksでのディープリンク連携が鍵です。Deferred Deep Linkで広告接触からオンボーディング内の文脈を再現し、体験の断絶を防ぎます。

import android.net.Uri
import android.os.Bundle
import androidx.appcompat.app.AppCompatActivity

class DeepLinkActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val uri: Uri? = intent?.data
        if (uri != null) {
            val campaign = uri.getQueryParameter("cmp")
            val intent = OnboardingActivity.createIntent(this, campaign)
            startActivity(intent)
            finish()
        } else {
            startActivity(MainActivity.createIntent(this))
            finish()
        }
    }
}

一般に、SSOやDeferred Deep Linkの併用は登録完了率の向上や初週リテンションの底上げにつながると報告されていますが、効果幅はプロダクトの前提条件に依存します⁵。

セッション復元とコールドスタート短縮で”戻りやすさ”を作る

復帰時の「どこまでやっていたか」を即座に復元することで、深い再開率が上がります。状態ハイドレーション（直前状態の再構築）を実装し、ネットワーク待ちをまたがずに直前の画面・フォーム内容・スクロール位置を再現します。安全なローカルキャッシュとバックグラウンド更新の組み合わせが要です。

import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

suspend fun restoreSession(): ViewState {
    val cached = withContext(Dispatchers.IO) { Cache.load("view_state") }
    if (cached != null) return cached
    return withContext(Dispatchers.IO) {
        val fresh = api.fetchState()
        Cache.save("view_state", fresh)
        fresh
    }
}

また、コールドスタートでのAPI多発はANRやタイムアウトを招きます。バルクAPIとサーバー集約でラウンドトリップを減らし、UIはSkeletonで先に応答する構成にすると、初回描画までの時間が短縮しやすく、セッション継続時間やD1に好影響が出やすくなります。

適切なタイミングのコミュニケーション運用

通知は万能ではありませんが、文脈・頻度・静穏時間の三点を守ると強力な復帰トリガになります。ユーザーが価値を得る直前の摩擦を取り除くためにだけ使うという原則で設計します⁶。

プッシュとアプリ内メッセージを行動起点で出し分ける

イベント駆動の配信は、遅延が命です。Cloud Functionsでイベント受領から数分以内の配信を実現し、TTLを短く保つことで、陳腐化したメッセージを避けます。

import * as functions from "firebase-functions";
import * as admin from "firebase-admin";
admin.initializeApp();

export const onCartAbandon = functions.firestore
  .document("carts/{uid}")
  .onUpdate(async (change, context) => {
    const before = change.before.data();
    const after = change.after.data();
    if (before.items.length > 0 && after.items.length > 0 && !after.checkedOut) {
      const token = await getFcmToken(context.params.uid);
      const message = {
        token,
        notification: { title: "カートの続き、今なら在庫あり", body: "今すぐチェック" },
        android: { ttl: 10 * 60 * 1000, priority: "high" },
        apns: { headers: { "apns-expiration": `${Math.floor(Date.now()/1000)+600}` } }
      };
      try { await admin.messaging().send(message); } catch (e) { console.error(e); }
    }
  });

静穏時間帯の尊重、チャネル選好の尊重、重複防止のデダプリケーションは必須です。配信結果のフィードバックループを作り、開封・反応・ディセーブル率まで計測することで、短期の復帰率と長期の通知オプトアウト率のバランスが取れます⁶。

リライアビリティの担保は通知より先に効く

クラッシュ率とANRが高いアプリは、それだけでリテンションを消耗します。ネットワークの不安定さを前提に、指数バックオフとジッターを実装し、ユーザー操作は冪等に保ちます。

import kotlin.random.Random
import kotlinx.coroutines.delay

suspend fun <T> retryWithBackoff(max: Int = 5, block: suspend () -> T): T {
    var attempt = 0
    var last: Exception? = null
    while (attempt < max) {
        try { return block() } catch (e: Exception) {
            last = e; attempt++
            val base = Math.pow(2.0, attempt.toDouble()).toLong() * 500
            val jitter = Random.nextLong(0, 250)
            delay(minOf(30_000, base + jitter))
        }
    }
    throw last ?: RuntimeException("unknown")
}

この種の基盤改善は、計測上は地味ですが、セッション継続・次回起動率・NPSまで波及します。Androidの公式ベンチマークでは、クラッシュ率を1%未満、ANRを0.5%未満に抑えることが推奨されており⁷、これらはリテンション改善の前提条件となりやすい指標です。

中長期で効く習慣化・検証・パーソナライズ

短期の復帰トリガだけでなく、アプリ内の習慣形成と実験文化の定着が、大きな伸びしろの源泉になります。ユーザーにとっての「続ける理由」を製品そのものに埋め込み、チーム側は常に検証し続ける運営体制にします。

ストリークとチェックインで使用のリズムを作る

連続利用日数やウィークリーミッションは、過度なゲーム化にならない範囲で導入すると、週次の粘着率（WAU/MAU）を底上げします⁵。状態はクライアントで先に更新し、サーバーで厳密化する非同期モデルが扱いやすい構成です。

import express from 'express';
import { verify } from './auth';
const app = express();

app.post('/streak/checkin', verify, async (req, res) => {
  const user = req.user.id;
  const today = new Date().toDateString();
  const streak = await db.getStreak(user);
  const last = streak?.lastDate;
  const updated = computeNextStreak(last, today);
  await db.saveStreak(user, updated);
  res.json(updated);
});

ストリークは失う痛みが強すぎると逆効果です。グレース期間や回復手段を用意し、健全な継続を支える設計が肝心です。

Feature FlagとA/Bテストを運用の中心に置く

本番での安全な実験がスピードと学習を生みます。クライアントはFlagでUI分岐を行い、計測はバリアント単位で自動紐付けします。

import com.myflags.Flags

fun renderHome(userId: String) {
    val showNewFeed = Flags.isEnabled("new_feed", userId)
    if (showNewFeed) renderNewFeed() else renderLegacyFeed()
}

効果判定はコホート×バリアントでのD7/D30に加え、活性イベントや収益イベントも見ます。A/Aテスト（同一条件同士の比較）で計測のバイアスを点検してから本番実験を走らせる流れを標準化しましょう。

おすすめの個別最適化で価値接触回数を増やす

協調フィルタリングやルールベースでも、推薦の精度が上がるだけで「価値に触れる機会」が増え、結果的に粘着度が上がります。最初は単純な頻度×新規性の混合スコアで十分です。バックエンドでのスコアリング結果をクライアントがキャッシュし、オフラインでも先頭数件は表示できるようにすると、通信不良時でも体験が崩れません。

休眠ユーザーのWin-backをイベント駆動で自動化する

最後の利用から一定日数が経過したユーザーに、価値の再提示と低摩擦の復帰導線を用意します。単なる割引告知ではなく、ユーザーが途中まで行っていた行動の再開を促すのが効果的です。クエリで対象者を抽出し、キャンペーンは常時走る仕組みにします。

-- 14日休眠、直前に"aha_moment"達成者
SELECT user_id
FROM (
  SELECT user_id,
         MAX(event_time) AS last_seen,
         MAX(IF(event_name='aha_moment', event_time, NULL)) AS last_aha
  FROM events GROUP BY user_id
)
WHERE DATE_DIFF(CURRENT_DATE(), DATE(last_seen), DAY) >= 14
  AND last_aha IS NOT NULL;

このリストをトリガに、Push/メール/アプリ内メッセージを連携します。キャンペーンは短期で焼き切れやすいので、クリエイティブと導線の多様性を維持しながら、常に小さくテストを回す体制が鍵です。

ここまでの10施策をどう束ね、60%改善を狙うか

ここまで挙げた要素は、イベント設計の是正、セグメント別の価値導線、SSO/パスキーとDeferred Deep Link、セッション復元とコールドスタート短縮、イベント駆動の通知、信頼性の担保、ストリーク設計、Feature FlagとA/Bテスト、推薦の個別最適化、Win-back自動化の10点に整理できます。鍵は個々の点ではなく、順序と同時性です。最初の2週間は計測と信頼性に集中し、次の2週間でオンボーディングとセッション復元を固め、その後に通知とWin-back、最後に個別最適化とA/Bを継続運転に載せると、効果の立ち上がりが早く、かつ持続します。

なお、平均水準（D7約10〜15%、D30約2〜6%）¹²を起点に、どのボトルネックが最も大きいかをコホートで見極め、上記10施策を段階的かつ並行で回すことが、改善幅を最大化するうえで現実的です。最終値はプロダクトの特性と流入品質に依存するため、土台（計測・信頼性）→初回体験→復帰トリガ→検証と個別最適化という流れを反復し、学習速度を高めることを優先してください。チームの状況に合わせて微調整すると良いでしょう。

性能・指標・体制のメモ

最後に、パフォーマンス目標として、コールドスタートのTTI（操作可能になるまでの時間）は2秒台、クラッシュ率は1%未満、ANRは0.5%未満を一つの目線にすると設計がブレません⁷。計測ではStickiness（WAU/MAU）と有効セッション比（活性イベント/起動）をモニタリングし⁵、ダッシュボードはコホート軸で揃えます。プロセス面では、毎週の実験レビューで「仮説→実装→計測→学び→次の仮説」を1スプリントで回す習慣化が、最も大きな差になります。通知の有効開封率は業界やアプリによって大きく変動しますが、数％台にとどまることが一般的で、配信の関連性とタイミングの最適化が鍵になります⁶。

  • 指標の監視軸 — D1/D7/D30をコホートで可視化
  • <1% — クラッシュ率の目安
  • 2.0s — TTI目標（コールド）

まとめ：速度と学習で、離脱の曲線を変える

リテンションは一発の必殺技では伸びません。計測の精度、初回価値への最短距離、戻りやすい土台、文脈あるコミュニケーション、そして小刻みな検証の蓄積。これらを同時に動かすことで、離脱の曲線はゆっくりと、しかし確実に変わります。今日から着手するなら、イベント設計の是正とクラッシュ/ANRの沈静化、そしてオンボーディングの摩擦除去の三点が最も投資対効果が高いはずです。チームの次のスプリントで、どの仮説を検証しますか。もし迷うときは、社内ダッシュボードにD1/D7/D30のコホートを並べ、最大の落とし穴を一緒に特定しましょう。次の一手は、データの中に必ず見つかります。

参考文献

  1. Adjust. 優れたアプリ継続率の条件とは？（2024年）https://www.adjust.com/ja/blog/what-makes-a-good-retention-rate/
  2. Business of Apps. Mobile App Retention（2024年）https://www.businessofapps.com/guide/mobile-app-retention/
  3. Mistplay. モバイルアプリで追跡すべき8つの重要なユーザー維持指標（2023年）https://ja.business.mistplay.com/resources/mobile-app-user-retention-metrics
  4. Lin YH, et al. Assessing User Retention of a Mobile App: Survival Analysis. JMIR mHealth and uHealth. 2020. https://pmc.ncbi.nlm.nih.gov/articles/PMC7728530/
  5. Userpilot. Mobile App Retention: 8 Strategies and Best Practices That Work（2024年）https://userpilot.com/blog/mobile-app-retention/
  6. PR Newswire. OneSignal State of Customer Messaging in 2023（2023年）https://www.prnewswire.com/news-releases/customer-retention-drives-higher-operating-margin-than-customer-acquisition-during-economic-downturn-onesignal-study-finds-301862739.html
  7. Android Developers. Android vitals の概要（Core vitals としきい値）https://developer.android.com/topic/performance/vitals?hl=ja