Cara Membedakan Balasan Lambat dari Churn dalam Produk Obrolan AI
Jika pengguna membalas dengan ritme mereka sendiri, jeda waktu yang lama dalam obrolan AI tidak cukup untuk menunjukkan bahwa mereka telah pergi. Untuk membedakan ritme lambat yang memang dipilih dari masalah pengiriman pesan atau tugas yang belum selesai, catat preferensi balasan eksplisit pengguna secara terpisah dari pengiriman pesan dan status tugas. Perlakukan keheningan saja sebagai hal yang tidak diketahui, bukan sebagai bukti pengabaian.
Mengapa waktu yang berlalu saja salah mengklasifikasikan pengguna
Jeda waktu mudah diukur, tetapi hal itu tidak menjelaskan apa yang terjadi selama rentang waktu tersebut. Seseorang mungkin memilih untuk kembali lagi nanti; pemberitahuan mungkin tidak sampai ke perangkat; aplikasi mungkin tidak mencatat tugas yang telah selesai; atau mungkin memang tidak ada tindakan baru yang perlu diamati. Berbagai kemungkinan ini memerlukan respons produk yang berbeda, sehingga menggabungkannya ke dalam satu label “tidak aktif” membuat data yang mendasarinya lebih sulit untuk ditafsirkan.
Sistem perpesanan itu sendiri membedakan tahapan pengiriman. Firebase Cloud Messaging melaporkan pengiriman (sends), penerimaan aplikasi Android, impresi notifikasi, dan pembukaan notifikasi (opens) sebagai metrik yang terpisah; status pengiriman dapat berarti pesan telah masuk antrean atau diteruskan ke layanan seperti APNs, bukan berarti pengguna telah melihatnya. Firebase juga mencatat bahwa beberapa pelaporan mengalami keterlambatan dan data pengiriman agregatnya memiliki batasan cakupan. Firebase: Understanding message delivery
Perbedaan tersebut menyarankan aturan analitik yang berguna: jangan pernah menyimpulkan ritme balasan seseorang dari peristiwa di tahap awal seperti permintaan pengiriman (send request), dan jangan pernah memperlakukan status pesan yang belum dibuka atau belum dibalas sebagai bukti kegagalan pengiriman. Tangkap apa yang dapat diamati oleh produk, dan biarkan hasil yang tidak teramati tetap berstatus tidak diketahui.
Biarkan pengguna menyatakan ritme balasan yang mereka sukai
Tawarkan preferensi sederhana dan opsional yang menjawab pertanyaan praktis: kapan pengguna ingin produk mengundangnya membalas atau menindaklanjuti? Gunakan pilihan yang mudah dipahami seperti “saat saya siap,” “nanti hari ini,” atau “ingatkan saya pada hari tertentu,” jika opsi-opsi tersebut sesuai dengan produk. Opsi pastinya adalah keputusan desain, bukan klaim tentang apa yang disukai oleh pengguna tertentu.
Simpan pilihan tersebut sebagai preferensi pengguna beserta waktu pembaruannya dan, jika berlaku, kondisi kedaluwarsa atau akhirnya. Preferensi adalah konteks yang tahan lama mengenai pola penggunaan produk yang dipilih orang tersebut; interval balasan adalah fakta tentang satu percakapan atau pesan. Platform analitik membuat perbedaan serupa antara properti pengguna (user properties), yang menggambarkan pengguna, dan properti peristiwa (event properties), yang menggambarkan tindakan spesifik. Amplitude: User properties and event properties
Buat preferensi tersebut mudah diubah atau dihapus. Hindari mengubah rata-rata waktu balasan yang teramati menjadi asumsi preferensi: pola historis dapat membantu menggambarkan perilaku masa lalu, tetapi hanya pilihan eksplisit yang dapat menunjukkan preferensi yang dinyatakan. Jika tidak ada preferensi yang tersimpan, catat nilainya sebagai tidak diketahui daripada menetapkan ritme default atas nama pengguna.
Lacak tugas percakapan sebagai status yang dapat diamati
Tentukan serangkaian kecil status tugas di sekitar tindakan yang dapat diverifikasi oleh sistem. Misalnya: waiting_for_user, waiting_for_service, ready_for_user, completed, dan cancelled. Gunakan suatu status hanya jika ada peristiwa atau respons sistem yang mendukungnya. Pengguna yang mengirim pesan dapat memindahkan tugas ke waiting_for_service; respons yang berhasil dapat menjadikannya ready_for_user; tindakan penyelesaian yang eksplisit dapat menandainya sebagai completed. Jika respons atau pembaruan status gagal, catat kegagalan tersebut dan pertahankan tugas tetap belum terselesaikan sampai ada peristiwa berikutnya yang memperjelasnya.
Lampirkan pengenal percakapan atau tugas ke peristiwa-peristiwa ini agar analis dapat merekonstruksi urutannya. Catat waktu peristiwa, jenis peristiwa, status tugas saat ini, dan hasil teknis yang relevan. Pisahkan preferensi tingkat pengguna dari detail per tugas: “lebih suka membalas saat siap” dapat berlaku di seluruh percakapan, sedangkan “tugas ini sedang menunggu tindakan pengguna” menggambarkan satu interaksi saat ini. Dalam analitik berbasis peristiwa, properti peristiwa menangkap konteks pada saat tindakan terjadi, sedangkan properti pengguna menggambarkan atribut yang dapat berubah seiring waktu. Amplitude: User properties and event properties
Pemisahan ini juga melindungi interpretasi historis. Ketika seseorang mengubah preferensi, pertahankan nilai lama pada peristiwa sebelumnya dan gunakan nilai baru untuk peristiwa berikutnya; jangan menulis ulang masa lalu seolah-olah preferensi yang lebih baru selalu berlaku sejak awal. Dokumentasi Amplitude menjelaskan perilaku sadar-waktu ini untuk properti pengguna. Amplitude: User properties and event properties
Pisahkan kesehatan pengiriman dari tindakan pengguna
Untuk setiap pesan obrolan keluar atau notifikasi, catat tahapan yang benar-benar ditampilkan oleh integrasi: upaya pengiriman (send attempted), diterima oleh layanan perpesanan (accepted by the messaging service), terkirim ke aplikasi jika tersedia (delivered to the app if available), ditampilkan jika tersedia (displayed if available), dibuka jika tersedia (opened if available), dan setiap kesalahan yang diketahui. Jangan mengada-ada tanda terima pengiriman yang tidak disediakan oleh platform. Pada platform Apple, APNs menangani pengiriman notifikasi jarak jauh ke perangkat pengguna; peran sistem tersebut berbeda dari catatan bahwa pengguna telah membuka notifikasi. Apple: User Notifications
Gunakan hasil infrastruktur sebagai sinyal infrastruktur. Misalnya, permintaan yang gagal, penolakan penyedia, batas waktu habis (timeout), atau antrean yang tertunda harus mendorong penyelidikan terhadap pengiriman atau kesehatan layanan. Permintaan kirim yang berhasil hanyalah bukti dari tahapan tersebut. Firebase menjelaskan bahwa statistik pengirimannya dapat merepresentasikan pesan yang dimasukkan ke dalam antrean untuk pengiriman atau diteruskan ke layanan lain, dan bahwa data transportasi Android agregatnya menggambarkan tren umum daripada setiap pesan individu. Firebase: Understanding message delivery
Untuk pemrosesan pesan internal, konfirmasi penerimaan (acknowledgments) juga perlu dibaca dengan cermat. Google Cloud Pub/Sub mendeskripsikan pesan sebagai pesan yang belum terselesaikan (outstanding) sampai diakui dan mencatat bahwa pesan yang belum diakui dapat dikirim ulang setelah melewati batas waktu; pesan juga dapat dikirim lebih dari sekali. Itu adalah pengingat yang berguna untuk membuat pemrosesan peristiwa toleran terhadap duplikasi dan untuk membedakan konfirmasi pemrosesan yang hilang dari balasan pengguna yang belum ada. Google Cloud: Subscription overview
Gunakan aturan klasifikasi yang hati-hati
Panduan keputusan yang praktis dapat menjaga label tetap spesifik dan berbasis bukti:
Bukti teramati: Pengguna memilih preferensi waktu balasan, dan tidak ada tindakan baru yang teramati; Label analitik yang sesuai: Preferensi tercatat; balasan belum teramati; Apa yang tidak dibuktikan: Bahwa pengguna telah pergi, atau bahwa pengiriman gagal
Bukti teramati: Permintaan layanan atau tahapan pengiriman pesan gagal atau waktu habis; Label analitik yang sesuai: Masalah teknis pada tahap yang tercatat; Apa yang tidak dibuktikan: Mengapa pengguna tidak membalas
Bukti teramati: Produk memiliki langkah berikutnya yang telah dikonfirmasi dan sedang menunggu tindakan pengguna; Label analitik yang sesuai: Tugas menunggu tindakan pengguna; Apa yang tidak dibuktikan: Bahwa tugas telah ditinggalkan
Bukti teramati: Penyelesaian, pembatalan, atau tindakan akhir lainnya tercatat; Label analitik yang sesuai: Selesai atau dibatalkan, sesuai pengamatan; Apa yang tidak dibuktikan: Penilaian yang lebih luas tentang penggunaan di masa mendatang
Bukti teramati: Bukti hilang, tertunda, atau saling bertentangan; Label analitik yang sesuai: Tidak diketahui atau perlu rekonsiliasi; Apa yang tidak dibuktikan: Penjelasan perilaku apa pun yang meyakinkan
Label “churn” harus membutuhkan aturan tingkat produk yang terdefinisi dan bukti yang cukup untuk aturan tersebut; label ini tidak boleh menjadi sinonim untuk jeda waktu yang lama di antara pesan. Jika dasbor memerlukan status sebelum bukti lengkap, “tidak ada balasan terbaru yang teramati” lebih tepat daripada klaim tentang mengapa pengguna tidak aktif. Perlakukan status tersebut sebagai sementara dan revisi ketika peristiwa yang tertunda tiba.
Bangun analisis di sekitar preferensi dan status tugas
Analisis kohort yang berguna mempertanyakan apakah pengguna yang secara eksplisit memilih ritme yang lebih lambat menyelesaikan tugas yang mereka nyatakan dalam jangka waktu yang konsisten dengan preferensi tersebut. Bandingkan hal-hal yang sepadan: kelompokkan berdasarkan preferensi yang dipilih dan jenis tugas, lalu periksa secara terpisah kegagalan pengiriman, permintaan layanan yang belum terselesaikan, dan peristiwa penyelesaian. Jangan mengubah jeda tenang satu orang menjadi sinyal kegagalan di seluruh produk; carilah pola di seluruh tugas dan kondisi pengiriman yang sebanding.
Misalnya, jika seseorang memilih “saat saya siap,” percakapan tetap terbuka, dan produk tidak memiliki catatan kesalahan pengiriman atau tindakan pengguna baru, status yang dapat dipertahankan adalah “tidak ada balasan yang teramati; preferensi tercatat; tugas masih terbuka.” Jika respons keluar memiliki catatan kesalahan layanan, status tersebut harus mencerminkan kesalahan tersebut meskipun preferensi pengguna juga diketahui. Ini adalah klasifikasi ilustratif berdasarkan model peristiwa di atas, bukan hasil produk yang terukur.
Sebelum menggunakan suatu metrik untuk pengambilan keputusan, periksa apakah ada peristiwa yang datang terlambat, terduplikasi, atau hilang pada platform tertentu. Firebase menyatakan bahwa beberapa pelaporan pengiriman tertunda dan metrik agregat dapat menghilangkan atau membulatkan hasil; Pub/Sub mendokumentasikan pengiriman setidaknya sekali (at-least-once delivery) dan kemungkinan pengiriman ulang. Rekonsiliasi peristiwa dengan pengenal pesan atau tugas yang stabil, dan hindari menghitung percobaan ulang (retry) sebagai tindakan pengguna kedua. Firebase: Understanding message delivery, Google Cloud: Subscription overview
Rancang tindak lanjut di sekitar pilihan pengguna
Jika tindak lanjut merupakan bagian dari produk, buatlah hal tersebut mencerminkan preferensi yang dipilih pengguna. Waktu pengingat yang dipilih dapat mengatur pengingat; “saat saya siap” dapat diartikan sebagai ketiadaan dorongan (nudge) berbasis waktu. Berikan pengguna cara yang jelas untuk mengubah pilihan tersebut, dan buat status saat ini terlihat dalam percakapan sehingga mereka dapat mengetahui apakah produk sedang menunggu mereka, menunggu layanan, atau sudah selesai.
Gunakan analitik untuk menemukan cacat teknis dan memahami penyelesaian tugas, bukan untuk memanipulasi kepastian dari keheningan. Preferensi eksplisit memberikan konteks, status tugas menunjukkan pekerjaan apa yang masih tersisa, dan peristiwa pengiriman mengungkapkan tahapan teknis mana yang diketahui. Ketika salah satu dari bagian tersebut hilang, pertahankan ketidakpastian dalam label. Pendekatan ini menghasilkan penjelasan yang lebih berguna mengenai balasan yang lambat sambil tetap memberikan kendali kepada pengguna mengenai kapan mereka akan kembali.