Apple과 Google이 푸시 알림 채널을 어떻게 중개하고, 요약하고, 우선순위를 매기며, 발신자 통제를 약화시키고 있는지에 대한 분석.
저는 최근에 Google, Yahoo, Microsoft, Apple이 당신의 이메일에 하고 있는 일에 대해 썼습니다. 네 개의 제공자가 어떻게 단순한 전송 계층이기를 멈추고 브랜드와 고객 사이의 능동적 중개자로 바뀌었는지, 메시지를 파싱하고, 순위를 매기고, 요약하고, 점점 더 수신자를 대신해 답하기까지 하게 되었는지를 다뤘습니다.
같은 일이 이제 푸시에서도 벌어지고 있습니다. 다만 네 개 회사가 아니라 두 개 회사가 통제합니다. Apple과 Google은 중요한 유일한 두 개의 파이프를 운영하고, 당신이 지금까지 보낸 모든 알림은 그중 하나를 통과했습니다. 지난 5년 동안 이제 전달과 잠금 화면 사이에 놓이게 된 온디바이스 모델은 그것을 요약하고, 재정렬하고, 일부 표면에서는 다시 쓰기 시작했습니다.
Android의 알림 요약.
푸시는 배터리 문제로 시작합니다. 2009년 6월 Scott Forstall은 WWDC 무대에 서서, iPhone이 설치된 모든 애플리케이션이 원격 서버를 향해 각자 백그라운드 폴링을 유지하도록 둘 여유가 없다는 논리를 폈습니다. 처음에는 2008년 9월 발표가 예정되어 있었지만, Apple이 규모 확장을 위해 기반 인프라를 재구성하기로 결정하면서 지연된 그 제안이 바로 Apple Push Notification Service였습니다. 이것은 각 기기에서 Apple로 이어지는 하나의 지속적인 TLS 연결 위로, 등록된 어떤 제3자라도 알림을 전달할 수 있게 하는 방식이었습니다.1APNs는 2009년 6월 17일 iPhone OS 3와 함께 출시되었습니다. Google은 2010년 Cloud to Device Messaging, 2012년 Google Cloud Messaging, 2016년 Firebase Cloud Messaging으로 뒤를 이었습니다.2
채널은 처음부터 중개되어 있었습니다. 당신이 iPhone으로 보내는 모든 알림은 Apple의 서버를 통과하고, Android 폰으로 보내는 모든 알림은 Google의 서버를 통과합니다. 플랫폼은 언제나 속도를 제한하고, 드롭하고, 로그를 남기고, 우선순위를 낮추거나, 거부할 수 있었습니다. 다만 채널 역사 대부분 동안 눈에 띄게 그렇게 하지는 않았습니다. 아키텍처는 개입을 허용했지만, 그들은 단지 많이 개입하지 않기로 선택했을 뿐입니다. 끝난 것은 바로 그 절제입니다.
2009년부터 2017년 사이의 초기 소비자 푸시 시대는 비교적 조용했습니다. APNs와 여러 Google 서비스는 사용자가 설치한 앱들에 전달했고, 플랫폼 수준 필터링은 제한적이었으며, 사용자 제어도 앱별 단일 on/off 토글 정도를 넘지 않았습니다.
Android의 첫 번째 중요한 온디바이스 개입은 2017년 8월 Android 8 Oreo의 알림 채널이었습니다.3Android 8 이전에는 개별 알림이 발신자가 정한 우선순위 수준을 담고 있었습니다. Android 8 이후에는 그 레버가 채널 수준에서 개발자에게, 그리고 다시 채널 수준에서 사용자에게 넘어갔습니다. 개발자는 앱마다 소수의 채널을 선언해야 했습니다. 예를 들어 다운로드, 메시지, 프로모션 같은 것들입니다. 각각은 IMPORTANCE_NONE에서 IMPORTANCE_HIGH까지의 중요도 값을 가졌고, 사용자는 다른 채널에 영향을 주지 않으면서 어떤 채널이든 독립적으로 음소거하고, 강등하고, 배지를 끄거나, 완전히 차단할 수 있었습니다.3채널의 중요도가 개발자에 의해 설정되고 나면 나중에 올릴 수 없었습니다. Android 8을 대상으로 하는 모든 앱은 채널을 선언해야 했고, 그렇지 않으면 알림이 아예 표시되지 않았습니다.
Apple은 2021년 9월 iOS 15에서 다른 언어로 자신의 버전을 도입했습니다. Focus, Scheduled Summary, 그리고 새로운 4단계 방해 분류체계(passive, active, time-sensitive, critical)가 iOS가 각 푸시를 다루는 방식을 재구성했습니다.4의미 있게 다룰 수 있는 유일한 수준은 time-sensitive였고, Apple은 그때도 지금도 이것을 마케팅에 쓰지 말아야 한다고 분명히 밝혔습니다.4Android는 2022년 8월 권한 자체를 레버로 만들었습니다. Android 13이 POST_NOTIFICATIONS를 런타임 권한으로 전환하면서, 플랫폼 출시 이후 적용되어 왔던 암묵적 opt-in 대신 명시적인 사용자 허가가 필요해졌습니다. opt-in 비율은 예상대로 떨어졌습니다. Pushwoosh의 1,600만 기기 샘플은 게임 앱이 opt-in 기반의 거의 3분의 1을 잃었고 뉴스 앱은 19 percent 하락했음을 보여주었습니다.510,000개 앱 전반에 걸친 8,000억 개 이상의 메시지에서 나온 Batch의 2025년 벤치마크는 Android opt-in이 1년 만에 85 percent에서 67 percent로 떨어졌고, 크로스 플랫폼 평균은 61 percent에서 안정화되었다고 보고했습니다.6
모든 단계는 발신자 통제의 한 단계를 빼앗습니다. 그 일부는 사용자에게 넘어가는데, 그것은 좋은 일입니다. 자신을 무엇이 방해해도 되는지를 사람이 스스로 결정하는 것은 채널이 제대로 작동하는 방식입니다. 나머지는 플랫폼으로 넘어갑니다. 그리고 바로 그 부분이 발신자에게 우려스러워야 합니다. 플랫폼의 판단은 불투명하고, 항소할 수 없으며, 사용자가 고른 설정이 아니라 점점 더 모델에 의해 내려지기 때문입니다. 15년 동안 이 채널은 하나의 가정을 중심으로 재구축되었습니다. 수신자의 주의는 플랫폼이 방어해야 할 희소 자원이라는 가정입니다. 플랫폼은 그 자원을 사용자를 위해서만이 아니라 자기 자신을 위해서도 방어합니다. 깔끔하고 피로도가 낮은 알림 표면은 플랫폼의 유지율과 생태계를 보호하고, 앱 삭제를 줄이며, 자사의 AI를 과시하게 해줍니다. 그래서 편집은 순수한 사용자 옹호가 아니라 플랫폼이 소유한 자산을 지키는 행동입니다. 발신자인 당신은 통제가 어느 쪽으로 움직였든 그 가정의 반대편에 서 있습니다.
이메일은 더 앞서 가 있고, 저는 그 이야기를 전체적으로 한 번 다룬 적이 있습니다. 같은 종류의 중개가 푸시에서도 병행해서 구축되어 왔고, 한 걸음 뒤에 있기 때문에 이메일은 푸시가 어디로 가고 있는지 보여주는 믿을 만한 예고편입니다. 다만 푸시가 더 어려운 경우입니다. 이메일은 적어도 발신자가 그것이 어떻게 작동하는지 볼 수 있는 계측 수단을 어느 정도 제공합니다. Postmaster Tools와 전달 가능성 대시보드 같은 것들입니다. 반면 푸시는 거의 아무것도 주지 않습니다. 푸시에는 받은편지함에 해당하는 것도 없습니다. 이메일은 수신자가 다시 스크롤하고, 검색하고, 돌아올 수 있는 장소에 남아 있지만, 알림은 알림 센터에만 살고, 거기는 통과하는 것을 지우고, 드롭하고, 요약하며, 신뢰할 수 있게 아무것도 보존하지 않습니다. 머신 러닝은 1990년대 후반부터 받은편지함 배치를 결정해 왔습니다. Bayesian 스팸 필터링이 제공자들을 규칙 기반 필터에서 콘텐츠, 발신자 평판, 수신자 참여를 함께 저울질하는 분류기로 옮겨 놓았을 때부터입니다. 인증 표준(SPF, DKIM, DMARC)은 그것을 대체하는 것이 아니라 그 모델에 입력되는 신호로 나중에 덧붙여졌습니다. 마케터들은 이메일을 출판 행위라기보다 보이지 않는 분류기가 승인하거나 거부하는 요청으로 점점 더 받아들이게 되었습니다.
2013년 Gmail의 탭형 받은편지함은 같은 종류의 분류기로 정상적인 메일을 Primary, Promotions, Social, Updates로 분류했습니다. Promotions 탭은 스팸 폴더가 아니었습니다. 사용자가 수신에 동의했지만 모델이 프로모션성이라고 판단한 상업 메일을 위한 별도 카테고리였습니다. Apple Mail도 2024년에 자체 분류를 추가했습니다. 이런 모든 변화는 발신자의 의도와 사용자의 경험 사이의 선을 발신자에게서 한 단계 더 멀어지게 만들었습니다.
2021년 9월 iOS 15와 함께 출시된 Mail Privacy Protection은 가시성 측면의 타격이었습니다. Apple Mail은 사용자가 메시지를 열었는지와 무관하게 Apple이 통제하는 프록시를 통해 원격 콘텐츠를 미리 가져오기 시작했고, IP 주소를 가리며, 마케터들이 10년 동안 의존해 온 open-pixel 메커니즘을 무너뜨렸습니다. 한 벤더 Omeda는 Apple로 인한 오픈율이 독자 때문이 아니라 이러한 프리페치만으로 6개월 사이 22.6에서 40.5 percent로 오르는 것을 보았습니다.7예전 형태의 오픈율은 회복 불가능해졌고, 클릭과 그 이후의 전환이 참여 신호를 대신하게 되었습니다.
그다음에는 Yahoo와 Google이 전달 가능성 자체를 게이트로 만들었습니다. 2024년 초부터 개인용 받은편지함으로 실제 볼륨을 보내는 어떤 발신자든 SPF와 DKIM으로 인증하고, DMARC를 정렬하고, 원클릭 수신 거부를 제공하며, 스팸 불만을 낮은 상한 아래로 유지해야 했습니다. 그렇지 않으면 아예 받은편지함에 도달하지 못했습니다. Google은 2025년 11월 유예에서 완전한 거부로 이동했고, Microsoft도 동등한 규칙을 발표했습니다.8Apple Intelligence의 요약 기능은 2024년 10월 Mail에 도달했고, Gmail의 Gemini 요약이 그 뒤를 따랐습니다.
푸시는 이제 대략 이메일이 10년 전에 도달했던 것과 비슷한 수준의 중개 성숙도에 도달했습니다. 다만 메커니즘에는 당신에게 불리한 몇 가지 차이가 있습니다. 이메일은 누구나 구현할 수 있는 개방적이고 연합된 프로토콜(SMTP, IMAP, DKIM과 DMARC 표준) 위에서 돌아갑니다. 읽기 클라이언트는 제공자와 분리되어 있어서 수신자는 같은 사서함을 어떤 앱에서든 열 수 있습니다. 그리고 구독은 발신자인 당신이 보유한 목록 위의 주소일 뿐입니다. 푸시에는 그런 것이 없습니다. 사용자의 권한은 특정 기기의 특정 설치 안에 존재합니다. 네이티브 앱이거나, iOS 16.4 이후에는 홈 화면 웹 앱일 수 있습니다. 그것은 Apple이나 Google이 마음대로 무효화할 수 있는 토큰(APNs 또는 FCM)에 묶여 있고, 당신은 다른 곳으로 가져갈 수 있는 어떤 목록도 쥐고 있지 않습니다. 웹 푸시는 App Store 다운로드 없이도 누가 보낼 수 있는지를 넓혀 주지만, 알림은 여전히 같은 온디바이스 편집 아래 같은 트레이에 도착하므로, 편집자를 벗어나지 않은 채 채널만 넓힐 뿐입니다. 이메일에는 수신 사서함이 확인할 수 있는 DKIM 서명이 있습니다. 푸시에는 그에 대응하는 것이 없습니다. 모든 알림이 애초에 전달 조건으로 Apple이나 Google의 인프라에 의해 이미 서명되기 때문입니다. 이메일은 HTML을 통해 레이아웃 제어를 줍니다. 푸시는 작은 구조화된 payload와, 플랫폼 템플릿을 벗어나는 잠금 화면 축약 보기 제어권을 거의 주지 않습니다. 확장 보기에는 더 풍부한 맞춤 레이아웃을 제공할 수 있습니다. iOS에서는 content extension, Android에서는 custom layouts 같은 것입니다. 하지만 그것은 사용자가 알림을 펼쳐야만 렌더링되고, 요약기가 다루는 축약 텍스트는 여전히 템플릿에 묶여 있습니다. 이메일은 사용자가 의도적으로 여는 큐에 살고, 푸시는 방해합니다.
이메일에서 오픈율의 죽음은 마케터들에게 오픈이 본래 무엇이었는지를 가르쳤어야 했습니다. 잘해야 전달의 대리 지표였을 뿐, 결코 참여의 지표는 아니었다는 사실입니다. 하지만 많은 사람들은 그것을 배우지 못했고, 오늘날에도 여전히 오픈을 참여로 읽습니다. 푸시는 같은 길로 가고 있습니다. 당신은 자신의 알림이 요약되었는지, Focus 모드 뒤에 숨겨졌는지, 온디바이스 모델에 의해 우선순위가 낮아졌는지, 조용한 폴더에 들어갔는지 알 수 있는 능력을 잃고 있습니다.
이메일의 편집은 대부분 이동 중에 일어납니다. Gmail의 Promotions 분류기, 스팸 필터, 발신자 평판 시스템, 대량 발신자 정책 집행은 모두 제공자의 서버에서 실행되며, payload가 지나가는 동안 그것을 읽습니다. 푸시의 편집은 그 모든 것의 하류에 있습니다. 전송은 중계기이고, 웹 푸시의 경우 종단간 암호화되어 있으며, 알림이 표시되는지, 요약되는지, 우선순위가 낮아지는지, 그룹화되는지에 대한 결정은 디스플레이 계층에서 기기 내부에서 내려집니다. 여기서 중요한 것은 네트워크가 아니라 온디바이스 모델이며, 그 가중치와 신호는 공개되어 있지 않습니다.
Apple Intelligence는 30억 파라미터의 온디바이스 기반 언어 모델과, Private Cloud Compute를 통해 사용 가능한 더 큰 Parallel-Track Mixture-of-Experts 서버 모델 위에서 동작합니다. 온디바이스 모델은 Apple silicon에 맞추기 위해 KV-cache sharing과 2-bit quantization-aware training을 사용합니다. 2025년 7월에 공개된 기술 보고서는 그 아키텍처를 자세히 설명합니다.9, 102024년 7월의 더 이른 보고서는 요약 어댑터 자체가 어떻게 훈련되는지를 설명했습니다. 이메일, 메시지, 알림 payload가 섞인 데이터 혼합 위에서, 목표 요약은 더 큰 서버 모델이 합성 생성한 뒤 필터링한 것입니다.11이 모델이 Apple Intelligence의 각 기능에 직접 사용되는 것은 아닙니다. 운영체제가 동적으로 로드하는, 대개 수십 메가바이트 크기의 작은 LoRA 스타일 어댑터가 특정 작업에 맞게 기반 모델을 특화합니다. 요약, 엔티티 추출, 정제, 알림 우선순위 지정 등이 여기에 포함됩니다.112024년 말과 2025년 초의 Apple 뉴스 요약 문제는 기능별로 다루기 쉬웠습니다. 기반 모델을 교체할 필요가 없었기 때문입니다. 어떤 표면의 어댑터만 재훈련하거나 끌 수 있었습니다. BBC가 요약이 잘못된 헤드라인을 만들어 낸다고 항의하자, Apple은 iOS 18.3에서 News와 Entertainment에 대해 요약을 비활성화했고, AI 요약을 이탤릭체로 표시하기 시작했으며, 잠금 화면에 앱별 끄기 스위치를 추가하고, 요약에 오류가 포함될 수 있다고 경고하기 시작했습니다.12이 편집은 보이지도 않고 영구적이기만 한 것은 아닙니다. 사용자가 그것을 끄면 전체 텍스트, 즉 당신의 텍스트가 다시 나타납니다. 기본값은 여전히 요약이고, 대부분의 사람은 그것을 바꾸지 않지만, 반발은 발신자들에게 부분적인 유예를 사다 주었습니다.
Google의 대응물인 Gemini Nano는 Android 14에서 도입된 Android 시스템 서비스인 AICore 내부에서 실행됩니다. AICore는 시스템 파티션에 모델을 보관하고, 모든 승인된 앱이 그 가중치를 공유하도록 하며, 입력이나 출력 데이터를 저장하지 않은 채 각 추론 요청을 격리합니다.13AICore는 Android의 Private Compute Core 원칙에 의해 관리됩니다. 제한된 패키지 바인딩, 직접적인 인터넷 접근 금지, Google Play System Updates를 통한 모델 업데이트가 그것입니다.13Gemini Nano는 여러 크기로 제공되며, 표준 메모리 기기용 Nano 1과 더 높은 RAM 기기용 Nano 2가 있고, 각각 자동으로 기기의 NPU, GPU 또는 CPU로 라우팅됩니다. Apple의 어댑터 접근처럼 AICore도 Low-Rank Adaptation을 지원하므로, 개별 기능(Pixel Recorder 요약, 알림 정리, smart reply)을 기반 모델을 재훈련하지 않고 특화할 수 있습니다.13Pixel 10 시리즈와 Samsung Galaxy S26 시리즈에서 알림 요약과 Notification Organiser는 이 스택 위에서 실행됩니다. 2차 보도에 따르면 One UI 요약 표면은 Samsung 전용 모델이 아니라 Android 자체의 System Intelligence이지만, OEM AI 스택은 문서화가 부족하고 빠르게 바뀌므로 세부사항은 잠정적인 것으로 보아야 합니다.14
Gemini Nano 아키텍처.
주어진 알림에 대한 편집 결정은 여러 계층의 산물입니다. 당신의 앱은 payload를 구성해 APNs나 FCM에 제출합니다. 플랫폼의 인프라가 그것을 기기로 전달하고, 운영체제는 먼저 사용자 제어 규칙을 적용합니다. Focus 모드, Do Not Disturb 일정, 채널 음소거, 앱별 차단 같은 것들입니다. 그다음 알림은 플랫폼의 랭킹과 표시 로직으로 들어갑니다. iOS에서는 Notification Summaries가 활성화되어 있고, 알림이 같은 앱이나 카테고리의 다른 알림들과 함께 그룹화될 수 있다면, 운영체제는 결합된 텍스트를 요약 어댑터가 붙은 온디바이스 기반 모델에 전달하고, 원래의 제목과 본문을 반짝이 아이콘과 이탤릭체로 표시된 생성 문장으로 대체합니다.15Priority Notifications가 활성화되어 있으면(iOS 18.4부터 기본값은 off), 시스템은 학습된 앱별 랭킹을 적용하여 일부 경고를 상단에 고정하고 다른 것들은 강등할 수 있습니다.16Reduce Interruptions Focus가 활성화되어 있으면, 모델은 각 알림이 사용자가 맞춤 설정한 중요도 임계값을 넘는지 평가합니다.15
두 건의 등록 특허는 Google Patents와 양수인 검색을 통해 확인됩니다. Microsoft Technology Licensing LLC의 US 11,340,963는 2022년 5월 24일 등록되었으며, 자동 생성된 알림에서 제공되는 정보의 명확성을 높이기 위해 “알림의 한 단어를 더 구체적인 다른 단어로 대체하고, 추가 콘텐츠를 더하고, 문법적 정확성 및/또는 명확성을 위해 내용을 바꾸어 쓰는” 방식을 설명합니다.17이것은 2019년 1월에 출원된 명시적인 ML 기반 알림 재작성으로, iOS 18 논란보다 몇 년 앞섭니다. Google LLC의 US 11,609,806은 사용자의 과거 상호작용과 대상 애플리케이션 사이의 관계를 이용해 알림을 전달할지, 언제 전달할지 결정하는 훈련된 머신 러닝 모델을 설명합니다.18Google의 우선순위 지정 작업은 더 이전까지 거슬러 올라갑니다. 우선일자가 2012년이고 2017년에 continuation이 등록된 US 8,707,201은 각 알림에 점수를 매기고, 사용자 입력으로 스스로를 업데이트하며, 가장 중요하다고 판단한 알림을 시각적으로 강조하는 온디바이스 랭킹 모델을 설명합니다. 이것은 Apple이 나중에 Priority Notifications로 출시할 형태와 같은 모습입니다.19이 유사성은 차용의 증거가 아닙니다. 여러 회사가 같은 몇 년 사이 학습된 사용자 행동에 따라 알림 순위를 매기는 변형들을 특허로 냈고, 그것이 말해 주는 것은 한 벤더가 다른 벤더에게서 가져갔다는 것이 아니라, 2010년대 초반에는 그 방향성이 명백했다는 사실입니다. 우선순위 지정, 요약, 예측 타이밍, 크로스 디바이스 조정 클러스터에는 다른 특허들도 존재하지만, 이 글을 쓰는 시점에 알려진 플랫폼 벤더 양수인에게 확실히 귀속되지 않은 것들은 추측성 인용을 피하기 위해 제외했습니다.
당신이 이 모든 것에 영향을 줄 수 있는 메커니즘은 제한적입니다. iOS에서 UNNotificationServiceExtension은 앱 코드가 표시 전 잠깐 전달된 알림을 변형할 수 있게 합니다. payload 복호화, 이미지 가져오기, 텍스트 수정 같은 것들입니다. UNNotificationContentExtension은 확장 보기용 맞춤 UI를 정의하게 합니다. 둘 다 플랫폼의 요약 또는 우선순위 지정 단계 이후에는 실행되지 않습니다. apns-priority 헤더는 5(비긴급 경고용, 전력을 보존하는 시간에 전달)와 10(정말로 상호작용적일 때 즉시 전달) 사이 선택지를 제공합니다. Android에서 NotificationListenerService는 OEM과 접근성 앱이 들어오는 알림을 읽는 데 사용하는 시스템 수준 API입니다. 당신은 NotificationManager에 쓰고 채널 중요도를 선언하지만, 시스템의 분류를 opt out할 수는 없습니다. Gemini Nano 스택은 당신의 payload가 파싱된 뒤에 실행됩니다. 당신의 알림이 요약되었는지, Notification Organiser의 Promotions 섹션에 들어갔는지, Focus에 의해 억제되었는지, Priority Notifications에 의해 조용히 강등되었는지 감지할 수 있는 API는 없습니다.
웨어러블 플랫폼은 이 스택을 그대로 이어받습니다. Apple Watch는 기본적으로 iPhone의 알림을 미러링하지만, iPhone의 Focus와 Summary 상태를 따릅니다. watchOS 11부터 Smart Stack은 위치, 시간, 캘린더 같은 온디바이스 신호를 사용해 관련 위젯을 띄웁니다. 당신은 Watch를 직접 타기팅하지 않고, 사용자 대상 토글을 통해 iOS 알림을 미러링할지 여부만 결정합니다. Wear OS는 기본적으로 폰 알림을 페어링된 시계로 브리지하며, 개발자 제어(BridgingConfig, setBridgeTag, setDismissalId)를 통해 동반 시계 앱이 설치된 경우 중복을 억제합니다. 저우선순위 경고에 대해 시계 전달을 억제할 수는 있지만, 사용자가 폰에서 음소거한 알림을 시계로 강제로 보내게 할 수는 없습니다. 웨어러블은 폰의 알림 스트림의 엄격한 부분집합이며, 같은 플랫폼 편집이 상류에서 적용되고, 추가로 하나의 필터(브리징 동작과 시계 측 complications)가 하류에서 적용됩니다.
대부분의 알림은 즉각적인 행동을 유도하지 않습니다. 사람들은 그것을 인지하고 계속 자기 일을 하며, 오직 일부만이 즉각적인 앱 전환을 만들어 냅니다. 이런 인지 역할은 데스크톱에서 먼저 확립되었고, Iqbal과 Horvitz의 CSCW 2010 Outlook 알림 현장 연구가 그것을 보여주었습니다. 이후 모바일 문헌은 그것을 확인하고 확장해 왔습니다.20
Sahami Shirazi, Henze, Dingler, Pielot, Weber, Schmidt의 CHI 2014 논문 “Large-Scale Assessment of Mobile Notifications”는 계측된 Android launcher를 통해 40,000명 이상의 사용자로부터 거의 2억 개의 알림을 수집했습니다. 이 논문은 사용자가 서로 다른 알림 카테고리에 부여하는 중요도 위계를 확인했는데, 메시징 알림은 일관되게 가장 가치 있게, 프로모션 알림은 일관되게 가장 가치 없게 평가되었습니다.21사람이 보낸 메시지와 브랜드가 보낸 메시지를 서로 다른 표면으로 다뤄야 한다는 원래의 경험적 근거, 그리고 Android Notification Organiser가 12년 뒤 이를 성문화하게 되는 근거는 이 논문에 있습니다.
Pielot, Church, de Oliveira의 MobileHCI 2014 연구 “An In-Situ Study of Mobile Phone Notifications”는 사용자가 하루 평균 63.5개의 알림을 마주하며, 대부분 messenger와 이메일에서 오고, 폰이 무음이든 아니든 몇 분 안에 그것들에 주의를 기울인다는 사실을 발견했습니다.22Mehrotra, Hendley, Musolesi의 UbiComp 2016 “PrefMiner”는 이것을 더 발전시켜 해석 가능한 규칙 학습 접근을 제시했습니다. 시스템은 사용자의 상호작용 이력에서 사람이 읽을 수 있는 if-then 규칙을 추출해 승인 여부를 묻고, 배포에서 생성된 규칙의 50 percent 이상이 승인되었습니다.23Mehrotra, Pejovic, Vermeulen, Hendley, Musolesi의 CHI 2016 논문 “My Phone and Me: Understanding User's Receptivity to Mobile Notifications”는 가치 있는 알림조차 방해를 일으키며, 개인의 심리적 특성이 그 방해를 어떻게 지각하는지 매개한다는 사실을 보여주었습니다.24Pielot와 Rello의 “Productive, Anxious, Lonely: 24 Hours Without Push Notifications”(arXiv 1612.02314, CHI 2017)는 30명의 참가자에게 하루 동안 알림 blackout을 적용했을 때, 사람들이 더 생산적이면서도 더 불안하고 사회적으로 덜 연결되었다고 보고합니다. 또 참가자의 절반 이상이 연구 후 알림을 더 의식적으로 비활성화하거나 관리하기 시작했습니다.25이 연구에서 실제 제품까지 이어지는 선은 직접적입니다. Okoshi와 동료들은 사용자의 폰 활동에서 breakpoint를 감지해 거기에 도달할 때까지 알림을 보류하는 middleware인 Attelia를 만들었고, 통제된 연구에서는 인지 부하를 46 percent, 실제 환경에서는 33 percent 줄였습니다.26이후 Yahoo! Japan 앱 내부의 대규모 배포는 타이밍만으로 클릭률이 최대 60.7 percent 증가했다고 보고했습니다.27Mehrotra와 Musolesi의 지능형 알림 시스템 서베이는 이 분야의 포괄적 참고문헌입니다.28
2020년 2월 Upland Software에 인수되고 Upland의 Customer Experience Management Cloud에 통합되기 전, Localytics는 널리 인용되는 결과를 발표했습니다. 푸시 알림을 비활성화한 사용자의 52 percent는 결국 앱에서 완전히 churn하고, 주당 2~5개의 알림이 대부분 앱에 최적 범위이며, 이를 넘기면 앱 삭제가 실질적으로 증가하고, 세그먼트된 오디언스는 브로드캐스트의 대략 두 배 비율로 엽니다.29이제 CleverTap의 일부인 Leanplum은 개인화된 알림의 오픈율이 일반 브로드캐스트보다 약 800 percent 높고, 열린 푸시 알림의 90 percent가 한 시간 안에 행동을 만들어 낸다고 발표했습니다. CleverTap의 자체 2025년 fintech 보고서는 세그먼트 캠페인의 평균 오픈율이 16.3 percent이고 비타기팅 캠페인은 4.7 percent라고 밝혔습니다.
이 숫자들은 벤더의 자기 보고이므로 그만큼 할인해서 봐야 하지만, 방향성은 벤더와 방법론과 수십 년을 가로질러 일관됩니다. 볼륨은 권한을 죽입니다. 당신이 통제할 수 있는 유일하게 신뢰할 만한 레버는 관련성입니다. 발송 시점은 중요하지만 관련성보다 덜 중요합니다. 프로모션처럼 보이는 것은 프로모션으로 분류됩니다. 대개 정확하게 그렇습니다. 사용자는 프로모션 알림보다 거래성 및 대화성 알림을 훨씬 더 높은 볼륨까지 견딥니다. 그래서 Android Notification Organiser의 Promotions 카테고리는 Gmail의 Promotions 탭이 이메일에서 그랬던 것처럼, 마케터가 보내는 푸시의 중심이 될 가능성이 높아 보입니다. 다만 프로모션 푸시가 얼마나 체계적으로 뒤로 밀리는지는 제조사마다 여전히 다르고, 이메일만큼 정착되지는 않았습니다.
이 모든 것이 균등하게 작동하는 것은 아닙니다. 편집은 브로드캐스트와 프로모션 푸시에 가장 가혹하게 작용합니다. 사람들이 실제로 원하는 알림은 손대지지 않거나 오히려 증폭되는 경향이 있습니다. 사람으로부터 온 메시지, Focus를 무시하는 critical alert, 차량 호출이나 배송을 추적하는 Live Activity, 사용자가 직접 시작한 어떤 것의 상태 업데이트는 정확히 사용자가 원하기 때문에 필터를 통과합니다. 심지어 일부는 존재감을 더 크게 얻습니다. Live Activities가 가장 명확한 사례입니다. ActivityKit 세션은 Lock Screen과 Dynamic Island라는, 알림 트레이와는 별개의 표면에 렌더링되므로 요약기나 그룹화가 절대 건드리지 않습니다. Android의 Live Updates와 ongoing notifications도 마찬가지입니다. 진짜로 실시간인 거래성 콘텐츠, 차량 호출, 배송, 경기, 타이머에는 이것이 편집자를 우회하는 가장 깨끗한 경로입니다. 다만 실제로 진행 중인 이벤트에서만 작동한다는 한계가 있습니다. 프로모션을 Live Activity로 위장할 수는 없습니다. 제어권도 사용자 쪽에 있습니다. 요약, Focus, 채널, 권한은 모두 꺼질 수 있습니다. 문제는 기본값이 지배하고 대부분의 사람들은 그것을 바꾸지 않는다는 점이며, 여기서의 논의는 마케터 브로드캐스트에 관한 것인데, 그것이 보내지는 대부분이자 편집되는 거의 전부이기 때문입니다.
Dekker, Baumgartner, Sumter, Ohme의 2024년 Media Psychology 연구 “Beyond the Buzz”는 1주일 무작위 실험을 수행했는데, 알림을 비활성화해도 사람들이 폰을 확인하는 빈도나 화면 시간을 줄이지 않는다는 결론을 내렸습니다.30사람들은 직접 앱으로 가는 방식으로 보상했습니다. 이것은 볼륨을 줄이는 것이 opt-out 비율이 암시하는 만큼 참여를 잃게 하지는 않는다는 확인으로 읽어야 합니다. opt out한 사용자들도 종종 여전히 스스로 앱으로 돌아오기 때문입니다.
이 모든 것에 대한 당신의 가시성은 설계상 좋지 않으며, 더 나빠지고 있습니다.
이용 가능한 지표를 신뢰도 증가 순으로 나열하면 sends, accepted-by-platform, delivered-to-device, displayed-on-device, opened, attributed conversion입니다. APNs와 FCM은 서버가 제출 시 응답 코드를 받기 때문에 accepted-by-platform을 신뢰할 만하게 노출합니다. APNs는 SMTP처럼 delivery receipt를 제공하지 않습니다. 당신이 아는 최대치는 Apple이 payload를 수락하고 큐에 넣었다는 사실뿐입니다.31FCM은 메시지 ID와, 경우에 따라 delivery callback을 포함해 약간 더 많은 정보를 주지만, “기기에 전달됨”과 “사용자에게 표시됨” 사이의 선은 여전히 불투명합니다. iOS는 오프라인 상태일 때 앱당 가장 최근 알림 하나만 저장하므로, 더 오래된 알림은 사용자에게 도달하기도 전에 조용히 드롭될 수 있습니다.32
라이프사이클 플랫폼(Braze, Iterable, OneSignal, Airship, CleverTap, MoEngage, Pushwoosh, Customer.io, Batch)은 이것 위에 자체 측정을 얹어서 앱의 SDK에서 집계된 메시지별 delivery, open, click rate를 노출합니다. SDK는 알림이 언제 표시되었는지, 사용자가 언제 탭했는지, 그 탭이 세션 시작을 만들었는지를 기록합니다. 세부 수준은 앱이 iOS의 NotificationServiceExtension이나 Android의 동등한 broadcast receiver를 선언했는지에 따라 달라지며, 이것은 SDK가 수신을 확인할 수 있게 합니다. 그것이 없으면 “delivered”는 다시 “APNs/FCM에 의해 수락됨”으로 붕괴하고, 사용자가 실제로 본 것에 비해 겉보기 delivery rate를 부풀립니다.
OneSignal 자체 가이드가 문서화하듯 click-through rate는 통상 taps를 deliveries로 나눈 것입니다. 그리고 deliveries는 보통 “FCM 또는 APNs를 통과했다”는 뜻입니다. 그러면 실제로 표시되지 않았거나, 읽지 않은 채 스와이프되었거나, 조용히 dismiss되었거나, Focus 또는 Reduce Interruptions 필터 뒤에 숨겨진 알림도 계산에 들어갑니다. 일부 플랫폼이 노출하는 “confirmed delivery” 지표는 SDK가 렌더링을 본 알림을 세기 때문에 진실에 더 가깝지만, 그래도 사용자가 그 렌더링된 알림을 dismiss하기 전에 봤는지는 말해주지 못합니다.33
모바일 측정 파트너(AppsFlyer, Adjust, Branch, Singular, Kochava)는 payload에 tracking link를 심고 이후 SDK 이벤트와 매칭하여 후속 세션을 특정 푸시 캠페인에 귀속합니다.34iOS에서는 2021년 4월 App Tracking Transparency 이후 SKAdNetwork 제약 아래에서도 이것이 작동해 왔습니다. 다만 재참여 귀속은 설치 귀속과 달리 ATT를 필요로 하지 않고 IDFV 또는 앱 수준 식별자를 대신 사용한다는 차이가 있습니다. 따라서 재참여 귀속은 당신이 비교적 안정적으로 유지할 수 있는 몇 안 되는 측정 체인 중 하나입니다.
인앱 분석 도구(Amplitude, Mixpanel, Heap, PostHog)는 자체적으로는 하류 세션만 보고 상류 알림은 보지 못합니다. 둘을 잇는 것은 이미 해결된 통합 문제입니다. 푸시 플랫폼의 send와 open 이벤트를 공통 사용자 식별자를 기준으로 분석 도구에 넣으면 됩니다. 네이티브 커넥터, Braze Currents 같은 event stream, 또는 reverse-ETL 작업을 통해 알림, 세션, 전환이 대체로 맞춰집니다. 로그인하지 않은 사용자와 재설치 주변의 identity-resolution 누수는 감안해야 합니다. 하지만 이것으로도 퍼널의 조용한 중간 단계는 복원되지 않습니다. 전달된 알림이 얼마나 자주 표시되었는지, 요약되었는지, 강등되었는지, Focus에 의해 억제되었는지, 아예 보이지 않았는지는 여전히 알 수 없습니다. 푸시 플랫폼도 그것을 말해 줄 수 없습니다. APNs, FCM, 운영체제 중 어느 것도 그것을 보고하지 않기 때문입니다. 그 중간은 어둡습니다.
다음 항목들에 대해서는 플랫폼이 제공하는 신호가 없습니다. 알림이 iOS에서 Notification Summary에 묶였는지 여부. Pixel에서 Notification Organiser의 Promotions 섹션에 들어갔는지 여부. Reduce Interruptions가 그것을 조용히 만들었는지 여부. Priority Notifications가 그것을 강등했는지 여부. iOS에서 사용자가 잠금 화면에서 읽지 않고 그것을 쓸어버렸는지 여부. 사용자가 그것을 억제하는 Focus 모드 안에 있는지 여부. iOS의 저장 제한 때문에 표시 전에 드롭되었는지 여부. Samsung의 One UI 8.5가 그것을 요약했는지 여부. 푸시가 이메일보다 나은 단 한 곳은 반대 방향으로 읽힙니다. Android에서는 사용자가 알림을 스와이프해 치울 때 delete-intent가 발생하므로, 신중한 dismiss가 로그에 남습니다. 명시적 거부가 드러나지 않는 이메일과는 다릅니다. 이것은 Android에서만 가능하고, 실제로 표시된 알림에 대해서만 발생하며, 숙고한 스와이프와 clear-all을 구분할 수 없으므로 좁은 승리지만, 실제 승리이긴 합니다.
2026년의 푸시 측정은 Mail Privacy Protection 이후 이메일 마케터가 이메일을 측정하는 방식과 비슷합니다. 보이지 않는 편집 계층의 하류에 놓여 있음을 알면서도 그 지표들을 쓰고, 실제로 행동한 사용자만 포착하는 전환 데이터에 맞춰 보정합니다. 측정 가능한 전환을 만들어 내는 알림들은 당신이 보낸 알림의 무작위 하위집합이 아니며, 그 편향은 플랫폼이 관련성이 있다고 판단한 방향으로 작동합니다. 시간이 지남에 따라 참여 지표가 개선되면, 당신이 더 나은 알림을 보내고 있을 수도 있고, 플랫폼이 점점 더 신뢰하는 알림을 보내고 있을 수도 있습니다. 대시보드 안에서는 둘을 구분할 수 없습니다. 이메일에는 적어도 부분적 진단 수단으로 Google Postmaster Tools가 있습니다. 푸시에는 그와 동등한 것이 없습니다.
브로드캐스트 카피는 더 이상 온전하게 살아남지 못합니다. 온디바이스 요약기는 알림을 요지로 압축하므로, 통과하는 것은 브랜드 보이스가 아니라 구체적 사실입니다. payload, 금액, 이름, 시간, 행동을 앞에 두면 요약이 붙잡을 것이 생깁니다. 브랜드 보이스식 오프닝, 감탄사, 이모지, 말장난 뒤에 묻어 두면, 요약은 이모지는 남기고 의미는 버리거나, 반쪽만 남길 수 있습니다. 사용자가 알림을 발신자 카테고리와 정보 유형으로 평가하지 문학성으로 평가하지 않는다는 Sahami Shirazi의 발견이 간접적인 뒷받침입니다. 요약기를 위해 어떻게 써야 하는지에 대한 직접 테스트를 발표한 사람은 아직 없습니다.21
제목을 자연어로 쓰인 구조화 데이터 필드로 취급하십시오. “Your delivery is 15 minutes away”는 요약 안정적입니다. “We've got great news!”는 그렇지 않습니다. 사실을 담고 있지 않기 때문입니다. 대략적인 자가 점검으로, 제목을 처음 몇 단어만 남기고 잘랐을 때도 사용자에게 유용한 무언가를 말해 주는지 보십시오. 그렇다면 요약기가 유지할 수 있는 사실이 있는 것입니다. 그렇지 않다면 그것은 브랜드 보이스 신호였고, 플랫폼이든 사용자든 혹은 둘 다가 그것을 알아볼 수 없게 편집할 것입니다. 이것을 보장이 아니라 습관으로 취급하십시오. 같은 원칙은 Live Activities와 Live Updates에도 적용됩니다. 제안의 핵심은 브랜드 포장이 아니라 필드(ETA, 점수, 걸음 수)입니다.
time-sensitive 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”.4한 번의 탭으로, 잠금 화면에서, 사용자 결정에 따라 앱별로 그 수준은 꺼집니다. 당신에게는 그에 상응하는 항소 수단이 없습니다.
푸시는 라이프사이클 프로그램에서 덜 많은 비중을 져야 합니다. 앱 안에서 당신이 소유하는 표면들은, 대체로 방해 정도가 낮은 순서에서 높은 순서로, 다음과 같습니다. 사용자가 의도적으로 도달하는 피드 안의 수동적 인프로덕트 카드(요약되지도 Focus에 막히지도 않음), 사용자가 돌아올 수 있는 영구적 위치인 지속형 인앱 메시지 센터 또는 inbox, 활성 세션 중에만 표시되는 세션 이벤트 기반 타기팅 인앱 메시지(modal, slide-up, banner), 그리고 사용자가 이미 방문하는 작업 완료 흐름 화면 안에 배치된 내장형 메시징 primitive입니다. 이 중 어느 것도 APNs나 FCM을 통과하지 않습니다. 어느 것도 Apple Intelligence나 Gemini Nano의 손을 타지 않습니다. 어느 것도 요약되지 않습니다. 어느 것도 Focus에 의해 억제되지 않습니다. 그리고 모두가 완전히 당신에게 보입니다. SDK가 플랫폼 중개 공백 없이 render, dismiss, interaction 이벤트를 기록합니다.
문제는 소유한 표면이 활성 사용자에게만 도달한다는 점입니다. 14일 동안 앱을 열지 않은 사람은 인앱 메시지로 도달시킬 수 없습니다. 푸시로만 도달할 수 있습니다. 그래서 푸시는 휴면 사용자를 재참여시키는 채널이 되고, 활성 사용자에게는 거래성이고 시간 민감한 경고를 보내는 채널이 됩니다. 인프로덕트 표면은 그 외 모든 것의 채널이 됩니다. cross-sell, upsell, 콘텐츠 발견, 교육, 부가가치 같은 것들입니다. Batch의 2025년 데이터는 프로모 코드 캠페인에서 인앱 메시지 클릭률이 Android에서 16.1 percent, iOS에서 17.9 percent로 푸시 CTR보다 훨씬 높았음을 보여주었습니다.6같은 데이터는 인앱이 세션을 필요로 하기 때문에 도달 가능한 인앱 오디언스가 도달 가능한 푸시 오디언스보다 더 작다는 점도 보여줍니다. 푸시는 사용자를 제품 안으로 다시 데려오기 위해 존재합니다. 일단 그들이 들어오면, 소유한 표면이 바통을 이어받습니다.
푸시와 인프로덕트 표면을 경쟁자가 아니라 포트폴리오로 취급하십시오. 플랫폼 편집자는 그중 오직 하나에만 작동합니다.
온디바이스 언어 모델은 일단 그곳에 자리 잡으면, 요약 외에도 쓰임이 있습니다. iOS 18.4부터 개발자에게 노출된 Apple의 Foundation Models framework는 어떤 앱이든 운영체제가 쓰는 동일한 모델을 호출할 수 있게 합니다. 요약, 엔티티 추출, 텍스트 이해, 정제, 짧은 대화에 사용할 수 있습니다.10, 35AICore 위에 놓인 Google의 ML Kit GenAI APIs는 요약, 교정, 재작성, 이미지 설명을 노출합니다.13, 36모델은 더 이상 기능이 아닙니다. 요청하는 어떤 앱에게나 제공되는 인프라입니다. 다음 단계는 Google의 “smarter, more proactive Android with Gemini Intelligence”라는 프레이밍과 Apple의 더 agentic한 Siri를 향한 로드맵에서 보이듯, 이런 모델들이 당신의 알림에 반응해 사용자를 대신해 행동하는 것입니다. 앱을 열고, 예약을 완료하고, 경고를 dismiss하고, 답장을 초안하는 식입니다.37Apple은 바로 이런 것의 한 버전을 특허로 냈습니다. 사용자가 어떤 알림을 보고 있는지 감지하고, 음성 지시를 받아, 앱 안이나 알림 시스템 자체 안에서 그 행동을 수행하는 디지털 비서입니다.38기저 능력은 추측이 아닙니다. Yahoo의 연구자들은 이미 10년 전에 제공자가 수신자가 기대하는 메시지의 인과 사슬, 예를 들어 구매 확인이 배송 공지를 예측하고, 배송 공지가 배달 알림을 예측하는 식의 사슬을 모델링하고, 그 사슬이 끊어질 때를 감지할 수 있음을 보여주었습니다.39이미 당신의 다음 메시지를 예상할 수 있고, 이미 눈앞의 메시지에 대해 온디바이스 모델을 돌려 그것을 요약하는 플랫폼은, 당신을 대신해 알림을 처리하는 데 필요한 구성 요소를 갖추고 있습니다. 행동 계층은 아직 오지 않았지만, 그것이 출시되면 더 무거운 추론은 전적으로 기기 안이 아니라 Apple의 Private Cloud Compute나 Google의 클라우드 모델에서 서버 측으로 실행될 가능성이 큽니다. 이 배관에는 이미 이름이 있습니다. Apple의 App Intents framework는 개발자가 Siri와 Apple Intelligence에 타입이 지정된 앱 행동을 노출하게 하고, Android에서는 App Actions와 Gemini의 서드파티 앱 내부 행동 능력이 그에 상응하는 일을 합니다.40발신자에게 주는 함의는 구체적입니다. 이제 일은 요약기가 망가뜨리지 않을 알림을 쓰는 것만이 아니라, 그 뒤의 행동을 노출해 에이전트가 사용자가 앱을 열지 않아도 예약을 완료하거나 경고를 지울 수 있게 만드는 것입니다. 알림은 목적지가 아니라 에이전트가 소비하는 트리거가 되고, 지난 10년간 푸시 측정을 지탱해 온 클릭률 지표는 의미 대부분을 잃습니다.
당신은 보이지 않는 편집자와 협상하고 있습니다. 그 편집자는 당신이 들여다볼 수 없는 모델 위에서 실행되며, 당신이 아니라 사용자에게 답합니다. 그것을 더 크게 외친다고 이길 수는 없고, 항소도 없습니다. 여기서 10가지가 따라 나옵니다.
푸시는 이메일처럼, 결코 진정으로 소유된 적이 없었습니다. 단지 소셜보다 덜 임대되어 있었을 뿐이고, 그 임대료는 매 릴리스마다 플랫폼에 유리하게 다시 책정되고 있습니다. 다음 10년을 무사히 건너갈 발신자는 가장 많이 보내는 사람도, 가장 영리하게 보내는 사람도 아닐 것입니다. 질문을 받았을 때 편집자가 기꺼이 방어할 메시지를 보내는 사람들일 것입니다. 수신자가 어차피 그것을 원했기 때문입니다. 그리고 자기 최고의 작업을 애초에 어떤 편집자도 앞을 가로막지 않는 표면으로 옮겨 둔 사람들일 것입니다. 당신이 결코 볼 수 없는 모델을 위해 쓰십시오. 그것이 닿지 못하는 채널을 위해 구축하십시오.
저는 방금 iPhone 17 Pro를 샀기 때문에, Apple Intelligence 기능이 실제 사용 중에 어떻게 작동하는지 보게 될 것을 기대하고 있습니다.
1 Apple Developer Documentation. Registering your app with APNs (User Notifications). https://developer.apple.com/documentation/usernotifications/registering-your-app-with-apns
2 Google / Firebase. Firebase Cloud Messaging documentation. https://firebase.google.com/docs/cloud-messaging
3a3b Android Developers. Create and manage notification channels (importance levels IMPORTANCE_NONE to IMPORTANCE_HIGH, channels required from Android 8.0). https://developer.android.com/develop/ui/views/notifications/channels
4a4b4c Batch. Understanding and managing iOS 15 time-sensitive interruption level. https://help.batch.com/en/articles/5543431-understanding-and-managing-ios-15-time-sensitive-interruption-level
5 Pushwoosh. 2025 Android 13 Impact: Opt-In Rates and User Engagement. https://www.pushwoosh.com/blog/android-13-opt-in-rates-research/
6a6b Batch. EXCLUSIVE: The Great Push Notifications Benchmark 2025. https://batch.com/ressources/etudes/benchmark-notifications-push-crm-mobile
7 Omeda. The Impact of Apple's Mail Privacy Protection: 6 Months Later. https://www.omeda.com/blog/the-impact-of-apples-mail-privacy-protection-6-months-later/
8 Google Workspace Admin Help. Email sender guidelines and FAQ (5,000/day bulk-sender threshold, SPF/DKIM, DMARC alignment, RFC 8058 one-click unsubscribe, 0.3% spam-rate ceiling, November 2025 enforcement). https://support.google.com/a/answer/81126 ; https://support.google.com/a/answer/14229414
9 Apple Machine Learning Research. Introducing Apple's On-Device and Server Foundation Models. https://machinelearning.apple.com/research/introducing-apple-foundation-models
10a10b Apple Machine Learning Research / arXiv. Apple Intelligence Foundation Language Models Tech Report 2025 (arXiv 2507.13575). https://arxiv.org/abs/2507.13575
11a11b Apple Machine Learning Research / arXiv. Apple Intelligence Foundation Language Models (arXiv 2407.21075, July 2024). https://arxiv.org/abs/2407.21075
12 Apple's statement temporarily disabling Apple Intelligence notification summaries for News and Entertainment apps in iOS 18.3 (January 2025), alongside italic labelling of AI summaries, a per-app lock-screen toggle, and a beta "may contain errors" warning, as reported by CNBC. https://www.cnbc.com/2025/01/16/apple-disables-ai-notifications-for-news-in-its-beta-iphone-software.html
13a13b13c13d Android Developers. Gemini Nano on Android. https://developer.android.com/ai/gemini-nano
14 SamMobile. AI notification summaries coming to Galaxy devices with One UI 8.5 (reportedly Android System Intelligence / on-device Gemini Nano), October 2025. https://www.sammobile.com/news/one-ui-8-5-ai-notification-summaries-galaxy-devices/
15a15b Apple Support. Summarize notifications and reduce interruptions with Apple Intelligence on iPhone. https://support.apple.com/guide/iphone/summarize-notifications-reduce-interruptions-iph1fbe7d2b9/ios
16 Apple Newsroom. Introducing Apple Intelligence for iPhone, iPad, and Mac (Priority Notifications, summaries, Reduce Interruptions Focus), June 2024. https://www.apple.com/newsroom/2024/06/introducing-apple-intelligence-for-iphone-ipad-and-mac/
17 Microsoft Technology Licensing LLC. US 11,340,963 - Augmentation of notification details (granted 24 May 2022). https://patents.google.com/patent/US11340963B2/en
18 Google LLC. US 11,609,806 - Determining whether and when to provide notifications based on application content. USPTO. https://image-ppubs.uspto.gov/dirsearch-public/print/downloadPdf/11609806
19 Google LLC. US 8,707,201 B1 - Systems and methods for prioritizing notifications on mobile devices (priority date 27 June 2012, granted 22 April 2014); continuation US 9,817,869 B2 (granted 2017). https://patents.google.com/patent/US8707201
20 Iqbal, S. T. and Horvitz, E. Notifications and awareness: a field study of alert usage and preferences. CSCW 2010. https://erichorvitz.com/shamsi_iqbal-eric_horvitz_cscw_2010.pdf
21a21b Sahami Shirazi, A., Henze, N., Dingler, T., Pielot, M., Weber, D. and Schmidt, A. Large-Scale Assessment of Mobile Notifications. CHI 2014. https://weberdo.com/publications/2014-Large-Scale-Assessment-of-Mobile-Notifications.pdf
22 Pielot, M., Church, K. and de Oliveira, R. An In-Situ Study of Mobile Phone Notifications. MobileHCI 2014, pp. 233-242. https://dl.acm.org/doi/10.1145/2628363.2628364
23 Mehrotra, A., Hendley, R. and Musolesi, M. PrefMiner: Mining User's Preferences for Intelligent Mobile Notification Management. UbiComp 2016. https://pure-oai.bham.ac.uk/ws/files/29201286/PrefMiner_Mining_User_s_Preferences_for_Intelligent_Mobile_Notification_Managemen.pdf
24 Mehrotra, A., Pejovic, V., Vermeulen, J., Hendley, R. and Musolesi, M. My Phone and Me: Understanding People's Receptivity to Mobile Notifications. CHI 2016, pp. 1021-1032. https://dl.acm.org/doi/10.1145/2858036.2858566
25 Pielot, M. and Rello, L. Productive, Anxious, Lonely: 24 Hours Without Push Notifications. arXiv 1612.02314. https://arxiv.org/pdf/1612.02314
26 Okoshi, T., Ramos, J., Nozaki, H., Nakazawa, J., Dey, A. K. and Tokuda, H. Attelia: Reducing User's Cognitive Load due to Interruptive Notifications on Smart Phones. IEEE PerCom 2015. https://www.semanticscholar.org/paper/b69d4d0a57a7dfebd42168b85661a4b14bd29d12
27 Okoshi, T., Tsubouchi, K., Taji, M., Ichikawa, T. and Tokuda, H. Attention and Engagement-Awareness in the Wild: A Large-Scale Study with Adaptive Notifications. IEEE PerCom 2017. Project page: https://www.ht.sfc.keio.ac.jp/~slash/research/attelia/
28 Mehrotra, A. and Musolesi, M. Intelligent Notification Systems: A Survey of the State of the Art and Research Challenges. arXiv 1711.10171 (2017). https://arxiv.org/abs/1711.10171
29 Upland Software. Upland Software Acquires Localytics, Raises Guidance (7 February 2020). https://uplandsoftware.com/resources/acquisitions/upland-software-acquires-localytics-raises-guidance/
30 Dekker, C. A., Baumgartner, S. E., Sumter, S. R. and Ohme, J. Beyond the Buzz: Investigating the Effects of a Notification-Disabling Intervention on Smartphone Behavior and Digital Well-Being. Media Psychology 28(1), 2024, pp. 162-188. https://www.tandfonline.com/doi/full/10.1080/15213269.2024.2334025
31 Apple Developer Documentation. Handling notification responses from APNs (the status codes APNs returns on submission). https://developer.apple.com/documentation/usernotifications/handling-notification-responses-from-apns
32 OneSignal Documentation. Push overview. https://documentation.onesignal.com/docs/en/push
33 OneSignal. Guide to Understanding Push Notification Performance. https://onesignal.com/blog/guide-to-understanding-push-notification-performance/
34 Singular. Push Notification Campaign Measurement. https://support.singular.net/hc/en-us/articles/34936651200539-Push-Notification-Campaign-Measurement
35 Apple Machine Learning Research. Updates to Apple's On-Device and Server Foundation Language Models. https://machinelearning.apple.com/research/apple-foundation-models-2025-updates
36 Google for Developers. Overview of the ML Kit GenAI APIs. https://developers.google.com/ml-kit/genai
37 Google Blog. A smarter, more proactive Android with Gemini Intelligence. https://blog.google/products-and-platforms/platforms/android/gemini-intelligence/
38 Apple Inc. US 12,243,523 - Digital assistant for providing handsfree notification management (detecting the notification a user attends to, taking a spoken instruction, and performing the action; PCT publication WO2023049140A1, 2023). https://patents.google.com/patent/WO2023049140A1/en
39 Gamzu, I., Karnin, Z., Maarek, Y. and Wajc, D. You Will Get Mail! Predicting the Arrival of Future Email. WWW 2015 (Companion). https://doi.org/10.1145/2740908.2741694
40 Apple Developer Documentation. App Intents: Integrating actions with Siri and Apple Intelligence. https://developer.apple.com/documentation/appintents/integrating-actions-with-siri-and-apple-intelligence
