アプリ リテンション 施策：App Storeの解約画面に出すメッセージを、サーバーなしで設定する

2026年11月4日、AppleはApp Store Connectでretention messages（リテンションメッセージ）の設定を可能にしました。購読者が解約確認画面で目にするメッセージと、必要ならオファーです。これまではRetention Messaging API経由でしか使えず、それもアクセスのリクエストが必要でした。今は管理画面だけで、サーバーのコードを1行も書かずにアプリ リテンション 施策を組めます。

MeteoHealthの購読はRevenueCatを使わず、StoreKit 2で実装しています。だから私の関心は、今日すぐ有効にできるものは何か、そして効いたかどうかをあとでどう判断するか、の2点です。以下では設定の順序、審査で文言が落ちる箇所、そしてAppleとRevenueCatの数字が測っているものの違いを書きます。

購読者に見えるもの#

購読者は設定アプリでサブスクの詳細ページを開き、Cancel Subscriptionをタップします。するとシステムがConfirm Cancellationページを表示し、その中の「From the developer」セクションに皆さんのメッセージが出ます。ボタンはCancel SubscriptionとKeep Subscriptionの2つ。オファーがある場合は、その利用ボタンが出ます。メッセージの形は3種類です。

• テキストのみ
• テキストと画像（オファーがない場合、または購読者が対象外の場合）
• テキストとオファー（対象の購読者のみ。画像は表示されず、オファーが画像の位置に入ります）

対応OSはiOS 15.1以降、iPadOS 15.1以降、visionOS 1以降、macOS 14以降です。それより古いOSでは、解約画面は従来のままです（APIの概要）。

アプリ リテンション 施策の設定方法は2通り#

メッセージはApp Store Connectで作る方法と、Retention Messaging API経由で返す方法があります。併用はできますが、必要なものが違います。

API方式では、有効な購読者が解約ボタン付きのサブスク詳細ページを開いた瞬間に、App Storeが皆さんのエンドポイントを呼び出します。リクエストはApp StoreがJWSで署名しており、この署名は必ず検証してください。中身には originalTransactionId、productId、userLocale、environment などが入っています。応答は本番で700ミリ秒以内に返す必要があり、本番に出す前にサンドボックスのPerformance Testを通さなければなりません。リクエストが失敗した場合は、その購読に設定したApp Store Connectのメッセージが出て、なければデフォルトメッセージが出ます。

優先順位は、リアルタイムの応答が最上位、次にApp Store Connectのメッセージ、最後にAPIのデフォルトメッセージです。11月4日のAPI 1.6からは、リアルタイム応答でApp Store Connectで作ったメッセージの識別子を返せるようになりました（変更履歴）。管理画面で作った素材を、サーバーが選んで出せるわけです。

APIのデフォルトメッセージは「プロダクト×ロケール」単位で、テキストのみ、オファーは付けられません。APIの利用申請について、AdaptyはAppleの審査に最長1か月かかると書いており、早めの申請を勧めています。これはAdaptyの記述で、Appleのドキュメントには期間の記載がありません。

私ならApp Store Connectから始めます。効果が未知の実験のためにサーバーを用意する必要はありません。効果が出たら、あとからAPIを足せます。1.6以降は、サーバーがApp Store Connectで作ったメッセージを返すこともできるからです。

App Store Connectでの設定手順#

詳細はAppleのヘルプとWWDC26のセッション309にあります。

1. アプリを開き、Monetization、Subscriptions、Retention Messagingの順に進んで、「+」またはGet Startedを押します。
2. Reference nameを付けます。購読者には見えません。
3. ヘッダーと本文を入力します。どちらも必須です。購読を販売しているすべてのストアフロントに合わせてローカライズしてください。
4. 画像を使うなら、3840 × 2160 または 5244 × 2950 ピクセルで用意します。ファイル形式と容量はヘルプに記載がありません。
5. 対象の購読を選びます。メッセージは1アプリあたり最大10件で、1件のメッセージに紐づけられる購読数に上限はありません。ただし1つの購読に紐づくメッセージは同時に1件だけです。
6. 必要ならretention offerを添付します（次の節）。
7. プレビューを開きます。カード表示、iPhoneとiPad向けの表示を確認でき、オファーの選択かNoneも切り替えられます。
8. Add for Reviewを押します。ステータスがApprovedになれば、メッセージは有効で、解約しようとしている対象の購読者に表示されます。

オファーの作り方#

retention offerはメッセージ単位ではなく購読単位で作り、購読者にはメッセージ経由でしか見えません。料金プランの種類（標準、または年間購読向けの12か月コミットメント付き月額）ごとに最大10件まで作れて、10件すべてを1つのメッセージに付けることもできます。どれを見せるかはApp Storeが決めます。WWDCでAppleは「対象の顧客に対して、App Storeが自動的に最適なオファーを選びます」と説明しています。

作る前に知っておくことが2つあります。Reference nameとオファー識別子は、作成後に変更できません。識別子はSales and TrendsでのセールスやStoreKitのトランザクションの追跡に使われるので、半年後に見ても意味が分かる名前にしておきましょう。

誰が対象になるかは条件で決まります。Paid Subscription Durationは、有料購読者として過ごした最低期間を求める条件です。Wait Between Offersは任意で、購読全体ではなくオファーごとに効きます。オファーの種類はPay as you go、Pay up front、Freeの3つ。他の国の価格は最新の為替レートで計算され、上書きもできます。

審査で落ちる文言#

ヘッダーと本文には、プロモーション、割引、具体的な価格を書けません。「$9.99」も「50% off」も「1か月無料」も不可で、審査で却下されます。本文はすべての購読者に見えるのに対し、オファーは対象者にしか見えないためです。

書いてよいのは、解約で失うものについての事実です。強要したり、確かめようのないことを断言したりするのは避けます。Appleが挙げる例は、VPNを解約するとウイルスに感染する、と書いてはいけない、というものです。「最高のアプリ」のような最上級表現や、裏付けのない統計は、Appleが強く非推奨としています。全部大文字や感嘆符の連打も、使わないよう求めています。

以下は「天気から体調の見通しを出す購読アプリ」を想定した例です。これらの文言は、説明のために私が自分で書いたものです。

文字数について。ヘッダー66文字、本文144文字という上限は、Retention Messaging APIのドキュメントにあるものです。App Store Connectで入力するメッセージの上限は、ヘルプに書かれていません。管理画面側の上限が示されていない以上、私なら同じ範囲に収めます。

バージョン管理の落とし穴#

• メッセージは元に戻せません。承認済みのメッセージを編集するとNew Versionができ、下書きは公開中の版の横に置かれ、購読者には引き続き公開中の版が表示されます。承認されると下書きが公開版を置き換え、前の版には戻れません。
• サンドボックスには、下書きを含む最新の版が表示されます。テスターには、まだ購読者に見えていない内容が見えることがあります。
• メッセージの削除は取り消せません。上限の10件に達していると、11件目を作るには既存のものを削除するしかありません。
• 1つの購読が属せるメッセージは1つです。別のメッセージで同じ購読を選ぶと、前のメッセージからは外れます。編集のあとは、どの購読がどのメッセージに紐づいているかを確認してください。

自動化について。WWDCではApp Store Connect APIも「Retention Messagingをサポートする予定」と語られ、ヘルプには同APIでメッセージを自動化できると書かれています。ただしエンドポイント名はドキュメントで見つけられませんでした。そのため、App Store Connect APIで自動化を組む土台は、今のところありません。

効果はあるのか#

AppleはWWDCで数字を出しています。save rateの平均上昇は1.4ポイントで、これは82%の増加にあたります。プロモーションオファー付きメッセージが最も高く、5.5ポイント、つまり223%の増加です。AppleはSave rateを、解約確認ページに到達した購読者のうち購読を続けた人の割合と定義しています。同じ説明の中でAppleは、開発者ごとに結果は異なると断っています。期間とサンプル数は示されていません。

RevenueCatのデータは別の姿を見せていて、こちらはベンダーのデータであり、第三者による調査ではありません。RevenueCatは10月6日に初期のベンチマークを公開しました。対象は早期アクセスの309アプリ（各100件以上のメッセージ）が送った21,960,020件で、期間は2026年3月22日から9月20日です。

• save rateの中央値は16.7%。下位4分の1のアプリは100人中10人未満、上位4分の1は27人超、上位10%は42以上。
• 6月から9月のオファー承諾率は、プロモーションオファーが1.1%、プラン変更が0.6%。
• 解約への影響は、有料顧客500人以上の64アプリを、条件を揃えた比較対象と見比べて調べています。RevenueCatの結論は、どちらの方向にも測定可能な効果は見えない、というもの。分析自体は、メッセージが購読者を留まらせた、あるいは更新させたことを証明するものではない、と書かれています。
• メッセージを使うアプリの割合は収益と共に増えます。月間収益が$1M以上で44.4%、$100k〜$1Mで16.9%、$10k〜$100kで4.7%、$1k〜$10kで1.3%、$1k未満で0.06%。

最後の点は、ほかの数字を読むうえで重要です。メッセージを使っているのは大きなアプリが中心なので、私の見立てでは標本が偏っている可能性があり、小さなプロジェクトでは違う挙動になるかもしれません。AppleとRevenueCatの数字は、そのまま比べられません。Appleは期間も標本も示しておらず、RevenueCatは初期参加者のデータだからです。

App Store Connectでの設定にかかるのは、管理画面での作業と審査だけです。自分のアプリでどうなるかは、自分の購読者でしか分からないので、効果は自分のデータで測ることになります。

測定のためにAppleが用意しているものは2つあります。購読者がretention offerを利用すると、署名付きトランザクションとrenewal infoに、値が5の offerType が入ります。もう1つは、オファー識別子がSales and TrendsとStoreKitのトランザクションに出ることです。これで、オファーを受けた人とそうでない人の更新を比べられます。Appleのヘルプには、対照群と比較する仕組みは見当たりませんでした。更新の比較は自分で組む必要があります。

MeteoHealthでの計画です。これは計画であって、まだ何も設定していません。最初は、失うものの事実だけを書いたテキストのみのメッセージをオファーなしで出し、解約の割合を、出す前の1か月と出した後の1か月で比べます。これはA/Bテストではありません。解約には季節も影響します。次にオファーを足し、offerType 5で何人が受け入れたか、その後に更新したかを見ます。結論が出るまでどれだけ待つかは、月あたりの解約数によります。

retention messagesとwin-back offersの違い#

retention messageを見るのは、解約ボタンを押した時点の有効な購読者です。win-back offerを受け取るのは、すでに辞めた人です。2024年9月10日に発表されたwin-back offersの対象は元購読者で、App Store、アプリ内、リンク、サブスクの設定画面に表示されます。どちらかがもう一方の代わりになるわけではありません。それでも辞めた人は、すでにretention messageを見ています。次はwin-backの番です。

公開前チェックリスト#

1. 購読の設定が済み、利用規約とEULAへのリンクがある。まだなら、サブスクのEULA・利用規約リンクの記事から始めてください。
2. 方式を決めた。App Store ConnectかAPIか。APIなら利用申請を早めに出している。
3. ヘッダーと本文に価格、割引、全部大文字、感嘆符がなく、失うものの事実が書かれている。App Reviewの要件と照らし合わせる。
4. 購読を販売しているすべてのストアフロントにローカライズがある。
5. 画像がある場合は、3840 × 2160 または 5244 × 2950 である。
6. オファーを使うなら、識別子が意味のある最終版で、条件（Paid Subscription Duration、必要ならWait Between Offers）が設定されている。
7. iPhoneとiPadでプレビューを確認し、サンドボックスでオファーありとなしの両方を試した。
8. 承認後、購読が意図したメッセージに紐づいている。
9. 測定の仕組みがある。レポートで offerType の5とオファー識別子を追える。トランザクションとrenewal infoはStoreKit 2で読めるので、詳しくはStoreKit 2のサブスク実装を参照。