網站自建流量後台
一個人或小團隊要看自己網站的數據，怎麼做得準、便宜，而且能回答「訪客到底卡在哪」這種真正該問的問題。這份是實作完兩個站之後的完整記錄，包含做得到的、做不到的，以及六個踩過的坑。
這個方案要解決什麼
大部分網站裝了 Google Analytics 就算有數據了。它能回答「多少人來、看哪幾頁、從哪裡來」，這些問題它答得比自建的好。
但有一種問題它答不了：訪客在你的頁面上，跟站內的 AI 客服問了什麼。
這件事在 2026 年變得重要，因為愈來愈多網站掛了 AI 助理。訪客不再只是看完就走，他們會問。而他們問的內容，是這個網站最直接的缺口清單：有人在課程頁反覆問「指令在哪」，代表那頁的指令不好找；有人在首頁一直問「什麼是知識庫」，代表首頁沒講清楚。
一句話
這個方案不是要取代 Google Analytics，是補上它拿不到的那一半：把流量跟站內 AI 對話放在同一個後台，交叉來看。
四種做法的能與不能
每一格都是實際做過或實測過的結果，不是規格書上的說法。
| 能回答的問題 | GA4 | Cloudflare | Vercel | 自建 |
|---|---|---|---|---|
| 多少人來、看哪幾頁 | 可以 | 可以 | 可以 | 可以 |
| 從哪個網站來的 | 最完整 | 可以 | 可以 | 只記主機名 |
| 停留多久、捲到哪 | 可以 | 沒有 | 沒有 | 沒有 |
| 訪客在這一頁問了 AI 什麼 | 拿不到 | 拿不到 | 拿不到 | 只有這個做得到 |
| 資料能不能程式撈回來 | 有 API | 要另開權杖 | 無公開 API | 自己的 |
| 會不會被廣告封鎖器擋 | 會 | 會 | 會 | 不會 |
| AI 爬蟲來讀幾次 | 量不到 | 量不到 | 量不到 | 量不到 |
| 要不要處理同意 | 要 | 較低 | 較低 | 較低（不等於不用） |
最後兩列要特別講
AI 爬蟲都不執行 JavaScript。GPTBot、OAI-SearchBot、PerplexityBot、ClaudeBot 全都是。所以任何靠前端埋點的工具，包含 GA4 和自建這套，都看不到它們來過。「在 robots.txt 放行 AI 爬蟲」的成效，要從伺服器端日誌才量得到。
能量到的是另一半：有人從 ChatGPT 或 Perplexity 點連結進來時，來源網站會顯示那個平台。這一項自建有做，而且獨立成一組。
至於「不會被廣告封鎖器擋」，原因是自建的請求打的是自己的網域，不是第三方腳本。這讓它在總量上反而比 GA4 準。
「要不要處理同意」那列，初稿寫成自建「不用」，跨家審查指出太絕對：自建雖然沒用 cookie，但在瀏覽器存了隨機識別碼，在歐盟 ePrivacy 規範下原則上仍需告知與同意，只是「純統計、第一方、不跨站」比較容易主張豁免，不是免除。
三層結構
缺任何一層，後台都只是空殼。
| 層 | 做什麼 | 技術 |
|---|---|---|
| 埋點 | 每次有人開頁面就記一次，含每頁每日的時間趨勢 | 一支 Serverless Function ＋ 一支前端 JS |
| 對話記錄 | 站內 AI 客服的每一句問答落地，含在哪一頁問的 | 一支 Function ＋ 改 AI 客服元件 |
| 後台 | 密碼門後面的儀表板，圖表與明細 | 一支 Function ＋ 一頁 HTML ＋ 一支 JS |
資料放哪
Serverless Function 加上一個 Redis。不用資料庫伺服器、不用後台管理系統。資料結構自己定，所以要撈什麼就撈什麼。
多個站可以共用同一個 Redis，靠 key 前綴隔離。但這一句有代價，風險那節會講。
後台實際長什麼樣
- 日期範圍查詢：近 30 天、3 個月、半年、一年、全部，或自選起訖
- 指標卡：這段期間對比前一段等長期間、平均每天、幾個人來過、AI 答不出來的比例
- 兩張趨勢圖：每日瀏覽、每日提問。分開畫不共用 Y 軸，因為量級差十倍以上
- 頁面排行，以及期間動能榜：這段期間排前面但累計不高的，就是正在被看的新內容
- 問題意圖排序、意圖佔比隨時間變化、頁面乘以意圖的熱區矩陣，點格子連動明細
- 訪客清單，點開才展開那個人的完整對話串，跨頁跨天串在一起
- 異常訊號：有人試探 AI 護欄、同一句話被重問、AI 答不出來的比例偏高
- 統計機制自我檢查：這些數字本身可不可信，哪些頁漏埋點，什麼沒在記
錢不是問題，維護才是
以每次瀏覽 10 個指令估，免費額度大約可支撐每月五萬次瀏覽。兩個站合計目前每月不到四千次，離上限還很遠。
真正的成本是維護責任：出問題沒有人會通知你。這點在風險那節攤開講。
六個踩過的坑
全部是實作這兩個站當天踩到的，不是想像的風險。
Serverless 裡沒有 await 的非同步操作會靜默消失
設定資料過期時間那行忘了 await，本機測完全正常（Node 會等事件迴圈清空），上線後就是沒生效。Serverless 函式在回應送出後會被凍結，沒 await 的操作不保證送得出去。
預設看「當月」會在月初整個垮掉
八月測的時候完全正常，因為八月已經過完。九月一號打開就變成：趨勢圖只有一個孤點、對話只剩一則、還顯示「比上月少 99%」這種假訊號，因為拿沒過完的一天去比上個月一整個月。
後台自己也會污染數據
後台頁如果跟著全站載入埋點，站長每看一次自己的數據，就替自己的流量加一次。站內 AI 客服也一樣，在後台試問幾句就混進統計。
垂直文字不要再轉 180 度
熱區矩陣的欄位標題用 writing-mode: vertical-rl 本身就是由上往下讀，再加 rotate(180deg) 會變成由下往上、字還是倒的。
時間戳只記到分鐘，問答會排反
資料庫的清單是新的在前，而時間戳只到分鐘，所以同一分鐘內的問與答只靠時間排序，會排成「AI 先回答、訪客後提問」。
try/catch 會把失敗吞成無聲
解析來源網站用了 new URL()，線上永遠寫不進去，但同一個程式區塊裡的另一個操作卻正常。查證過：程式碼確實上線、本機邏輯正確、手動打資料庫指令也正常。唯一的差別就是那個建構子，而它被包在 try { } catch { } 裡，拋錯之後變數保持空字串，沒有留下任何痕跡。
這套方案的弱點
這一節是跨家 AI 審查時被指出來的，原本的方案沒有處理。
最大的風險不是不準，是靜默漏數
自建的資料只有一份，放在免費方案的 Redis 上，沒有備份、沒有服務保證、沒有告警。埋點壞掉的那天，後台會顯示 0，而 0 跟「那天真的沒人來」長得一模一樣。
不準你知道要打折。靜默漏數你會以為那是事實，然後拿它做判斷。上一節第六個坑就是活例子，那個問題沒有任何機制會通知，是回頭去查才發現的。
該補的三件
- 異常歸零告警：前七天有流量、昨天是 0，就是壞了，要有人知道
- 每日備份：把彙總資料匯出到 Redis 以外的地方
- 月度對帳：跟另一套追蹤工具比一次，差太多代表有一邊壞了
第三件正好是「不要把既有的第三方追蹤拆掉」的理由。留著它就是對帳的基準。
2026-09-07 補上的四件
告警與備份同一支腳本，每天早上九點自動跑，正常就安靜，有紅燈才通知。月度對帳改成半自動：每月一號腳本先把自建的月總量填進對帳表，人只填另一邊的數字，程式算差異，不為了自動抓第三方數字多開一組權杖。另外補了原始對話的保存期限：每月一份，該月結束後保留一年就自動刪除，之前只有筆數上限。
多站共用一個資料庫的代價
用 key 前綴隔離只防名稱撞在一起，不是安全隔離。兩個站共用同一組存取金鑰，任何一站的金鑰外洩或被濫用，另一站的資料與額度會一起受害。
判準：站的擁有者是同一個人、金鑰都在自己手上、規模都不大，共用可以接受。替客戶做、跨組織、或任何一站會交給別人維護，一律分開開資料庫。
什麼時候不該用這個方案
- 只想要一個總瀏覽數：放一個計數器就好，不用做後台
- 站上沒有 AI 客服：這個方案最大的價值消失了，用現成的分析工具更省事
- 需要完整的行為分析：停留時間、捲動深度、轉換漏斗，這套都沒有
- 沒有人能維護：出問題沒有客服可以問，也沒有人會通知你
- 要做給客戶看的成效報告：後台是自己看的，資料原貌都在。給別人看的成效頁是另一件事
兩個站的真實數據
知識官網
自建埋點是這個站最早的一套追蹤，比 Cloudflare Analytics 早 52 天。上線時順手掃出六篇文章頁與兩個課程頁從來沒引入埋點，流量一直記為零，看起來像沒人看，其實是沒在數。
八月的對話資料：152 則訪客提問、65 段對話、36 個瀏覽器。其中一整輪是有人在系統性地試探 AI 的護欄，要求輸出系統設定、宣稱自己是管理員。這件事沒有後台就完全不會知道。
後台實際長這樣，六張都是 2026 年 8 月的真實畫面：
永續影響力報告書網站
這個站原本就有 Google Analytics，而且有每 10 天自動匯出到雲端試算表。缺的一直是後台，不是埋點。
把 GA4 的歷史匯進自建的資料庫：2026-06-01 到 08-30 共 83 天、956 次瀏覽。每日總數是精確的；每頁的數字是近似值，因為來源是每 10 天一次的前十名快照，加總約佔總量 96%，缺的是每期十名以外的長尾。
匯入歷史資料的三條規矩
- 精確與近似要分開講，兩者都匯，但頁面上要標明哪個是近似的
- 不要覆蓋自建已經記到的數字，先讀出當前值再加上去
- 資料來源的分界要寫在頁面上，中間空缺的那一天也要講，不要讓看的人以為那天真的沒人來