AIチャット製品において遅い返信とチャーン（離脱）を見分ける方法
ユーザーが自分のペースで返信している場合、AIチャットにおける長い空白期間は、離脱したことを示す根拠としては不十分です。あえて遅いペースを選んでいるのか、配信の問題なのか、あるいは未完了のタスクなのかを区別するには、メッセージの配信状況やタスクの状態とは切り離して、ユーザーが明示的に設定した返信設定を記録してください。沈黙そのものは証拠のない「不明」として扱い、離脱の証拠とは見なさないようにしましょう。
経過時間だけではユーザーを誤認してしまう理由
時間の経過は計測しやすいものの、その間に何が起きていたのかまでは説明してくれません。ユーザーがあえて後で戻ることを選んだのかもしれませんし、通知がデバイスに届かなかったのかもしれません。あるいは、アプリが完了したタスクを記録していなかったり、単に観察すべき新たなアクションが存在しなかったりする可能性もあります。これらの可能性にはそれぞれ異なる製品対応が必要となるため、一括して「非アクティブ」という単一のラベルにしてしまうと、基礎となるデータの解釈が難しくなります。
メッセージングシステム自体も、配信の各段階を明確に区別しています。Firebase Cloud Messagingでは、送信、Androidアプリでの受信、通知の表示、開封を個別の指標としてレポートします。送信とは、メッセージがキューに入れられたり、APNsなどのサービスに渡されたりしたことを意味する場合があり、ユーザーが実際に目にしたことを意味するわけではありません。またFirebaseは、一部のレポートに遅延が生じることや、集計配信データに対象範囲の制限があることにも言及しています。Firebase: Understanding message delivery
この違いは、分析における有用なルールを示唆しています。送信リクエストのような上流のイベントからユーザーの返信ペースを推測してはならず、開封や返信がないことを配信失敗の証拠として扱ってはならないということです。製品側で観測可能な事象のみを記録し、観測されていない結果は不明のままにしておきましょう。
希望する返信ペースをユーザー自身に設定してもらう
実用的な問いに答える、シンプルで任意の設定項目を提供しましょう。「製品側からいつ返信を促したり、フォローアップを行ったりしてほしいか？」という問いです。製品に適しているなら、「準備ができたら」「今日の遅い時間」「指定した日にリマインド」といった、わかりやすい選択肢を用意します。具体的な選択肢はデザイン上の決定事項であり、特定のユーザーの好みを決めつけるものではありません。
選択内容は、更新日時や（該当する場合は）有効期限または終了条件とともに、ユーザープロパティとして保存します。設定とは、そのユーザーによる製品利用の意図に関する持続的なコンテキストです。一方で、返信間隔は1つの会話またはメッセージに関する個別の事象です。アナリティクスプラットフォームでも同様に、ユーザーを説明する「ユーザープロパティ」と、特定のアクションを説明する「イベントプロパティ」を区別しています。Amplitude: User properties and event properties
この設定は簡単に変更またはクリアできるようにしてください。観測された平均返信時間を、推定された設定へと勝手に変換することは避けましょう。過去のパターンは以前の行動を説明するのには役立ちますが、明示的な選択のみがユーザーの意思表明となり得ます。保存された設定がない場合は、製品側で勝手にデフォルトのペースを割り当てるのではなく、値を「不明」として記録してください。
会話タスクを観測可能な状態として追跡する
システムが検証可能なアクションを中心に、少数のタスク状態を定義します。例えば、waiting_for_user（ユーザー待ち）、waiting_for_service（サービス待ち）、ready_for_user（ユーザー対応可能）、completed（完了）、cancelled（キャンセル）などです。イベントやシステム応答によって裏付けがある場合にのみ、その状態を使用してください。ユーザーがメッセージを送信するとタスクはwaiting_for_serviceに移行し、正常な応答があればready_for_userになり、明示的な完了アクションによってcompletedとマークされるような設計です。応答や状態の更新に失敗した場合は、その失敗を記録し、後続のイベントによって明確になるまでタスクを未解決のままにしておきます。
これらのイベントに会話またはタスクの識別子を付与し、アナリストが一連の流れを再現できるようにします。イベント発生時刻、イベントタイプ、現在のタスク状態、関連する技術的結果を記録してください。ユーザーレベルの設定とタスクごとの詳細は分けて管理しましょう。「準備ができたら返信したい」という設定は複数の会話にまたがって適用されますが、「このタスクはユーザーのアクション待ちである」というのは現在の1つのインタラクションを表します。イベントベースのアナリティクスでは、イベントプロパティがアクション発生時のコンテキストを捉え、ユーザープロパティは時間の経過とともに変化し得る属性を表します。Amplitude: User properties and event properties
この分離は、過去データの正確な解釈を守ることにもつながります。ユーザーが設定を変更した際は、以前のイベントには古い値を保持し、それ以降のイベントに新しい値を適用します。あたかも新しい設定が最初から適用されていたかのように過去を書き換えてはなりません。Amplitudeのドキュメントでも、ユーザープロパティにおけるこのような時間に応じた挙動が説明されています。Amplitude: User properties and event properties
配信の健全性とユーザーのアクションを切り離す
送信される各チャットメッセージや通知について、連携機能が実際に開示している段階を記録します。送信試行、メッセージングサービスによる受付、（可能であれば）アプリへの配信、（可能であれば）表示、（可能であれば）開封、および判明しているエラーなどです。プラットフォームが提供していない配信確認を勝手に捏造してはいけません。Appleプラットフォームでは、APNsがユーザーのデバイスへのリモート通知配信を処理しますが、そのシステム上の役割は、ユーザーが通知を開封したという記録とは異なります。Apple: User Notifications
インフラストラクチャの結果は、インフラのシグナルとして利用してください。例えば、リクエストの失敗、プロバイダーによる拒絶、タイムアウト、キューの遅延などは、配信やサービスの健全性を調査するきっかけとすべきです。送信リクエストの成功は、あくまでその段階が成功したことの証拠にすぎません。Firebaseは、送信統計が配信待ちとしてエンキューされたことや別のサービスに渡されたことを表す場合があること、そして集計されたAndroidの転送データは個々のメッセージではなく大まかな傾向を示すものであると説明しています。Firebase: Understanding message delivery
内部のメッセージ処理においては、確認応答（ack）の解釈にも注意が必要です。Google Cloud Pub/Subでは、メッセージは確認応答があるまで未処理（outstanding）とみなされ、期限後に再配信される可能性があること、またメッセージが複数回配信される場合があることが明記されています。これは、イベント処理で重複を許容できるようにし、システム処理の確認応答漏れとユーザーからの返信がない状態とを区別するための有益な注意点となります。Google Cloud: Subscription overview
慎重な分類ルールを運用する
実践的な判断基準を用いることで、ラベルの適用範囲を限定し、証拠に基づいたものに保つことができます。
観測された証拠：ユーザーが返信タイミングの設定を選択しており、それ以降のアクションは観測されていない。適切な分析ラベル：設定記録済み、返信は未観測。確定できないこと：ユーザーが離脱したこと、または配信が失敗したこと
観測された証拠：サービスリクエストまたはメッセージ配信の段階で失敗またはタイムアウトした。適切な分析ラベル：記録された段階での技術的問題。確定できないこと：ユーザーが返信しなかった理由
観測された証拠：ユーザーのアクションを待っている確定済みの次のステップが製品側にある。適切な分析ラベル：ユーザーアクション待ちのタスク。確定できないこと：タスクが放棄されたこと
観測された証拠：完了、キャンセル、またはその他の最終アクションが記録されている。適切な分析ラベル：観測結果に応じた「完了」または「キャンセル」。確定できないこと：将来の利用に関する広範な判断
観測された証拠：証拠が存在しない、遅延している、または矛盾している。適切な分析ラベル：不明、または要照合。確定できないこと：確信を持てるあらゆる行動的理由付け
「チャーン（離脱）」というラベルは、定義された製品レベルのルールと、そのルールを満たす十分な証拠を必要とすべきであり、メッセージ間のインターバルが長いことの同義語であってはなりません。証拠が揃う前にダッシュボードで何らかのステータスが必要な場合、「ユーザーが不在である理由」を断定するよりも、「最近の返信が観測されていない」とする方が正確です。そのステータスは暫定的なものとして扱い、遅れてイベントが到着した際には修正してください。
設定とタスクの状態を軸に分析を組み立てる
有用なコホート分析とは、あえて遅いペースを明示的に選んだユーザーが、その設定に沿った時間枠の中でタスクを完了させているかどうかを問うものです。同じ条件のもの同士を比較してください。選択された設定やタスクタイプごとにグループ化し、配信の失敗、未解決のサービスリクエスト、完了イベントを個別に検証します。1人の静かな期間を製品全体の問題シグナルに仕立て上げてはなりません。類似したタスクや配信条件の間にあるパターンを探すようにしましょう。
例えば、あるユーザーが「準備ができたら」を選択し、会話が開いたままで、製品側に配信エラーや新しいユーザーアクションが記録されていない場合、妥当なステータスは「返信未観測・設定登録済み・タスク未完了」です。送信側の応答にサービスエラーが記録されている場合は、ユーザーの設定が判明していたとしても、そのステータスにはエラーを反映させるべきです。これは上記のイベントモデルに基づいた説明用の分類例であり、計測された製品の実績値ではありません。
意思決定に指標を用いる前に、特定のプラットフォームでイベントの到着が遅れていないか、重複していないか、欠落していないかを確認してください。Firebaseは一部の配信レポートに遅延が生じることや、集計指標では結果が省略・四捨五入される可能性があると述べています。またPub/Subは、少なくとも1回の配信（at-least-once）と再配信の可能性について言及しています。不変のメッセージ識別子やタスク識別子を用いてイベントの整合性を取り、リトライ処理をユーザーによる2回目のアクションとして誤ってカウントしないようにしてください。Firebase: Understanding message delivery, Google Cloud: Subscription overview
ユーザーの選択に合わせたフォローアップを設計する
フォローアップが製品の一部である場合は、ユーザー自身が選択した設定を反映させましょう。指定されたリマインド時刻に基づいてリマインドを行い、「準備ができたら」が選ばれている場合は時間ベースのプッシュ通知を控えるといった対応です。設定を簡単に変更できる手段を提供し、会話内で現在の状態（システムがユーザーを待っているのか、サービスを待っているのか、完了しているのか）がわかるように可視化してください。
アナリティクスは技術的な欠陥を発見し、タスクの完了状況を把握するために活用すべきであり、沈黙から無理やり確信をでっち上げるために使うべきではありません。明示的な設定は文脈を与え、タスクの状態は残りの作業を示し、配信イベントは判明している技術的フェーズを明らかにします。これらの要素のいずれかが欠けている場合は、ラベルに不確実性を残しておきましょう。そうすることで、ユーザーに戻るタイミングのコントロールを委ねつつ、遅い返信についてより有益な把握ができるようになります。