重點觀察
點任一列看完整說明
- 活躍使用者
- —
- 新使用者
- —
- 平均參與時間
- —
- 事件計數
- —
活躍使用者
各來源的導流與品質
| 來源平台 | 進站 | 自動跳轉 | 手動點下載 | 手動點擊率 | 參與率 | 實際互動 | 每次頁數 |
|---|---|---|---|---|---|---|---|
| 載入中… | |||||||
自動跳轉=廣告或連結把人直接送到 /get,手機一落地就自動跳到商店。那不是使用者的決定,是我們設計好的動線,所以這一欄只供參考,標 ⚠ 的列代表點擊幾乎全來自自動跳轉。
手動點下載=使用者自己在網站上找到按鈕、伸手按下去。這一欄才代表「被說服了」,也是唯一可以跨來源比較的。
導到 /get 的廣告在「手動」這欄會接近 0,那是正常的 —— 網站沒給他按的機會。那種廣告的成效要看 Play Console 的實際安裝數。
為什麼不看「到達下載頁」了:那個欄位已經移除。廣告和小編連結本來就直接指向 /get,所以「有沒有到達下載頁」在點進來的那一刻就是 100%,比的是連結怎麼下、不是人被說服了沒 —— 實測 IG 付費廣告正是 235 進站/235 到達/100%。改看點商店就沒有這個問題。
右邊三欄輔助判斷品質:參與率(停留 10 秒以上、或看第二頁、或觸發轉換的比例)、實際互動秒數、每次造訪看幾頁。
「實際互動」用的是前景互動時間,不是工作階段時長。工作階段時長算的是「第一個到最後一個事件的時間差」,包含分頁擺在背景沒人看的時間 —— IG 站內瀏覽器會把頁面留在背景,使用者切回 IG 繼續滑,等幾分鐘後真的關掉才送出最後一個事件。於是會出現「停留 9 分鐘但前景互動 0 秒」這種失真數字,實測倍數差到 25000 倍。
UTM 活動成效
| 貼文性質 | 來源平台 | 哪一則 | 進站 | 自動 | 手動 | 手動點擊率 |
|---|---|---|---|---|---|---|
| 載入中… | ||||||
同一則廣告跑在多個版位會合併成一列。Meta 一支廣告常同時投到 Facebook、Instagram、Threads,
對看報表的人來說那是同一則,分開列只會讓人以為成效被稀釋。滑過「來源平台」可看各版位的數字。
名稱出現 %E 或亂碼=廣告名稱太長被截斷。GA4 這個欄位上限 100 字元,
而且算的是編碼後長度 —— 一個中文字佔 9 個字元,所以純中文最多 11 個字。
系統會試著把截斷的那筆接回完整的那一則,但如果從頭到尾都沒有完整版就接不回來,只能改短名稱重投。
一長串數字的活動名稱是廣告平台自動帶進來的編號。要顯示看得懂的名字,
必須在投放後台的網址參數加上 utm_campaign={{campaign.name}},GA4 沒辦法反查。
只列出小編實際加了 utm_campaign 的連結。GA4 自動填的 (referral)、(direct) 不是活動名稱,已濾掉。這張表是驗收 UTM 有沒有落實的地方 —— 小編貼了帶參數的連結,隔天這裡就會出現。
比的是「點擊率」不是「進站」。帶進 40 人有 22 人去商店,勝過帶進 400 人只有 12 人去商店。進站數受預算和粉絲數影響,點擊率才反映貼文本身寫得好不好。
進站數少於 10 的列不標顏色 —— 樣本太小,5 個人裡有 1 個點就是 20%,那不是成效,是運氣。
來源、國家與熱門網頁
流量來源
同一平台的多個網域已合併(Facebook 就有 facebook.com、m.、l.、lm. 四種)。滑過任一列可看實際網域與筆數。
直接進入=沒有帶來源網址:直接輸入、書籤,或從 LINE/Messenger 等 App 內開啟(這些 App 會拿掉 referrer)。
尚未歸因=GA4 還沒把工作階段配到來源,24–48 小時後會自動歸位 —— 所以今天與昨天的來源分布會失真。
使用者 · 依國家
台灣 · 依縣市
台灣 · 依行政區
依 IP 推估,只列得出行政區的部分。同一縣市內解析不到行政區的流量不會出現在這裡。
| 網頁標題 | 瀏覽 | 使用者 | |
|---|---|---|---|
| 載入中… | |||
這張表看的是「哪些頁面被看得多」。跳出率不放在這裡 —— 不是入口的頁面(例如從首頁點進去的文章)跳出率必然趨近 0%,那反映的是「沒人從這裡進站」,不是內容好。要看跳出率請往下。
進站頁面 · 看一眼就走
| 訪客從這裡進站 | 工作階段 | 看一眼就走 |
|---|---|---|
| 載入中… | ||
看一眼就走(GA4 裡叫「跳出率」)= 進來之後停留不到 10 秒、沒有點第二頁、也沒有做任何動作就離開的比例。數字越低越好,一般網站落在 40–60%。只有「進站頁面」算這個才有意義。
商店下載次數為什麼看不到即時數字
Google Play 與 App Store 都沒有提供即時或逐時的下載數 API,這是平台本身的限制,不是設定問題。
| 來源 | 最細粒度 | 延遲 | 取得方式 |
|---|---|---|---|
| Google Play | 每日 | 1–2 天 | Play Console 統計資料匯出到 Cloud Storage 的 CSV |
| App Store | 每日 | 約 1 天 | App Store Connect API 銷售與趨勢報表 |
目前唯一能做到即時、逐時的替代指標是官網的「點擊前往商店」次數 —— 它量的是下載意圖,不是實際安裝,但兩者高度相關,而且能即時反應推廣活動的效果。這需要官網埋一個 store_click 事件,目前尚未埋設。
瀏覽 · 依畫面
事件 · 依名稱
依國家,以及為什麼即時看不到「來源」
GA4 的即時 API 不提供來源/媒介維度,這是 Google 的限制。來源資料請看「網站流量」分頁。
過去 30 分鐘的畫面
| # | 畫面名稱 | 使用者 | 瀏覽 |
|---|---|---|---|
| 載入中… | |||
重點觀察
點任一列看完整說明
- 模型完整下載
- — AI 模型被完整下載的次數
- 模型傳輸量
- —
- 涉及模型
- —
- 快取命中率
- —
模型下載傳輸量
各模型下載明細
| 模型 | 分段 | 完整大小 | 傳輸量 | 完整下載 |
|---|---|---|---|---|
| 載入中… | ||||
完整下載=該模型傳出去的總量 ÷ 模型完整大小。分母是所有分段加起來(直接向來源逐一確認過,不是只算當天出現的分段),所以只抓一半就放棄的人不會被算成一次完整下載。小數代表下載到一半的情形 —— 例如 2.2 就是「2 次完整,外加 1 次抓了兩成」。
灰色那幾列是模型執行時需要的輔助小檔(語音偵測、分詞器等),體積只有幾 MB,不計入上方的完整下載次數。
逐時明細(哪一小時下載了哪些檔案)
| 時段 | 完整下載 | 傳輸量 | 模型 |
|---|---|---|---|
| 載入中… | |||
請求數 · 網頁與模型分開看
一次模型下載會被切成上百個分段請求。混在一起看,會誤以為網站很熱鬧 —— 所以這裡把兩者堆疊分開。點任一根長條,可以拆解那一小時到底在請求什麼。
傳輸量組成、用戶端與狀態碼
| 類型 | 分類 | 傳輸量 | 請求 | 平均 |
|---|---|---|---|---|
| 載入中… | ||||
瀏覽 · 依用戶端
請求 · 依國家
| 狀態碼 | 意義 | 請求 | 占比 |
|---|---|---|---|
| 載入中… | |||
4xx 偏高不一定是網站壞掉。下面把每一個 404 的實際網址列出來並分類。
官網真正的 404
| 網址 | 判定 | 次數 |
|---|---|---|
| 載入中… | ||
預設只列官網真正的錯誤。App 下載模型時的分段探測(下載器要抓到 404 才知道分段結束)和機器人掃描都已排除 —— 前者是設計行為,後者是任何公開網站都有的雜訊。
Cloudflare 與 GA4 的數字為什麼對不起來
會不會被收費
GA4 Data API · 今日配額
Cloudflare Worker · 今日請求
已內建的成本護欄
| 機制 | 作用 |
|---|---|
| 邊緣快取 60 秒(即時) | 十個人同時看,一分鐘只打一次 GA4 |
| 邊緣快取 300 秒(其餘) | 報表本來就有 24–48 小時延遲 |
| 只接受 GET | 沒有任何寫入操作,POST 回 405 |
| 前端零憑證 | 原始碼複製走也拿不到金鑰 |
| 唯讀權杖 | GA4 檢視者、Cloudflare 僅 Analytics 讀取 |
自行查帳單:Cloudflare 頭像 →「帳單」→「訂閱項目」,確認 Workers 為免費方案。Google 這邊沒有帳單這回事。