PUSH NOTIFICATION: TỐI ƯU HOÁ THỜI ĐIỂM GỬI - THẤU HIỂU TÂM LÝ NGƯỜI DÙNG

MỘT BÀI VIẾT HAY VỀ PUSH NOTIFICATION MÀ MỌI LẬP TRÌNH VIÊN ỨNG DỤNG DI ĐỘNG NÊN ĐỌC!

Bạn từng bỏ lỡ thông báo hoặc bực bội vì những thông báo được gửi tới không đúng lúc?

Ở vị trí một lập trình viên ứng dụng di động, đã bao giờ bạn tự đặt câu hỏi "mình nên thiết kế chức năng thông báo như thế nào để mọi người dùng đều muốn mở ra đọc?"

Chúng ta bắt gặp rất nhiều lời khuyên về việc tối ưu tính năng Push Notification từ mạng internet. Tuy nhiên, có một yếu tố vô cùng quan trọng khác nhưng dường như thường bị bỏ qua. Đó chính là Thời điểm gửi thông báo!

Xin giới thiệu đến các bạn một bài viết thú vị từ Tech blog của Yahoo! JAPAN về khái niệm Thời điểm gửi thông báo hiệu quả!

Hãy cùng TBV tìm hiểu cách Yahoo! JAPAN sử dụng Machine Learning để tối ưu hoá tính năng Push Notification cho các ứng dụng nổi tiếng của mình. Biết đâu từ đó, chúng ta lại tìm được những ý tưởng hay cho ứng dụng mà mình đang phát triển?

https://techblog.yahoo.co.jp/entry/20200518830116/



Tôi là Kota Tsubouchi thuộc bộ phận nghiên cứu của Yahoo! JAPAN. Hôm nay, câu chuyện của tôi là về Thông báo (Notification).

Bạn từng bỏ lỡ thông báo hoặc bực bội vì những thông báo được gửi tới không đúng lúc? Ở bài viết này, tôi sẽ giới thiệu đến các bạn kết quả nghiên cứu về thời điểm thích hợp để gửi thông báo.

Các quảng cáo và thông tin gợi ý của Yahoo! JAPAN mà các bạn vẫn thấy đều được cá nhân hoá. Tức là từ lịch sử hành vi của người dùng, chúng tôi suy đoán sở thích của họ để từ đó gợi ý các bản tin hoặc các sản phẩm liên quan. Chức năng push notification cũng hoạt động với cơ chế tương tự. Push notification có giới hạn về số lượng ký tự hiển thị và số lượng thông báo có thể gửi. Từ sở thích người dùng, các thông báo phù hợp sẽ được gửi đến họ, tương tự như tính năng quảng cáo hay tính năng gợi ý trước giờ. Tuy nhiên, vẫn còn một yếu tố nữa giúp chúng ta tối ưu push notification, đó chính là "thời điểm".

Ví dụ, khi phân tích kỹ lưỡng Yahoo log của người dùng và nhận thấy người đó đang tìm kiếm sản phẩm giày chạy bộ, vậy là đã đủ để gửi thông báo?



(Hình 1: Air notification và KY notification)

"Thông báo vô nghĩa" hay "thông báo vô duyên" là cách tôi vẫn gọi các thông báo gửi đến sai thời điểm. Thông báo vô nghĩa là những thông báo gửi đến khi điện thoại đang ở trên bàn, trong cặp hoặc trong túi quần áo, người dùng không hề nhận ra vì nó rung rất nhẹ. Thông báo vô duyên là những thông báo gây cản trở khi người dùng đang tập trung cao độ vào điện thoại, khiến họ cảm thấy phiền phức (ví dụ khi người dùng đang chơi bắn súng thì thông báo xuất hiện trên màn hình khiến họ mất tập trung và cảm thấy bực mình).

Hãy thử liên kết với những trải nghiệm của bản thân, bạn sẽ dễ dàng nhận ra rằng khi gửi thông báo, ngoài nội dung thì thời điểm cũng là một yếu tố quan trọng cần tối ưu.

Vì lý do đó, nghiên cứu lần này của tôi đã tập trung vào "tối ưu hóa thời điểm". Sau quá trình nghiên cứu, tôi đã trình bày trình bày hai nội dung tại các hội nghị quốc tế. Nội dung thứ nhất là về hiệu quả kiểm chứng được khi kiểm soát thời điểm gửi thông báo, nội dung thứ hai là về cách triển khai và các đề xuất. 

Do không thể cung cấp toàn bộ chi tiết trong bài viết này nên nếu quan tâm, xin vui lòng đọc thêm từ đường dẫn bên dưới. Nội dung được viết bằng tiếng Anh, rất mong các bạn thông cảm!

1）Attention and Engagement-Awareness in the Wild: A Large-Scale Study with Adaptive Notifications（Percom2017）

2）Real-World Product Deployment of Adaptive Push Notification Scheduling on Smartphones（KDD2019）

Kiểm soát thời điểm thông báo như thế nào?

Phần này sẽ giải thích kiến ​​trúc cơ bản để tối ưu hóa thời điểm thông báo.

Khi bắt đầu nghiên cứu này, tôi đã tiến hành điều tra và nghiền ngẫm dựa trên nỗi trăn trở "mình nên làm gì để thay đổi thời điểm gửi thông báo". Tôi sẽ không trình bày các phương án thay thế hay quá trình nghiên cứu cụ thể mà đi ngay đến kết luận, rằng tôi đã hiện thực hoá được ý tưởng kiểm soát thời gian thông báo với cơ chế trình bày ở Hình 2!



（Hình 2: thông báo bình thường và thông báo được kiểm soát thời gian gửi)

Thông báo bình thường sẽ được push (đẩy) ngay thời điểm điện thoại nhận được tín hiệu. Ví dụ như cơ chế gọi module push khi bạn nhận thông báo bản tin từ Yahoo! News vậy.

Nếu kiểm soát thời gian gửi thì cơ chế hoạt động sẽ khác. Khi bản tin thuộc thông báo đó được gửi đến, ứng dụng sẽ bật nhiều loại cảm biến trên điện thoại để quan sát sự thay đổi trạng thái. Điện thoại sẽ xử lý các thông tin có được từ cảm biến hay nhật ký hoạt động (activity log) và chờ đợi thời điểm thích hợp để gửi thông báo. Lúc này, điện thoại liên tục tính toán Timing Score (điểm số giúp xác định thời điểm thích hợp để gửi tin nhắn - tôi sẽ giải thích ở bên dưới). Khi Timing score vượt qua một ngưỡng nhất định, đó cũng chính là thời điểm thích hợp để gửi thông báo. Thế là lần đầu tiên, module push được gọi!

Tính toán Timing Score bằng Machine Learning

Chìa khoá của cơ chế này nằm ở chỗ tính toán Timing Score. Timing Score được tính bằng một mô hình được "train" bởi Machine Learning, gọi là Mô hình Phân biệt (Discriminant Model). Hình 3 giới thiệu về tổng quan hệ thống kiểm soát thời điểm thông báo.



(Hình 3: sơ đồ tổng quan hệ thống)

Timing Score sẽ "học" để biết rằng khi điện thoại ở trạng thái như thế nào thì có khả năng người dùng sẽ mở thông báo, kết hợp với nhật ký (log) thất bại/thành công trước đó cũng như trạng thái của điện thoại ở cùng thời điểm.

Bảng 1 dưới đây mô tả các đặc trưng (feature)* được sử dụng để xác định trạng thái của điện thoại.

* Đặc trưng (feature): một thuật ngữ trong Machine Learning. Có ý kiến cho rằng, số lượng đặc trưng càng nhiều thì độ chính xác càng cao. Tuy nhiên, tùy theo từng bài toán mà có thuộc tính này hữu ích hơn các thuộc tính kia và cần loại bỏ bớt các thuộc tính không liên quan. (chú thích của TBV)



(Bảng 1: các đặc trưng  được sử dụng để tính toán Timing Score)

Hãy thử lấy một vài ví dụ với các đặc trưng ở bảng 1 trên:

- Vào thời điểm 8 giờ, người dùng đang đi bộ thì dừng lại, điện thoại chưa được sạc, âm lượng được đặt ở mức 2, chế độ im lặng không được bật, mạng LTE được sử dụng. Thông báo gửi vào thời điểm này đã không được mở.

- Vào thời điểm 9 giờ, người dùng đang đi bộ, điện thoại chưa được sạc, âm lượng được đặt ở mức 2 hoặc 3, chế độ im lặng không được bật, mạng Wi-fi được sử dụng. Thông báo vào thời điểm này đã được mở.

Chúng ta có thể thu được từ người dùng hàng triệu dữ liệu nhật ký hoạt động như vậy (chỉ là những thông tin không giúp xác định một cá nhân cụ thể).

Từ nhật ký hoạt động, chúng ta cho mô hình học để biết rằng, ở trạng thái nào thì khả năng cao người dùng sẽ mở thông báo và ngược lại. Từ đó, mô hình phân biệt có tên là It's Timing! được tạo ra. Mô hình này hoạt động dựa trên nguyên tắc đại loại như: đang đi bộ mà dừng lại thì trừ một điểm, bật âm lượng từ mức 2 lên 4 thì cộng một điểm. Timing Score được tính toán bởi mô hình này!

Có nên để mô hình phân biệt It's Timing! hoạt động giống nhau trên mọi ngữ cảnh?

Điều tôi quan tâm ở cơ chế trên chính là mô hình phân biệt It's Timing! Cơ chế cơ bản và đơn giản nhất của nó là dùng duy nhất một mô hình để phân biệt bất kỳ ai vào bất kỳ thời điểm nào. Ví dụ: cho dù người dùng đang trên tàu điện đến trường hoặc nơi làm việc, đang hát karaoke với bạn bè hay đang chạy bộ đi nữa, chỉ có một mô hình duy nhất được sử dụng với cơ chế kiểu như: đang đi bộ mà dừng lại thì khả năng cao sẽ mở thông báo → tăng một score.   

Vấn đề nằm ở đây.

Hãy xem như ví dụ trên là kết quả của việc mô hình đã học được cơ chế: đang đi bộ mà dừng lại thì khả năng cao sẽ chú ý vào điện thoại nên có thể sẽ mở thông báo. Cũng là "đi bộ → dừng lại" nhưng nếu hoàn cảnh là dừng để chờ đèn xanh trên đường đi bộ đến trường hoặc nơi làm việc, rất có thể người đó sẽ nhìn vào điện thoại. Tuy nhiên, cũng có khi người ta đang đi hát karaoke với bạn bè, đang hát giữa chừng thì muốn đi vệ sinh nên chỉ muốn đi thật nhanh để quay lại hát tiếp. Trong bối cảnh này, nếu phán đoán đã đúng thời điểm "đi bộ → dừng lại" rồi gửi thông báo thì chỉ có vô ích mà thôi. Tương tự với ví dụ về chạy bộ, có khi người ta chạy mệt nên chuyển sang đi bộ nhưng vì vẫn còn mệt nên dừng lại chút rồi chạy tiếp. Lúc đó không cần thiết phải gửi thông báo.

Chính vì vậy, tôi đã nảy ra ý tưởng về cơ chế thứ hai: cho mô hình phân biệt học theo nhiều ngữ cảnh (context) người dùng khác nhau. Tuy nhiên, rất khó để bao quát mọi ngữ cảnh như hát karaoke, trên đường đi học đi làm hay chạy bộ. Vì vậy, tôi đã thể hiện 64 ngữ cảnh (4x4x2x2) tổ hợp được từ bốn yếu tố: ngày thường/ngày lễ, thời gian rảnh, chế độ rung và chế độ ngủ. Và mỗi một mô hình tôi lại cho nó học một ngữ cảnh khác nhau!



(Bảng 2: danh sách ngữ cảnh tham khảo)

Nhờ vậy, tôi đã đạt được bước tiến lớn. Đó là bất kể trường hợp nào, nếu người dùng đặt ra các tình huống khác nhau, tôi sẽ tính điểm bằng cách sử dụng các mô hình phân biệt khác nhau, được đào tạo bởi những dữ liệu khác nhau. Đây chính là điểm mấu chốt của cơ chế thứ hai.

Kiểm soát thời điểm thông báo mang lại hiệu quả đến đâu?

Vậy kết quả như thế nào đối với hai loại thông báo được gửi bởi hai loại mô hình phân biệt It's Timing! hoạt động theo hai cơ chế khác nhau: cơ chế cơ bản và cơ chế phân biệt ngữ cảnh? Chúng tôi đã thực nghiệm để kiểm tra trên khoảng 400 ngàn người dùng Android được chia làm hai nhóm ngẫu nhiên.

Nhóm 1: thông báo như trước giờ (có thông báo là push) 

Nhóm 2: kiểm soát thời gian thông báo

Nếu tỉ lệ mở thông báo của nhóm một là 1, tỉ lệ của nhóm hai sẽ như thế nào? Hình 4 bên dưới thể kết quả chỉ số "gain" của nhóm hai.



（Hình 4: tỉ lệ mở thông báo của nhóm hai）

Về cơ bản, các thông báo gửi cho nhóm một và nhóm hai đều giống nhau. Nếu kết quả gain là 1.0, nghĩa là tỉ lệ mở thông báo của nhóm một và nhóm hai giống nhau. Nếu gain lớn hơn 1.0, nghĩa là tỉ lệ mở đã được cải thiện. Ngược lại, nếu gain nhỏ hơn một, nghĩa là kết quả không tốt. Đường màu xanh lá thể hiện chỉ số gain của thông báo có kiểm soát thời điểm ở mức cơ bản được gửi trong 20 ngày đầu tiên của thực nghiệm. Đường màu xanh dương thể hiện mức gain của thông báo được kiểm soát ở mức phân biệt ngữ cảnh.

Nhìn vào hình 4, ta có thể thấy hai điều. Thứ nhất, không có ngày nào chỉ số gain xuống dưới 1. Tức là, tỉ lệ người dùng mở thông báo cao hơn khi có kiểm soát thời điểm. Thứ hai, tỉ lệ mở trong giai đoạn 30 ngày sau cao hơn 20 ngày đầu. Khác biệt duy nhất giữa hai giai đoạn này là ở chỗ 30 ngày sau có áp dụng kiểm soát ngữ cảnh. Ta có thể hiểu rằng, kết quả sẽ còn tuyệt vời hơn khi ta kiểm soát thời điểm kết hợp ngữ cảnh. Thống kê cho thấy rõ ràng việc áp dụng mô hình có ngữ cảnh đã mang lại hiệu quả. Chỉ số gain tỉ lệ mở thông báo cao hơn 1.4 lần so với thông báo thông thường (push ngay khi có thông báo)! Nó thực sự hiệu quả!

Tôi muốn chia sẻ thêm một kết quả thú vị nữa. Số lượng người dùng mở thông báo cao hơn trong 120 giây đầu! Đường liền nét là thông báo  kiểm soát thời gian kèm ngữ cảnh và đường chấm là thông báo bình thường.



（Hình 5: phản ứng của người dùng trong vòng 120 giây đầu tiên）

Từ hình 5, có thể thấy rằng đối với thông báo bình thường (đường chấm), từ thời điểm push, số lượng người dùng mở thông báo tăng lên từng chút một khi thời gian trôi qua. Đối với thông báo có kiểm soát thời điểm, người dùng mở ngay khi thông báo được push. Thông báo được push ngay thời điểm người dùng đang chăm chú vào điện thoại nên nó được mở ngay lập tức. Có thể suy đoán đây chính là yếu tố đóng góp vào mức gain ở hình 4 bên trên.

Cho đến nay, chúng ta thường đặc biệt chú trọng vào việc sử dụng các kỹ thuật xử lý ngôn ngữ và phân tích sở thích để suy đoán sở thích người dùng. Tất nhiên, đó cũng là một kỹ thuật quan trọng. Tuy nhiên, tôi nhận ra rằng, đối với thông báo, việc tối ưu cả thời điểm gửi cũng là một cách mang lại hiệu quả tuyệt vời. Chỉ cần thay đổi thời điểm, thông báo của chúng ta sẽ được nhiều người dùng mở ra, bạn nghĩ sao về cơ chế này?

Ngoài lề: cơ chế này không có nhược điểm?

Cuối cùng là một câu chuyện ngoài lề. Có lẽ các bạn cho rằng cơ chế này thật tuyệt vời. Hãy thử suy nghĩ xem nó có nhược điểm gì không nào! Mọi người cùng suy nghĩa trước khi đọc tiếp nhé!!!

Tôi đã từng nhờ các nhân viên Yahoo! JAPAN khác suy nghĩ về nhược điểm của việc kiểm soát thời điểm gửi thông báo tại các hội thảo nội bộ và thu được hai ý kiến nổi bật:

Tiêu thụ pin nhiều hơn

Cảm thấy khó chịu vì như bị theo dõi 

Về vấn đề tiêu thụ nhiều pin, đúng là như vậy! Sau khi thông báo tới, điện thoại liên tục tính toán để đưa ra Timing Score. Lượng tính toán càng tăng thì lượng pin tiêu thụ càng nhiều. Tuy nhiên, tôi đã kiểm tra và thấy rằng, lượng pin có tăng nhưng rất ít và gần như người dùng không hề nhận ra.

Về vấn đề không thoải mái vì cảm giác như mình đang bị theo dõi, tôi hoàn toàn hiểu. Đây là một vấn đề luôn đi kèm với các loại phân tích cá nhân hóa, điều quan trọng là chúng ta phải giải thích rõ ràng tới đâu để người dùng thấu đáo. Trong trường hợp này, chúng ta không  tạo mô hình cho riêng cá nhân nào và các mô hình hoạt động giống nhau trên mọi người dùng, Hoàn toàn không có việc sử dụng dữ liệu để phân tích riêng bất kỳ ai. Vì vậy, tôi đánh giá vấn đề riêng tư này ở mức độ thấp.

Vậy thật sự mô hình này không có nhược điểm? 

Thực ra, tôi đã xác nhận được một nhược điểm là mô hình thông báo kiểm soát thời điểm hoạt động quá mạnh!



（Hình 6: tỉ lệ mở các thông báo về tin nóng）

Sơ đồ trên thể hiện tỉ lệ mở thông báo về Tin nóng (breaking news) Đó là các tin tức về việc người nổi tiếng qua đời, đội thắng giải bóng chày chuyên nghiệp hay các chính sách lớn được quyết định... Yahoo! JAPAN cũng cung cấp dịch vụ thông báo tin nóng cho các ứng dụng của mình. Tin nóng là loại tin có tính tức thời nên trong thí nghiệm của mình, tôi đã thực hiện cơ chế "push ngay khi có" đối với cả nhóm thí nghiệm kiểm soát thời điểm gửi. Đồng nghĩa với việc không kiểm soát thời điểm đối với thông báo về tin nóng.

Về tin nóng, chắc chắn cả nhóm thông báo thông thường lẫn nhóm thông báo có kiểm soát thời điểm đều giống nhau. Vậy mà trong 30 ngày thí nghiệm, mức gain của thông báo về tin nóng lại dưới 1.0! Tức là, dù tin nóng có được push ngay lập tức nhưng vào thời điểm người dùng chú ý đến điện thoại, các thông báo tích lũy lại trước đó (do kiểm soát thời gian) cũng được gửi đến khiến họ không xem tin nóng được. Vì lý do này, chúng ta cần nghĩ cách để có thể lưu hiệu quả nhiều loại thông báo trên cùng một chiếc điện thoại (ví dụ: tắt chức năng điều khiển thời điểm một lúc khi có tin nóng).

Lời kết

Các bạn thấy thế nào? Tôi rất mong bài viết của mình sẽ khiến các bạn nhận ra rằng, việc chú ý đến thời điểm cho push notification cũng thật thú vị! Xưa nay, chúng ta thường nghe khái niệm về "sự mới mẻ" đối với các chức năng như gợi ý đề xuất. Điều đó có nghĩa là machine learning có lợi thế cạnh tranh ngay cả trong một thế giới vốn có rất ít thời gian để suy nghĩ về sự mới mẻ. Tôi thực sự muốn đi sâu vào lĩnh vực này.

Cảm ơn bạn đã đọc bài viết!

※ Bài viết được trích từ Yahoo! JAPAN Tech Blog.