Apple và Google đang làm gì với thông báo đẩy

• Thông báo đẩy đang chuyển từ một lớp truyền tải đơn thuần thành một kênh biên tập do nền tảng kiểm soát, nơi Apple và Google phân tích cú pháp, xếp hạng, tóm tắt và viết lại
• APNs và FCM khởi đầu như một cấu trúc trung gian tập trung để tiết kiệm pin, và mọi thông báo trên iPhone và Android ngay từ đầu đều đi qua máy chủ nền tảng
• Kênh thông báo của Android, Focus·Summary trên iOS, và việc chuyển quyền POST_NOTIFICATIONS trên Android 13 đã làm giảm quyền kiểm soát của bên gửi, biến hệ thống thành nơi sự chú ý của người dùng được nền tảng bảo vệ
• Các mô hình on-device tóm tắt, nhóm và hạ cấp thông báo ở lớp hiển thị, nhưng bên gửi gần như không có API để phát hiện liệu thông báo có bị tóm tắt, bị Focus chặn, hay bị giảm ưu tiên hay không
• Về mặt thực tiễn, nên giới hạn thông báo đẩy cho việc đánh thức người dùng không hoạt động và các thông báo giao dịch nhạy cảm về thời gian, đồng thời chuyển trọng tâm sang phân khúc·cá nhân hóa và các bề mặt sở hữu như trong ứng dụng

---

Xu hướng thông báo đẩy trở thành kênh biên tập của nền tảng

• Thông báo đẩy đang dịch chuyển khỏi vai trò một lớp truyền tải đơn thuần như email để trở thành một kênh nơi Apple và Google đứng giữa, phân tích cú pháp, xếp hạng, tóm tắt và viết lại
• Apple và Google vận hành các tuyến thông báo đẩy cốt lõi của iPhone và Android, và trong 5 năm gần đây, các mô hình trên thiết bị đã chen vào giữa khâu phân phối và màn hình khóa để tóm tắt, sắp xếp lại thông báo, thậm chí viết lại ở một số màn hình
• Nếu trong email, bốn nhà vận hành Google, Yahoo, Microsoft và Apple đã trở thành bên trung gian chủ động giữa thương hiệu và khách hàng, thì với thông báo đẩy, cấu trúc này được đảm nhiệm bởi hai công ty là Apple và Google

Kiến trúc thông báo đẩy bắt đầu từ vấn đề pin

• Ngay từ đầu, thông báo đẩy đã được thiết kế theo cấu trúc trung gian tập trung vì vấn đề pin
• Tại WWDC 2009, Scott Forstall giải thích rằng iPhone không thể gánh nổi việc mọi ứng dụng đã cài đều tự polling máy chủ từ xa của mình ở chế độ nền, nên Apple đề xuất Apple Push Notification Service, trong đó mỗi thiết bị duy trì một kết nối TLS liên tục với Apple và bên thứ ba gửi thông báo qua kết nối đó
• APNs bị trì hoãn do vấn đề mở rộng sau khi được công bố lần đầu vào tháng 9/2008, và ra mắt cùng iPhone OS 3 vào ngày 17/6/2009
• Google đi theo lộ trình từ Cloud to Device Messaging năm 2010, Google Cloud Messaging năm 2012, đến Firebase Cloud Messaging năm 2016
• Mọi thông báo gửi tới iPhone đều đi qua máy chủ của Apple, và mọi thông báo gửi tới Android đều đi qua máy chủ của Google
• Nền tảng từ trước tới nay luôn có thể giới hạn, xóa, ghi lại, xử lý ưu tiên thấp hoặc từ chối thông báo; điều thay đổi là Apple và Google giờ đây không còn kiềm chế như trước

15 năm nền tảng can thiệp ngày càng sâu

• Trong thời kỳ đầu của thông báo đẩy cho người tiêu dùng, APNs và các dịch vụ của Google chỉ đơn giản chuyển thông báo tới các ứng dụng mà người dùng đã cài, còn việc lọc ở cấp nền tảng vẫn khá hạn chế
• Quyền kiểm soát của người dùng khi đó cũng gần như chỉ là một công tắc bật/tắt theo từng ứng dụng
• Can thiệp trên thiết bị đầu tiên đáng kể của Android là notification channels trong Android 8 Oreo vào tháng 8/2017
  • Trước Android 8, từng thông báo riêng lẻ mang mức ưu tiên do bên gửi đặt; sau đó, nhà phát triển phải định nghĩa theo kênh và người dùng điều khiển theo từng kênh
  • Nhà phát triển khai báo các kênh như tải xuống, tin nhắn, khuyến mãi cho mỗi ứng dụng và gán mức quan trọng từ IMPORTANCE_NONE đến IMPORTANCE_HIGH cho từng kênh
  • Người dùng có thể tắt tiếng theo kênh, hạ mức quan trọng, tắt badge hoặc chặn hoàn toàn mà không ảnh hưởng tới các kênh khác
  • Mức quan trọng của kênh sau khi nhà phát triển thiết lập một lần thì về sau không thể tăng lên, và ứng dụng nhắm tới Android 8 mà không khai báo kênh sẽ không hiển thị thông báo
• Apple giới thiệu Focus, Scheduled Summary và hệ phân loại gián đoạn 4 cấp trong iOS 15 vào tháng 9/2021
  • Bốn cấp gồm passive, active, time-sensitive và critical, nhưng trên thực tế mức mà nhà phát triển có thể xử lý chủ yếu là time-sensitive
  • Apple nêu rõ không được dùng time-sensitive cho mục đích marketing, và chính sách này vẫn tiếp tục được duy trì
• Android chuyển POST_NOTIFICATIONS thành quyền runtime trong Android 13 vào tháng 8/2022, yêu cầu người dùng cấp phép rõ ràng thay vì opt-in ngầm định
  • Trong mẫu 16 triệu thiết bị của Pushwoosh, ứng dụng game mất gần một phần ba cơ sở opt-in, còn ứng dụng tin tức giảm 19%
  • Benchmark 2025 của Batch, dựa trên hơn 800 tỷ tin nhắn từ 10.000 ứng dụng, cho thấy tỷ lệ opt-in trên Android giảm từ 85% xuống 67% chỉ trong một năm, và mức trung bình đa nền tảng dừng ở 61%
• Mỗi bước đi như vậy đều làm suy giảm quyền kiểm soát của bên gửi, và tái định hình kênh thông báo đẩy theo hướng nền tảng coi sự chú ý của người nhận là một tài nguyên khan hiếm cần được bảo vệ
• Một bề mặt thông báo sạch sẽ, ít gây mệt mỏi giúp bảo vệ tỷ lệ giữ chân và hệ sinh thái của nền tảng, giảm xóa ứng dụng, đồng thời là cách để phô diễn các tính năng AI, nên biên tập ở cấp nền tảng không đơn thuần chỉ là bảo vệ người dùng

Email đã trải qua quá trình trung gian hóa trước

• Email đã bị trung gian hóa trước thông báo đẩy, và trong thông báo đẩy, xu hướng tương tự đang diễn ra chậm hơn một nhịp
• Thông báo đẩy là một kênh còn bất lợi hơn email
  • Email có các công cụ đo lường như Postmaster Tools và dashboard về khả năng phân phối, nhưng thông báo đẩy thì hầu như không có
  • Email còn nằm lại trong hộp thư để người dùng cuộn, tìm kiếm và quay lại, còn thông báo thì bị xóa khỏi trung tâm thông báo, trôi xuống dưới, bị tóm tắt và không được lưu giữ ổn định
• Gmail đã dùng tabbed inbox từ năm 2013 để phân loại email hợp lệ vào Primary, Promotions, Social và Updates, còn Apple Mail bổ sung cách phân loại riêng vào năm 2024
• Mail Privacy Protection được đưa vào iOS 15 tháng 9/2021, khiến Apple Mail tải trước nội dung từ xa thông qua proxy do Apple kiểm soát bất kể người dùng có thực sự mở thư hay không
  • Cách làm này che giấu địa chỉ IP và phá vỡ cơ chế open pixel mà các nhà tiếp thị dựa vào
  • Omeda quan sát thấy tỷ lệ mở do Apple tạo ra tăng từ 22,6% lên 40,5% trong 6 tháng, nhưng đó không phải do độc giả tăng mà là do prefetch
  • Tỷ lệ mở theo kiểu cũ đã không thể khôi phục, và tỷ lệ nhấp cùng các chuyển đổi ở tầng dưới đã thay thế nó như tín hiệu tương tác
• Từ đầu năm 2024, Yahoo và Google yêu cầu những bên gửi có khối lượng đáng kể tới hộp thư cá nhân phải có xác thực SPF và DKIM, căn chỉnh DMARC, hủy đăng ký bằng một cú nhấp và duy trì tỷ lệ khiếu nại spam thấp
• Email hoạt động trên các giao thức mở và liên hợp, còn đăng ký nhận thông báo đẩy tồn tại dưới dạng quyền gắn với một cài đặt cụ thể trên một thiết bị cụ thể, trong ứng dụng native hoặc trong web app trên màn hình chính kể từ iOS 16.4
• Thông báo đẩy bị ràng buộc với token APNs hoặc FCM, Apple hoặc Google có thể tùy ý vô hiệu hóa token đó, và bên gửi không có một danh sách có thể mang đi nơi khác
• Web push mở rộng phạm vi bên gửi vì có thể gửi mà không cần tải ứng dụng từ App Store, nhưng nó vẫn đi vào cùng một khay thông báo và chịu cùng kiểu biên tập trên thiết bị, nên không thoát khỏi vai trò của biên tập viên
• Với thông báo đẩy, bên gửi cũng ngày càng khó biết liệu thông báo của mình có bị tóm tắt, bị ẩn sau Focus mode, bị mô hình trên thiết bị hạ ưu tiên, hay bị chuyển vào một thư mục yên lặng hay không

Trình biên tập trên thiết bị

• Việc biên tập email chủ yếu diễn ra trong lúc truyền, còn việc biên tập thông báo đẩy diễn ra ở tầng hiển thị
• Việc có hiển thị thông báo hay không, có tóm tắt hay không, có để ở mức ưu tiên thấp hay không, có nhóm lại hay không được quyết định ở tầng hiển thị của thiết bị
• Điểm cốt lõi không phải là mạng mà là mô hình trên thiết bị, và trọng số cùng tín hiệu của nó không được công khai
• Apple Intelligence sử dụng foundation language model trên thiết bị 3 tỷ tham số và một mô hình máy chủ Parallel-Track Mixture-of-Experts lớn hơn có sẵn trong Private Cloud Compute
  • Báo cáo kỹ thuật tháng 7/2025 đề cập đến KV-cache sharing và quantization-aware training 2-bit được tối ưu cho Apple silicon
  • Các tính năng của Apple Intelligence thường không dùng trực tiếp mô hình nền tảng mà để hệ điều hành nạp động các adapter kiểu LoRA nhỏ, thường chỉ vài chục MB, chuyên cho các tác vụ như tóm tắt, trích xuất thực thể, tinh chỉnh câu chữ và xếp hạng ưu tiên thông báo
  • Sau khi BBC phàn nàn rằng phần tóm tắt tạo ra các tiêu đề sai lệch, Apple đã vô hiệu hóa phần tóm tắt cho ứng dụng News and Entertainment trong iOS 18.3, hiển thị phần tóm tắt AI bằng chữ nghiêng, đồng thời thêm công tắc tắt theo từng ứng dụng và cảnh báo có thể có lỗi trên màn hình khóa
• Gemini Nano của Google chạy bên trong AICore, một dịch vụ hệ thống được giới thiệu trong Android 14
  • AICore đặt mô hình trong phân vùng hệ thống, cho phép các ứng dụng có quyền chia sẻ trọng số, cô lập từng yêu cầu suy luận và không lưu dữ liệu đầu vào hay đầu ra
  • AICore tuân theo các nguyên tắc của Android Private Compute Core, áp dụng package binding bị giới hạn, chặn truy cập internet trực tiếp và cập nhật mô hình qua Google Play System Updates
  • Gemini Nano được tự động điều phối tới NPU, GPU hoặc CPU của thiết bị, và thông qua Low-Rank Adaptation có thể chuyên biệt hóa cho các tính năng như tóm tắt Pixel Recorder, sắp xếp thông báo và smart reply mà không cần huấn luyện lại mô hình nền
• Luồng biên tập cho từng thông báo diễn ra theo cách ứng dụng tạo payload và gửi lên APNs hoặc FCM, sau đó hệ điều hành trước tiên áp dụng các quy tắc kiểm soát của người dùng như Focus modes, lịch Do Not Disturb, tắt tiếng theo channel và chặn theo từng ứng dụng
• Sau đó thông báo đi vào logic xếp hạng và hiển thị của nền tảng; nếu Notification Summaries trên iOS được bật, hệ điều hành có thể chuyển văn bản đã gộp vào mô hình trên thiết bị có gắn adapter tóm tắt và thay tiêu đề cùng nội dung gốc bằng câu do AI tạo ra
• Nếu Priority Notifications được bật, thì từ iOS 18.4 trở đi mặc định là tắt, hệ thống có thể áp dụng cơ chế xếp hạng theo từng ứng dụng đã được huấn luyện để ghim một số thông báo và hạ mức ưu tiên của các thông báo khác
• Khi Reduce Interruptions Focus được kích hoạt, mô hình sẽ đánh giá xem từng thông báo có vượt qua ngưỡng mức độ quan trọng do người dùng tùy chỉnh hay không
• US 11,340,963 của Microsoft Technology Licensing LLC và US 11,609,806, US 8,707,201 của Google LLC cho thấy hướng tiếp cận dùng mô hình học máy để viết lại thông báo, quyết định thời điểm gửi và xếp hạng ưu tiên đã tồn tại từ rất lâu trước tranh cãi về iOS 18

Những phương tiện kiểm soát hạn chế mà bên gửi có thể dùng

• UNNotificationServiceExtension của iOS cho phép mã ứng dụng chỉnh sửa ngắn gọn thông báo đã được gửi trước khi hiển thị, và có thể dùng để giải mã payload, tải ảnh hoặc sửa văn bản
• UNNotificationContentExtension cho phép định nghĩa UI tùy chỉnh cho extension view
• Cả hai extension đều không chạy sau giai đoạn tóm tắt hoặc xếp hạng ưu tiên của nền tảng
• Header apns-priority cung cấp một trong hai giá trị 5 và 10; 5 dùng để gửi các thông báo không khẩn cấp vào thời điểm tiết kiệm năng lượng, còn 10 dùng để chuyển ngay các thông báo thực sự có tính tương tác
• Trên Android, nhà phát triển ghi vào NotificationManager và khai báo mức độ quan trọng của channel, nhưng không thể thoát khỏi phân loại của hệ thống
• NotificationListenerService là API cấp hệ thống được OEM và các ứng dụng trợ năng dùng để đọc thông báo đến
• Không có API nào để phát hiện liệu thông báo đã bị tóm tắt, đã bị đưa vào mục Promotions của Notification Organiser, đã bị Focus chặn hay đã bị âm thầm hạ xuống ưu tiên thấp bởi Priority Notifications hay chưa

Thiết bị đeo là tập con của luồng thông báo trên điện thoại

• Apple Watch về cơ bản phản chiếu thông báo của iPhone, nhưng tuân theo trạng thái Focus và Summary của iPhone
• Từ watchOS 11, Smart Stack sử dụng các tín hiệu trên thiết bị như vị trí, thời gian và lịch để hiển thị các widget liên quan
• Wear OS mặc định bridge thông báo trên điện thoại sang đồng hồ đã ghép đôi, đồng thời cung cấp các cơ chế kiểm soát cho nhà phát triển như BridgingConfig, setBridgeTag, setDismissalId để ngăn trùng lặp khi đã cài companion watch app
• Có thể chặn việc chuyển các thông báo ưu tiên thấp sang đồng hồ, nhưng không thể ép chuyển sang đồng hồ những thông báo mà người dùng đã tắt tiếng trên điện thoại
• Thiết bị đeo là một tập con nghiêm ngặt của luồng thông báo trên điện thoại, chịu cùng kiểu biên tập của nền tảng ở phía thượng nguồn và ở phía hạ nguồn lại đi qua thêm bộ lọc là hành vi bridging và complication phía đồng hồ

Cách người dùng thực sự xử lý thông báo

• Phần lớn thông báo không khiến người dùng chuyển ngay sang ứng dụng, mà hoạt động như tín hiệu nhận thức để người dùng nhận biết rồi tiếp tục việc đang làm
• Nghiên cứu CHI 2014 “Large-Scale Assessment of Mobile Notifications” của Sahami Shirazi, Henze, Dingler, Pielot, Weber và Schmidt đã thu thập khoảng 200 triệu thông báo từ hơn 40.000 người dùng thông qua đo đạc launcher trên Android
  • Thông báo nhắn tin liên tục được đánh giá là có giá trị nhất, còn thông báo quảng bá liên tục bị đánh giá thấp nhất
  • Đây là bằng chứng thực nghiệm cho thấy cần xử lý khác nhau giữa tin nhắn từ con người và tin nhắn từ thương hiệu trên các bề mặt hiển thị khác nhau
• Nghiên cứu MobileHCI 2014 “An In-Situ Study of Mobile Phone Notifications” của Pielot, Church và de Oliveira cho thấy người dùng nhận trung bình 63,5 thông báo mỗi ngày, phần lớn đến từ ứng dụng nhắn tin và email, và họ vẫn chú ý chỉ trong vài phút ngay cả khi điện thoại đang để im lặng
• Attelia do Okoshi và cộng sự phát triển là middleware phát hiện các điểm ngắt trong hoạt động trên điện thoại của người dùng và giữ thông báo lại đến thời điểm đó; trong nghiên cứu có đối chứng, nó giảm tải nhận thức 46%, và trong môi trường thực tế giảm 33%
• Ở giai đoạn triển khai quy mô lớn sau đó trong ứng dụng Yahoo! Japan, chỉ riêng việc điều chỉnh thời điểm gửi đã giúp tăng tỷ lệ nhấp tối đa 60,7%
• Localytics công bố rằng 52% người dùng đã tắt thông báo đẩy cuối cùng rời bỏ hẳn ứng dụng, khoảng tối ưu đối với hầu hết ứng dụng là 2–5 thông báo mỗi tuần, và nhóm đối tượng được phân khúc cho thấy tỷ lệ mở cao gần gấp đôi so với gửi đại trà
• Leanplum, hiện đã được sáp nhập vào CleverTap, công bố rằng tỷ lệ mở của thông báo cá nhân hóa cao hơn khoảng 800% so với gửi đại trà thông thường, và 90% thông báo đẩy đã được mở dẫn tới hành động trong vòng 1 giờ
• Báo cáo fintech 2025 của CleverTap đưa ra tỷ lệ mở trung bình 16,3% cho chiến dịch phân khúc và 4,7% cho chiến dịch không nhắm mục tiêu
• Dù các con số do chính nhà cung cấp tự báo cáo cần được xem một cách dè dặt, xu hướng thì nhất quán
  • Khối lượng gửi sẽ giết chết quyền cấp phép, và mức độ liên quan là đòn bẩy ổn định duy nhất có thể kiểm soát
  • Thời điểm gửi cũng quan trọng, nhưng kém quan trọng hơn mức độ liên quan
  • Những gì trông giống quảng bá nhìn chung sẽ bị phân loại là quảng bá, và thường phán đoán đó là đúng
  • Người dùng chấp nhận thông báo giao dịch và hội thoại với tần suất cao hơn rất nhiều so với thông báo quảng bá
• Cơ chế biên tập của nền tảng tác động mạnh nhất lên các đợt gửi đại trà và thông báo đẩy mang tính quảng bá, trong khi những thông báo mà người dùng thực sự muốn thường vẫn được đi qua hoặc thậm chí được nhấn mạnh hơn
• Live Activities là đường vòng rõ ràng nhất
  • Phiên ActivityKit được render trên Màn hình khóa và Dynamic Island, là các bề mặt tách biệt với khay thông báo, nên bộ tóm tắt và cơ chế nhóm không đụng tới
  • Live Updates và thông báo ongoing trên Android cũng đóng vai trò tương tự
  • Với nội dung giao dịch đang thực sự diễn ra như gọi xe, giao hàng, trận đấu, bộ đếm giờ, đây là con đường sạch nhất để tránh bộ biên tập của nền tảng
  • Chúng chỉ có thể dùng cho sự kiện thực sự đang diễn ra, và không thể ngụy trang nội dung quảng bá thành Live Activity
• Nghiên cứu Media Psychology năm 2024 “Beyond the Buzz” của Dekker, Baumgartner, Sumter và Ohme báo cáo rằng trong một thử nghiệm ngẫu nhiên kéo dài 1 tuần, việc tắt thông báo không làm giảm tần suất kiểm tra điện thoại hay thời gian dùng màn hình, và người dùng có hành vi bù trừ bằng cách tự mở ứng dụng trực tiếp

Những gì marketer có thể nhìn thấy

• Mức độ quan sát của marketer bị giới hạn một cách có chủ đích, và đang ngày càng tệ hơn
• Các chỉ số đo lường đi từ đáng tin cậy nhất đến kém đáng tin cậy hơn theo chuỗi gửi, được nền tảng chấp nhận, được chuyển tới thiết bị, được hiển thị trên thiết bị, được mở, rồi chuyển đổi quy gán
• APNs và FCM trả về mã phản hồi khi gửi từ máy chủ nên mức “được nền tảng chấp nhận” hiện ra khá ổn định, nhưng APNs không cung cấp xác nhận chuyển phát kiểu SMTP, và bạn chỉ biết rằng Apple đã chấp nhận payload rồi đưa nó vào hàng đợi
• FCM cung cấp message ID và trong một số trường hợp có callback chuyển phát, nhưng ranh giới giữa “đã chuyển tới thiết bị” và “đã hiển thị cho người dùng” vẫn mờ đục
• Trên iOS, khi ngoại tuyến hệ thống chỉ lưu thông báo mới nhất cho từng ứng dụng, nên các thông báo cũ hơn có thể bị xóa âm thầm trước khi đến được người dùng
• Các nền tảng lifecycle như Braze, Iterable, OneSignal, Airship, CleverTap, MoEngage, Pushwoosh, Customer.io và Batch bổ sung đo lường dựa trên SDK trong ứng dụng
  • SDK ghi lại việc thông báo được hiển thị, người dùng chạm vào, và liệu thao tác chạm đó có dẫn đến khởi đầu một phiên hay không
  • Mức độ chi tiết phụ thuộc vào việc trên iOS có khai báo NotificationServiceExtension hay trên Android có khai báo broadcast receiver tương đương hay không
  • Nếu không có extension, “đã chuyển phát” lại co về mức “đã được APNs/FCM chấp nhận”, khiến tỷ lệ chuyển phát bề ngoài bị thổi phồng so với những gì người dùng thực sự thấy
• Theo hướng dẫn của chính OneSignal, tỷ lệ nhấp theo thông lệ được tính bằng số lần chạm chia cho số lần chuyển phát, còn “chuyển phát” thường có nghĩa là “đã đi qua FCM hoặc APNs”
  • Cách này bao gồm cả những thông báo không được hiển thị, bị vuốt bỏ mà không đọc, bị gỡ bỏ âm thầm, hoặc bị ẩn sau bộ lọc Focus hay Reduce Interruptions
  • “Confirmed delivery” trên một số nền tảng gần với thực tế hơn vì SDK chỉ đếm những thông báo mà nó thấy đã được render, nhưng vẫn không thể biết người dùng có thực sự nhìn thấy thông báo đã render đó trước khi bị gỡ hay không
• Các đối tác đo lường di động như AppsFlyer, Adjust, Branch, Singular và Kochava đặt liên kết theo dõi vào payload rồi khớp với các sự kiện SDK về sau để quy phiên downstream cho một chiến dịch push cụ thể
• Các công cụ phân tích trong ứng dụng như Amplitude, Mixpanel, Heap và PostHog nhìn thấy các phiên downstream nhưng tự chúng không thấy được thông báo upstream
• Nếu gửi các sự kiện gửi/mở từ nền tảng push sang công cụ phân tích bằng một định danh người dùng dùng chung, có thể nối thông báo, phiên và chuyển đổi lại với nhau, nhưng phần giữa của phễu kiểu “thông báo đã chuyển phát được hiển thị, bị tóm tắt, bị hạ cấp, bị Focus chặn, hoặc không được nhận biết với tần suất bao nhiêu” thì không thể khôi phục
• Có rất nhiều tín hiệu mà nền tảng không cung cấp
  • Trên iOS, thông báo có bị gom vào Notification Summary hay không
  • Trên Pixel, nó có bị đưa vào mục Promotions của Notification Organiser hay không
  • Reduce Interruptions có biến nó thành thông báo im lặng hay không
  • Priority Notifications có hạ cấp nó hay không
  • Trên iOS, người dùng có vuốt bỏ từ Màn hình khóa mà không đọc hay không
  • Người dùng có đang ở chế độ Focus vốn chặn thông báo hay không
  • Nó có bị xóa trước khi hiển thị do giới hạn lưu trữ của iOS hay không
  • Samsung One UI 8.5 có tóm tắt nó hay không
• Một điểm mà push tốt hơn email là delete-intent trên Android
  • Khi người dùng vuốt để xóa một thông báo đã được hiển thị, một sự kiện sẽ được kích hoạt để có thể ghi lại việc gỡ bỏ có chủ ý
  • Nó chỉ có trên Android, chỉ xảy ra với thông báo đã hiển thị, và không thể phân biệt giữa một lần vuốt cân nhắc kỹ với thao tác xóa tất cả
• Đo lường push trong năm 2026 sẽ giống đo lường email sau Mail Privacy Protection: dùng dữ liệu chuyển đổi chỉ bắt được những người thực sự có hành động để hiệu chỉnh các chỉ số nằm bên dưới một lớp biên tập vô hình

Cách viết cho các mô hình trong đường ống

• Toàn bộ câu chữ gửi đi sẽ không còn được giữ nguyên vẹn nữa
• Trình tóm tắt trên thiết bị nén thông báo thành ý chính, nên thứ được truyền đạt không phải là giọng điệu thương hiệu mà là sự thật cụ thể
• Nếu đặt các payload cốt lõi như số tiền, tên, thời gian, hành động lên đầu, trình tóm tắt sẽ có thứ để giữ lại
• Nếu chôn nội dung cốt lõi sau phần mở đầu kiểu thương hiệu, thán từ, emoji, hoặc chơi chữ, trình tóm tắt có thể chỉ để lại emoji rồi bỏ mất ý nghĩa, hoặc giữ lại một nửa sai lệch
• Cần xem tiêu đề như một trường dữ liệu có cấu trúc được viết bằng ngôn ngữ tự nhiên
  • “Your delivery is 15 minutes away” ổn định trong tóm tắt
  • “We've got great news!” không chứa thông tin thực tế nên không ổn định
  • Một cách tự kiểm tra thô là xem liệu chỉ giữ lại vài từ đầu của tiêu đề có còn cung cấp thông tin hữu ích cho người dùng hay không
  • Điều này nên được xem là một thói quen, không phải sự bảo đảm
• Cùng nguyên tắc đó cũng áp dụng cho Live Activities và Live Updates, trong đó đề xuất cốt lõi là các trường như ETA, tỷ số, số bước chân chứ không phải lớp bọc thương hiệu
• Cơ sở để không lạm dụng mức ngắt quãng nhạy cảm theo thời gian đã được nêu rõ trong hướng dẫn dành cho nhà phát triển của 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”
  • Người dùng có thể tắt thông báo nhạy cảm theo thời gian của từng ứng dụng chỉ bằng một lần chạm từ màn hình khóa, và không có quy trình kháng nghị tương xứng nào cho bên gửi

Dịch chuyển trọng tâm sang các bề mặt sở hữu

• Push nên đảm nhận vai trò nhỏ hơn trong các chương trình vòng đời
• Các bề mặt do ứng dụng sở hữu bên trong app có thể được chia theo mức độ ít xâm nhập hơn
  • Thẻ in-product thụ động trong feed mà người dùng chủ động tìm đến
  • Trung tâm tin nhắn hoặc hộp thư in-app mang tính thường trực để người dùng có thể quay lại
  • Tin nhắn in-app nhắm mục tiêu dựa trên sự kiện phiên, chỉ hiển thị trong phiên đang hoạt động
  • Các thành phần nhắn tin nhúng bên trong luồng sản phẩm, được đặt trên những màn hình mà người dùng vốn đã ghé vào để hoàn thành tác vụ
• Những bề mặt sở hữu này không đi qua APNs hay FCM, và cũng không bị Apple Intelligence hay Gemini Nano can thiệp
• Không có tóm tắt hay ức chế bởi Focus, SDK ghi lại các sự kiện render, đóng và tương tác, nên có thể quan sát được mà không có khoảng trống do nền tảng trung gian tạo ra
• Giới hạn là các bề mặt sở hữu chỉ tiếp cận được người dùng đang hoạt động
  • Người dùng không mở ứng dụng trong 14 ngày sẽ không thể được tiếp cận bằng tin nhắn in-app mà chỉ có thể bằng push
  • Push trở thành kênh tái tương tác với người dùng ngủ đông và là kênh thông báo giao dịch, nhạy cảm theo thời gian cho người dùng đang hoạt động
  • Bán chéo, bán nâng hạng, khám phá nội dung, giáo dục và gia tăng giá trị sẽ do các bề mặt in-product đảm nhiệm
• Trong dữ liệu năm 2025 của Batch, CTR của tin nhắn in-app trong các chiến dịch mã khuyến mãi là 16.1% trên Android và 17.9% trên iOS, cao hơn CTR của push
• Trong cùng bộ dữ liệu đó, vì in-app cần có phiên nên nhóm đối tượng có thể tiếp cận nhỏ hơn so với push
• Push tồn tại để đưa người dùng quay lại sản phẩm, và sau khi người dùng đã vào, các bề mặt sở hữu sẽ tiếp quản

Thay đổi tiếp theo: tác nhân xử lý thông báo

• Mô hình ngôn ngữ trên thiết bị, một khi đã được triển khai, sẽ được dùng cho nhiều mục đích vượt ra ngoài việc tóm tắt
• Foundation Models framework của Apple cho phép nhà phát triển, từ iOS 18.4, gọi cùng mô hình mà hệ điều hành sử dụng để tóm tắt, trích xuất thực thể, hiểu văn bản, tinh chỉnh và hội thoại ngắn
• ML Kit GenAI APIs của Google, chạy trên AICore, cung cấp tóm tắt, hiệu đính, viết lại và mô tả hình ảnh
• Bước tiếp theo là để mô hình phản hồi thông báo và hành động thay người dùng
  • Các hành động khả dĩ gồm mở ứng dụng, hoàn tất đặt chỗ, tắt thông báo, soạn nháp trả lời
  • Những suy luận nặng hơn nhiều khả năng sẽ chạy phía máy chủ như Apple Private Cloud Compute hoặc các mô hình đám mây của Google, thay vì chỉ chạy trên thiết bị
• Framework App Intents của Apple cho phép nhà phát triển đưa các hành động ứng dụng có kiểu dữ liệu rõ ràng ra cho Siri và Apple Intelligence
• Trên Android, App Actions và Gemini đóng vai trò tương đương như một năng lực đang nổi lên để hành động bên trong ứng dụng của bên thứ ba
• Bên gửi không chỉ phải viết thông báo mà trình tóm tắt không làm hỏng, mà còn phải phơi bày các hành động phía sau thông báo để tác nhân có thể hoàn tất đặt chỗ hoặc xóa thông báo ngay cả khi người dùng không mở ứng dụng
• Thông báo sẽ không còn là đích đến mà trở thành một trigger để tác nhân tiêu thụ, và chỉ số CTR vốn là trung tâm của đo lường push suốt 10 năm qua sẽ mất đi phần lớn ý nghĩa

Nguyên tắc thực tiễn khi xử lý thông báo đẩy

• Chỉ dùng push cho những việc mà kênh khác không làm được

  • Push là kênh có thể chạm tới cả những người dùng đã không mở ứng dụng trong nhiều tuần, nên phù hợp nhất để đánh thức người dùng không hoạt động và các thông báo giao dịch thực sự nhạy cảm về thời gian
  • Thông báo phục vụ cross-sell, up-sell, giáo dục hay khám phá vẫn có thể dùng nếu đủ tính thời điểm và cá nhân hóa, nhưng về cơ bản chúng được xếp vào nhóm quảng bá và phải cạnh tranh trong thế bất lợi nhất về ngân sách gây phiền nhiễu của người dùng
  • Thông điệp quảng bá hiệu quả hơn và ít rủi ro hơn trên những màn hình mà người dùng chủ động mở ra

• Thiết kế xoay quanh hoạt động và yêu cầu của người dùng

  • Những thông báo dễ đi qua lớp biên tập trung gian của nền tảng là các tín hiệu do người dùng tự thiết lập và các sự kiện do sản phẩm tạo ra từ trạng thái của người dùng
  • Giảm giá, có hàng trở lại, danh sách quan tâm, kích hoạt ngưỡng, thông báo trạng thái của mục đang chờ đều là các tín hiệu do người dùng tự thiết lập
  • Tài liệu được chia sẻ, bình luận hoặc trả lời trên công việc, tác vụ đã hoàn tất, hạn mức bị vượt, bước tiếp theo của công việc đang diễn ra đều là các sự kiện do sản phẩm tạo ra từ trạng thái của người dùng
  • Cả hai loại đều là thông báo về thứ “thuộc về” người nhận, nên tự nhiên đáp ứng tiêu chí liên quan, và cần deeplink tới đúng vị trí trong sản phẩm nơi người dùng có thể hành động ngay

• Yêu cầu quyền không nên thực hiện ở lần chạy đầu mà trong đúng ngữ cảnh

  • Sau khi Android 13 chuyển quyền thông báo sang cơ chế phê duyệt runtime rõ ràng, tỷ lệ opt-in đã giảm mạnh
  • Thay vì hiện system prompt ngay sau lần chạy đầu, cần cho người dùng thấy giá trị bằng cách gắn nó với một tính năng mà họ sẽ muốn nhận thông báo, rồi mới yêu cầu
  • Vì quyền thông báo áp dụng cho toàn bộ kênh, không nên lãng phí nó vào một yêu cầu đầu tiên lạnh lùng

• Phân khúc và cá nhân hóa là mặc định

  • Dữ liệu từ vendor là tài liệu mang tính định hướng, nhưng suốt 10 năm qua vẫn chỉ ra cùng một kết luận: thông báo được phân khúc và cá nhân hóa có tỷ lệ mở cao xấp xỉ gấp đôi so với broadcast
  • Gửi hàng loạt một cách chung chung cho hiệu quả thấp và tiêu tốn quyền mà không thể lấy lại
  • Nếu đó không phải là thông điệp có thể gửi cho một người cụ thể vì một lý do cụ thể, thì tốt hơn là đừng gửi cho tất cả mọi người

• Đừng dùng quyền gây gián đoạn mà bạn chưa kiếm được

  • Không nên ngụy trang thông điệp marketing thành thông báo nhạy cảm về thời gian
  • Trên iOS, người dùng có thể tắt thông báo nhạy cảm về thời gian theo từng ứng dụng từ màn hình khóa, và bên gửi không thể phản đối điều đó
  • Tăng khối lượng gửi sẽ giết chết quyền, và đòn bẩy duy nhất mà bên gửi có thể duy trì là mức độ liên quan

• Mức độ tương tác quyết định khả năng được phân phối

  • Hệ thống xếp hạng của nền tảng học từ việc người dùng có hành động với thông báo hay không, nên một tệp người nhận lớn nhưng không nhấn vào sẽ khiến mô hình học cách đánh giá thấp ứng dụng và đẩy người dùng tới chỗ tắt thông báo
  • Push không có cơ chế danh tiếng người gửi bài bản như email, và hiệu quả cũng khác nhau theo từng ứng dụng và OS, nhưng xu hướng thì giống nhau
  • Những đăng ký đã im lặng cần được dọn dẹp; một tệp nhỏ nhưng có tương tác sẽ giữ được độ phủ tốt hơn một tệp lớn bị phớt lờ

• Ưu tiên sự thật hơn văn phong

  • Ở đầu tiêu đề, nên đặt payload cụ thể thay vì phần dẫn nhập mang giọng thương hiệu: thông tin như số tiền, tên, thời gian, hành động phải được ưu tiên
  • Bộ tóm tắt sẽ nén về phần cốt lõi và giữ lại nội dung mà máy dễ đọc, nên tiêu đề dựa trên sự thật có khả năng sống sót sau khi bị viết lại cao hơn tiêu đề dựa trên giọng điệu
  • Đây không phải quy tắc đã được đo lường mà là một mặc định hợp lý; không có thử nghiệm công khai và bằng chứng cũng chỉ là gián tiếp

• Đừng mù quáng tin vào dashboard push

  • Lượt mở và lượt nhấp nằm sau lớp biên tập vô hình, và các lượt chuyển đổi có thể đo được là mẫu lệch của những thông báo mà nền tảng đã quyết định ưu tiên
  • Chuyển đổi downstream là tín hiệu ít tệ nhất, nhưng sự kiện chuyển đổi từ push lại hiếm, nên với sản lượng gửi thông thường rất khó đạt ý nghĩa thống kê theo từng chiến dịch
  • Nếu có thể xác nhận việc render bằng SDK thì hãy xác nhận, gom các chiến dịch lại và kéo dài cửa sổ quan sát rồi mới tin vào các con số
  • Sự gia tăng tương tác có thể được hiểu là “copy tốt hơn” cũng nhiều như là “nền tảng tin tôi hơn”

• Dịch chuyển trọng tâm sang các bề mặt sở hữu

  • Hộp thư đến trong ứng dụng, màn hình sản phẩm đã đăng nhập, thư vật lý, các bề mặt loyalty do doanh nghiệp trực tiếp vận hành đều không có mô hình nằm trong đường ống
  • Các bề mặt này không bị tóm tắt, xếp hạng hay làm im lặng, và có thể đo lường đến tận cùng
  • Push và các bề mặt sở hữu không nên được vận hành như những kênh cạnh tranh mà như một danh mục thống nhất

• Thiết kế cho agent, không chỉ cho màn hình khóa

  • Khi Siri và Gemini bắt đầu hành động dựa trên thông báo, thứ mà agent có thể thực thi là những đề xuất sạch sẽ và máy có thể đọc được
  • Hành động đằng sau thông báo không nên bị chôn ở chỗ phải nhấn ba lần trong UI, mà phải được phơi bày dưới dạng có thể gọi qua App Intents của iOS hoặc App Actions của Android
  • Cần viết sao cho mô hình có thể thực hiện thông điệp ngay cả khi con người không đọc nó

Kết luận

• Push chưa bao giờ là một kênh được sở hữu hoàn toàn như email, mà gần với một kênh ít bị thuê lại hơn so với social
• Nền tảng đang định giá lại các điều kiện thuê theo hướng có lợi cho họ qua mỗi lần phát hành
• Những bên gửi sẽ vượt qua 10 năm tới không phải là bên gửi nhiều nhất hay dùng thông minh nhất, mà là bên gửi những thông điệp mà biên tập viên của nền tảng có thể bảo vệ vì người nhận vốn dĩ đã muốn nhận
• Công việc tốt nhất sẽ nghiêng về phía những bên đã chuyển sẵn sang các bề mặt nơi không có biên tập viên đứng phía trước
• Hãy viết cho những mô hình vô hình, và xây dựng cho những kênh mà các mô hình đó không thể chạm tới

[GN⁺]

Ý kiến trên Hacker News

• Nếu điện thoại làm phiền tôi, thì điều đó phải có nghĩa là ngay lúc này ai đó thực sự cần sự chú ý của tôi; nếu không thì đừng làm phiền tôi. Cài đặt thông báo của tôi chỉ cho phép đẩy thông báo từ điện thoại, tin nhắn, WhatsApp, Apple Health, ứng dụng ngân hàng
  Không có lý do gì để các ứng dụng khác phải gọi tôi ngay lập tức. Phần lớn ứng dụng gửi thông báo không phải vì có việc quan trọng mà vì chúng muốn chiếm sự chú ý của tôi
  Tôi không cần các thông báo như chuỗi ngày sử dụng, giảm giá, gợi ý hay cập nhật giao hàng; chúng hoàn toàn có thể chờ đến khi tôi chủ động mở ứng dụng

  • Bài này được viết khá lộ liễu từ góc nhìn của bên gửi, và lo rằng nền tảng đang giành lấy “quyền kiểm soát của người gửi”
    Nhưng hầu hết ứng dụng đã chứng minh quá đủ rằng chúng không thể tôn trọng sự chú ý của người dùng. Nền tảng càng dựng thêm nhiều rào cản giữa các thông báo không cần thiết và điện thoại của tôi thì càng tốt; tôi không xem Apple hay Google là anh hùng, nhưng ít nhất lợi ích của họ còn gần với lợi ích của tôi hơn là bộ phận marketing của cái ứng dụng tôi bị ép cài chỉ vì mua vé một lần
  • Vấn đề lớn nhất là các ứng dụng làm cả hai việc. Ví dụ, tôi muốn Uber báo khi tài xế đã đến, nhưng không muốn nhận kiểu giảm 10% cho 5 chuyến tiếp theo
    Không dễ để chặn riêng thông báo thiết yếu và thông báo quảng cáo
  • Tôi nhớ đến câu “marketing chưa từng gặp một hệ thống liên lạc nào mà họ không muốn chiếm lấy”
    Tôi lại nghĩ đến điều đó mỗi khi thấy khách hàng muốn thêm hỗ trợ WhatsApp vào ứng dụng thương mại để “giao tiếp với khách hàng”
    Đồng thời, với mỗi người dùng, tập con ứng dụng mà họ muốn nhận thông báo lại khác nhau. Nhân viên làm ca cần biết ca được phân hoặc ca mở đột xuất; thứ cực kỳ quan trọng với người này có thể lại là spam với người khác
    Thông báo hữu ích rất dễ biến chất thành thông báo marketing. Tôi muốn biết tài xế giao hàng đang ở ngoài, nhưng không muốn biết ưu đãi đặc biệt của tuần này
    Đây không phải vấn đề có thể giải quyết hoàn toàn bằng kỹ thuật. Kẻ xấu thì thực sự sẽ hành xử tệ. Dù vậy, hệ thống vẫn nên được thiết kế để các ứng dụng tử tế hoạt động tốt, và cuối cùng người quyết định sẽ xem gì phải là người dùng. Không phải Google hay Apple
    Nếu xây dựng xã hội theo mẫu số chung thấp nhất thì sẽ dở cho tất cả mọi người. Cần cho phép trừng phạt hành vi xấu đồng thời tích cực khuyến khích hành vi tốt, chứ không phải cấm sạch mọi thứ chỉ vì “có thể sẽ xấu”
  • Bài này đang trộn lẫn giữa “thông báo đẩy” và “bị làm phiền bởi thông báo đẩy”. Trên điện thoại của tôi có nhiều ứng dụng quan trọng nhưng không khẩn cấp, và tôi đặt chúng ở chế độ thêm im lặng vào trung tâm thông báo của iOS
    Với các ứng dụng đặt như vậy, khi thông báo đến sẽ không hiện banner và cũng không xuất hiện trên màn hình khóa. Chúng chỉ hiện khi tôi tự cuộn xuống bên dưới các thông báo mang tính thời điểm trên màn hình khóa để xem lại toàn bộ thông báo
    Thực chất nó bị hạ xuống thành một kiểu “hộp thư đến email” mà nếu muốn thì kiểm tra, không thì thôi. Khác với email, thông báo không thể là đường bắt buộc trong luồng công việc của ứng dụng, nên có thể dọn sạch hộp thư đến thông báo bất cứ lúc nào mà không áp lực
  • Apple và Google đã thất bại trong việc khiến thông báo đẩy trở nên đáng dùng suốt 10 năm qua. Những thông báo quan trọng bị chôn vùi trong biển rác hoàn toàn không liên quan
    Đây là một cấu trúc thô sơ nơi rất nhiều ứng dụng tranh giành một chút không gian màn hình, và đa số thông báo đẩy chẳng nói được gì hơn ngoài “đã có gì đó xảy ra!”. Thông tin có thể hành động được thì ít, còn chuyện thực sự đã xảy ra là gì thì lại mơ hồ
    Kết quả là giá trị của chính khái niệm thông báo bị suy giảm, và ngay cả khi có thứ gì đó đôi lúc thú vị lướt qua thì cũng dễ bỏ lỡ hoặc khó tìm lại
    Trải nghiệm người dùng của thông báo đẩy rất tệ, và ngày càng tệ hơn theo thời gian khi các nhà phát triển ứng dụng lạm dụng siêu năng lực làm phiền người dùng tùy ý. Apple và Google đã cố kiểm soát điều này, nhưng kết quả còn lại chỉ ở mức tầm thường ngay cả với số ít trường hợp sử dụng chính đáng
    Những thứ như phê duyệt ngân hàng hay xác thực hai yếu tố thì hữu ích với deeplink vào ứng dụng, nhưng ngoài ra không đáng để tôi dừng việc đang làm và nhìn vào điện thoại
    Trên điện thoại Android của tôi, các ứng dụng dùng nhiều nhất là Firefox, Gmail và chỉ thêm vài cái khác. Về kênh thông báo, hộp thư đến email hữu ích hơn thông báo đẩy trên di động rất nhiều. Nó có thể hành động hơn, nhiều thông tin hơn, và cũng dễ hủy đăng ký từng loại, lọc hay tìm lại hơn. Phần lớn ứng dụng làm được cả hai nên thông báo đẩy trở thành thứ kém hơn và trùng lặp

• Bài này đọc như thể tác giả đang giận vì Apple và Google chặn hoặc kiểm soát một số loại thông báo nhất định, tức thông báo dạng spam
  “Bán chéo, bán nâng cấp, giáo dục, khám phá cũng có thể hiệu quả qua push”, nhưng thông báo đẩy chỉ nên dùng cho thông báo giao dịch. Tôi không muốn thêm một hộp thư đến dành cho rác nữa

  • Tôi muốn bật thông báo cho ứng dụng đặt lịch bệnh viện vì cần nhắc lịch. Nhưng gần đây họ bắt đầu gửi tin nhắn marketing qua chính kênh đó
    Chắc là có cách tắt riêng tin marketing, nhưng đa số sẽ không biết và cũng không đổi. Thật sự rất bực
  • Tôi ước Apple bắt buộc nhà phát triển ứng dụng triển khai thông báo quảng bá và thông báo giao dịch thành các kênh thông báo khác nhau. Như vậy người dùng có thể chỉ chọn những gì mình muốn
  • Trong tiêu đề “thông báo đẩy của bạn”, “bạn” không phải người dùng mà là marketer. Chỉ riêng điều đó cũng cho thấy khá rõ giá trị của bài này
  • Không hẳn là giận, mà là lo rằng mọi kênh rồi sẽ ngày càng phải đi qua sự môi giới của Big Tech
  • Tùy từng trường hợp. BlackBerry 10 Hub được thiết kế rất chặt như một hộp thư đến dùng chung, chứ không phải hệ thống thông báo lỏng lẻo kiểu iOS hay Android, và nó thực sự rất tốt

• Những dịch vụ như Uber, Bolt, Airbnb thật khó chịu. Dịch vụ cốt lõi thì cần push, nhưng nhà cung cấp lại lợi dụng khe hở đó để nhét spam vào

  • Uber đặc biệt tệ. Tôi sống ở vùng quê nên bình thường không dùng, nhưng khi đi du lịch thì có dùng Uber hoặc đôi khi là Uber Eats
    Giờ rác marketing xâm lấn quá mức nên tôi chỉ cài ứng dụng khi nghĩ là sắp cần, còn không thì xóa đi. Được giao hamburger thì tốt đấy, nhưng điều còn khó chịu hơn là dịch vụ ấy theo nghĩa đen chẳng có gì có thể mang đến tận nhà tôi cả
  • Apple và Google đã để các dịch vụ lạm dụng thông báo, khiến thông báo về cơ bản trở nên vô giá trị. Tôi ước họ tôn trọng hơn thời gian và sự chú ý của tôi

• Mọi người quá thụ động trước những thứ đánh cắp sự chú ý của mình, điều đó luôn làm tôi ngạc nhiên
  Điện thoại của tôi để Không làm phiền 24/7. Nếu ứng dụng báo mấy thứ vô bổ thì tôi xóa và dùng website
  Tôi cũng có quy tắc email chuyển mọi thư có chữ “unsubscribe” ra khỏi hộp thư đến sang một vùng gắn thẻ riêng. Cứ vài ngày tôi lại vào đó và hủy đăng ký tất cả những thứ mới đến
  Nếu ở quầy thanh toán cửa hàng người ta hỏi thông tin cá nhân, số điện thoại hay bắt tham gia câu lạc bộ thành viên, tôi sẽ hỏi có được giảm giá không. Không giảm thì không có thông tin. Nếu họ đưa ra mức giá hợp lý cho dữ liệu của tôi thì tôi sẽ cân nhắc, nhưng đến giờ chưa có cửa hàng nào trả xứng với giá trị thời gian và thông tin của tôi

  • Khi cửa hàng đòi số điện thoại thì ngay từ đầu đã có vẻ chẳng đáng để cân nhắc. Họ có thể giảm giá một lần rồi giữ và lạm dụng thông tin đó suốt nhiều năm
  • Tôi đã làm một phiên bản nâng cao hơn của quy tắc hủy đăng ký để diệt sạch mọi thông báo email không cần thiết, và đã mã nguồn mở nó
    https://unfuck.email
  • Tôi hiểu và thấy cách nói “thụ động” là hợp lý, nhưng nói chính xác hơn thì đa số cảm thấy mình không có lựa chọn
    Không nghe điện thoại hay không trả lời tin nhắn là điều cấm kỵ với nhiều người, nên họ bị cuốn vào một cuộc chạy đua vũ trang khi spammer và các ứng dụng mạng xã hội tấn công từ mọi phía. Những người đó thấy ngột ngạt khi chúng ta sống trong vùng đất Không làm phiền 24/7
    Tôi không biết giải quyết thế nào, nhưng cũng hiểu lập trường đó

• Hãy thử tắt hết mọi thứ trừ thông báo tin nhắn và sống như vậy một ngày. Bạn sẽ không chết đâu. Bạn sẽ nhanh chóng quen với việc định kỳ kiểm tra những thứ mình thực sự quan tâm, còn phần còn lại thì phải chờ đến khi bạn quan tâm
  Tôi đã sống như vậy nhiều năm rồi, bạn bè và đồng nghiệp của tôi không biết chuyện đó và cũng không cần biết. Thông báo không giúp tôi trả lời nhanh hơn, chúng kéo sự chú ý của tôi khỏi việc tôi đang định làm
  Hôm nay tôi còn chưa kiểm tra Discord hay email. Khi nào tôi muốn biết bạn bè có nhắn gì không, có hóa đơn mới không, hay có thứ gì cần theo dõi tiếp không, tôi sẽ mở ứng dụng đó lên và xử lý
  Tôi có thể để điện thoại bên cạnh hàng giờ mà không bị xao nhãng

  • Việc “quen với chuyện định kỳ kiểm tra những thứ mình thực sự quan tâm” là thay đổi lớn nhất với tôi. Trước đây tôi lo tắt thông báo sẽ bỏ lỡ việc quan trọng, nhưng thật ra có thông báo tôi vẫn bỏ lỡ như thường
    Thói quen định kỳ kiểm tra những thứ quan trọng cũng có tác dụng phụ tích cực. Tôi bớt phụ thuộc vào việc điện thoại làm thay, nên hệ thống nhắc nhở tinh thần của tôi tốt hơn, và tôi cũng thấy rõ hơn những ứng dụng và dịch vụ mình ngày càng ít kiểm tra thực ra chẳng quan trọng đến thế
    Giờ tôi có ít ứng dụng và tài khoản hơn nhiều, mà ngược lại còn giữ thời gian tốt hơn trên tổng thể

• Phần này không đúng sự thật: “Thông báo chỉ tồn tại trong trung tâm thông báo, và trung tâm thông báo sẽ xóa, loại bỏ, tóm tắt những gì đi qua, không lưu giữ ổn định bất cứ thứ gì”
  Trung tâm thông báo có lưu giữ thông tin một cách ổn định. Kiểu như một hộp thư đến vậy, chỉ là không có trong không gian người dùng nhưng thực tế vẫn tồn tại: https://www.forbes.com/sites/larsdaniel/2026/04/10/fbi-pulle...

• “Trong 15 năm, kênh này đã được tái kiến trúc xoay quanh một giả định: sự chú ý của người nhận là tài nguyên khan hiếm và nền tảng có nghĩa vụ bảo vệ nó. … Với tư cách người gửi, bạn đứng ở phía đối diện của giả định đó, bất kể quyền kiểm soát chuyển về bên nào”
  Điều thú vị là tác giả công khai đóng khung tình huống này như một trường hợp lợi ích của người gửi và người nhận đối lập nhau

  • Không hẳn là đối lập, mà gần với trạng thái căng kéo hơn
    Một thiết bị quá nhiệt tình bảo vệ sự chú ý của người dùng đôi khi có thể chặn thứ mà người dùng thực sự muốn thấy
    Dù vậy, phần lớn thông báo là rác và nên bị chặn
  • Có vẻ là cách đọc khá khắt khe. Tôi nghĩ câu đó gần với việc nói rằng nền tảng hành động theo lợi ích của chính nền tảng, chứ không phải lợi ích của người dùng

• “Không phải mọi tác động này đều diễn ra đồng đều. Việc biên tập giáng mạnh nhất vào các push mang tính phát tán/quảng bá, còn những thông báo mà người dùng thực sự muốn thì thường vẫn lọt qua hoặc thậm chí được khuếch đại”
  Với tôi thì nghe ổn đấy

• “Trong phần lớn lịch sử của kênh này, nền tảng hầu như không can thiệp một cách dễ thấy. Về mặt cấu trúc thì hoàn toàn có thể can thiệp, chỉ là họ chọn không can thiệp nhiều. Sự kiềm chế đó đã kết thúc”
  Có thể không phải lúc nào cũng nhìn thấy rõ, nhưng ngay từ đầu đã luôn có sự can thiệp dưới dạng nào đó. Ở WhatsApp, chúng tôi luôn theo dõi độ trễ, việc chặn, và gộp push, và theo trí nhớ của tôi thì đó đã là một phần của hệ thống ít nhất từ khi tôi tham gia năm 2011
  Nếu nó không hoạt động đúng trong hệ thống đó thì tin nhắn người dùng sẽ không được chuyển đúng lúc

  • Thú vị thật. Tôi muốn biết liệu bạn có thể chia sẻ thêm bối cảnh liên quan không. Tôi chưa từng làm ở một sản phẩm quy mô lớn như vậy, nên việc theo dõi của tôi luôn chỉ giới hạn ở những gì có thể lấy từ các nền tảng push thương mại

• Một điều gì đó đã thay thế việc thu thập hàng loạt siêu dữ liệu cuộc gọi theo Điều 215 của USA PATRIOT Act dường như đang ảnh hưởng đến cấu trúc của Apple Push Notification, Firebase Cloud Messaging, v.v.
  Apple sở hữu kết nối liên tục tới mọi iPhone, và chỉ APNs mới có thể đánh thức ứng dụng. Ở đây, “tự lưu trữ” có nghĩa là vận hành backend nhà cung cấp của riêng mình để quyết định gửi gì rồi chuyển cho APNs, thay vì giao cho bên thứ ba như Firebase Cloud Messaging, OneSignal hay Pusher. Nhưng chặng cuối cùng thì chưa bao giờ là của tôi
  Kiến trúc buộc lưu lượng của mọi người phải đi qua một số ít bên trung gian nhận diện danh tính, về bản chất thiết kế, là một hệ thống thu thập hàng loạt siêu dữ liệu chỉ chờ công cụ pháp lý được kích hoạt
  Tháng 12 năm 2023, Thượng nghị sĩ Ron Wyden đã tiết lộ rằng chính phủ Mỹ và các chính phủ nước ngoài đã bí mật buộc Google và Apple phải giao nộp thông tin thông báo đẩy, siêu dữ liệu liên lạc, và đôi khi cả nội dung. Điều các nhà phát triển cần quan tâm là không có cách nào để ngăn chặn thực tiễn này nếu muốn gửi thông báo trên các nền tảng mà iPhone và Android phụ thuộc vào
  Apple bị cấm tiết lộ về chương trình này cho đến khi nó bị công khai, và sau đó cho biết sẽ phản ánh chi tiết các yêu cầu như vậy trong báo cáo minh bạch của mình. Vì vậy, giả thuyết mang tính cấu trúc này không phải suy đoán mà là một cơ chế đã được xác nhận; điểm khác với Section 215 là phạm vi không phải cuộc gọi mà là ứng dụng, và công cụ pháp lý không phải học thuyết hồ sơ kinh doanh cụ thể của §215 mà là trát đòi thông thường, lệnh FISA và NSL
  Câu “đó chỉ là siêu dữ liệu thôi mà” rốt cuộc xuất phát từ chính bối cảnh như thế này. Tất nhiên đây là một câu đùa; không phải chỉ một cá nhân đơn lẻ phải chịu trách nhiệm cho chuyện này, mà đó là kết quả của ý chí chính trị tập thể, và đáng buồn là có thể đây là điều tốt nhất chúng ta có thể làm
  https://www.youtube.com/watch?v=9iUdm0QMDM0
  https://epic.org/sen-wyden-reveals-government-surveillance-o...