Push notification (thông báo đẩy) là tin ngắn hiện trên điện thoại để báo đơn hàng, nhắc lịch hoặc thông tin có ích ngay cả khi khách không mở ứng dụng. Gửi đúng lúc có thể giúp khách quay lại; gửi quá nhiều hoặc sai nhu cầu dễ khiến họ tắt thông báo hay gỡ app.
Trước khi gửi, doanh nghiệp cần biết ai nên nhận, việc gì đang chờ họ, lúc nào phù hợp, nhấn vào thấy gì và đo kết quả ra sao. Kinh doanh, chăm sóc khách hàng và kỹ thuật phải phối hợp để không gửi các thông báo trùng nhau.
Trả lời nhanh: Hãy xin quyền đúng lúc, chọn đúng người nhận, gửi theo việc thật, giới hạn tần suất, mở đúng màn hình và đo số việc hoàn tất. Luôn cho khách điều chỉnh/tắt thông báo; lượt mở không đủ để kết luận tăng giữ chân người dùng.
Push notification là gì trong hệ thống retention?
Thông báo đẩy là tin có thể hiện khi app đang đóng, ví dụ “Lịch hẹn lúc 15 giờ đã xác nhận”. Nó chỉ giúp khách quay lại khi có việc cần làm, không thay được một ứng dụng thường xuyên gặp lỗi hoặc thiếu giá trị.
Firebase Cloud Messaging (FCM) giúp hệ thống gửi thông báo. iPhone/iPad cần xử lý quyền theo Apple; với Android 13 trở lên, hầu hết thông báo mới cần người dùng cho phép qua quyền POST_NOTIFICATIONS. Người dùng có thể kiểm soát từng nhóm tin. Quyền trên điện thoại không thay thế yêu cầu đồng ý tiếp thị và bảo vệ dữ liệu khi pháp luật áp dụng.
Tham khảo Apple notification permission, Android notification permission, Android notification channels và Firebase Cloud Messaging.
Những loại thông báo nào nên gửi?
| Loại | Ví dụ | Lưu ý |
|---|---|---|
| Giao dịch/lịch | Đơn đã giao, lịch đã xác nhận. | Đúng trạng thái, không trộn quảng cáo. |
| Bảo mật | Phát hiện đăng nhập mới. | Ưu tiên và bảo vệ thông tin riêng. |
| Nhắc công việc | Hoàn tất hồ sơ hoặc lịch đặt dở. | Dừng nếu khách đã làm xong. |
| Ưu đãi/thành viên | Điểm sắp hết hạn, mã giảm giá. | Đúng đối tượng, giới hạn gửi. |
| Nội bộ | Việc cần duyệt hoặc đổi ca. | Đúng vai trò, có người xử lý. |
Không dùng chung tần suất hoặc âm thanh cho tất cả loại tin. Ưu tiên giao dịch và bảo mật, nhưng luôn tránh gửi trùng hoặc nhắc trạng thái đã hết hiệu lực.
Xin quyền khi khách hiểu lợi ích
Ví dụ: sau khi đặt lịch, app mới hỏi “Bạn có muốn được nhắc trước giờ hẹn?”. Khách hiểu rõ lợi ích nên có căn cứ quyết định. Không có quy tắc cố định là phải xin quyền ngay lần mở đầu hoặc sau ba màn hình.
Nếu chưa hiểu lợi ích: giải thích trước. Đã từ chối: không ép bật liên tục; vẫn cho dùng chức năng chính khi có thể. Chỉ muốn một số loại tin: cho điều chỉnh trong app và điện thoại. Không hứa chắc mọi thông báo đều đến ngay.
Apple còn có chế độ nhận thử một số thông báo không gây gián đoạn (provisional); app vẫn phải kiểm tra trạng thái quyền trước khi gửi. Khách có thể thay đổi lựa chọn trong cài đặt điện thoại. Tùy chọn trong app chỉ bổ sung quyền kiểm soát, không thay thế quyền hệ điều hành.
Cho khách chọn loại thông báo muốn nhận
- Phân biệt tin giao dịch, bảo mật, công việc và ưu đãi.
- Nêu rõ nội dung và nhịp gửi dự kiến.
- Cho khách tắt bớt, tạm dừng hoặc đổi sở thích phù hợp; tôn trọng cài đặt điện thoại.
- Ghi nhận lựa chọn và không đổi tên nhóm để né việc khách đã từ chối.
Ai thực sự cần nhận thông báo?
Trước khi gửi, kiểm tra khách có cho phép loại tin này không, việc còn cần làm không, nội dung có đúng người và đúng điều kiện không, đã nhận quá nhiều tin chưa, và có nguy cơ lộ dữ liệu trên màn hình khóa không. Đã đặt lịch xong thì không tiếp tục nhắc đặt lịch.
Không mở app 14 ngày chưa chắc là bỏ dùng: app đặt xe và app bảo hành có nhịp sử dụng khác nhau. Chỉ nhắc khi thật sự có việc hoặc quyền lợi phù hợp.
Quy trình gửi thông báo an toàn gồm những bước nào?
5 bước: (1) nhận sự kiện thật; (2) kiểm tra người, quyền, trạng thái và tần suất; (3) soạn tin rõ và đúng dữ liệu; (4) gửi, theo dõi lỗi, tránh gửi trùng; (5) đo khách có hoàn thành việc không. Nếu đơn đã xử lý hoặc thông báo quá hạn thì hủy gửi.
Không phải sự kiện nào cũng cần gửi ngay: tin không khẩn cấp có thể chờ giờ phù hợp hoặc chuyển sang thông báo trong app.
Khi nào nên nhắc khách quay lại app?
| Tình huống | Thông báo phù hợp | Lúc phải dừng |
|---|---|---|
| Chưa hoàn tất việc đầu tiên | Nhắc hoàn tất hồ sơ đã bắt đầu. | Đã xong, hết hạn hoặc từ chối. |
| Đã đặt lịch/đặt đơn | Cập nhật tình trạng, bước tiếp theo. | Không còn việc cần làm. |
| Dùng theo chu kỳ | Nhắc lịch hoặc quyền lợi cần dùng. | Không còn phù hợp. |
| Gặp sự cố | Cách giải quyết thanh toán/đơn chưa xong. | Đã xử lý hoặc chuyển hỗ trợ. |
| Ít sử dụng/điểm thành viên | Thông báo giá trị mới hoặc điểm sắp hết hạn có thật. | Khách tắt nhắc hoặc hết điều kiện. |
Đối chiếu chiến lược giữ chân khách hàng bằng app và app loyalty. Push chỉ nên kích hoạt value đã tồn tại trong product/service.
Nên dùng thông báo đẩy hay tin trong app, email?
| Kênh | Khi nên dùng |
|---|---|
| Thông báo đẩy | Khách chưa mở app, thông tin ngắn và cần hành động. |
| Tin trong app | Khách đang ở đúng màn hình. |
| Giải thích dài hoặc thông tin cần lưu. | |
| SMS/cuộc gọi | Tình huống quan trọng, khi được phép và phù hợp quy định. |
| Hộp thư trong app | Cần lưu lịch sử, tránh gián đoạn. |
| Không gửi | Không có việc có ích hoặc khách từ chối. |
Firebase In-App Messaging là một lựa chọn để hiển thị message theo ngữ cảnh cho người dùng đang active. Dù dùng công cụ nào, channel decision vẫn cần dựa trên task và permission. Tham khảo Firebase In-App Messaging.
Gửi bao nhiêu thông báo là phù hợp?
- Đặt giới hạn chung cho mọi tin quảng cáo và nhắc quay lại, không chỉ từng chiến dịch.
- Tin giao dịch/bảo mật có mức ưu tiên riêng nhưng vẫn tránh gửi trùng.
- Tránh giờ nghỉ, tính đúng múi giờ của khách.
- Dừng nhắc khi việc đã hoàn tất hoặc trạng thái đổi.
- Nếu nhiều người tắt thông báo hay phàn nàn, giảm tần suất.
Không có mức gửi chung cho mọi app. Hãy dựa vào chu kỳ dùng, sở thích và tỷ lệ khách tắt thông báo.
Nhấn vào thông báo phải đến đúng màn hình
Liên kết mở đúng màn hình (deep link) đưa khách đến lịch, đơn hoặc việc liên quan. Nếu chưa đăng nhập hoặc thông tin hết hạn, cần có cách xử lý thay thế.
Ví dụ: nhấn “Lịch đã xác nhận” sẽ mở đúng lịch. Nếu chưa đăng nhập, hướng dẫn đăng nhập rồi trở lại; nếu lịch đã hủy, báo trạng thái hiện tại. Không được mở dữ liệu của người khác hoặc tạo lại giao dịch khi xử lý lỗi.
Viết thông báo sao cho khách muốn đọc
| Tình huống | Lời nhắn mẫu | Lưu ý |
|---|---|---|
| Đơn hàng | “Đơn của bạn đã sẵn sàng để nhận.” | Trạng thái thật, không lộ thông tin riêng. |
| Lịch hẹn | “Lịch 15:00 ngày mai đã được xác nhận.” | Ngày giờ phải đúng. |
| Bảo mật | “Có đăng nhập mới. Kiểm tra tài khoản.” | Không hiện thông tin nhạy cảm. |
| Ưu đãi | “Bạn có ưu đãi cho đơn đủ điều kiện hôm nay.” | Ưu đãi thật, không thúc ép giả. |
Không hiển thị thông tin sức khỏe, tài chính hoặc dữ liệu nhạy cảm trên màn hình khóa. Dùng cách viết rõ, ngắn, phù hợp ngữ cảnh; xem hướng dẫn viết nội dung trong app.
Làm sao biết thông báo thực sự có tác dụng?
Khách nhận tin có thể vốn đã định quay lại. Vì vậy lượt mở và đơn sau khi gửi không chứng minh toàn bộ kết quả do thông báo tạo ra. Khi có đủ khách, hãy so nhóm đủ điều kiện nhận tin với một nhóm tương tự không nhận để đo tác động tăng thêm.
Ví dụ giả định: chia ngẫu nhiên khách có lịch đặt dở thành hai nhóm phù hợp. Nhóm A nhận một lời nhắc, nhóm B không nhận, các kênh khác giữ nguyên. So tỷ lệ hoàn tất lịch và cả việc gửi trùng, tắt thông báo, phàn nàn. Không thử với người đã đặt xong hoặc không đủ quyền nhận.
Thử hai lời nhắn chỉ cho biết cách viết nào tốt hơn trong nhóm có nhận. Muốn biết có nên gửi không, cần so với nhóm không nhận phù hợp.
Những chỉ số nào cho thấy thông báo có ích?
| Cần xem | Giúp trả lời |
|---|---|
| Quyền nhận và người phù hợp | Có gửi đúng người được phép? |
| Lỗi gửi, tin được nhận nếu có dữ liệu | Có trục trặc kỹ thuật? |
| Mở tin và đến đúng màn hình | Khách có xem được thông tin cần thiết? |
| Đặt lịch, đơn hoàn tất, quay lại | Khách có thực hiện việc có giá trị? |
| Tắt tin, phàn nàn, gỡ app | Thông báo có đang gây phiền? |
Theo Firebase, “đã gửi” có thể chỉ là đã xếp hàng hoặc chuyển sang dịch vụ khác. Việc nhận, hiển thị và mở tin có phạm vi đo khác nhau giữa Android/iOS; số liệu cũng có thể đến muộn.
Đội kỹ thuật cần chuẩn bị gì?
- Gắn đúng thiết bị với người dùng, cập nhật và loại mã nhận tin đã hết hiệu lực.
- Kiểm tra quyền và từng nhóm thông báo Android.
- Tránh gửi tin trùng, tin quá hạn; có cách dừng chiến dịch sai.
- Thử app đang mở/đóng, chưa đăng nhập, mất mạng và đổi thiết bị.
- Theo dõi lỗi từ máy chủ, dịch vụ gửi đến màn hình khách mở sau khi nhấn.
Firebase hỗ trợ mã cũ và mã thiết bị FID trong giai đoạn chuyển đổi. Đội kỹ thuật cần cập nhật và loại mã đã lỗi theo hướng dẫn FCM. Thiết bị không hoạt động một tháng chưa chắc là khách đã bỏ app.
Checklist trước khi gửi thông báo
- Biết rõ mục đích, nguồn dữ liệu và người phụ trách thông báo.
- Kiểm tra quyền và khách đủ điều kiện, tôn trọng việc từ chối.
- Có tần suất, giờ nghỉ và điều kiện ngừng gửi.
- Tin không lộ dữ liệu riêng tư, nhấn mở đúng màn hình.
- Đã thử khi mạng lỗi, tin cũ, gửi trùng và trên nhóm nhỏ.
- Có người xử lý lỗi, đo kết quả và công tắc dừng chiến dịch.
6 sai lầm khiến khách tắt thông báo
- Xin quyền khi khách chưa hiểu lợi ích.
- Gửi một tin cho mọi người bất kể nhu cầu.
- Không giới hạn tổng số tin từ nhiều bộ phận.
- Nhắc việc đã hoàn thành hoặc đưa về sai màn hình.
- Lộ thông tin riêng tư trên màn hình khóa.
- Chỉ đo lượt mở mà bỏ qua khách tắt tin, phàn nàn hoặc gỡ app.
Với chiến dịch mùa vụ, đối chiếu push notification và in-app event mùa lễ hội. Với dữ liệu và consent/preference, xem first-party data.
App có lượt tải nhưng người dùng không quay lại?
WebsiteHCM có thể hỗ trợ rà cách xin quyền, nhóm khách, nội dung, kết nối Firebase/CRM và báo cáo hiệu quả. Doanh nghiệp nên chuẩn bị mục tiêu, nhóm khách đang dùng app, các thông báo hiện gửi và số liệu sẵn có trước khi tư vấn.
Câu hỏi thường gặp
Push notification có thực sự tăng retention không?
Có thể, nếu tin giúp khách hoàn thành việc có ích. Để đánh giá tác động, nên so nhóm nhận và không nhận khi đủ dữ liệu.
Nên gửi push bao nhiêu lần mỗi tuần?
Không có mức chung. Tin giao dịch theo sự kiện, còn lời nhắc và ưu đãi phải giới hạn theo nhu cầu và lựa chọn của khách.
Push khác in-app message thế nào?
Push có thể hiện khi app đóng và cần quyền; thông báo trong app chỉ hiện khi khách đang sử dụng.
Có nên gửi cho người lâu không mở app?
Chỉ gửi khi có việc hoặc quyền lợi còn giá trị, dừng nhắc khi khách không muốn nhận.
KPI quan trọng nhất là gì?
Nên đo việc hoàn tất như đặt lịch hoặc đơn hàng, cùng số khách tắt tin, phàn nàn và lỗi gửi.
Đội kỹ thuật cần tham gia phần nào?
Đội kỹ thuật quản lý quyền, mã thiết bị, gửi trùng, liên kết mở đúng màn hình, báo cáo và cách dừng chiến dịch lỗi.
Kết luận
Thông báo đẩy chỉ có ích khi đúng người, đúng việc, đúng lúc và có quyền gửi. Bắt đầu bằng một tình huống thiết thực như nhắc lịch đã đặt, kiểm tra việc khách hoàn thành và giảm/tắt tin gây phiền; đừng gửi nhiều chỉ để tăng lượt mở.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.