站內流量地圖

產品、搜尋、推薦、行銷團隊都想知道「使用者在 App 裡怎麼走」，但每次都得開需求請分析師撈數，問題一換就要重寫一次 SQL。既有報表只看單頁的流量與跳出，看不到頁與頁之間的關係。

更麻煩的是，商品頁內「從一個商品跳到另一個商品」在以頁面切段的資料裡會被合併成同一段，推薦版位的貢獻因此一直被低估。

1. 只算真進站。以「開啟 App」事件界定工作階段，排除推播收到但沒打開的幻影；依啟動來源分成冷啟動、背景喚醒、推播、外部連結四種進站方式。
2. 壓縮停留段。同一頁的連續事件合併成一個停留段；商品頁換商品時另記一次「頁內連逛」，才看得到過去消失的那一段。
3. 判定觸發手段。取換頁前最後一個點擊事件，分成搜尋、推薦、廣告版位、分類瀏覽、交易、功能導航等八類；曝光這類被動事件不參與判定。
4. 疊上價值層。把地圖建成吸收態馬可夫鏈，用 removal effect 估算每一頁對成交的邊際貢獻，避免「大家都會經過」的頁被高估。
5. 做成自己會用的工具。所有彙總在 BigQuery 完成，再由 Python 產生單一 HTML 儀表板，不需要部署伺服器。

-- 同頁連續事件壓縮成停留段（示意）
SELECT session_id, event_ts, page_type,
       COUNTIF(prev_page IS NULL OR page_type != prev_page
               OR item_id != prev_item)
         OVER (PARTITION BY session_id ORDER BY event_ts) AS run_no
FROM (
  SELECT *, LAG(page_type) OVER w AS prev_page, LAG(item_id) OVER w AS prev_item
  FROM app_events
  WINDOW w AS (PARTITION BY session_id ORDER BY event_ts)
)

以上數字皆由模擬資料計算，僅保留分析方法與結論的型態。

它擅長指出問題在哪，不擅長證明改動有效。「逛越多、成交率越高」多半是本來就想買的人會多逛，屬於相關性；要回答效果，仍需要 A/B 實驗。

資料是一週快照，看不到趨勢；粒度停在頁面類型，看不到哪個商品或搜尋詞。我把這些限制寫在儀表板的「口徑與決策」分頁裡，讓每個數字都有出處。