Cập nhật lần cuối: 2026-09-04

Giới hạn ký tự thông báo đẩy - Hướng dẫn iOS & Android

Thông báo đẩy phải cạnh tranh sự chú ý trong khay thông báo đông đúc. Việc hiểu giới hạn ký tự theo từng nền tảng và thiết kế văn bản để đạt tác động tối đa trong những ràng buộc đó là điều thiết yếu cho tương tác người dùng. Những giới hạn này không chỉ xuất phát từ lựa chọn thiết kế UI mà còn từ các ràng buộc kỹ thuật về kích thước payload của APNs (Apple Push Notification service) và FCM (Firebase Cloud Messaging).

Giới hạn payload APNs và FCM - Nguyên nhân kỹ thuật gốc

Nguyên nhân cơ bản khiến văn bản thông báo đẩy bị giới hạn nằm ở giới hạn kích thước payload. Với API HTTP/2 hiện hành, APNs cho phép payload tối đa 4.096 byte (4 KB). Đây là giá trị của giao diện hiện tại: kết nối nhị phân kiểu cũ chỉ cho phép 2 KB và đã ngừng hoạt động từ tháng 3 năm 2021, nên các tài liệu cũ ghi 2 KB không còn phản ánh thực tế. Tin nhắn thông báo FCM cũng có cùng mức trần 4.096 byte, trong khi tin nhắn dữ liệu bị giới hạn ở 4.000 byte.

Payload chứa nhiều hơn chỉ tiêu đề và nội dung. Cài đặt âm thanh, số huy hiệu và dữ liệu tùy chỉnh (URL deep-link, ID chiến dịch, v.v.) đều chiếm không gian trong cùng một envelope được mã hóa JSON. Vì UTF-8 mã hóa ký tự đa byte ở mức 2–4 byte mỗi ký tự, số ký tự hiệu quả thay đổi theo ngôn ngữ. Sau khi trừ đi metadata và các trường tùy chỉnh, ngân sách văn bản thực tế thường ít hơn một nửa giới hạn payload thô.

Giới hạn ký tự theo nền tảng

Ngoài giới hạn payload, mỗi hệ điều hành áp đặt các ràng buộc hiển thị riêng. Trước khi xem bảng, cần lưu ý một điểm: tài liệu chính thức của các nền tảng quy định lượng nội dung hiển thị theo số dòng, chứ không quy định theo số ký tự. Tài liệu của Android chỉ nói rằng nội dung ở trạng thái thu gọn được cắt cho vừa một dòng, và không nêu bất kỳ ngưỡng ký tự nào.

Vì vậy, các con số trong bảng dưới đây là mức tham chiếu thực tế tính đến tháng 8 năm 2026, dựa trên cỡ chữ mặc định của hệ thống, và bao gồm cả những hạng mục không được nhà cung cấp công bố. Hãy đọc chúng như quan hệ tương đối giữa các khung hiển thị (khung nào rộng hơn khung nào) thay vì như những giá trị tuyệt đối cần tuân thủ chính xác. Cỡ chữ do người dùng đặt, ngôn ngữ và phiên bản hệ điều hành đều làm con số thực tế xê dịch.

Một chi tiết quan trọng: ngay cả trên cùng một hệ điều hành, ngữ cảnh hiển thị cũng ảnh hưởng rất lớn. Banner iOS hiển thị khoảng 80 ký tự nội dung trước khi biến mất, trong khi màn hình khóa hiển thị khoảng 178 ký tự trên bốn dòng. Trung tâm thông báo cho phép người dùng nhấn giữ để xem toàn bộ văn bản payload.

Phân bổ số ký tự theo loại thông báo

Thay vì tìm một con số "chuẩn" dùng cho mọi thông báo, hãy chia thông báo theo mục đích rồi phân bổ số ký tự khác nhau cho từng loại. Cách chia đơn giản nhất là hai loại sau.

• Thông báo để xác nhận: xác nhận đơn hàng, biến động số dư, trạng thái giao hàng, kết quả xử lý. Người dùng đã biết trước rằng thông báo này sẽ đến, nên chỉ cần dữ kiện: cái gì, bao nhiêu, khi nào. Ở đây mọi lời dẫn dắt đều chiếm chỗ của dữ kiện, vì vậy hãy dồn thông tin quan trọng vào tiêu đề và giữ nội dung ngắn nhất có thể
• Thông báo để dẫn dắt hành động: khuyến mãi, gợi ý nội dung mới, nhắc quay lại ứng dụng. Người dùng không chờ đợi thông báo này, nên tiêu đề phải nêu được lý do đáng mở ngay, còn nội dung cần đủ chỗ cho một điều kiện cụ thể (thời hạn, phạm vi áp dụng). Loại này thường cần nhiều ký tự hơn loại xác nhận, nhưng phần vượt thêm phải mang thông tin chứ không phải lời hô hào

Cái bẫy thường gặp là dùng chung một mẫu (template) cho cả hai loại. Khi mẫu được thiết kế cho thông báo khuyến mãi, thông báo xác nhận sẽ bị chèn thêm phần chào hỏi mở đầu và con số quan trọng bị đẩy ra khỏi khung hiển thị thu gọn; ngược lại, khi mẫu được thiết kế cho thông báo xác nhận, thông báo dẫn dắt lại mất phần điều kiện nên người dùng không hiểu vì sao phải mở. Với mỗi mẫu đang dùng, hãy kiểm tra một điều: dữ kiện quan trọng nhất có nằm trong phạm vi hiển thị của khung hẹp nhất hay không.

Giống như email doanh nghiệp, sự ngắn gọn là thiết yếu, nhưng thông báo đẩy đòi hỏi nén nhiều hơn nữa. Với chế độ xem thu gọn chỉ hiển thị 1–2 dòng, 40 ký tự đầu tiên của nội dung phải chứa thông điệp cốt lõi.

Tại sao giới hạn ký tự khác nhau giữa các nền tảng

Thông báo banner iOS bị giới hạn ở hai dòng theo thiết kế. Thông báo vốn được thiết kế như một sự ngắt quãng đối với việc người dùng đang làm, nên vùng hiển thị được giữ nhỏ một cách có chủ đích: nó phải đủ để nhận ra nội dung mà không chiếm lấy toàn bộ màn hình. Bắt đầu từ iOS 16, thông báo màn hình khóa được chuyển xuống cuối màn hình để ưu tiên hiển thị hình nền, càng thu hẹp thêm vùng hiển thị.

Chế độ xem mở rộng của Android đi theo cách nghĩ về giao diện thường được gọi là tiết lộ dần dần (progressive disclosure). Trạng thái thu gọn hiển thị tóm tắt một dòng; nếu người dùng quan tâm, họ có thể mở rộng để đọc toàn bộ tin nhắn. Kể từ Android 13, quyền thông báo đã chuyển sang mô hình đồng ý chủ động yêu cầu sự đồng ý rõ ràng của người dùng thông qua quyền POST_NOTIFICATIONS - tương tự hành vi iOS. Thay đổi này đã làm giảm tỷ lệ đồng ý trên Android, khiến việc cung cấp thông báo chất lượng cao cho những người dùng đã cấp quyền trở nên quan trọng hơn bao giờ hết.

Giới hạn ký tự thông báo đa phương tiện và cân nhắc thiết kế

Thông báo đa phương tiện - sử dụng Notification Content Extensions của iOS và BigPictureStyle / BigTextStyle của Android - hỗ trợ hình ảnh, nút hành động và carousel. Tuy nhiên, chúng tạo ra các ràng buộc văn bản khác với thông báo văn bản thuần.

• Hình ảnh đính kèm thu nhỏ vùng văn bản: khi có ảnh đính kèm, phần văn bản phải chia không gian với ảnh nên vùng đọc được của nội dung hẹp lại; mức hẹp đi bao nhiêu thay đổi theo khung hiển thị và phiên bản hệ điều hành nên không nên coi là một con số cố định. Thêm nữa, ảnh được tải qua mạng và có thể không kịp hiện: hãy viết sao cho khi chỉ còn tiêu đề và nội dung, thông báo vẫn hiểu được trọn nghĩa, đừng để thông tin quyết định chỉ nằm trong ảnh
• Nhãn nút hành động: tài liệu của Android nêu rõ một thông báo có thể cung cấp tối đa ba nút hành động; ở phía iOS, số nút hiển thị được cũng chỉ là một vài. Còn độ dài tối đa của nhãn thì không được nêu trong tài liệu chính thức, và nhãn dài sẽ bị cắt, nên trên thực tế hãy giữ nhãn ở mức khoảng 5–8 ký tự (ví dụ: "Mua ngay", "Xem chi tiết")
• Ảnh hưởng đến payload: URL hình ảnh và định nghĩa nút hành động chiếm không gian payload, giảm ngân sách dành cho văn bản. Hình ảnh thường được gửi qua tham chiếu URL (sử dụng mutable-content của APNs + Notification Service Extension) thay vì nhúng trực tiếp trong payload

Ràng buộc hiển thị thiết bị đeo - Trường hợp biên bị bỏ qua

Apple Watch và thiết bị Wear OS áp đặt giới hạn ký tự chặt hơn cả điện thoại thông minh. Trên Apple Watch, Short Look (hiển thị trong vài giây khi nhận thông báo) chỉ hiển thị tên ứng dụng và một phần tiêu đề - nội dung không hiển thị cho đến khi người dùng chuyển sang Long Look. Ngay cả trong Long Look, màn hình nhỏ khiến văn bản xuống dòng ở khoảng 60 ký tự.

Trên Wear OS, thông báo xuất hiện dưới dạng thẻ mà người dùng có thể cuộn qua, nhưng chế độ xem ban đầu chỉ hiển thị tiêu đề và khoảng 30 ký tự đầu tiên của nội dung. Vì người dùng thiết bị đeo thường kiểm tra thông báo khi đang di chuyển hoặc tập thể dục, chỉ riêng tiêu đề phải truyền tải thông tin thiết yếu. Đối với thông báo tối ưu cho thiết bị đeo, hãy giữ tiêu đề dưới 20 ký tự và đặt thông điệp cốt lõi trong 30 ký tự đầu tiên của nội dung.

Ràng buộc thông báo đẩy Web

Thông báo đẩy web khác biệt đáng kể giữa các tổ hợp trình duyệt và hệ điều hành. Chrome, Firefox và Safari mỗi trình duyệt hiển thị số ký tự và kiểu trực quan khác nhau, vì vậy thiết kế cho môi trường hạn chế nhất là cách tiếp cận an toàn nhất.

Safari bắt đầu hỗ trợ Web Push từ macOS Ventura, nhưng trên iOS, Web Push chỉ khả dụng từ iOS 16.4 trở đi và chỉ dành cho PWA (ứng dụng được thêm vào màn hình chính). Các tab trình duyệt thông thường không thể gửi Web Push trên iOS, điều này hạn chế khả năng tiếp cận người dùng iOS.

Theo nguyên tắc chung, tiêu đề dưới 30 ký tự và nội dung dưới 80 ký tự sẽ hiển thị không bị cắt trên các tổ hợp trình duyệt-hệ điều hành chính. Với Web Push, tên nguồn gửi được hiển thị theo tên miền hoặc tên trình duyệt nên người dùng khó nhận ra ngay đó là thông báo của trang nào; vì vậy biểu tượng và hình huy hiệu nên được đặt để nhận diện nguồn gửi, và nếu tên thương hiệu chưa xuất hiện ở đâu khác thì hãy đưa nó vào đầu tiêu đề.

Thiết kế A/B Test cho thông báo đẩy

A/B test thông báo đẩy đòi hỏi cách tiếp cận khác với A/B test email. Thông báo không thể thu hồi sau khi gửi, và phản ứng của người dùng tập trung trong vài phút, vì vậy thiết kế thử nghiệm phải tính đến những ràng buộc này.

• Cô lập một biến cho mỗi thử nghiệm: Nếu bạn đang thử nghiệm độ dài tiêu đề, hãy giữ nguyên nội dung, thời gian gửi và hình ảnh. Thay đổi nhiều yếu tố cùng lúc khiến không thể quy kết quả cho bất kỳ yếu tố đơn lẻ nào
• Đảm bảo kích thước mẫu đủ lớn: Mỗi biến thể cần ít nhất 1.000–2.000 người dùng để có kết quả có ý nghĩa thống kê. Ứng dụng có cơ sở người dùng nhỏ hơn nên tích lũy dữ liệu qua nhiều chu kỳ thử nghiệm
• Kiểm soát theo thời gian trong ngày: Gửi cả hai biến thể cùng thời điểm. Tỷ lệ nhấp buổi sáng và buổi tối khác nhau đáng kể, vì vậy gửi lệch thời gian sẽ làm sai lệch kết quả
• Theo dõi ngoài tỷ lệ nhấp: Đo tỷ lệ chuyển đổi từ thông báo, thời gian phiên trong ứng dụng và tỷ lệ tắt thông báo cùng với tỷ lệ nhấp. Tỷ lệ nhấp cao kèm theo tỷ lệ tắt thông báo tăng là tín hiệu thiệt hại dài hạn

Chiến lược ký tự thông báo cá nhân hóa

Thông báo cá nhân hóa chèn dữ liệu động - tên người dùng, tên sản phẩm hoặc số dư tài khoản - vào mẫu, nghĩa là phần văn bản cố định phải được điều chỉnh kích thước để chứa các phần chèn có độ dài thay đổi. Ví dụ, một mẫu như "{username}, bạn đã để lại sản phẩm trong giỏ hàng" sẽ thay đổi tổng độ dài tùy thuộc vào tên người dùng.

Tên người dùng thường chỉ gồm vài ký tự, nhưng cũng có những trường hợp vượt quá 20 ký tự. Khi thiết kế mẫu, hãy giữ phần cố định dưới 25 ký tự và dành ít nhất 15 ký tự cho phần động, để tiêu đề vẫn hiển thị không bị cắt cả với tên dài.

Điều dễ bị bỏ qua khi cá nhân hóa là chuyện phần chèn thất bại. Nếu dữ liệu chưa có hoặc không lấy được, mẫu có thể hiện ra dạng "{username}, bạn đã để lại sản phẩm..." hoặc mất hẳn phần tên và trở thành một câu vô nghĩa. Vì vậy hãy chuẩn bị một văn bản thay thế cho mọi phần chèn (ví dụ: "Bạn" thay cho tên) và trước khi phát hành hãy kiểm tra hiển thị với hai trường hợp biên: giá trị dài nhất có thể, và chuỗi rỗng. Chỉ cần xem hai trường hợp này trên khung hiển thị hẹp nhất là đã chặn được phần lớn sự cố.

Ngăn chặn mệt mỏi thông báo - Tần suất và số ký tự

Với thông báo đẩy, "không gửi quá nhiều" là điều tối quan trọng. Gửi nhiều lần trong một ngày làm tăng rủi ro người dùng tắt thông báo hoặc gỡ ứng dụng. Việc tắt thông báo là một dạng rời đi gần như không thể đảo ngược: rất khó chờ người dùng tự bật lại, và phía gửi lại khó nhận ra rằng thông báo "không còn đến được" nữa. Nếu chỉ theo dõi tỷ lệ mở, bạn sẽ không thấy được việc tổng số người nhận đang âm thầm giảm đi.

Tần suất và số ký tự có mối tương quan. Khi gửi thường xuyên (một lần mỗi ngày trở lên), hãy giữ mỗi thông báo cực ngắn (tiêu đề dưới 15 ký tự, nội dung dưới 30) để giảm thiểu tải nhận thức. Khi gửi ít hơn (1–2 lần mỗi tuần), nội dung dài hơn một chút (60–80 ký tự) với chi tiết phong phú hơn có thể chấp nhận được mà không gây mệt mỏi.

Loại thông báo cũng quan trọng. Thông báo giao dịch (xác nhận đơn hàng, cập nhật vận chuyển) được miễn giới hạn tần suất vì người dùng mong đợi chúng theo thời gian thực. Tuy nhiên, thông báo quảng cáo nên giới hạn ở mức 2–5 lần mỗi tuần cho hầu hết ứng dụng. Triển khai giới hạn tần suất theo người dùng (số lần gửi tối đa trong một khoảng thời gian cuộn) cung cấp biện pháp bảo vệ có hệ thống chống lại mệt mỏi thông báo.

Sự khác biệt tỷ lệ cấp quyền iOS và Android

iOS từ đầu đã yêu cầu người dùng cấp quyền thông báo một cách rõ ràng, trong khi Android 12 trở về trước bật thông báo theo mặc định cho mọi ứng dụng. Từ Android 13, quyền POST_NOTIFICATIONS cần được người dùng đồng ý rõ ràng, nên hiện nay cả hai hệ điều hành đều có cùng tiền đề: thông báo chỉ đến được với những người đã cấp quyền. Sau thay đổi này, tỷ lệ đồng ý trên Android có xu hướng giảm.

Đối với ứng dụng iOS, thời điểm và cách diễn đạt yêu cầu cấp quyền rất quan trọng. Thay vì yêu cầu ngay lần khởi chạy đầu tiên, mô hình "tiền cấp quyền" - hỏi sau khi người dùng đã trải nghiệm giá trị (ví dụ: sau lần mua đầu tiên hoặc thêm mục yêu thích) - hiệu quả hơn nhiều. Hãy dùng một hộp thoại trong ứng dụng để giải thích lợi ích của thông báo trước, và chỉ khi người dùng chọn "nhận thông báo" thì mới gọi hộp thoại cấp quyền của hệ điều hành. Lý do là hộp thoại của hệ điều hành chỉ hiện được một lần: khi đã bị từ chối, ứng dụng không thể gọi lại mà phải hướng dẫn người dùng vào tận màn hình cài đặt. Đặt hộp thoại trong ứng dụng lên trước chính là để dành cơ hội một lần đó cho những người thực sự quan tâm.

Các lỗi thường gặp

• Gửi thông báo vào đêm khuya: Thông báo từ 10 giờ tối đến 7 giờ sáng không chỉ làm phiền giấc ngủ; chúng trực tiếp dẫn đến việc tắt thông báo và gỡ cài đặt ứng dụng. Lên lịch theo múi giờ là thiết yếu. Đối với ứng dụng phân phối toàn cầu, điều này có nghĩa là phát hiện múi giờ địa phương của mỗi người dùng và lên lịch gửi tương ứng
• Tiêu đề mơ hồ như "Cập nhật" hoặc "Quan trọng": Tiêu đề chung chung bị bỏ qua như spam. Nếu tiêu đề chứa con số và thời hạn cụ thể, chẳng hạn "Giảm 50% đến 6 giờ chiều hôm nay", người dùng có thể phán đoán được nội dung ngay tại thời điểm nhìn thấy thông báo mà không cần mở ứng dụng
• Gửi cùng một thông báo cho tất cả người dùng: Gửi hàng loạt không phân đoạn là tiếng ồn đối với người dùng không liên quan. Phân đoạn theo thuộc tính người dùng (lịch sử mua hàng, tần suất sử dụng ứng dụng, khu vực) và điều chỉnh nội dung thông báo cho từng phân đoạn cải thiện cả tỷ lệ nhấp và tỷ lệ chuyển đổi
• Thiếu deep link: Mở màn hình chính của ứng dụng sau khi nhấp thông báo là thất bại UX. Hãy đưa người dùng trực tiếp đến màn hình tương ứng với nội dung thông báo (trang chi tiết sản phẩm, trang chiến dịch, màn hình trạng thái đơn hàng). Điểm cốt lõi là không buộc người vừa quan tâm vì thông báo phải đi tìm lại màn hình đó trong ứng dụng

Kỹ thuật thông báo chuyên nghiệp

• Dùng thông báo đa phương tiện theo kiểu "chỉ văn bản vẫn đủ": hình ảnh hoặc ảnh thu nhỏ giúp thông báo dễ được để ý hơn trong danh sách, nhưng ảnh có thể không tải được tùy tình trạng mạng của thiết bị. Hãy dựng bố cục sao cho khi ảnh không hiện, chỉ tiêu đề và nội dung cũng đã đủ dùng, và đừng dồn hết thông tin vào ảnh
• Tối ưu hóa thời gian gửi theo từng người dùng: Thay vì gửi cho tất cả người dùng cùng lúc, hãy suy luận giờ hoạt động nhiều nhất của mỗi người dùng từ mô hình sử dụng ứng dụng và lên lịch gửi riêng lẻ. Khung giờ được cho là có phản hồi tốt thay đổi theo tính chất của từng dịch vụ và khác biệt giữa các cá nhân cũng rất lớn, nên cách chắc chắn nhất là xem log gửi của chính bạn theo từng khung giờ rồi mới quyết định
• Tận dụng kênh thông báo để kiểm soát ưu tiên: Kênh thông báo Android 8.0+ cho phép bạn tách các loại thông báo (giao dịch, quảng cáo, tin tức) thành các kênh riêng biệt. Người dùng có thể bật/tắt từng kênh độc lập, ngăn các cảnh báo giao dịch quan trọng bị tắt tiếng cùng với tin nhắn quảng cáo

Kết luận

Giới hạn ký tự thông báo đẩy được định hình bởi cả giới hạn payload APNs/FCM và triết lý thiết kế UI của mỗi hệ điều hành. Ràng buộc hiển thị khác nhau không chỉ giữa iOS và Android mà còn giữa màn hình khóa, banner, trung tâm thông báo và thiết bị đeo. Để an toàn đa nền tảng, hãy giữ tiêu đề dưới 20 ký tự và nội dung dưới 40. Việc phân bổ số ký tự theo loại thông báo (để xác nhận, hay để dẫn dắt hành động), cải thiện liên tục bằng A/B test, và thiết kế cá nhân hóa có tính đến cả trường hợp phần chèn bị thất bại là những yếu tố quyết định hiệu quả của thông báo. Sử dụng Bộ đếm ký tự để xác minh văn bản thông báo của bạn phù hợp trước khi gửi.