前一篇我們利用 Experiment 比較不同版本的結果。假設新版 Checkout 的 Conversion Rate 明顯比較差，我們至少已經知道這次改動可能有問題。
但這個結果本身還不會告訴我們問題在哪裡。
即使再往 Funnel 看，發現很多使用者停在填完 Shipping Address 之後，我們通常也只能知道「使用者沒有繼續完成下一步」，至於畫面當時發生了什麼，單靠 Event 很難判斷。
這時就可以回頭看使用者實際怎麼操作頁面。PostHog 裡面主要有 Heatmap 與 Session Replay 兩個工具可以處理這件事。
Heatmap 會把大量使用者在頁面上的操作位置疊在一起，讓我們直接從畫面上看到哪些地方經常被點擊。
例如一個看起來像連結、實際上不能點的文字，如果一直累積大量 Click，就值得檢查看看；反過來，如果原本預期使用者會操作的 CTA 幾乎沒有什麼互動，也可能表示按鈕的位置、樣式或前面的內容有問題。
這和前面 Web Analytics 看到的 Rage Click、Dead Click 有些類似，只是 Heatmap 會把互動直接放回頁面的位置上，因此比較容易理解「大家到底在點哪裡」。
不過 Heatmap 是把很多人的操作疊在一起。即使看到某個地方很熱，也不知道某一個使用者在點擊前後做了什麼，更不知道他最後有沒有完成原本的工作。
如果要知道某一個使用者實際經歷了什麼，就可以進一步看 Session Replay。
前面介紹 Error Tracking 時其實已經用過 Session Replay：發生 Exception 後，可以回頭看使用者出錯以前做了哪些操作。這裡的方向稍微不同，我們已經先從 Product Analytics 或 Experiment 發現某個行為值得調查，再利用 Replay 看當時的畫面。
例如 Funnel 顯示不少使用者在填完 Shipping Address 後離開：
open_checkout
→ fill_shipping_address
→ ?
→ purchase_completed
Replay 裡可能看到使用者填完地址後按下 Next，畫面沒有明顯反應，於是又按了幾次，接著上下捲動頁面，最後直接離開。
這時候就比單純看到 Funnel Drop-off 多了很多資訊。問題可能是 Loading State 不清楚，也可能是 Validation Message 出現在使用者沒有注意到的位置。接下來工程師才有比較具體的東西可以檢查。
實際使用 Replay 時，也不太需要從所有 Recording 裡隨便挑幾個來看。PostHog 可以依照 Event、URL、使用者或其他 Session 條件篩選 Recording，所以如果問題出現在 Checkout，就先把 Recording 限制在真的進過 Checkout、甚至做過特定操作的 Session，再看其中反覆出現哪些狀況。
一段 Replay 很容易讓人留下很深的印象，但單一使用者的操作不一定具有代表性。如果只看到一個人連點五次就修改產品，很可能只是在針對特例最佳化。
如果只是追查一個特定問題，挑幾段 Session Replay 來看通常就夠了。但當我們想確認「這種情況到底是不是反覆發生」時，一段一段人工檢查很快就會變得不切實際。
這時可以利用 Replay Vision。它會讓 AI 同時觀看 Session Replay 的畫面與其中的事件，再把結果整理成可以查詢的 Observation。核心概念是先建立一個 Scanner，告訴 PostHog「我要你在 Recording 裡找什麼」。
Scanner 目前有幾種常見形式：
completed、abandoned、blocked_by_error。回到前面的 Checkout 案例。假設 Funnel 已經告訴我們，問題集中在 fill_shipping_address 之後，我們想知道：
使用者填完地址後，是否嘗試繼續操作，卻因為介面沒有提供清楚的下一步而卡住？
這是一個很適合 Monitor 的問題。
建立 Scanner 時，可以先把 Recording Filter 限制在真的進過 Checkout，而且包含 fill_shipping_address 的 Session，避免浪費時間與額度分析完全無關的 Recording。接著 Prompt 可以寫成：
如果使用者填完 Shipping Address 後嘗試繼續，但沒有順利前進，例如重複點擊 Next、在頁面上來回捲動尋找下一步、反覆修改相同欄位，最後仍然沒有進入下一步，回答 yes；否則回答 no。請說明判斷依據，並標記對應的 Recording 時間點。
這裡和一般寫 Prompt 一樣，最好描述可以看到的行為，而不是直接要求模型猜「使用者是不是很困惑」。
設定完成後，我不會立刻讓 Scanner 掃過所有 Session。比較實際的作法是先從 On-demand 挑 5～10 段自己已經看過的 Recording 進行測試。
每次掃描會產生一筆 Observation。打開 Observation 後，可以看到判斷結果、Confidence、Reasoning，以及模型引用的時間點；點擊引用就可以直接跳到 Replay 中對應的位置。這樣很快就能確認 Scanner 是真的抓到我們想找的行為，還是把其他情況誤判成問題。
Prompt 調整到可以接受之後，再啟用 Background Sweep，讓 Scanner 持續處理新的 Recording。如果 Session 很多，也可以利用 Filter、Session Coverage 與 Sampling Rate 控制實際掃描的範圍。
更重要的是，成功的 Observation 不只存在 Replay Vision 裡。PostHog 還會把它記錄成 $recording_observed Event，因此前面學過的 Product Analytics、SQL Insight、Dashboard 與 Alert 又都可以接回來。
例如前面的 Monitor 可以直接計算「被判定為卡住」的比例：
SELECT
toFloat64(countIf(properties.scanner_output_verdict = 'yes')) / count() AS stuck_rate
FROM events
WHERE event = '$recording_observed'
AND properties.scanner_name = 'Checkout stuck after address'
這樣 Replay 就不再只是「偶爾挑幾段影片來看」的工具。我們可以先利用數據找到值得調查的區域，再用 Replay Vision 將畫面中的行為轉換成結構化資料，最後重新回到 Insight 或 Dashboard 持續觀察它。
到這裡，我們可以從不同解析度觀察使用者的行為。
Heatmap 讓我們看到很多人在頁面上集中操作哪些位置；Session Replay 則可以還原某一次使用過程；Replay Vision 則進一步把人工觀看 Replay 的過程擴展到大量 Session，將我們關注的行為轉成可以持續分析的資料。
不過這些工具主要仍然是在觀察「發生了什麼」。
假設 Replay 顯示很多使用者在付款前又回到商品頁，我們可以看到他回去了，也可以知道這件事發生得多頻繁，但原因仍然可能很多：商品資訊不夠清楚、想重新確認價格、不信任 Checkout 顯示的資訊，或者單純只是使用習慣。
如果想知道使用者當時為什麼這樣做，光靠行為資料就很難繼續往下推。
下一篇，我們來直接問使用者，也就是 PostHog 的 Survey。
iThome鐵人賽
看影片追技術