今天要聊什麼？

上一篇談了搜尋、情境文章、商品照片牆與推薦，這些入口讓使用者開始搜尋與探索，接下來我們還得知道，他們能不能順利找到商品、查看資訊，再往購買走。這一篇我們想討論這個問題：

當使用者找不到商品、點了卻沒反應時，我們要留下哪些紀錄，才能還原過程、查出原因，並確認改動真的改善了體驗？

我們在意什麼使用者體驗？

同樣是「沒有前往購買通路」，背後可能是搜尋根本找不到商品，也可能是文章已經引起興趣，商品入口卻不好操作。只看最後的點擊數，我們很難決定該補選品、改搜尋，還是調整介面。

以選物網站為例，我們在意三件事：

1. 找得到：帶著明確需求進來的人，能不能找到符合需求的商品？
2. 找到靈感：還沒有目標的人，能不能透過文章與選物，找到想進一步了解的商品？
3. 走得下去：有興趣之後，能不能順利查看資訊、前往通路，繼續做購買判斷？

這裡可以做一個以終為始的練習：先想像使用者在找商品、看介紹或前往通路時可能卡在哪裡，再問「如果明天真的有人遇到，我們有足夠的紀錄還原這次操作嗎？」這個練習一方面幫我們從使用者的角度檢查整段流程，一方面也讓每個追蹤欄位都有要回答的問題。

下面我們用案例來走過「體驗卡住 → 決定要記什麼 → 查核原因 → 確認改善」的過程：

1. 一個人得換句話搜尋，才找得到露營杯；
2. 另一個人看了「週末早餐桌」，卻要點三次才能打開商品。

例子一：為什麼要換個說法，才找得到杯子？

假設一位使用者想找露營時可以帶出門的不鏽鋼杯。他輸入「露營用的不鏽鋼杯」，畫面顯示沒有結果，必須要改搜「不鏽鋼隨行杯」之後才看到相對應的商品。

最後雖然有商品點擊，使用者卻得多試一個說法，才找到原本想找的杯子。使用者用自己的需求搜尋，就能找到合適的商品，才是我們想改善的體驗。要主動發現這種問題，不能只記最後的點擊，還得留下操作前後的細節。我們大致可以整理成以下三種路線：

1. 請求或呈現沒有完成？記錄搜尋成功、失敗或降級狀態、後端結果數，以及畫面實際呈現的商品。後端有結果卻沒顯示，就先查呈現流程。
2. 請求正常，但條件偏離需求？核對查詢原文、使用者選的條件與系統實際套用的條件，確認商品是否被錯誤排除。
3. 請求與條件正常，但沒有找回合適商品？用查詢與商品識別值，接回商品收錄、檢索紀錄與當時使用的資料版本，分清楚沒有這類選品，還是有商品卻沒被找回。

這些資訊要透過搜尋識別值 search_id 串聯某次查詢、結果與點擊，再用造訪識別值 session_id 接起前後兩次搜尋。有了這些紀錄，就能主動找出「零結果後，在同次造訪中重新搜尋」的操作，再查是搜尋出了問題還是使用者改變了需求。

假設我們資料中看到了以下的資訊：

{
  "session_id": "visit-camping", "environment": "production",
  "searches": [
    {
      "at": "10:14:00", "search_id": "q1",
      "query": "露營用的不鏽鋼杯", "status": "ok",
      "result_count": 0, "displayed_product_ids": []
    },
    {
      "at": "10:14:20", "search_id": "q2",
      "query": "不鏽鋼隨行杯", "status": "ok",
      "result_count": 2, "displayed_product_ids": ["steel-cup", "steel-cup-with-lid"]
    }
  ],
  "click": {
    "at": "10:14:25", "search_id": "q2", "product_id": "steel-cup"
  }
}

搜尋狀態與結果數來自後端，呈現與點擊來自前端。先核對第一次搜尋：請求正常完成，後端回傳零筆，前端也完成了空結果畫面的呈現。這次沒有服務失敗，也沒有「後端有商品、畫面卻漏掉」的落差，而是搜尋本身就已經沒有找到對應的商品。再核對第一次搜尋：使用者要找不鏽鋼杯，解析出的材質與實際套用的篩選都是「不鏽鋼」，商品也符合條件。第二次搜尋能找到兩件商品，而且它們的商品介紹都帶有「露營」用途，讓我們有理由繼續查第一次搜尋的檢索過程，確認它們為什麼沒有被找回。

我們接著沿著 search_id = q1 查檢索（retrieval）紀錄，確認商品有沒有進入候選集合。仔細檢查後發現，正式環境（production）的商品文字已更新到第 8 版，向量表示（embedding）卻仍依第 7 版文字產生；測試環境（staging）則已經用第 8 版文字產生新版向量。發布紀錄也顯示，正式環境的向量發布失敗。這表示新版商品文字雖然已經上線，對應的向量卻還沒進入正式環境的搜尋流程。

{
  "search_id": "q1", "product_id": "steel-cup",
  "request": { "status": "ok", "result_count": 0 },
  "render": { "status": "completed", "displayed_count": 0 },
  "filters": {
    "parsed_material": "不鏽鋼", "applied_material": "不鏽鋼",
    "product_matches": true
  },
  "retrieval": { "candidate_found": false },
  "staging": { "text_revision": 8, "vector_source_revision": 8 },
  "production": { "text_revision": 8, "vector_source_revision": 7 },
  "production_update": { "text": "completed", "vector_publish": "failed" }
}

把依新版商品介紹產生的向量發布到正式環境後，保持原本查詢與篩選不變，再搜一次「露營用的不鏽鋼杯」，確認使用者不必換句話，就能找到原本想找的杯子。這個例子把排查走了一次：先分開檢查請求與呈現、條件、檢索，用紀錄排除前面的問題，再追到向量部署更新失敗，最後用原本的操作確認修正。

例子二：為什麼點了照片，卻看不到商品？

現在我們來看另外一個案例：使用者打開「週末早餐桌」的情境文章，看到一只想進一步了解的不鏽鋼杯。他點了商品照片後畫面沒有變化，又點一次還是留在文章裡，沒有跳到商品頁，往下找到「查看商品」的文字連結之後，第三次點擊才成功打開商品資訊。

看到有興趣的杯子後，點預期的入口就能查看商品，才是我們想改善的體驗。最後那一次成功的連結點擊，沒有告訴我們前面兩次操作為什麼沒反應。這次也沿著流程拆開檢查：先確認照片有沒有呈現，再查點擊與導頁，最後查商品資訊是否載入。

1. 照片沒有呈現或進入畫面？需要文章、段落、商品與可見性資訊，或操作回放（session replay）中的畫面。文章開過，不代表這張照片被看到。
2. 照片已呈現，但點擊沒有啟動導頁？需要點擊對象、位置與導頁事件，分清楚點的是照片、文字連結，還是其他區域。
3. 導頁已啟動，但資訊沒有載入？需要目標網址、載入狀態與商品頁呈現紀錄，也保留裝置與介面版本，才能查載入失敗或特定版本的問題。

這些紀錄也要接回同一次造訪、同一篇文章與同一件商品。否則我們只會看到幾次點擊，無法判斷它們是一次操作裡的重試，還是不同訪客各點一次。排查時，可以先找出照片反覆被點擊、畫面卻沒有變化的片段，再回放核對位置。這能讓我們主動找到可能的介面障礙；點擊本來就不該導頁的區域，也可能出現相同訊號，因此還得檢查入口設計。

{
  "session_id": "visit-breakfast", "article_id": "weekend-breakfast",
  "product_id": "steel-cup",
  "ui_check": {
    "photo_visible": true, "photo_href": null,
    "text_link_href": "/products/steel-cup",
    "click_intercepted": false
  },
  "actions": [
    { "at": "21:05:00", "action": "article_presented" },
    {
      "at": "21:05:08", "action": "click", "target": "product_photo",
      "navigation_started": false
    },
    {
      "at": "21:05:10", "action": "click", "target": "product_photo",
      "navigation_started": false
    },
    {
      "at": "21:05:14", "action": "click",
      "target": "product_text_link", "navigation_started": true
    },
    { "at": "21:05:15", "action": "product_page_presented" }
  ]
}

先看回放，我們已知照片已經出現在畫面裡，而且被點了兩次，可以排除照片尚未呈現的情況。再核對導頁事件，照片點擊後沒有啟動導頁；文字連結卻能啟動導頁，一秒後商品資訊也成功呈現，因此這次先查照片入口，而不是商品頁載入。

回到相同介面版本檢查元素，照片的連結目標是空的，文字連結則指向 /products/steel-cup；點擊也確實落在照片上，沒有被覆蓋層攔截。這些證據接起來才確認原因是照片沒有接上商品入口。若照片原本有連結，就要繼續查事件攔截或導頁錯誤，不能只憑畫面沒變就套用同一個結論。

讓照片與文字都連到同一個商品頁，並保留清楚的「查看商品」文字，示意如下：

<a href="/products/steel-cup">
  <img src="/images/steel-cup.png" alt="查看不鏽鋼杯商品資訊">
</a>

這個例子同樣從分層檢查走到修正：先確認看得見，再分開查點擊、導頁與載入，用回放和介面紀錄找到缺少的連結，最後重試原本想點的照片。修正後仍要觀察更多造訪，確認問題是否持續出現；一次成功操作，也不能當成整體購買表現提升的證明。

把紀錄接起來，找出值得改善的體驗

兩個例子都讓我們從使用者卡住的地方，倒推出需要留下的證據。實際設計追蹤時，事件（event）記錄發生的動作，事件屬性（event properties）保存當時的脈絡；要能還原過程，每筆紀錄至少得回答以下問題：

• 做了什麼、涉及什麼？記下搜尋、商品點擊或前往通路等動作，以及商品、文章等穩定識別值。
• 從哪裡來、當時有什麼條件？保留搜尋查詢與篩選，或文章主題與段落；需要排查介面時，再補上裝置與版本。
• 前後操作怎麼接起來？用發生時間、造訪識別值與搜尋識別值，連回同次操作的前後紀錄。
• 操作完成了嗎？分開記錄點擊、導頁啟動與資訊呈現，才能知道使用者停在哪個環節。

紀錄接得起來之後，就能看同樣的障礙是否反覆出現，我們可以用路徑分析查看實際操作，再用漏斗（funnel）觀察「閱讀文章 → 查看商品 → 前往通路」在哪一步沒有繼續，從中挑出值得查的造訪，回到回放與系統紀錄確認原因。分析前先核對事件有正常送出，避免把漏記當成流失。

這段流程可以交給現有工具協助，選擇時就拿前面的兩個案例試跑，看能不能從紀錄找到相關造訪，再回到操作畫面：

• PostHog：目前專案已用它做事件追蹤，可以先補上事件關聯，並設定需要的操作回放，把一個問題從發現查到原因。
• Mixpanel：能用事件、漏斗與族群比較觀察不同入口的表現，再從分析結果查看操作回放，適合拿來試跑「哪些造訪卡住，再看當時怎麼操作」的流程。
• Fullstory：可用回放與反覆點擊、點擊後沒有變化等摩擦訊號，挑出像照片入口沒反應的片段，再核對介面。

下一篇：商品資料改了，搜尋什麼時候才會更新？

追蹤設計要從想改善的體驗出發，留下能還原操作、查核原因的紀錄，再重走使用者原本的任務，確認改動是否解決問題。露營杯的例子也把我們帶到資料更新的落差：商品介紹已經補上露營用途，搜尋卻還在使用舊版向量。使用者在商品頁看到的新資訊，需要經過哪些步驟，才能進入搜尋？

下一篇會沿著這件杯子的更新流程，先看資料新鮮度如何讓搜尋跟上新版介紹，再看索引如何加速候選查找。資料要先跟得上，接著才是怎麼找得更快。