1. 入口ごとの入り口（表示 → 開いた／触れた → 接触）
2. 入口 × 状況のファネル
段は上から順に狭くなるのが普通。狭まり方が急な段が詰まり。0（省略）＝設定で飛ばした段で、落ちではない。実架電の率は提案に対する割合（電話タップと独立に起きるため）。表示 → 接触は入口で分母が違うので、全体では接触から始める
| 入口 | 状況 | 接触 | 提案 | 提案率 | 葬儀社へ電話（タップ） | 相談員へ通話要求 | 相談員と通話 | 行動率（÷提案） | 実架電（葬儀社へ実際に電話。BigQuery 突合） | うち提案後 | 受注 | 判定不可 | 集計待ち |
|---|
3. 提案後の行動
提案後にとった行動（1人1つ）
タップの内訳（提示 → 葬儀社へ電話（タップ））
4. チャットの流れのどこで止まったか
| 段 | 種類 | ボットの文言 | 到達 | 止まった | うちチャット | うちフォーム | 止まった÷接触 |
|---|
5. 答えられなかった入力
ボットが答えられずに聞き返した入力の全文です。件数の多い順に並びます。ここを見てKW辞書に応答を足すのが月次の運用です（実装要件 F-405）。段＝その時いた質問や案内（S6b＝市区町村の入力待ち、GOAL＝葬儀社カードの提示後）。訪問者の自由入力なので、個人に関わる内容が含まれることがあります。
6. 日別
| 日付 | imp | imp（開いた） | 接触 | 使用率 | 提案 | 葬儀社へ電話（タップ） | 送客（手動） | 実架電（葬儀社へ実際に電話。BigQuery 突合） | 受注 |
|---|
実架電（葬儀社へ実際に電話。BigQuery 突合）・受注は相談日（最初の発話の日）で数える。突合済みの期間より新しい日は「…」（集計待ち）。送客（手動）はオペレーターの記録（cv_soukyaku）
有人対応（返信率・提案率・通話利用率・クロージング率・CVまで往復／所要）
実装要件 5.2 の定義のまま。提案率＝proposal_sent ÷ 接触、通話利用率＝call_connected ÷ 接触、クロージング率＝cv_soukyaku ÷ 提案（有人）。ボットの提案・葬儀社へ電話（タップ）は含まない
ボットの補助指標（未マッチ率・読み替え・引き継ぎ・概算提示・CVまで往復／所要）
利用時間帯（接触セッションの開始時刻）
基盤の健全性（GA4 キー取得率・突合の状態・遅延 p95）
GA4のクッキー（_ga / _ga_<ストリーム>）から user_pseudo_id と ga_session_id が読めたセッションの割合。実架電の突合はこのキーが揃ったセッションだけが対象になるため、この率がそのまま実架電の上限になる。「_gaのみ」が多ければGTMの発火順や同意管理、「どちらも無し」が多ければITP・プライベートモード・クッキー拒否が疑わしい
送信0.3秒以内・受信0.5秒以内が目標（N-101/102）。受信側はクライアント端末とサーバーの時計差を補正して計測
開始導線の検証（モード別・データがある期間だけ）
| モード | imp | imp（開いた） | 接触 | CV | 使用率 | 選択の内訳 |
|---|
imp（開いた）＝チャットが開いた状態で始まったセッション数。接触・CV・使用率は全体指標と同じ定義。選択＝確認ポップアップの利用する／利用しない・カウントダウンの満了。2026-08-21 の検証。entry_mode が normal だけの期間は 1 行になる