4段階のプッシュ通知疲労モデル

プッシュ通知は、ユーザーを失う最も安上がりな方法です。1日あたり1回のプッシュであれば、リテンション曲線は良好に見えます。LocalyticsやUrban Airshipの業界データでは、3か月後のリテンションが88パーセント前後に集中しています。1日あたり3回のプッシュでは、曲線は17ポイント低下します。1日あたり5回では34ポイント低下します。その形状は急激で、後戻りできません。アプリが望まれない週2～5回のプッシュを送ると、46パーセントのユーザーがプッシュ通知を完全にオプトアウトしてしまうのです。

Soulwiseの対応策は、4段階の疲労モデルです。これは直近14日間のローリングウィンドウで開封率の低下を検知し、ユーザーが完全にオプトアウトしてしまう前に、通知の量を段階的に減らしていきます。

この記事では、その設計、しきい値、そして回復ロジックについて解説します。

4つの段階

ステートマシンはシンプルです。すべてのユーザーは、常にいずれか1つの段階に属します。

• T0 - 健全。 フルスケジュール。朝のリチュアル通知、午前中の文脈に応じたナッジ、夜の振り返り、さらにイベント連動型の通知。
• T1 - 降格。 午前中の文脈に応じたナッジが一時停止されます。それ以外はすべて継続します。
• T2 - アンカーのみ。 朝のリチュアル通知と日曜日の振り返りだけが残ります。任意のプッシュ通知はすべて一時停止されます。
• T3 - 週次のみ。 週に1回のプッシュ通知だけが残ります。日々のリズムは停止されます。

順序が重要です。午前中のナッジが最初に外されるのは、イベントの重みが最も低いためです。これは文脈に応じたナッジであり、日々のリチュアルそのものの一部ではありません。朝の通知が最も長く維持されるのは、イベント連動型の日次プッシュが汎用的なものに比べて約2.85倍のリテンションを生むからです。これを止めることは、アプリそのものを止めることに等しいのです。

ティア変更を引き起こす要因

ユーザーごとに、開封率データを14日間のローリングウィンドウで管理します。モデルは毎日、直近の14日間を確認し、その期間中に送信されたプッシュ通知に対するユーザーの開封率を算出します。

Soulwiseのしきい値は、ユーザー個人のベースラインからの開封率の30パーセントの低下です。あるユーザーが通常プッシュ通知の60パーセントを開封しており、ローリングウィンドウでその数値が42パーセント以下に低下した場合、モデルはそのユーザーを1つ下のティアに移動させます。この低下は、単発の不調な週（休暇、体調不良、多忙な仕事の週など）に反応しないよう、最低でも3日間続く必要があります。

昇格も同様の仕組みです。ユーザーがT2にいて、開封率がベースラインから30パーセントのしきい値を引いた水準を3日連続で上回って回復した場合、そのユーザーはT1へと昇格します。T0への回復も同じステップを踏みます。

イベント連動型のプッシュ通知が最も長く生き残る理由

設計の根拠となっているのは、Localytics／Urban Airship のデータです。イベント連動型のデイリープッシュは、汎用的なデイリープッシュと比べておよそ2.85倍のリテンションを生み出します。9時に届く「チェックインしましょう！」といった汎用的な通知は、記憶に残りません。一方、今日の実際のサイクル位相に連動した朝のプロンプト（「ゆるやかなスタート。今日は何が控えていますか？」）はイベント連動型であり、新しい情報を含んでいます。

T2が朝のプロンプトを残しているのは、それを取り除くと日々の習慣そのものが失われてしまうからです。アプリ内のその他すべては、ユーザーが朝に一度、夜に一度ログインすることを軸に設計されています。プロンプトがなければ、このループは崩れてしまいます。

疲労バナーのUX

ユーザーの通知頻度が下げられると、次回アプリを開いたタイミングで、アプリ内に小さなバナーが表示されます。

「7日間、通知を控えめにしていました。元に戻しますか？」

この一文は3つの役割を果たします。変化があったことを認め、その原因をアプリ側の挙動（ユーザーの失敗ではなく）として伝え、そして選択の余地を与えるのです。ユーザーは、通知を元に戻したいと思えば、ワンタップでこの設定変更を取り消せます。

これが重要なのは、何も告げずに頻度を下げると、アプリがユーザーを見放したように感じられるからです。一方、しっかり伝えれば、アプリが気にかけてくれているように感じられます。同じ操作でも、伝え方ひとつで印象は変わるのです。

あえて作らなかったアンチパターン

プロダクト仕様では、禁止事項を明確に定めています。

• 「連続記録を途切れさせないで」という罪悪感を煽るプッシュは送らない。 連続記録は損失回避を利用した羞恥心の刺激です。疲労度モデルはユーザーの優先度を下げるだけで、彼らを辱めることはしません。
• T3の終わりに「会いたいです」という再アクティブ化プッシュは送らない。 T3の時点で、ユーザーはアプリに何かを伝えています。さらにプッシュを増やすのは間違った対応です。
• プッシュ本文に偽のカウンターや希少性を演出しない。 「たった今X人が登録しました」はダークパターンの演出であって、通知ではありません。
• プッシュのタイトルや本文に月経や占星術のコンテンツを含めない。 プッシュはCIのlintチェックを通過し、禁止パターンを含むビルドは拒否されます。疲労度モデルがこれを回避することは決してありません。

システム内部のデータが実際にどのような形をしているか

このモデルは、ユーザーごとの状態を3つのフィールドで保存します。

tier: 'T0' | 'T1' | 'T2' | 'T3'
rolling_open_rate_14d: 0.0 to 1.0
baseline_open_rate: 0.0 to 1.0 (computed from first 30 days)
last_tier_change_at: timestamp

これが疲労状態のすべてです。閲覧履歴もなければ、開封率を超えるエンゲージメントスコアリングもなく、ユーザーを対象に訓練された機械学習モデルもありません。このシンプルさにこそ意味があります。ルールは監査可能で、しきい値は文書化されており、UXへの影響は予測可能です。

これは何ではないか

適用範囲についての注記です。

疲労モデルはユーザー単位であり、コホート単位ではありません。「あなたに似たユーザー」を分析したり、リテンションを学習するためにユーザーを意図的に冷遇する実験を行ったりすることはありません。このモデルは個人のために機能します。

また、ユーザーが管理する設定を置き換えるものでもありません。サイレント時間、カテゴリーごとのミュート、そしてすべてのプッシュ通知を明示的に無効化する設定は、いずれも疲労モデルとは独立して動作します。2つのシステムは協調しますが、ユーザーの明示的な選択は常にモデルの推論よりも優先されます。

アプリ全体にとって、なぜこれが重要なのか

プッシュ通知は、毎日の習慣を「毎日」のものとして定着させる手段です。チェックイン型アプリがプッシュ通知の権限を失えば、主要なリテンションの仕組みそのものを失うことになります。4段階のモデルが存在するのは、アプリがこの権限を乱用し、ほんの少しだけ煩わしい状態を十分長く続けてしまうことで、じわじわと権限を手放してしまわないようにするためです。

毎日の習慣に関するより詳しい背景は、Soulwiseハブでご覧いただけます。疲労モデルは、この習慣が一方的に要求するものではなく、相互的なものであり続けるための理由の一つです。

短く言えば、プッシュ通知の適切な回数とは、オプトアウトを引き起こさない最大の回数です。疲労モデルは、アプリがその回数をユーザーごとに14日ごとに見つけ出すための仕組みなのです。