◉RORK LABEN
●GPT-6.1 SOL — Rork のモデルメニューに追加(09-29)。Low/Medium/High を選べ、Pro・Max に含まれます●SONNET 5.5 — UI づくりが得意で、Sonnet 5 より出力が速いモデルが選べます(09-28)●SDK 58 — Expo SDK 58 が 10/15 に正式リリースされました(Beta は 09/15 から)。上げる前に依存の対応状況を確認しましょう●WIDGET — iOS のウィジェットが本番ビルドだけ真っ黒になる原因を追った報告が出ています●OBSERVE — EAS Observe がネイティブクラッシュも記録します(SDK 57.0.21 以降・10/07)●NEW — 起動広告が、背面から戻った回にしか出ていませんでした。「前面に戻った」合図が、…●GPT-6.1 SOL — Rork のモデルメニューに追加(09-29)。Low/Medium/High を選べ、Pro・Max に含まれます●SONNET 5.5 — UI づくりが得意で、Sonnet 5 より出力が速いモデルが選べます(09-28)●SDK 58 — Expo SDK 58 が 10/15 に正式リリースされました(Beta は 09/15 から)。上げる前に依存の対応状況を確認しましょう●WIDGET — iOS のウィジェットが本番ビルドだけ真っ黒になる原因を追った報告が出ています●OBSERVE — EAS Observe がネイティブクラッシュも記録します(SDK 57.0.21 以降・10/07)●NEW — 起動広告が、背面から戻った回にしか出ていませんでした。「前面に戻った」合図が、…
記事一覧/ビジネス
⟐ ビジネス/2026-07-19上級

プッシュ通知を1日3件に増やしたら、翌週の再訪が減っていたとき — 通知頻度を D7 リテンションとオプトアウト率で測り直す運用メモ

プッシュ通知を厚くすれば再訪は増えるはず、という思い込みが D7 リテンションを削っていました。通知頻度をコホート別の D7 とオプトアウト率で測り直し、1日3件から1件へ減らすまでの計測と判断の運用メモです。

retentionpush-notificationcohort-analysisD7engagement

✦ プレミアム記事

Rork で作った学習記録アプリの再訪が伸び悩んでいて、私はプッシュ通知を厚くしました。それまで1日1件だったものを、朝・昼・夜の3件へ。理屈はいたって素朴です。思い出す回数が増えれば、戻ってくる回数も増えるはず。

最初の数日、通知経由の起動数は確かに増えました。ダッシュボードのその数字だけを見て、私はしばらく満足していました。ところが2週間後、インストールから7日後の継続率(D7 リテンション)を週ごとに並べたとき、線が下を向いていることに気づきます。通知を増やした週のコホートだけ、D7 が 14.2% から 9.8% へ落ちていました。

戻ってきてほしくて通知を足したのに、その通知が離脱を早めていた。このアプリの収益は AdMob のインタースティシャル広告に乗っているので、D7 が落ちることは翌週の広告表示回数がそのまま減ることを意味します。再訪の数字は、私にとって手触りのある売上の数字でもありました。この記事は、その思い込みを数字で解くまでの記録です。個人開発で回している小さなアプリの話ですが、通知頻度を「感覚」ではなく「コホート」で決めるやり方は、規模を問わず効くはずです。

通知経由の起動数は、増えたように見えるだけでした

最初につまずいたのは、見ていた指標が間違っていたことでした。「通知をタップして開いた回数」は、通知を3倍送れば当然ある程度増えます。送った数が増えたのだから、タップの絶対数が増えるのは自明で、これは施策の成功を意味しません。

本当に見たかったのは、通知の有無にかかわらず「そのユーザーが1週間後も戻ってきているか」でした。通知経由の起動と、通知なしの自発的な起動を、最初から分けて記録しておくべきだったのです。

// lib/analytics.js — 起動を「きっかけ別」に記録する
// これを分けておかないと、通知の効果を過大評価する
 
export function trackAppOpen({ source, userId }) {
  // source: 'push' | 'organic' | 'deeplink'
  analytics.capture('app_open', {
    userId,
    source,                          // ← ここが後の切り分けの生命線
    ts: Date.now(),
  });
}
 
// 通知タップ時
Notifications.addNotificationResponseReceivedListener(() => {
  trackAppOpen({ source: 'push', userId: currentUser.id });
});
 
// コールドスタート(通知以外の自発起動)
if (!launchedFromNotification) {
  trackAppOpen({ source: 'organic', userId: currentUser.id });
}

source を分けて記録し始めてから、絵がはっきりしました。通知経由の起動は週あたり約 1.9 倍に増えていた一方で、自発的な起動(organic)は逆に 12% 減っていたのです。通知で無理に引き戻したユーザーが、自分から開く習慣を失っていく。合計するとプラスに見えず、むしろ D7 を削っていました。

インストール週でコホートを切り、指標を並べます

「通知を増やしたら悪くなった」を主張するには、増やす前と後を同じ物差しで比べる必要があります。私はインストールした週でユーザーを束ね、コホートごとに D1・D7・D30 とオプトアウト率を並べました。

インストール週通知頻度D1D7D30通知オプトアウト率
第1週(基準)1日1件31.4%14.2%6.1%4.3%
第2週1日3件30.9%11.6%—9.7%
第3週1日3件31.1%9.8%—13.1%

D1 はほとんど動いていません。通知頻度は初日の体験には効かないからで、これは筋が通っています。効いていたのは D7 とオプトアウト率でした。通知を厚くした2週は D7 が下がり続け、通知の許可を切るユーザーの割合が 4.3% から 13.1% へ跳ね上がっています。一度オプトアウトされると、そのユーザーへは二度と通知が届きません。目先の再訪と引き換えに、将来の再訪チャネルを焼いていたわけです。

コホートを切る SQL は難しくありません。イベントログさえ source 付きで貯めておけば、あとは集計するだけです。

-- インストール週ごとの D7 リテンション
-- installs: user_id, install_date
-- opens:    user_id, ts, source
SELECT
  date_trunc('week', i.install_date)               AS cohort_week,
  count(distinct i.user_id)                         AS installs,
  count(distinct case
    when o.ts::date = i.install_date + interval '7 day'
    then o.user_id end)                             AS d7_returned,
  round(100.0 * count(distinct case
    when o.ts::date = i.install_date + interval '7 day'
    then o.user_id end) / count(distinct i.user_id), 1) AS d7_rate
FROM installs i
LEFT JOIN opens o ON o.user_id = i.user_id
GROUP BY 1
ORDER BY 1;
✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること
✦通知頻度を変えた週ごとにインストールコホートを切り、D1/D7/D30 とオプトアウト率を並べて比較する計測の組み方
✦「通知経由の起動」だけを見ると増えて見えるのに、総 D7 が落ちる錯覚を、通知なし起動と分けて可視化する手順
✦1日3件から1件へ減らして D7 が回復した実測と、頻度を上げてよいユーザー層の線引き
Stripe による安全な決済 · いつでもキャンセル可能
✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または
メンバーシップなら全記事が読み放題 →
シェア

お読みいただきありがとうございます

Rork Lab は広告なしで運営しており、サーバー費用などの運営コストはメンバーシップのご支援で賄っています。実装コード・ベンチマーク・本番設計パターンなど、実務でお役立ていただける記事を毎日更新しています。もし読んでよかったと感じていただけましたら、ぜひご覧ください。

  • ✦コピー&ペーストで使える実装コード付き
  • ✦毎日新しい上級ガイドを追加
  • ✦¥580/月 または ¥1,480 の永久アクセス
メンバーシップを見る →

関連記事

⟐ ビジネス2026-10-18
提出ログを貼っても直らなかった夜は、末尾ではなく「最初のエラー」から読み直します
Rork の App Store 提出が失敗し、ログを貼って直してもらっても同じ失敗が続くとき。ログの最初のエラー行だけを取り出す 40 行ほどのスクリプトと、公式ドキュメントが挙げる 4 つの原因との突き合わせ方をまとめました。
⟐ ビジネス2026-10-17
予約や物販のアプリで Stripe を使ってよいか — Apple の線引きは「どこで消費されるか」です
予約や物販のアプリに Stripe を入れてよいのか、アプリ内課金を求められるのか。App Review Guidelines の 3.1.1 と 3.1.3 を「どこで消費されるか」で読み分け、売るもの別の判定表と審査メモの書き方をまとめました。
⟐ ビジネス2026-10-16
Rork で作り始めた最初の1年、請求が届く順番を並べてみました
Rork の無料枠から始めると、お金が動く場面は Rork だけではありません。Rork Pro・Apple・Google Play・EAS・Supabase の公式料金ページを突き合わせ、初年度に何がいつ請求され、何が請求ではなく『止まる』のかを時系列で並べました。