AppleとGoogleはプッシュ通知に何をしているのか
(jacquescorbytuech.com)- プッシュ通知は単なる配信レイヤーではなく、AppleとGoogleが解析・順位付け・要約・書き換えを行うプラットフォーム編集チャネルへと変わりつつある
- APNsとFCMはバッテリー節約のための中央仲介構造として始まり、すべてのiPhone・Android通知は当初からプラットフォームサーバーを経由してきた
- Androidのチャネル、iOSのFocus・Summary、Android 13の権限変更は送信者の制御権を弱め、ユーザーの注意をプラットフォームが防衛する構造を作った
- オンデバイスモデルは表示レイヤーで通知を要約・グループ化・格下げするが、送信者には要約・Focus抑制・優先度低下の有無を検知するAPIがほとんどない
- 実務的にはプッシュを休眠ユーザーの呼び起こしと時間に敏感なトランザクション通知に限定し、セグメンテーション・パーソナライズとアプリ内などの所有面へ重心を移す必要がある
プッシュ通知がプラットフォーム編集チャネルへ変わる流れ
- プッシュ通知はメールのような単純な配信レイヤーではなく、AppleとGoogleが途中で解析・順位付け・要約・書き換えするチャネルへ移行中である
- AppleとGoogleはiPhoneとAndroidの中核的なプッシュ経路を運営しており、この5年でデバイス内モデルが配信とロック画面の間に入り込み、通知を要約・再整列し、一部の画面では書き換えまで行うようになった
- メールではGoogle、Yahoo、Microsoft、Appleの4事業者がブランドと顧客の間の能動的な仲介者になったが、プッシュではAppleとGoogleの2事業者が同じ役割を担う構造である
バッテリー問題から始まったプッシュアーキテクチャ
- プッシュは最初からバッテリー問題のために中央仲介構造として設計された
- 2009年のWWDCでScott Forstallは、インストールされたすべてのアプリがそれぞれリモートサーバーをバックグラウンドでポーリングするとiPhoneは耐えられないと説明し、Appleは各デバイスがAppleと1本の永続TLS接続を維持し、その接続で第三者が通知を配信するApple Push Notification Serviceを提案した
- APNsは初期の2008年9月の発表後、スケーラビリティ問題で遅延し、2009年6月17日にiPhone OS 3とともにリリースされた
- Googleは2010年のCloud to Device Messaging、2012年のGoogle Cloud Messaging、2016年のFirebase Cloud Messagingへと続く道を選んだ
- iPhoneに送られるすべての通知はAppleサーバーを通り、Androidに送られるすべての通知はGoogleサーバーを通る
- プラットフォームは常に通知を制限・削除・記録・低優先度処理・拒否できたが、変わったのはAppleとGoogleが以前ほど自制しなくなった点である
15年間で大きくなったプラットフォーム介入
- 初期の消費者向けプッシュ時代には、APNsとGoogleのサービス群がユーザーのインストールしたアプリに通知を届けており、プラットフォームレベルのフィルタリングは限定的だった
- ユーザー制御も概ねアプリ単位のオン/オフトグル1つに近かった
- Androidで最初の重要なデバイス内介入は、2017年8月のAndroid 8 Oreoのnotification channelsだった
- Android 8以前は個々の通知に送信者が決めた優先度が付いていたが、その後は開発者がチャネル単位で定義し、ユーザーがチャネル単位で制御するようになった
- 開発者はアプリごとにダウンロード、メッセージ、プロモーションのようなチャネルを宣言し、各チャネルに
IMPORTANCE_NONEからIMPORTANCE_HIGHまでの重要度を与える - ユーザーはチャネルごとにミュート、重要度低下、バッジ無効化、完全ブロックを他のチャネルに影響させず設定できる
- 開発者が一度設定したチャネル重要度は後から上げられず、Android 8を対象とするアプリはチャネルを宣言しなければ通知が表示されない
- Appleは2021年9月のiOS 15でFocus、Scheduled Summary、4段階のinterruption taxonomyを導入した
- 4段階はpassive、active、time-sensitive、criticalで、実質的に開発者が扱えたレベルはtime-sensitiveだった
- Appleはtime-sensitiveをマーケティングに使ってはならないと明記しており、この方針は現在も維持されている
- Androidは2022年8月のAndroid 13で
POST_NOTIFICATIONSをランタイム権限に変更し、暗黙のオプトインではなくユーザーの明示的な許可を求めるようにした- Pushwooshの1,600万デバイス標本では、ゲームアプリがオプトインベースのほぼ3分の1を失い、ニュースアプリは19%減少した
- Batchの2025年ベンチマークは、10,000アプリの8,000億件超のメッセージを基に、Androidのオプトインが1年で85%から67%へ落ち、クロスプラットフォーム平均が61%にとどまったと示している
- 各段階は送信者の制御権を弱め、受信者の注意をプラットフォームが防衛すべき希少資源として扱う方向へプッシュチャネルを作り変えてきた
- クリーンで疲労の少ない通知面は、プラットフォームの維持率とエコシステムを守り、削除を減らし、AI機能を見せる手段にもなるため、プラットフォーム編集は純粋なユーザー擁護だけではない
メールが先に経験した仲介化
- メールはプッシュより先に仲介化され、プッシュでも同じ流れが一段遅れて並行している
- プッシュはメールよりさらに不利なチャネルである
- メールにはPostmaster Toolsや配信到達性ダッシュボードのような計測手段があるが、プッシュにはほとんどない
- メールは受信トレイに残るためユーザーがスクロール・検索・再訪できるが、通知は通知センターで消され、流れ落ち、要約され、安定して保存されない
- Gmailは2013年にtabbed inboxで正当なメールをPrimary、Promotions、Social、Updatesに分類し、Apple Mailは2024年に独自分類を追加した
- Mail Privacy Protectionは2021年9月のiOS 15に含まれ、Apple Mailがユーザーの実際の開封有無と無関係にApple管理のプロキシ経由でリモートコンテンツを事前取得するようにした
- この方式はIPアドレスを隠し、マーケターが依存していたopen pixelの仕組みを壊した
- OmedaはAppleによる開封率が6か月で22.6%から40.5%へ上がったが、これは読者増ではなくプリフェッチによるものだと観察した
- 従来型の開封率は回復不能となり、クリック率と下位コンバージョンがエンゲージメントシグナルの代わりになった
- YahooとGoogleは2024年初頭から、個人の受信トレイに実質的なボリュームを送る送信者に対し、SPFとDKIM認証、DMARC整合、ワンクリック配信停止、低いスパム苦情率の維持を求めている
- メールはオープンで連合的なプロトコル上で動くが、プッシュ購読は特定デバイス上の特定インストール、ネイティブアプリ、またはiOS 16.4以降のホーム画面Webアプリ内にある権限として存在する
- プッシュはAPNsまたはFCMトークンに結び付けられ、AppleやGoogleがそのトークンを任意に無効化でき、送信者は他所へ持ち運べるリストを持てない
- Web pushはApp Storeダウンロードなしで送れるため送信者の範囲を広げるが、同じ通知トレイと同じデバイス内編集を受けるため、編集者から逃れられない
- プッシュでも送信者は、自分の通知が要約されたのか、Focus modeの後ろに隠れたのか、デバイス内モデルによって低優先度化されたのか、静かなフォルダに入れられたのかを知るのが難しくなっている
デバイス内エディタ
- メールの編集は主に送信中に行われる一方、プッシュ通知の編集は表示レイヤーで行われる
- 通知を表示するか、要約するか、低優先度にするか、グループ化するかは、デバイスの表示レイヤーで決定される
- 重要なのはネットワークではなくデバイス内モデルであり、その重みとシグナルは公開されていない
- Apple Intelligenceは、30億パラメータのデバイス内 foundation language model と、Private Cloud Computeで利用可能な、より大きな Parallel-Track Mixture-of-Experts サーバーモデルを使用する
- 2025年7月の技術レポートでは、Apple silicon向けのKV-cache sharingと2-bit quantization-aware trainingを扱っている
- Apple Intelligenceの機能は、基盤モデルを直接使うのではなく、通常は数十MB規模の小さなLoRAスタイルのアダプターをOSが動的にロードし、要約、エンティティ抽出、文の磨き込み、通知の優先順位付けといった作業に特化させる
- BBCが要約によって誤った見出しが生成されると抗議した後、AppleはiOS 18.3でNews and Entertainmentアプリの要約を無効化し、AI要約をイタリック体で表示し、ロック画面にアプリごとのオフスイッチと誤りの可能性に関する警告を追加した
- GoogleのGemini Nanoは、Android 14で導入されたシステムサービスAICore内で動作する
- AICoreはモデルをシステムパーティションに置き、権限のあるアプリが重みを共有し、各推論リクエストを分離し、入出力データを保存しない
- AICoreはAndroid Private Compute Coreの原則に従い、制限付きpackage binding、直接のインターネットアクセス遮断、Google Play System Updatesによるモデル更新を適用する
- Gemini NanoはデバイスのNPU、GPU、CPUへ自動でルーティングされ、Low-Rank AdaptationによってPixel Recorderの要約、通知の整理、smart replyのような機能を基盤モデルの再学習なしに特化できる
- 通知ごとの編集フローは、アプリがペイロードを作成してAPNsまたはFCMに送信した後、OSがまずFocus modes、Do Not Disturb schedules、channel mutings、アプリごとのブロックといったユーザー制御ルールを適用する形で進む
- その後、通知はプラットフォームのランキングおよび表示ロジックに入り、iOSのNotification Summariesが有効なら、OSは結合されたテキストを要約アダプター付きのデバイス内モデルに渡し、元のタイトルと本文を生成文に置き換えることがある
- Priority Notificationsが有効な場合、iOS 18.4以降ではデフォルトでオフの状態から、システムが学習済みのアプリ別ランキングを適用し、一部の通知を固定表示し、他を下位に下げることがある
- Reduce Interruptions Focusが有効になると、モデルは各通知がユーザーがカスタマイズした重要度しきい値を超えるかどうかを評価する
- Microsoft Technology Licensing LLCのUS 11,340,963とGoogle LLCのUS 11,609,806、US 8,707,201は、通知の書き換え・配信タイミング・優先順位付けを学習モデルで扱う方向性が、iOS 18を巡る論争よりはるか以前から存在していたことを示している
送信者が制御できる限定的な手段
- iOSの
UNNotificationServiceExtensionは、アプリコードが表示前に配信された通知を短時間だけ変更できるようにするもので、ペイロードの復号、画像の取得、テキストの修正に使える UNNotificationContentExtensionは、拡張ビュー向けのカスタムUIを定義できるようにする- どちらの拡張も、プラットフォームの要約または優先順位付けの段階より後には実行されない
apns-priorityヘッダーは5か10のいずれかを指定し、5は緊急でない通知を省電力のタイミングで配信し、10は実際に対話性のある通知を即時配信するためのものだ- Androidでは、開発者は
NotificationManagerに書き込み、チャネル重要度を宣言するが、システムの分類から逃れることはできない NotificationListenerServiceは、OEMとアクセシビリティアプリが受信通知を読む際に使うシステムレベルAPIだ- 通知が要約されたか、Notification OrganiserのPromotionsセクションに入ったか、Focusによって抑制されたか、Priority Notificationsによって静かに低優先度へ下げられたかを検出するAPIは存在しない
ウェアラブルは電話の通知ストリームの部分集合
- Apple WatchはデフォルトでiPhoneの通知をミラーリングするが、iPhoneのFocusとSummaryの状態に従う
- watchOS 11から、Smart Stackは位置、時間、カレンダーといったデバイス内シグナルを使って関連ウィジェットを表示する
- Wear OSはデフォルトでスマートフォンの通知をペアリングされたウォッチへブリッジし、companion watch appがインストールされている場合は、重複を防ぐため
BridgingConfig、setBridgeTag、setDismissalIdのような開発者向け制御を提供する - 低優先度通知のウォッチへの配信は抑制できるが、ユーザーがスマートフォンでミュートした通知をウォッチへ強制配信することはできない
- ウェアラブルはスマートフォン通知ストリームの厳密な部分集合であり、上流で同じプラットフォーム編集を受け、下流でブリッジ動作とウォッチ側のcomplicationという追加フィルターを通過する
ユーザーが通知を実際に扱う方法
- ほとんどの通知は即時のアプリ切り替えを引き起こさず、ユーザーが認識したあとに元の作業を続けられるようにする認知シグナルとして機能する
- Sahami Shirazi、Henze、Dingler、Pielot、Weber、SchmidtによるCHI 2014の研究「Large-Scale Assessment of Mobile Notifications」は、Androidランチャーの計測を通じて4万人以上のユーザーから約2億件の通知を収集した
- メッセージング通知は一貫して最も価値が高く、プロモーション通知は一貫して最も低く評価された
- 人から来たメッセージとブランドから来たメッセージを異なる面で扱うべきだという実証的根拠になった
- Pielot、Church、de OliveiraによるMobileHCI 2014の研究「An In-Situ Study of Mobile Phone Notifications」は、ユーザーが1日平均63.5件の通知を受け取り、その大半がメッセンジャーとメールから来ており、携帯電話がサイレントでも数分以内に注意を向けるという結果を示した
- Okoshiらが作ったAtteliaは、ユーザーの携帯電話操作の中断点を検出してその時点まで通知を保留するミドルウェアであり、統制研究で認知負荷を46%、実環境で33%減らした
- その後のYahoo! Japanアプリ内部での大規模展開では、送信タイミングの調整だけでクリック率が最大60.7%上昇した
- Localyticsは、プッシュ通知をオフにしたユーザーの52%が最終的にアプリから完全に離脱し、ほとんどのアプリでは週2〜5件の通知が最適範囲であり、セグメント化された対象は全体配信に比べて約2倍の開封率を示すと発表した
- CleverTapに統合されたLeanplumは、パーソナライズ通知の開封率が通常の全体配信より約800%高く、開封されたプッシュ通知の90%が1時間以内に行動につながると発表した
- CleverTapの2025年フィンテック報告書は、セグメント化キャンペーンの平均開封率を16.3%、非ターゲティングキャンペーンを4.7%と示している
- ベンダー自身の報告値は割り引いて見るべきだが、方向性は一貫している
- 配信量は許可を殺し、関連性が制御可能な唯一の安定したレバーである
- 配信タイミングも重要だが、関連性ほど重要ではない
- プロモーションのように見えるものはたいていプロモーションとして分類され、その判断はしばしば正しい
- ユーザーはプロモーション通知よりも、取引型・対話型通知をはるかに高い頻度で許容する
- プラットフォームの編集は全体配信とプロモーション性の高いプッシュに最も強く作用し、ユーザーが本当に望む通知はそのまま通過するか、むしろ強調される傾向がある
- Live Activitiesは最も明確な回避経路である
- ActivityKitセッションは通知トレイとは別の面であるロック画面とDynamic Islandにレンダリングされるため、要約機能やグルーピングの影響を受けない
- AndroidのLive Updatesと進行中通知も同じ役割を果たす
- 配車、配送、試合、タイマーのように実際に進行中の取引型コンテンツでは、プラットフォームのエディタを避ける最もクリーンな経路である
- 実際に進行中のイベントにしか使えず、プロモーションをLive Activityのように装うことはできない
- Dekker、Baumgartner、Sumter、Ohmeによる2024年のMedia Psychology研究「Beyond the Buzz」は、1週間の無作為化実験で通知の無効化が携帯電話の確認頻度や画面時間を減らさず、ユーザーがアプリに直接入る形で代償行動をしたと報告している
マーケターが見えるもの
- マーケターの可視性は意図的に低く設定されており、さらに悪化している
- 測定指標は信頼性が高い順から低い順に、送信、プラットフォーム受理、デバイス配信、デバイス表示、開封、貢献コンバージョンへと続く
- APNsとFCMはサーバー送信時にレスポンスコードを返すため、プラットフォーム受理は安定して把握できるが、APNsはSMTPのような配信確認を提供せず、Appleがペイロードを受理してキューに入れたことまでしか分からない
- FCMはメッセージIDと一部ケースで配信コールバックを提供するが、「デバイスに配信された」と「ユーザーに表示された」の境界は依然として不透明である
- iOSはオフライン時にアプリごとの最新通知しか保存しないため、古い通知はユーザーに到達する前に静かに削除される可能性がある
- Braze、Iterable、OneSignal、Airship、CleverTap、MoEngage、Pushwoosh、Customer.io、Batchのようなライフサイクルプラットフォームは、アプリSDKベースの測定を追加する
- SDKは通知表示、ユーザーのタップ、タップによるセッション開始の有無を記録する
- 詳細度はiOSのNotificationServiceExtensionまたはAndroidの同等のbroadcast receiverを宣言しているかどうかに依存する
- 拡張がない場合、「配信済み」は再び「APNs/FCMが受理した」に縮小され、ユーザーが実際に見た数より見かけ上の配信率が膨らむ
- OneSignalの自社ガイドによれば、クリック率は慣例的にタップ数を配信数で割った値であり、配信は通常「FCMまたはAPNsを通過した」ことを意味する
- この方式には、表示されなかった通知、読まずにスワイプされた通知、静かに解除された通知、FocusやReduce Interruptionsフィルターの背後に隠れた通知まで含まれる
- 一部プラットフォームの「confirmed delivery」はSDKがレンダリングを確認した通知を数えるため、より実態に近いが、ユーザーが解除前にレンダリングされた通知を実際に見たかどうかは分からない
- AppsFlyer、Adjust、Branch、Singular、Kochavaのようなモバイル計測パートナーは、ペイロードに追跡リンクを入れ、その後のSDKイベントと照合して下位セッションを特定のプッシュキャンペーンに帰属させる
- Amplitude、Mixpanel、Heap、PostHogのようなアプリ内分析ツールは、下位セッションは見えるが、それ自体では上位通知は見えない
- プッシュプラットフォームの送信・開封イベントを共有ユーザー識別子とともに分析ツールへ送れば、通知、セッション、コンバージョンを結び付けられるが、「配信された通知がどれくらいの頻度で表示・要約・格下げ・Focusによって抑制・未確認になったか」というファネル中間部は復元できない
- プラットフォームが提供しないシグナルが多数存在する
- iOSで通知がNotification Summaryにまとめられたかどうか
- PixelでNotification OrganiserのPromotionsセクションに入ったかどうか
- Reduce Interruptionsによってサイレント化されたかどうか
- Priority Notificationsによって格下げされたかどうか
- iOSでユーザーがロック画面から読まずにスワイプしたかどうか
- ユーザーが通知を抑制するFocusモードにいるかどうか
- iOSの保存上限のため表示前に削除されたかどうか
- Samsung One UI 8.5が要約したかどうか
- プッシュがメールより優れている点の1つはAndroidのdelete-intentである
- ユーザーが表示された通知をスワイプして消したときにイベントが発生し、意図的な解除を記録できる
- Android専用であり、表示された通知に対してのみ発生し、熟慮したスワイプと全消去を区別することはできない
- 2026年のプッシュ計測は、Mail Privacy Protection以後のメール計測のように、見えない編集レイヤーの下にある指標を、実際に行動したユーザーだけを捉えるコンバージョンデータで補正する形になる
パイプ内のモデルに向けた書き方
- 配信文面全体は、もはや完全な形では残らない
- オンデバイス要約機能は通知を要点へ圧縮するため、伝わるのはブランドトーンではなく具体的な事実である
- 金額、名前、時間、行動のような中核payloadを先頭に置くと、要約機能が保持すべき対象が生まれる
- ブランド流の導入文、感嘆詞、絵文字、言葉遊びのあとに核心を埋もれさせると、要約機能が絵文字だけを残して意味を捨てたり、誤った半端な内容だけを残したりする可能性がある
- タイトルは自然言語で書かれた構造化データフィールドのように扱うべきである
- “Your delivery is 15 minutes away” は要約でも安定している
- “We've got great news!” は事実を含まないため安定していない
- タイトルの最初の数語だけが残っても、ユーザーに有用な情報を与えられるか確認するやり方が、粗い自己点検になりうる
- これは保証ではなく、習慣として扱うべきである
- Live ActivitiesとLive Updatesにも同じ原則が適用され、中心的な提案はETA、スコア、歩数のようなフィールドであり、ブランド向けの装飾ではない
- 時間依存のinterruption levelを乱用すべきでない根拠は、Batchの開発者ガイドに明記されている
- “If your time-sensitive notifications are not often interacted with, iOS will prompt your users from the lock screen to let them disable time-sensitive alerts for your app”
- ユーザーはロック画面から1回のタップでアプリ別の時間依存通知を無効化でき、送信者側に同等の異議申し立て手段はない
所有する面への重心移動
- プッシュはライフサイクルプログラムの中で、より小さな役割を担うべきである
- アプリ内で所有する面は、侵襲性が低い順に分けられる
- ユーザーが意図的に到達するフィード内の受動的なインプロダクトカード
- ユーザーが再び戻れる永続的なアプリ内メッセージセンターまたは受信箱
- アクティブなセッション中にのみ表示される、セッションイベントベースのターゲティングされたアプリ内メッセージ
- ユーザーが作業を完了しようとしてすでに訪れている画面に配置された、プロダクトフロー内の埋め込み型メッセージ要素
- これらの所有面はAPNsやFCMを通らず、Apple IntelligenceやGemini Nanoにも触れられない
- 要約やFocusによる抑制なしにSDKがレンダリング、解除、インタラクションイベントを記録するため、プラットフォーム媒介の空白なく観測できる
- 限界は、所有面がアクティブユーザーにしか到達できない点である
- 14日間アプリを開いていないユーザーにはアプリ内メッセージでは届かず、プッシュでしか届かない
- プッシュは休眠ユーザーの再エンゲージメントと、アクティブユーザー向けのトランザクション性・時間依存通知チャネルとなる
- クロスセル、アップセル、コンテンツ発見、教育、付加価値はインプロダクト面が担う
- Batchの2025年データでは、プロモーションコードキャンペーンのアプリ内メッセージのクリック率はAndroid 16.1%、iOS 17.9%で、プッシュCTRより高かった
- 同じデータでは、アプリ内はセッションが必要なため、到達可能な対象がプッシュより小さい
- プッシュはユーザーをプロダクトへ呼び戻すために存在し、ユーザーが入ってきた後は所有面が引き継ぐ
次の変化: 通知を処理するエージェント
- オンデバイス言語モデルは、いったん搭載されると要約を超えてさまざまな用途に使われる
- AppleのFoundation Models frameworkは、iOS 18.4から開発者がオペレーティングシステムで使われるのと同じモデルを、要約、エンティティ抽出、テキスト理解、推敲、短い会話に呼び出せるようにする
- GoogleのML Kit GenAI APIsは、AICore上で要約、校正、書き換え、画像説明を公開している
- 次の段階は、モデルが通知に応答してユーザーの代わりに行動する方向である
- 可能な行動には、アプリを開く、予約を完了する、通知を解除する、返信の下書きを作成することなどがある
- より重い推論は、デバイス内だけで実行されるのではなく、Apple Private Cloud ComputeやGoogleのクラウドモデルのようなサーバー側で実行される可能性が高い
- AppleのApp Intentsフレームワークは、開発者がSiriとApple Intelligenceに型付きのアプリ操作を公開できるようにする
- Androidでは、App ActionsとGeminiがサードパーティーアプリ内で動作する新興の能力として同等の役割を果たす
- 送信者は、要約機能に壊されない通知を書くことにとどまらず、通知の背後にある行動を公開し、エージェントがユーザーがアプリを開かなくても予約を完了したり通知を消したりできるようにしなければならない
- 通知は目的地ではなく、エージェントが消費するトリガーとなり、10年間プッシュ測定の中心だったクリック率指標は大きく意味を失う
プッシュ通知を扱う実務原則
-
プッシュは他のチャネルではできないことにだけ使う
- プッシュは数週間アプリを開いていないユーザーにも届くチャネルなので、休眠ユーザーの掘り起こしと本当に時間に敏感なトランザクション通知に最も適している
- クロスセル、アップセル、教育、発見目的の通知も、十分な適時性とパーソナライズがあれば可能だが、基本的には販促と分類され、ユーザーの注意という限られた予算を巡って最も不利に競争する
- 販促メッセージは、ユーザーが意図して開いた画面で見せるほうが効果的でリスクも低い
-
ユーザーの活動とリクエストを中心に設計する
- プラットフォームの中間編集を通過しやすい通知は、ユーザーが自分で設定したシグナルと、プロダクトがユーザーの状態から生成したイベントである
- 値下げ、再入荷、お気に入りリスト、しきい値トリガー、待機中アイテムの状態通知は、ユーザーが自分で設定したシグナルに当たる
- 共有ドキュメント、作業物についたコメントや返信、完了した作業、超過した上限、進行中タスクの次の段階は、プロダクトがユーザーの状態から生成したイベントに当たる
- どちらのタイプも受信者の「自分ごと」に関する通知なので、関連性の基準を自然に満たし、ユーザーがすぐ行動できるプロダクト内の場所へディープリンクすべきである
-
権限要求は初回起動ではなく文脈の中で行う
- Android 13が通知権限を明示的なランタイム許可に変えて以降、オプトイン率は大きく低下した
- 初回起動直後にシステムプロンプトを出すのではなく、ユーザーが通知を受け取りたくなる機能と結びつけて価値を示したあとで要求すべきである
- 通知権限はチャネル全体に関わるため、冷たい最初の要求で無駄にしてはならない
-
セグメンテーションとパーソナライズを基本にする
- ベンダーデータは方向性を示す資料だが、10年にわたり同じ結論を指しており、セグメント化・パーソナライズ通知はブロードキャストよりおおむね2倍水準の開封率を示している
- 一般的な一斉配信は成果が低く、取り戻せない権限を消費する
- 特定の理由で特定の人に送れないメッセージなら、全員に送らないほうがよい
-
得ていない割り込み権を使わない
- マーケティングメッセージを時間に敏感な通知のように装ってはならない
- iOSではユーザーがロック画面でアプリごとに時間に敏感な通知をオフにでき、送信者はこれに異議を唱えられない
- 配信量の増加は権限を殺し、送信者が維持できる唯一のレバーは関連性である
-
エンゲージメントが到達可能性を左右する
- プラットフォームのランキングは、ユーザーが通知に反応するかを学習するため、タップされない大規模な受信基盤は、モデルにアプリを低く評価させ、ユーザーが通知を切る方向へ追い込む
- プッシュにはメールの送信者レピュテーション体系ほど整った仕組みはなく、効果もアプリ・OSごとに異なるが、方向性は同じである
- 反応しなくなった購読は整理すべきであり、無視される大きな基盤よりも、反応する小さな基盤のほうが広い到達を維持する
-
文体より事実を先に置く
- タイトル前半には、ブランドトーンの導入より具体的な payloadを置くべきである。金額、名前、時間、行動といった情報が優先される
- 要約器は要点へ圧縮し、機械が読みやすい内容を保持するため、事実中心のタイトルはトーン中心のタイトルより書き換え後も生き残りやすい
- これは実測されたルールではなく合理的なデフォルトであり、公開されたテストはなく、根拠も間接的である
-
プッシュダッシュボードを盲信しない
- 開封とクリックは見えない編集レイヤーの後ろにあり、測定可能なコンバージョンは、プラットフォームがすでに優遇すると決めた通知の偏った標本である
- 下流のコンバージョンは最もましなシグナルだが、プッシュのコンバージョンイベントは希少で、一般的な配信量ではキャンペーン別の統計的有意性に達しにくい
- SDKでレンダリングを確認できるなら確認し、キャンペーンを束ね、観測ウィンドウを広げたうえで数字を信頼すべきである
- エンゲージメント上昇は、「コピーが良くなった」と同じくらい「プラットフォームが自分をより信頼している」と読める
-
自社保有サーフェスへ重心を移す
- アプリ内受信箱、ログイン済みのプロダクト画面、実物郵便、直接運営するロイヤルティサーフェスには、パイプライン内のモデルが存在しない
- これらのサーフェスは要約・ランキング・サイレント処理されず、最後まで測定できる
- プッシュと自社保有サーフェスは競合チャネルではなく、一つのポートフォリオとして運用すべきである
-
ロック画面ではなくエージェントのために設計する
- SiriとGeminiが通知に対して行動し始めるなら、エージェントが実行できるのは、整っていて機械可読な提案である
- 通知の背後にあるアクションは、UIの中で3回タップしないとたどり着けない場所に埋もれていてはならず、iOSのApp IntentsやAndroidのApp Actionsを通じて呼び出せる形で公開されるべきである
- モデルが人間に読まれなくてもメッセージを実行できるように書くべきである
結論
- プッシュはメールのように完全に所有されたチャネルではなく、ソーシャルよりは借り物度の低いチャネルに近かった
- プラットフォームはリリースのたびに、その賃貸条件を自分たちに有利なように再設定している
- 次の10年を生き残る送信者は、最も多く送る側でも最も巧妙に使う側でもなく、受信者がもともと望んでいたため、プラットフォームの編集者が正当化できるメッセージを送る側である
- 最良の仕事は、編集者が前に立っていないサーフェスへすでに移してある側が有利である
- 見えないモデルのために書き、そのモデルが届かないチャネルのために構築すべきである
1件のコメント
Hacker News の意見
自分のスマホが自分を邪魔するなら、それは今まさに誰かが本当に自分の注意を必要としているときであるべきで、そうでないならそもそも邪魔すべきではない。自分の通知設定では、電話、メッセージ、WhatsApp、Apple Health、銀行アプリくらいにしかプッシュ通知を許可していない
それ以外のアプリに、今すぐ自分を呼び出す理由はない。ほとんどのアプリは重要なことがあるからではなく、自分の注意を引きたいから通知を送ってくる
連続利用記録、割引、おすすめ、配送状況の更新といった通知は不要で、自分がアプリを開くと決めるまで待てば十分だ
でも大半のアプリは、ユーザーの注意を尊重できないことをすでに十分証明している。不要な通知と自分のスマホの間に、プラットフォームが障壁を多く置けば置くほどよい。Apple や Google を英雄だとは思わないが、少なくともチケットを1回買っただけで無理やり入れさせられたアプリのマーケティング部門よりは、自分の利害と一致している
必須通知と広告通知を分けてブロックするのが簡単ではない
商用アプリに「顧客とコミュニケーションする」ためのWhatsApp サポートを入れたいという顧客を見るたびにそう思う
同時に、通知を望むアプリの部分集合はユーザーごとに違う。シフト勤務の人は割り当てられた勤務や急に空いた勤務を知る必要があるし、あるユーザーには本当に重要でも、別のユーザーにはスパムだ
有用な通知は、マーケティング通知へと簡単に劣化する。配達員が外にいることは知りたいが、今週の特売は知りたくない
これは技術的に完全解決できる問題ではない。悪質な行為者は実際に悪質に振る舞う。それでもシステムは善良なアプリがうまく動くように作るべきで、最終的に何を見るかを決めるのはユーザーであるべきだ。Google でも Apple でもない
最低共通分母を基準に社会を作れば、誰にとってもあまり良くない。悪い行動を罰せるようにしつつ、良い行動を積極的に促すべきであって、「悪いかもしれない」という理由で全部禁止すべきではない
こう設定したアプリは、通知が届いてもバナーは出ず、ロック画面にも表示されない。ロック画面に上がってくるタイムリーな通知を過ぎて、自分で下にスクロールしてすべての通知を追うときにだけ見える
実質的には、見たければ確認し、そうでなければ見なくてもいい「メール受信箱」に格下げされるようなものだ。メールと違って、通知はアプリのワークフローに必須の経路にはなりえないので、通知受信箱はいつでも気軽に空にできる
多くのアプリがごく小さな画面領域を奪い合う原始的な構造で、ほとんどのプッシュ通知は「何か起きた！」以上のことを伝えない。実行可能な情報も少なく、実際に何が起きたのかも曖昧だ
その結果、通知という概念自体の価値が下がり、ときどき面白いものが流れても見逃したり、後で探し直しにくかったりする
プッシュ通知のユーザー体験はひどく、アプリ開発者がユーザーを好き勝手に邪魔できる超能力を乱用したせいで、時間とともにさらに悪化してきた。Apple と Google はこれを抑えようとしてきたが、残った結果は数少ない正当な用途に対してさえ、せいぜい平凡な水準にすぎない
銀行の承認や2段階認証のようなものは、アプリへ入るディープリンクとしては有用だが、それ以外は今やっていることを止めてスマホを見る価値がない
自分の Android スマホで最もよく使うアプリは Firefox と Gmail、それにいくつかだけだ。通知チャネルとしては、メール受信箱のほうがモバイルのプッシュ通知よりはるかに有用だ。より実行可能で情報量が多く、個別の配信停止やフィルタリング、再検索もしやすい。ほとんどのアプリは両方できるので、プッシュ通知は劣っていて重複している
この記事は、筆者が Apple と Google が特定の種類の通知、つまりスパム通知を防いだり制御したりすることに腹を立てているように読める
「クロスセル、アップセル、教育、発見もプッシュで機能しうる」とあるが、プッシュ通知は取引通知にだけ使うべきだ。ゴミ用の受信箱をもう1つ欲しいとは思わない
おそらくマーケティングメッセージだけを切る方法はあるのだろうが、ほとんどの人は知らないし、変えもしないだろう。本当にいら立つ
Uber、Bolt、Airbnb のようなサービスにはうんざりする。中核サービスにはプッシュが必要なのに、提供側がその隙を利用してスパムを差し込んでくる
今はマーケティングのゴミがあまりに侵襲的なので、必要になりそうなときだけアプリを入れて、そうでなければ消している。ハンバーガー配達はありがたいが、サービスがうちまで届けられるものは文字通り何もないという点も、なおさら腹立たしい
人は自分の注意を奪うものに対してあまりにも受動的で、いつも驚かされる。
自分のスマホは24時間ずっとおやすみモードにしている。アプリがどうでもいいことを通知してきたら削除して、Webサイトを使う。
「unsubscribe」という単語が入ったメールは受信トレイから外して別のタグ領域へ移すメールルールもある。数日ごとにそこへ行って、届いたものを全部配信停止にしている。
小売店のレジで個人情報や電話番号を聞かれたり、クラブ加入を求められたりしたら、割引があるのか聞く。割引がなければ情報もない。自分の情報に正当な対価を提示するなら考えるが、これまで自分の時間と情報の価値に見合うだけ支払った小売店は一つもない。
https://unfuck.email
電話に出なかったりメッセージに返信しなかったりするのは多くの人にとってタブーで、そのためスパマーやソーシャルアプリがあらゆる方向から突っ込んでくる軍拡競争に置かれている。そういう人たちは、私たちが24時間おやすみモードの地に住んでいることをもどかしく思っている。
どう解決できるかは分からないが、その立場も理解できる。
メッセージ通知以外を全部切って一日過ごしてみればいい。死にはしない。本当に気にしていることは定期的に確認するのにすぐ慣れるし、残りは自分が気にするまで待たなければならない。
何年もこうやって暮らしているが、友人や同僚はそのことを知らないし、知る必要もない。通知は素早く返事するのを助けるのではなく、自分がやろうとしていたことから注意を奪う。
今日はまだDiscordもメールも確認していない。友人が何か書いたか、新しい請求があるか、何かフォローアップが必要か知りたくなったときに、そのアプリを開いて処理するつもりだ。
スマホを何時間もそばに置いていても、気が散らずにいられる。
重要なものを定期的に確認する習慣には良い副作用もあった。スマホが代わりにやってくれることへの依存が減るにつれて、自分の精神的な通知システムが良くなり、だんだん確認しなくなるアプリやサービスが実際にはどれだけ重要でないかも、よりはっきりしてきた。
今ではアプリやアカウントがずっと少なくなり、むしろ全体として時間を守れるようになった。
この部分は事実と異なる。"通知は通知センターにしか存在せず、通知センターは通り過ぎるものを消し、捨て、要約し、何も安定して保持しない"
通知センターは情報を安定して保持する。受信トレイのようなものはユーザー領域にはないだけで、実際には存在している。: https://www.forbes.com/sites/larsdaniel/2026/04/10/fbi-pulle...
「15年のあいだ、このチャネルは一つの前提を中心に再構築されてきた。受信者の注意は希少な資源であり、プラットフォームにはそれを防衛する義務がある。…送信者としてのあなたは、制御がどちら側へ移ろうとも、その前提の反対側に立っている」
著者が状況を送信者と受信者の利害が対立するものとして公然と枠づけている点が興味深い。
ユーザーの注意を熱心に守る装置は、ユーザーが見たがっていた何かを時々ブロックしてしまうことがある。
それでも、ほとんどの通知はゴミであり、ブロックされるべきだ。
「これらすべての影響は均等には作用しない。編集型・放送型・宣伝型のプッシュに最も強く落ち、人々が実際に望む通知はそのまま通過するか、むしろ増幅される傾向がある」
自分には悪くないように聞こえる。
「チャネルの歴史の大半において、プラットフォームは目に見える形ではほとんど介入しなかった。構造的には介入可能だったが、ただあまり介入しないことを選んでいただけだ。その自制は終わった」
いつも目に見えていたわけではないが、最初から何らかの形で介入はあった。WhatsAppではプッシュの遅延、抑制、統合を常にモニタリングしていて、記憶が正しければ少なくとも自分が参加した2011年からシステムの一部だった。
そのシステムの中で正しく動作しないと、ユーザーメッセージは適時に配信されない。
USA PATRIOT Act 第215条の 電話メタデータ大量収集 に取って代わった何かが、Apple Push Notification や Firebase Cloud Messaging などの構造に影響していると見ている
Apple はすべての iPhone に対する持続的接続を保持しており、APNs だけがアプリを起動できる。ここでいう「セルフホスティング」とは、Firebase Cloud Messaging、OneSignal、Pusher のような第三者に任せず、何を送るかを決めて APNs に渡す独自のプロバイダーバックエンドを運用することを意味する。しかし最後の区間は決して自分のものではない
すべての人のトラフィックを少数の身元識別可能な仲介者に通す構造は、設計上、法的手段を待つだけの 大量メタデータ収集システム である
2023年12月、ロン・ワイデン上院議員は、米国政府と外国政府が Google と Apple に対し、プッシュ通知情報、通信メタデータ、ときには内容までも秘密裏に引き渡すよう強制していた事実を明らかにした。開発者が気にすべき点は、iPhone と Android が依存するプラットフォームで通知を送るには、この慣行を防ぐ方法がないということだ
Apple はこのプログラムが公表されるまで口外禁止の状態に置かれており、その後、この種の要請を透明性レポートに詳しく反映すると明らかにした。したがって、この構造的仮説は推測ではなく確認済みの仕組みであり、Section 215 との違いは、対象領域が通話ではなくアプリであり、法的手段が §215 の特定事業記録理論ではなく、通常の召喚状、FISA 命令、NSL であるという程度だ
「それは単なるメタデータにすぎない」という言葉は、結局こういう文脈から出てくる。もちろん冗談であり、このようなことに単独の個人だけが責任を負うわけではなく、集団的な政治意思の結果であり、残念ながらこれが私たちにできる最善なのかもしれない
https://www.youtube.com/watch?v=9iUdm0QMDM0
https://epic.org/sen-wyden-reveals-government-surveillance-o...