如何在 AI 對話產品中區分回覆緩慢與使用者流失

為什麼單憑流逝的時間會誤判使用者

時間間隔很容易衡量，但它無法解釋在此期間發生了什麼事。某人可能選擇稍後再回覆；通知可能未送達裝置；應用程式可能未記錄已完成的任務；或者只是單純沒有新的動作可供觀察。這些可能性需要不同的產品應對措施，因此將它們合併為單一的「非活躍」標籤會使底層數據更難以解讀。

訊息傳遞系統本身會區分不同的傳送階段。Firebase Cloud Messaging 將發送、Android 應用程式接收、通知曝光和開啟次數作為獨立的指標進行報告；發送可能僅意味著訊息已進入佇列或已傳遞至 APNs 等服務，而非表示使用者已經看到該訊息。Firebase 也指出，部分報告存在延遲，且其匯總的傳送數據具有覆蓋範圍限制。Firebase: Understanding message delivery

這種區分提出了一條實用的分析規則：切勿從發送請求等上游事件推斷使用者的回覆節奏，也切勿將未開啟或未回覆視為傳送失敗的證明。只記錄產品能夠觀察到的內容，對於未觀察到的結果則保持未知。

讓使用者表明偏好的回覆節奏

提供一個簡單且選填的偏好設定，以回答一個實際問題：使用者希望產品在何時提示回覆或進行後續追蹤？若適合該產品，可使用易於理解的選項，例如「等我準備好時」、「今天稍後」或「在選定的日期提醒我」。具體的選項是一項設計決策，而非對任何特定使用者偏好的斷言。

將該選擇儲存為使用者偏好設定，並附帶其更新時間，以及在適用情況下的過期時間或結束條件。偏好設定是關於該使用者選擇如何使用該產品的持久上下文；而回覆間隔則是關於單次對話或訊息的客觀事實。分析平台對描述使用者的「使用者屬性（user properties）」與描述特定動作的「事件屬性（event properties）」也做出了類似的區分。Amplitude: User properties and event properties

讓此偏好設定易於更改或清除。避免將觀察到的平均回覆時間轉換為假定的偏好：歷史模式有助於描述過去的行為，但只有明確的選擇才能代表陳述的偏好。如果沒有儲存的偏好設定，請將該值記錄為未知，而不是代表使用者分配預設的節奏。

將對話任務追蹤為可觀察的狀態

圍繞系統可驗證的操作定義一組精簡的任務狀態。例如：waiting_for_user、waiting_for_service、ready_for_user、completed 和 cancelled。僅在有事件或系統回應支援時才使用相應狀態。使用者發送訊息可能會將任務移至 waiting_for_service；成功的回應可能會使其變為 ready_for_user；明確的完成動作可將其標記為 completed。如果回應或狀態更新失敗，請記錄該失敗並保持任務未解決，直到後續事件將其釐清。

為這些事件附加對話或任務識別碼，以便分析人員能夠重建事件序列。記錄事件時間、事件類型、當前任務狀態以及相關的技術結果。將使用者層級的偏好與個別任務的詳細資訊分開：「偏好在準備好時回覆」可適用於多個對話，而「此任務正在等待使用者操作」則描述當前的一次互動。在以事件為基礎的分析中，事件屬性會擷取動作發生時的上下文，而使用者屬性則描述隨時間變化的屬性。Amplitude: User properties and event properties

這種區隔同時也能保護歷史解讀的準確性。當有人更改偏好時，應在較早的事件上保留舊值，並將新值套用於後續事件；切勿改寫過去的數據，假裝新偏好一直適用。Amplitude 的說明文件描述了使用者屬性的這種具有時間感知能力的行為。Amplitude: User properties and event properties

將傳送健全狀況與使用者行為分開

針對每則外發的對話訊息或通知，記錄整合技術實際公開的各個階段：嘗試發送、訊息服務已接收、已送達應用程式（若可用）、已顯示（若可用）、已開啟（若可用），以及任何已知錯誤。切勿偽造平台未提供的送達回執。在 Apple 平台上，APNs 負責處理向使用者裝置傳送遠端通知；該系統角色與記錄使用者開啟通知是兩回事。Apple: User Notifications

將基礎設施的結果作為基礎設施的信號。例如，失敗的請求、提供商拒絕、超時或佇列延遲應促使團隊去調查傳送或服務的健全狀況。成功的發送請求僅能證明該階段已完成。Firebase 解釋稱，其發送統計數據可能代表訊息已排隊等待傳送或已傳遞給其他服務，且其匯總的 Android 傳輸數據描述的是大致趨勢，而非每則個別訊息。Firebase: Understanding message delivery

對於內部訊息處理，確認信號（acknowledgments）同樣需要仔細判讀。Google Cloud Pub/Sub 將訊息描述為在確認之前處於未處理（outstanding）狀態，並指出未確認的訊息在截止時間後可能會被重新傳送；訊息也可能會被傳送不只一次。這是一個實用的提醒：應使事件處理能夠容忍重複，並將處理確認信號的缺失與使用者回覆的缺失區分開來。Google Cloud: Subscription overview

採用謹慎的分類規則

實用的決策輔助工具可以讓標籤保持明確且有據可查：

觀察到的證據：使用者選擇了回覆時間偏好，且未觀察到更新的操作；合適的分析標籤：已記錄偏好；尚未觀察到回覆；未能證明的結論：使用者已離開，或傳送失敗

觀察到的證據：服務請求或訊息傳送階段失敗或超時；合適的分析標籤：在記錄的階段出現技術問題；未能證明的結論：使用者未回覆的原因

觀察到的證據：產品已有確認的下一步正在等待使用者操作；合適的分析標籤：任務等待使用者操作；未能證明的結論：該任務已被放棄

觀察到的證據：記錄了完成、取消或其他最終操作；合適的分析標籤：已完成或已取消（按觀察結果）；未能證明的結論：對未來使用的更廣泛判斷

觀察到的證據：證據缺失、延遲或相互矛盾；合適的分析標籤：未知或需要比對調節；未能證明的結論：任何確信的行為解釋

「流失（churn）」標籤應該需要明確定義的產品級規則，以及支撐該規則的充分證據；它不應成為訊息間隔時間長的同義詞。如果在證據完整之前儀表板需要一個狀態，那麼「近期未觀察到回覆」比斷言使用者為何缺席更為精確。請將該狀態視為暫定狀態，並在延遲的事件送達時進行修正。

圍繞偏好和任務狀態建立分析

一項有價值的同群組分析（cohort analysis）會探討：明確選擇較慢節奏的使用者，是否在與該偏好相符的時間範圍內完成了他們設定的任務。進行同類比較：按選定的偏好和任務類型分組，並分別檢查傳送失敗、未解決的服務請求和完成事件。切勿將某一個人的沉默間隔轉化為全產品範圍的失敗信號；要在同類任務和傳送條件中尋找規律模式。

例如，如果某人選擇了「等我準備好時」，對話仍保持開啟，且產品沒有記錄傳送錯誤或新的使用者操作，那麼站得住腳的狀態是「未觀察到回覆；已記錄偏好；任務仍處於開啟狀態」。如果外發回應記錄了服務錯誤，則即使已知使用者的偏好，該狀態也應反映該錯誤。這是基於上述事件模型的示範性分類，而非實際測得的產品結果。

在將某個指標用於決策之前，請檢查事件在特定平台上是否存在到達延遲、重複或缺失的情況。Firebase 表示部分傳送報告存在延遲，匯總指標可能會遺漏或四捨五入結果；Pub/Sub 記錄了至少一次（at-least-once）傳遞和可能的重複傳遞。請使用穩定的訊息或任務識別碼來調節核對事件，並避免將重試計為第二次使用者操作。Firebase: Understanding message delivery, Google Cloud: Subscription overview

圍繞使用者的選擇設計後續追蹤

如果後續追蹤是產品功能的一部分，請使其反映使用者選擇的偏好。選定的提醒時間可用於控制提醒發送；「等我準備好時」可以意味著不進行基於時間的推播提醒。為使用者提供明確更改該選擇的方法，並在對話中顯示當前狀態，以便他們能夠判斷產品是在等待他們、等待服務回應還是已完成。

利用分析工具來發現技術缺陷並了解任務完成情況，而不是從沉默中憑空捏造確定性。明確的偏好提供了背景資訊，任務狀態顯示了尚待處理的工作，傳送事件則揭示了哪些技術階段是已知的。當缺少其中一項資訊時，請在標籤中保留這種不確定性。這樣既能更有效地解釋回覆緩慢的情況，同時又能讓使用者自主掌控何時返回產品。

繼續探索這個主題