前面介紹 Product Analytics 時，我們需要先決定想回答的問題，再建立對應的 Insight。

但對網站來說，有一部分資訊其實非常固定，例如有多少人進站、看了哪些頁面、從哪裡進來、使用什麼裝置等等。如果每次都自己建立 Insight 會有點麻煩，因此 PostHog 另外提供 Web Analytics，直接把常見的網站分析整理在同一個頁面中。

下面是目前的 Web Analytics 主畫面。

• Visitors：這段時間有多少不同訪客。
• Page views：總共產生多少次頁面瀏覽。
• Sessions：這些瀏覽被分成多少個 Session。
• Session duration：Session 平均持續多久。
• Bounce rate：有多少 Session 被 PostHog 判定為 Bounce。PostHog 的 Bounce 會考慮是否只有單一 Pageview、停留時間很短，而且沒有其他互動。

這些可以幫助我們迅速的掌握狀況，可以考慮將觀察此圖表列為例行公事。

Paths、來源、裝置與地區

Paths 直接按照網址路徑列出 Visitors、Views 和 Bounce Rate。從這裡可以先知道流量主要集中在哪些頁面，而且每一列右邊都有 View recordings，需要時可以直接往 Session Replay 看。

再往下，左邊是 Sources by Channel。目前用 Channel 分組，可以看到 Organic Social、Direct、Organic Search、Referral、Paid Search 等來源各自帶來多少 Visitors 和 Views。這個區塊也可以切換其他來源拆分方式，例如 Referring Domain 或 UTM。

右邊的 Devices by Device type 則把 Mobile、Desktop、Tablet 分開，下面還有 Geography Map。這些資料的用法很直接：同一批網站流量可以再依照來源、裝置、國家等條件拆開來看。

例如某個頁面整體看起來沒有什麼異常，但 Mobile 的表現和 Desktop 差很多，就可以再加上 Device Filter 往下查。來源也是一樣，如果某段時間流量突然增加，可以先看是哪個 Channel 或 Referrer 增加。

再下面還有 Retention 和 Active hours。Retention 前面已經另外花一篇介紹過，這裡顯示的是網站訪客後續有沒有再回來；Active hours 則是把一週七天和 24 小時畫成 Heatmap，可以看到訪客通常集中在哪些時間出現。

畫面裡的 Track your conversions 是另一個可以自行設定的區塊。設定一個 Action 作為 Conversion Goal 後，就能在 Web Analytics 裡一起觀察完成這個行為的訪客與轉換率。這部分和前面 Funnel、Activation 的概念有不少重疊，這裡先知道 Web Analytics 也能把 Conversion 放進同一頁即可。

Frustrating Pages

再往下其實還有一小塊 Error Tracking。這個功能 Day 4 已經介紹過，Web Analytics 這裡只是把近期的 Error、影響使用者數與發生次數列出來，可以直接進 Error Tracking 繼續查。

比較值得另外講的是下面的 Frustrating Pages。

從截圖可以看到，它不是列 Exception，而是按照 URL 整理三個數字：

• Rage clicks：使用者在同一個位置快速重複點擊。
• Dead clicks：使用者點了一個看起來可以互動、實際上沒有反應的地方。
• Errors：這個頁面發生的 Exception。

這個表補上 Error Tracking 看不到的一部分。

例如按鈕其實有成功送出 Request，只是畫面沒有 Loading，使用者不知道到底有沒有按到，於是又連點了很多次。這種狀況不一定會產生 Exception，但很可能留下 Rage click。

Dead click 也很常出現在介面提示不清楚的地方。例如一個 Card 長得很像可以點，實際上沒有 Link，使用者按下去就會留下這類訊號。

判讀 Frustrating Pages 時，要注意這裡顯示的是發生次數。一個流量很大的頁面自然比較有機會累積 Rage click 或 Error，所以不能只看到第一名就直接認為它最糟。可以先回到上面的 Paths 看這個 URL 有多少 Visitors / Views，再決定它到底值不值得優先處理。

另一個很方便的地方是右邊同樣有 View recordings。看到某個 URL 的 Rage click 特別多時，可以直接打開對應的 Session Replay，看使用者當時實際在點什麼。

這裡也剛好能和前面一直提到的 Signal 接起來。Rage click 告訴我們「這裡可能有問題」，但它沒有告訴我們問題是 Loading 太久、按鈕壞掉、文案看不懂，還是其他原因。Replay 可以再把這個範圍縮小。

Session Replay 後面還會另外介紹，這裡先記得 Frustrating Pages 可以幫我們找到值得看的 Page 和 Recording 就好。

Web Vitals

Web Analytics 上方還有一個獨立的 Web vitals Tab。

網站工程師對 Web Vitals 應該不會太陌生，所以這裡不再重新介紹 LCP、INP、CLS 分別在量什麼。如果不熟悉，可以先參考這篇文章：https://ithelp.ithome.com.tw/articles/10363193

畫面右上角可以選 P75、P90 或 P99。這裡的 Percentile 不是平均值，例如 P75 可以理解成：有 75% 的測量結果落在這個值以下。比起直接平均所有人的結果，這種表示方式比較不容易被少數極端值影響。

上方四張卡分別是 INP、LCP、FCP 和 CLS，PostHog 也直接用綠、黃、紅標出 Good、Needs Improvement 和 Poor。以圖中的 P75 為例，LCP 和 FCP 是綠色，INP 已經進到 Needs Improvement，CLS 則落在 Poor。

點選其中一個指標後，下方會顯示它的趨勢。圖中選的是 INP，所以除了實際數值之外，也能直接看到 200ms 與 500ms 兩條分界線。這樣除了知道現在屬於哪一級，也能觀察問題是一直存在，還是最近才開始變差。

再往下是 Path Breakdown。這裡會按照目前選擇的指標，把不同 Path 分到 Good、Needs Improvement、Poor，並顯示各頁面的實際結果。

這個部分對工程師來說比只看全站數字更有用。假設整體 INP 落在 Needs Improvement，但 Path Breakdown 顯示只有某一類頁面特別差，那接下來要處理的範圍就很明確，不需要把整個網站都當成效能問題來查。

另外，PostHog 收集的是實際使用者瀏覽時產生的 Web Vitals。找到有問題的 Path 之後，再回到 DevTools、Lighthouse 或其他 Performance Tool 找真正的原因就可以了。

Page reports

另外一個 Tab 是 Page reports，可以指定單一 Page，取得和 Web Analytics 主畫面類似、但只針對該頁面的完整報表。需要特別分析某個 Landing Page、文章或其他頁面時再進來看即可。

到這裡，我們已經可以從 Web Analytics 看到網站的流量、熱門頁面、來源、裝置，以及一些和使用體驗有關的資訊。

其中 Sources 看起來也回答了「使用者從哪裡來」這個問題。不過，這裡顯示的是一次 Session 的來源，不見得等於真正讓使用者知道產品的地方。

例如使用者先在 X 看到別人介紹產品，過幾天自己搜尋品牌名稱，最後從 Google 進站。Web Analytics 看到的可能是 Organic Search，但真正讓使用者第一次知道產品的是前面的 X 貼文。

這就會進入下一篇要討論的 Attribution：我們究竟應該怎麼判斷一個使用者是從哪裡來的？

如果你願意花 30 秒留下回饋，我會用這些意見來調整後續文章：分享你的意見