Thông báo push người dùng không tắt: thời điểm và thiết kế

Tại sao người ta tắt thông báo push

Thông báo gây phiền giống như có ai đó chạm vào vai bạn suốt ngày, rồi tỏ vẻ ngạc nhiên khi bạn rời đi. Chúng ngắt quãng, đòi hỏi sự chú ý và thường không mang lại gì cho người dùng. Sau vài ngày như vậy, người ta làm điều đơn giản nhất: im lặng bạn.

Phần lớn việc từ chối xảy ra vì lý do rõ ràng. Tin nhắn đến quá thường xuyên, không liên quan hoặc xuất hiện vào thời điểm không phù hợp (đêm khuya, giờ làm, hoặc ngay sau khi người dùng vừa làm xong việc). Đôi khi nội dung mơ hồ hoặc giật tít, khiến người dùng mất lòng tin. Và nếu thông báo đầu tiên tới trước khi người dùng hiểu giá trị của ứng dụng, nó giống như: "Bạn hầu như không biết tôi, nhưng bạn muốn truy cập màn hình khoá của tôi."

Tắt push cũng là cách giảm nhiễu tinh thần. Nhiều người đã mệt mỏi vì email, mạng xã hội và nhóm chat. Nếu ứng dụng của bạn thêm những tiếng chập cheng ngẫu nhiên, nó bị xếp chung với đống còn lại và bị cắt. Trên di động, quyết định này thường là quyết liệt: một khi tắt, nhiều người hiếm khi mở lại.

Mục tiêu thực sự không phải giành quyền lần một. Mà là giữ quyền trong nhiều tháng vì mỗi tin nhắn đều xứng đáng.

Một thông báo hay dễ mô tả: nó là điều người dùng mong đợi, hữu ích và đúng thời điểm. Mong đợi nghĩa là người dùng có thể đoán vì sao họ nhận nó. Hữu ích nghĩa là nó giúp họ làm điều họ quan tâm. Đúng thời điểm nghĩa là nó tới khi có thể giúp, không chỉ khi hệ thống của bạn sẵn sàng.

Các mẫu dễ gây opt-out có thể đoán trước: hỏi quyền ngay lần đầu mở mà không có lý do rõ ràng, gửi "Chúng tôi nhớ bạn" mà không có giá trị cá nhân, lặp lại cùng một lời nhắc sau khi người dùng đã phớt lờ hai lần, dùng từ gấp rút cho cập nhật thường xuyên, và trộn tin marketing vào cùng kênh với cảnh báo quan trọng.

Nếu bạn coi push như đặc quyền, người dùng coi đó như lợi ích. Nếu bạn coi nó như chỗ quảng cáo miễn phí, người dùng coi nó là spam.

Điều gì khiến ai đó sẵn sàng đồng ý

Người ta bấm "Allow" khi họ tin thông báo sẽ giúp họ, chứ không phải chỉ giúp ứng dụng. Cách dễ nhất để có thông báo mà người dùng không tắt là coi quyền như trao đổi giá trị: bạn hứa điều cụ thể, rồi thực hiện đều đặn.

Trước khi hỏi quyền, hãy nói lời hứa bằng ngôn ngữ đơn giản. Tránh những câu mơ hồ như "Cập nhật thông tin." Thay vào đó, giải thích sẽ gửi gì, tại sao quan trọng và người dùng có thể điều khiển thế nào. Một màn hình pre-permission tốt trả lời ba việc: bạn sẽ gửi gì (trạng thái đơn hàng, nhắc nhở, giảm giá, cảnh báo bảo mật), tần suất thế nào (và "hiếm" nghĩa là gì), và họ thay đổi thế nào sau này (tùy chọn, tắt tiếng, giờ im lặng).

Tỉ lệ opt-in tăng khi thông báo phù hợp với mục tiêu thực tế mà người dùng đã có. Nghĩ theo những gì họ muốn đạt được, chứ không phải những gì bạn muốn quảng bá.

Mọi người dễ chấp nhận thông báo khi nó có giá trị cụ thể: tiết kiệm ("Giảm giá"), nhắc nhở ("Lịch hẹn của bạn còn 2 giờ"), cập nhật ("Đơn giao của bạn cách 10 phút"), an toàn ("Đăng nhập mới"), hoặc tiến trình ("Bạn đạt mục tiêu tuần này").

Thiết lập kỳ vọng sớm, dù trông kém "bán hàng" hơn. Nếu bạn gửi năm tin mỗi tuần, hãy nói vậy. Nếu chỉ gửi khi có kích hoạt (như cập nhật vận chuyển), hãy nói rõ. Bất ngờ tạo ra mất lòng tin, và mất lòng tin dẫn đến tắt thông báo.

Cho thấy một mẫu nhỏ về giá trị trước khi hộp thoại hệ thống xuất hiện. Một ví dụ thực tế có thể hiệu quả hơn một đoạn copy dài:

"Mẫu thông báo: Gói hàng của bạn đang được giao - đến trong khoảng 15:10 đến 15:40."

Một dòng như vậy giúp người dùng hình dung khoảnh khắc thông báo tiết kiệm thời gian cho họ, và báo hiệu bạn không định spam họ.

Thời điểm hỏi quyền cảm thấy tự nhiên

Hầu hết người ta không ghét thông báo. Họ ghét bị hỏi quá sớm, trước khi hiểu họ sẽ nhận gì. Thời điểm hỏi quyền thường quyết định giữa thông báo mà người ta không tắt và thông báo họ tắt mãi mãi.

Một quy tắc đơn giản: hỏi ngay sau khi người dùng làm điều gì đó chứng tỏ họ quan tâm. Khi ai đó lưu mục, theo dõi chủ đề, đặt lịch, hoặc hoàn thành buổi tập, họ đã cho bạn biết điều gì quan trọng với họ. Đó là lúc đề nghị nhận cập nhật liên quan.

Một mẫu đáng tin cậy là màn hình hỏi mềm trước hộp thoại hệ thống. Giữ ngắn và cụ thể: họ sẽ nhận gì, tần suất và vì sao nó hữu ích. Rồi thêm hai nút rõ ràng: "Cho phép thông báo" và "Không ngay". Chỉ hiện hộp thoại hệ thống nếu họ chọn "Cho phép." Điều đó loại bỏ bất ngờ và thiết lập kỳ vọng.

Những khoảnh khắc tốt để hỏi thường là ngay sau một chiến thắng (đặt hàng xong, hoàn thành mục tiêu), ngay sau khi họ theo dõi/đăng ký, vừa lưu hoặc đánh dấu, vừa đặt nhắc hoặc bắt đầu theo dõi, hoặc ngay sau khi bật tính năng cần cập nhật.

Khoảnh khắc xấu là khi người dùng bận, lo lắng hoặc hoài nghi. Hỏi ngay lần đầu mở là sai lầm phổ biến vì chưa có niềm tin. Hỏi trong lúc đăng ký cũng rủi ro vì họ đang điền form, mật khẩu và xác thực.

Nếu họ từ chối, đừng trừng phạt họ và đừng liên tục hiện hộp thoại. Hồi phục khéo léo. Xác nhận họ vẫn dùng app bình thường, và đưa tuỳ chọn yên tĩnh sau đó trong cài đặt gần tính năng ảnh hưởng. Ví dụ: "Nhận thông báo khi mục lưu của bạn thay đổi" với một toggle, để lựa chọn gắn với lợi ích thực.

Ví dụ cụ thể: một app mua bán đồ second-hand cho phép người dùng lưu tìm kiếm "giày size 38." Ngay sau khi họ bấm "Lưu tìm kiếm", một màn hình nói: "Muốn nhận cảnh báo khi có kết quả mới? Chúng tôi sẽ gửi tối đa 1 lần/ngày." Yêu cầu đó có tính hợp lý vì gắn với điều người dùng vừa yêu cầu.

Thiết kế trung tâm tùy chọn thông báo

Một trung tâm tùy chọn tốt là van an toàn của bạn. Nó giữ người dùng khỏi việc tắt thông báo ở cấp hệ thống vì họ có thể tăng/giảm mà không cảm thấy bị mắc kẹt.

Bắt đầu với ba điều khiển dễ hiểu: chủ đề, tần suất và giờ im lặng. Chủ đề cho phép họ chọn những gì họ thực sự quan tâm. Tần suất trả lời câu hỏi thực sự đằng sau nhiều opt-out: "Tại sao bạn nhắn cho tôi nhiều vậy?" Giờ im lặng ngăn con đường nhanh nhất dẫn tới bị tắt: một tiếng rung vào thời điểm sai.

Các điều khiển nên có (và cách đặt nhãn)

Giữ lựa chọn ít và rõ ràng. Nếu bạn đưa 20 công tắc, người ta sẽ không quản lý chúng, họ sẽ tắt hết.

Hướng đến một bộ ngắn như: danh mục chủ đề (đơn hàng, nhắc nhở, bảo mật, cập nhật sản phẩm — dùng từ người dùng hay dùng), tùy chọn tần suất (ngay lập tức, tóm tắt hàng ngày, tóm tắt hàng tuần), giờ im lặng (khung giờ theo thời gian thiết bị), lựa chọn kênh (push vs email vs thông báo trong app), và tuỳ chọn tạm dừng (ngủ 24 giờ hoặc 7 ngày).

Mặc định quan trọng. Đặt chúng hữu ích nhưng không quá hung hăng. Mặc định an toàn nhiều nơi là: cảnh báo thiết yếu bật (bảo mật hoặc trạng thái giao dịch), cập nhật kiểu marketing tắt, và tần suất đặt ở dạng digest khi hợp lý. Nếu mọi thứ mặc định bật, bạn tạo mệt mỏi thông báo ngay từ ngày đầu.

Nơi nên đặt nó

Đừng giấu tùy chọn chỉ trong menu cài đặt sâu. Đặt nơi người dùng tự nhiên tìm khi họ quan tâm.

Sau các hành động chính, hiển thị một lời nhắc nhỏ như: "Muốn nhận cập nhật về chuyện này?" và dẫn họ thẳng tới lựa chọn chủ đề và tần suất. Sau khi đặt hàng, ví dụ, cho họ bật "Trạng thái đơn hàng" push trong khi giữ "Khuyến mãi" tắt.

Cũng làm cho nó dễ tìm trong Tài khoản/Cài đặt, và bất cứ nơi nào thông báo xuất hiện (ví dụ, "Quản lý thông báo" gần hộp thư trong app). Nếu ai đó cảm thấy khó chịu, họ nên tìm thấy tùy chọn "tạm dừng" hoặc "ít hơn" trong dưới 10 giây, thay vì phải truy vào cài đặt hệ thống.

Nếu bạn xây sản phẩm với Koder.ai, hãy coi trung tâm tùy chọn là tính năng hàng đầu chứ không phải phần phụ. Giữ người dùng là rẻ hơn nhiều so với cố gắng lấy lại họ.

Thiết kế nội dung tin nhắn khiến người dùng tin tưởng

Người ta giữ thông báo bật khi tin nhắn giống cái vỗ vai hữu ích, không phải chiêu thu hút chú ý. Những thông báo tốt nhất mà người ta không tắt đều rõ lý do đến và hành động tiếp theo là gì.

Viết như người thật. Dùng từ ngắn, đơn giản, và đặt chi tiết quan trọng lên trước. "Báo cáo của bạn đã sẵn sàng" tốt hơn "Có cập nhật mới." Cụ thể thắng khéo léo.

Giữ mỗi tin một mục đích. Nếu một thông báo cố làm hai việc (tin tức + khuyến mãi + nhắc nhở), nó giống quảng cáo và khiến người dùng phớt lờ. Nếu bạn có nhiều thứ để nói, gửi ít thông báo hơn và để app xử lý phần còn lại.

Cá nhân hóa phải được kiếm lấy. Dựa trên điều người dùng thực sự làm, không phải điều bạn đoán.

Ví dụ: nếu ai đó xuất mã nguồn hôm qua, "Xuất hoàn tất. ZIP của bạn đã sẵn sàng" hợp lý. Nếu bạn gửi "Hôm nay xây app di động chứ?" cho người chưa bao giờ hỏi về di động, nó sẽ cảm thấy ngẫu nhiên và kỳ quặc.

Gấp rút thì ổn. Tạo áp lực thì không. Cấp bách thực sự giải thích hậu quả mà không khoa trương:

• Tốt: "Thanh toán thất bại. Cập nhật thẻ để tránh mất quyền truy cập vào ngày mai."
• Tệ: "Cơ hội cuối! Hành động ngay!"

Thời điểm quan trọng hơn nhiều người nghĩ. Tin hữu ích vào giờ sai trở nên phiền phức. Tôn trọng giờ địa phương và tránh giờ ngủ thông thường. Với sản phẩm công việc, cố gắng ở trong giờ làm việc trừ khi thực sự khẩn cấp.

Mẫu đơn giản hoạt động

Một cấu trúc nhất quán giúp người dùng học cách tin tường phong cách của bạn:

• Chuyện gì đã xảy ra (1 câu ngắn)
• Tại sao nó quan trọng (tuỳ chọn, 1 cụm ngắn)
• Cần làm gì (một hành động rõ ràng)

Ví dụ cho sản phẩm như Koder.ai: "Deployment failed. Check logs to retry." Thẳng thắn, phù hợp hành động người dùng đã làm và không giả vờ khẩn cấp.

Khi thông báo cụ thể, được mong đợi và đúng thời điểm, người dùng thấy chúng là một phần của sản phẩm, không phải là tiếng ồn.

Từng bước: lập kế hoạch hệ thống thông báo của bạn

Nếu muốn thông báo push mà người dùng không tắt, lập kế hoạch quan trọng như copy. Một kế hoạch nhỏ ngăn bạn gửi "cái gì đó hữu ích" một cách bừa bãi và vô tình tạo mệt mỏi.

1) Lập danh mục thông báo

Liệt kê mọi tin push bạn có thể gửi, bao gồm cả những thứ hiển nhiên (cập nhật đơn hàng, nhắc nhở) và những thứ "có thể sau" (digest, khuyến mãi). Đặt tên tạm cho mỗi tin để dễ thảo luận.

Với mỗi thông báo, ghi: nó dành cho mục đích gì, giúp ai, và người dùng nên làm gì sau khi thấy nó. Nếu bạn không trả lời được trong một câu, đó là dấu hiệu nên cân nhắc không gửi.

2) Nhóm tin theo mục đích

Nhóm kho danh sách thành vài nhóm dễ hiểu. Với nhiều app, các nhóm này đủ bao phủ: nhắc nhở (điều người dùng yêu cầu), cập nhật (thay đổi trạng thái họ đang chờ), khuyến mãi (bán hàng, upsell, marketing), an toàn/tài khoản (cảnh báo bảo mật, thay đổi chính sách), và mẹo/giáo dục (chỉ nếu người dùng thực sự muốn).

Những nhóm này là xương sống cho UX trung tâm tùy chọn. Người dùng không muốn 25 công tắc. Họ muốn 3–6 lựa chọn rõ ràng.

3) Quyết định kích hoạt và giới hạn

Với mỗi tin, định nghĩa điều kiện kích hoạt và giới hạn. Kích hoạt trả lời "khi nào nó liên quan?" Giới hạn trả lời "làm sao tránh spam?"

Một bộ thực tế: tối đa mỗi ngày, tối đa mỗi tuần, và khung giờ im lặng (ví dụ, không gửi ban đêm theo giờ địa phương). Cũng quyết định chuyện gì xảy ra khi nhiều thông báo cạnh tranh: tin nào được ưu tiên, tin nào bị bỏ.

4) Soạn mẫu và đặt tên như sản phẩm

Tạo một mẫu ngắn cho mỗi thông báo: tiêu đề, nội dung, và hành động khi chạm. Đặt tên theo cách người dùng mô tả, không theo mã nội bộ. "Cập nhật giao hàng" tốt hơn "SHIP_STATUS_CHANGED_V2."

Kỷ luật đặt tên đó có lợi khi xây opt-in và cài đặt, và khi bộ phận hỗ trợ cần giải thích người dùng đã nhận gì.

5) QA với kịch bản thực

Kiểm thử kế hoạch với hành trình thực, không phải từng tin đơn lẻ. Đi qua một người dùng mới (ít niềm tin), người dùng trở lại (muốn ít bất ngờ hơn), và người dùng quyền (volume cao, cần điều khiển). Bao gồm trường hợp người dùng tắt khuyến mãi nhưng giữ cảnh báo an toàn, và trường hợp người dùng không hoạt động 30 ngày.

Nếu bất kỳ kịch bản nào tạo ra một loạt thông báo, thời điểm lộn xộn, hoặc những tin giả định quá nhiều, sửa kích hoạt hoặc thắt chặt giới hạn trước khi hỏi quyền.

Những sai lầm phổ biến khiến người dùng tắt

Hầu hết người ta không ghét thông báo. Họ ghét bất ngờ, lộn xộn và những tin có vẻ gửi cho công ty chứ không phải cho họ. Cách nhanh nhất để mất lòng tin là coi opt-in như thắng lợi một lần thay vì mối quan hệ liên tục.

Sai lầm phổ biến là hỏi quyền ngay khi app mở, trước khi người dùng làm gì cả. Không có ngữ cảnh, yêu cầu cảm thấy ngẫu nhiên, nên người dùng hoặc từ chối hoặc chấp nhận rồi hối hận. Quy tắc tốt hơn: kiếm lấy "đồng ý" đầu tiên bằng lợi ích rõ ràng ngay lúc nó quan trọng.

Kẻ giết niềm tin khác là volume. Nhiều nhóm gửi một loạt tin ngay sau khi ai đó opt-in để "kích hoạt" họ. Điều đó thường tạo mệt mỏi thông báo, và hành động tiếp theo của người dùng là tắt hết. Nếu bạn phải gửi tin sớm, giữ ít, cụ thể và gắn với hành động họ đã làm.

Copy mơ hồ cũng khiến người dùng tắt. Tin như "Xem thử" hoặc "Đừng bỏ lỡ" buộc người dùng mở app mới biết họ bị làm phiền vì gì. Nếu giá trị thật sự, hãy nói thẳng.

Lỗi thời điểm cũng nguy hiểm. Nếu bỏ qua múi giờ, bạn có thể làm phiền người khác giữa họp, ăn tối hoặc giờ ngủ. Chỉ một thông báo 3 giờ sáng có thể khiến người dùng tắt hết.

Cuối cùng, làm cho tùy chọn dễ. Nếu chỉ có "tất cả" hoặc "không gì cả", thì "không gì cả" thắng. Người dùng cần cách tạm dừng mà không phải mò trong cài đặt.

Những mẫu dẫn đến opt-out thường lặp lại: hộp thoại xuất hiện quá sớm, quá nhiều thông báo trong 24–72 giờ đầu, nội dung mập mờ, gửi vào giờ địa phương không phù hợp, và không có công cụ đơn giản (tạm dừng, giờ im lặng, lựa chọn chủ đề).

Ví dụ: một app mua sắm gửi "Tin lớn!" lúc 7 sáng địa phương trong ba ngày liên tiếp, không có cách tắt khuyến mãi trong khi giữ cập nhật đơn hàng. Người dùng tắt thông báo hoàn toàn, kể cả những tin hữu ích.

Kiểm tra nhanh trước khi gửi

Trước khi nhấn gửi, dừng 30 giây. Hầu hết opt-out xảy ra sau một tin cảm thấy bất ngờ, mơ hồ hoặc quá thường xuyên.

Bài kiểm 5 giây về độ phù hợp

Hỏi một câu: người dùng có đang mong đợi tin này ngay bây giờ không?

Một cập nhật giao hàng khi đơn được gửi thì hợp lý. Một khuyến mãi sáng hôm sau khi họ vừa mua món đó thì không. Dùng danh sách kiểm nhanh:

• Tin này có khớp với điều người dùng vừa làm (hoặc rõ ràng họ quan tâm)?
• Họ có hiểu ngay từ dòng đầu mà không phải mở không?
• Nó đến vào giờ hợp lý theo múi giờ địa phương tránh giờ im lặng?
• Có giới hạn tần suất cho loại tin này không?
• Nếu họ không thích, họ có thể tắt hạng mục này trong cài đặt không?

Rồi đọc tin như một người lạ. Nếu giá trị không rõ ngay lập tức, viết lại dòng đầu. Nếu cần quá nhiều ngữ cảnh, có lẽ nó không nên là push.

Kiểm tra thời điểm và điều khiển để tránh mệt mỏi

Hai thứ âm thầm dẫn đến mệt mỏi: thời điểm tệ và không có lối thoát. Giờ địa phương quan trọng hơn bạn nghĩ. Gửi 9 giờ sáng với bạn có thể là 2 giờ sáng với họ; một cú đánh thức có thể khiến bạn mất kênh.

Giới hạn tần suất là rào chắn khác. Quyết định trần cho mỗi danh mục (ví dụ, không quá 2 khuyến mãi/tuần), rồi giữ kỷ luật dù marketing phấn khích. Lúc bạn phá quy tắc, người dùng nghĩ nó sẽ tiếp tục.

Cuối cùng, xác nhận trung tâm tùy chọn có danh mục đó chính xác. Kiểm tra nhanh: nếu người dùng than phiền, bộ phận hỗ trợ có thể chỉ họ đổi chỗ nào trong dưới 10 giây không? Nếu không, bạn đang gửi thông báo mà mình chưa sẵn sàng bảo vệ.

Ví dụ: nếu ai đó xem vé máy bay, một cảnh báo giảm giá một lần là hữu ích. Ba cảnh báo trong một ngày, không có cách tắt "giảm giá", trông như spam dù ưu đãi thật.

Ví dụ thực tế: kiếm opt-in mà không làm phiền

Tưởng tượng một app lập kế hoạch bữa ăn. Nó muốn opt-in push, nhưng biết rằng ấn tượng đầu tệ dẫn đến tắt nhanh.

Trong phiên đầu, app giúp người dùng trước. Nó cho họ tìm công thức, lưu yêu thích và xây kế hoạch tuần. Không có hộp thoại xin quyền. Thay vào đó, một dòng nhỏ: "Bạn có thể nhận nhắc sau nếu muốn." Người dùng tập trung vào nhiệm vụ, không bị hộp thoại hệ thống làm gián đoạn.

Khoảnh khắc app giành quyền hỏi là gắn với hành động rõ ràng. Sau khi người dùng lưu 3 công thức, app hiện nhẹ (không phải hộp thoại OS): "Muốn nhắc khi đến giờ nấu? Chọn thứ bạn muốn." Nếu họ bấm "Có", app mới gọi yêu cầu quyền. Nếu bấm "Không ngay", app rút lui và tiếp tục hoạt động bình thường.

Màn hình tiếp theo là trung tâm tùy chọn đơn giản với ngôn ngữ dễ hiểu và mặc định hợp lý. Nó đưa vài lựa chọn: nhắc bữa ăn (tối đa 1/ngày vào ngày có kế hoạch), công thức mới (tóm tắt hàng tuần), và ưu đãi (chỉ khi người dùng muốn). Mặc định khuyến mãi tắt.

Một tuần sau, kết quả khác hẳn so với cách "hỏi khi mở" thông thường. Ít người opt-in tổng thể hơn, nhưng những người đồng ý thì hài lòng hơn. Số lần gửi thấp hơn vì app chỉ nhắc những người đã yêu cầu loại tin đó, theo tần suất họ chọn. Kết quả là ít lần tắt và ít lúc người dùng bấm "tắt hết".

Đó là cách bạn có thông báo push người ta không tắt: nối việc hỏi quyền với một lợi ích người dùng vừa có và đảm bảo mỗi tin giống thứ họ yêu cầu.

Đo lường, cải thiện và quyết định bước tiếp theo

Xem thông báo như một tính năng sản phẩm: đo, thay đổi một thứ, rồi học nhanh.

Bắt đầu theo dõi kết quả cho biết bạn đang kiếm được niềm tin hay đốt nó. Đừng chỉ dừng ở opens. Bạn cần cả mặt chi phí:

• Tỉ lệ opt-in (theo màn hình, khoảnh khắc, và phân khúc người dùng)
• Tỉ lệ tắt (sau thông báo cụ thể và theo thời gian)
• Tỉ lệ mở (và hành động tiếp theo, không chỉ lượt chạm)
• Tín hiệu churn (gỡ cài đặt, ít phiên, hủy email)
• Sửa đổi tùy chọn (ai tắt danh mục so với tắt hết)

Tiếp theo, rà soát những cái gây hại nhất. Tìm mẫu: danh mục nào, khung giờ nào, hay mẫu thông điệp nào thường dẫn đến tắt. Gắn nhãn mỗi thông báo theo lý do đơn giản (cập nhật đơn hàng, nhắc, promo) để bạn trả lời: "Tin nào gây nhiều opt-out nhất trên 1.000 lượt gửi?" Sửa những cái đó trước.

Thực hiện các thử nghiệm nhỏ thay vì đại tu lớn. Thay một biến tại một thời điểm: hỏi muộn hơn (sau khoảnh khắc thành công), viết lại copy để nêu lợi ích cụ thể, giới hạn tần suất theo danh mục, tách rõ phải biết và nên biết, và bắt đầu với ít danh mục bật.

Giữ tùy chọn dễ tìm và chỉnh nhanh. Nếu người dùng có thể tắt một loại thông báo trong 2 thao tác hoặc ít hơn, họ ít có khả năng tắt hết. Quy tắc hữu ích: bất kỳ thông báo nào đều có thể chỉnh từ trung tâm tùy chọn trong 2 thao tác.

Nếu muốn đi nhanh, xây và lặp trên luồng xin quyền và trung tâm tùy chọn trong Koder.ai (Koder.ai) có thể giúp bạn phát hành thay đổi nhanh, rồi xuất source khi sẵn sàng triển khai sâu hơn.