Looker Studio 報告指南：5 頁 KPI、7 步流程與 12 項交收清單
直接答案：Looker Studio 報告適合需要定期把 GA4、Google Ads、Search Console、試算表或 CRM 數據放在同一決策畫面的中小企。它可以減少每月人手複製數字，統一 KPI 名稱並讓不同角色查看相同版本；但如果轉化追蹤本身錯誤、CRM 沒有合資格查詢或成交狀態、團隊未定義指標，Dashboard 只會更快展示不完整數據。正確次序是先定義業務問題及數據責任，再接駁、驗收和視覺化。
Looker Studio 報告是否適合你的公司？
| 情況 | 適合程度 | 原因 | 先做甚麼 |
|---|---|---|---|
| 每月要合併兩個或以上渠道 | 適合 | 可用連接器建立多個 data source，減少重複匯出 | 先統一日期、貨幣、campaign ID 與 KPI 名稱 |
| 管理層只需固定查看核心數字 | 適合 | 可建立管理摘要、日期及渠道篩選 | 限制第一頁為 6 至 10 個真正會引發行動的 KPI |
| 網站事件或表單追蹤未驗收 | 暫不適合 | 視覺化不會補回漏發、重複或錯誤事件 | 先用測試個案驗證 GA4、廣告及 CRM |
| 只有瀏覽量，沒有查詢質素或成交資料 | 只適合流量層 | 無法由訪客直接推斷有效商機或收入 | 在 CRM 建立合資格、報價、成交及流失狀態 |
| 期望所有平台數字完全相同 | 不適合此期望 | 平台在事件、身份、時區及歸因上可以合理不同 | 列明每個數字的來源、範圍和用途 |
| 沒有人負責權限及維護 | 高風險 | 連接器失效、員工離職或欄位變更會令圖表中斷 | 指定業務 owner、技術 owner 及備援帳戶 |
Google 官方把 data source 定義為外部資料與報告圖表之間的管道；連接器負責接駁 GA4、Google Ads、Sheets、BigQuery 等來源。大部分來源維持即時連線並按需要查詢，Extract data 則是可更新的靜態快照。換言之，Looker Studio 是呈現與輕量建模工具，不等於 CRM、資料倉庫、會計系統或獨立歸因平台。
先分清四層數據角色
| 數據層 | 回答問題 | 常見來源 | 不可直接當作 |
|---|---|---|---|
| 投放 | 用了多少預算、買到多少曝光及點擊？ | Google Ads、Meta Ads | 實際網站工作階段或成交 |
| 網站行為 | 用戶到站後看了甚麼、觸發甚麼事件？ | GA4、GTM、網站後台 | 全部廣告平台歸因或合資格商機 |
| 搜尋可見度 | 哪些查詢及頁面有 Google 自然搜尋曝光？ | Search Console | 完整網站流量或已成交收入 |
| 商業結果 | 哪個查詢成為合資格機會、報價及成交？ | CRM、訂單、POS、會計或受控試算表 | 平台自行估算的轉化功勞 |
| 管理視圖 | 本期結果、原因、異常及下一步是甚麼？ | Looker Studio | 原始數據唯一來源 |
每張圖表都應標示 source、scope、時區、貨幣、更新頻率及 last refreshed。GA4 官方亦提醒，User acquisition 使用 first-user scope，Traffic acquisition 使用 session scope，即使指標名稱相近，數值也不應在沒有範圍說明下直接比較。
常用報告欄位英文對照
| 欄位 | 中文工作定義 | 使用提醒 |
|---|---|---|
| Sessions | 工作階段 | 不是廣告點擊，也不是獨立使用者 |
| Engaged sessions | 有參與的工作階段 | 應列明採用的 GA4 定義及日期 |
| Total users | 總使用者 | 受身份與量度方法影響 |
| New users | 新使用者 | 不要與 first-time CRM leads 混用 |
| Key events | 已標記為重要的事件 | 不一定等同合資格查詢或成交 |
| Session source / medium | 工作階段來源／媒介 | 適合 Traffic acquisition 分析 |
| First user source / medium | 首次使用者來源／媒介 | 屬 first-user scope，不應與 session scope 混算 |
| Campaign ID | 穩定活動識別碼 | 比可變 campaign name 更適合對接 |
| Cost per lead | 每個查詢成本 | 先定義 lead 是否包含垃圾及重複查詢 |
| Qualified lead | 合資格查詢 | 要有明確準則及 CRM 狀態 |
| Opportunity | 銷售機會 | 列明何時由 lead 轉為 opportunity |
| Revenue | 收入 | 分清訂單金額、已收款及平台估算價值 |
| Data freshness | 資料更新門檻 | 不等同底層平台完成處理的時間 |
| Owner’s Credentials | 資料憑證擁有者授權 | 分享前核對接收者及最少權限 |
| Viewer’s Credentials | 檢視者自行授權 | 每位檢視者要有原始 dataset 權限 |
中小企 Dashboard 應保留哪些 KPI？
| 頁面 | 核心指標 | 切分維度 | 要回答的決策 |
|---|---|---|---|
| 1. 管理摘要 | 花費、合資格查詢、成交／收入、每個合資格查詢成本、資料完整率 | 月份、服務、地區 | 結果是否達標？哪個問題需要先處理？ |
| 2. 渠道與活動 | 曝光、點擊、sessions、engaged sessions、key events、成本 | source、medium、campaign ID | 哪個渠道帶來有效流量及商機？ |
| 3. Landing Page | sessions、CTA、表單、WhatsApp、電話、轉化率 | 頁面、裝置、來源 | 哪頁有流量但未能推動下一步？ |
| 4. 銷售漏斗 | 新查詢、合資格、報價、成交、流失、回應時間 | 渠道、服務、負責人 | 問題在獲客、篩選、跟進還是成交？ |
| 5. 數據質素 | (not set)、Unassigned、缺失成本、重複 leads、連接器錯誤、更新時間 | 來源、日期、負責人 | 目前有多少數字不應用來做決策？ |
避免把所有可取得的指標塞入首頁。管理摘要應先展示結果、差距及行動；診斷指標放在後頁。每個比率要有清楚分子與分母，例如「Landing Page 表單轉化率 = 成功提交表單數 ÷ 該頁 sessions」，不要在同一張表把 ad clicks、GA4 users 和 CRM leads 混成一條沒有共同範圍的漏斗。
7 步建立可交收的 Looker Studio 報告
1. 先寫管理問題
每個 KPI 都要對應一個決策，例如「是否增加某活動預算」、「哪個 Landing Page 先改」或「哪類查詢需要改善跟進」。沒有人會因數字變動而採取行動的圖表，可以刪除。
2. 建立數據字典
逐項記錄名稱、業務定義、公式、來源、scope、更新頻率、owner、適用限制及例子。GA4 dimension 與 metric 並非全部兼容；連接前應用官方 Dimensions & Metrics Explorer 或實際查詢驗證，而不是把空白圖表當成零。
3. 指定共同鍵
跨平台合併至少要有可管理的日期、campaign ID、lead ID 或 order ID。名稱只供人閱讀，穩定 ID 才適合對接。先制定 UTM 及 CRM 規則，避免同一活動因大小寫或別名變成多行。
4. 選擇連接與建模方式
原生連接器適合 GA4、Google Ads、Search Console 及 Sheets 等常見來源；Community Connector 的費用、權限、支援與資料處理要另行審核。Looker Studio 可在一個 blend 合併最多五個 data sources，但複雜多對多關係、歷史快照、成本分攤或大量資料，應考慮先在受控試算表、資料庫或 BigQuery 建模。
5. 先做最小可用版本
先完成管理摘要、渠道、Landing Page、漏斗及數據質素五頁；確認有決策價值後才增加圖表。Calculated field 可建立比率、分類及條件邏輯，但公式要放入數據字典，避免每張圖各自計算出不同版本。
6. 用固定測試個案驗收
選一個日期、一個 campaign、一條 lead 及一宗訂單，由原始系統逐層對數。驗收不只看總數，亦要測試日期篩選、渠道篩選、零值、缺失值、時區邊界、貨幣、連接器失效及沒有權限的使用者。
7. 設定月度治理
每月記錄新欄位、公式變更、異常、已知限制及修正人。報告需顯示資料更新時間；不同 connector 可用的 freshness 選項不同，Dashboard 顯示最新不代表底層平台已完成處理。
權限與資料安全應如何設定？
Looker Studio 的 data credentials 決定誰可以看底層數據。Owner’s Credentials 讓檢視者使用 credential owner 的授權看報告，檢視者不一定需要原始 dataset 權限；Viewer’s Credentials 則要求每位檢視者本身有 dataset 權限。Google 明確提醒：分享使用 Owner’s Credentials 的報告前，要信任獲分享人士。
- 使用公司管理帳戶，不以離職風險高的個人 Gmail 作唯一 owner；
- 檢視、編輯、資料來源及原始系統權限分開，採最少權限；
- 不在報告展示姓名、電話、電郵或逐筆敏感資料，除非有明確業務及私隱依據；
- Community Connector 要先核對供應商、授權範圍、資料位置、費用及停用安排；
- 每季檢查分享連結、群組成員、credential owner、失效連接及備援 owner。
常見症狀與診斷方法
| 症狀 | 較可能原因 | 檢查 | 處理 |
|---|---|---|---|
| 圖表顯示 No data | 欄位不兼容、篩選衝突、權限或連接器失效 | 由單一 dimension／metric 開始逐項加入 | 修正 scope、filter 或重新授權 |
| 總數比原平台高 | blend join 產生多對多重複列 | 比較 join key 唯一性及原始列數 | 先聚合到共同粒度再合併 |
| 廣告與 GA4 轉化不同 | 事件、身份、時區、歸因或處理時間不同 | 固定日期、事件及 campaign 逐層對數 | 分開「平台優化」與「商業結果」視圖 |
| 資料好像未更新 | freshness、底層處理延遲或 cached result | 查看 last refreshed 與原平台資料時間 | 按 connector 規則刷新並註明延遲 |
| 某同事看不到數據 | Viewer’s Credentials 或 dataset 權限不足 | 核對 data credentials 及原始來源權限 | 按安全需要調整權限，不共享帳戶 |
| 員工離職後報告壞掉 | 唯一 credential owner 被停用 | 盤點全部 data source owner | 交接 credential、備援 owner 及文件 |
每月 30 分鐘報告會議應該點開？
Dashboard 的價值不在於「有圖」，而在於縮短由異常到決定的時間。會前由數據負責人完成更新及 QA；會議只處理需要選擇、負責人和期限的項目。建議固定使用同一議程，避免每月因某個數字升跌便臨時改 KPI 或重新定義成功。
| 時間 | 問題 | 所需證據 | 會議輸出 |
|---|---|---|---|
| 首 5 分鐘 | 數據是否完整及可用？ | last refreshed、連接器、缺失率、已知異常 | 列明本月不可採用的數字 |
| 第 6 至 10 分鐘 | 商業結果與目標差多少？ | 合資格查詢、報價、成交、收入及同期比較 | 選出一個首要差距 |
| 第 11 至 18 分鐘 | 差距較可能在哪一層？ | 渠道、Landing Page、查詢質素及銷售漏斗 | 提出可驗證原因，不即時當作結論 |
| 第 19 至 25 分鐘 | 下一個最小行動是甚麼？ | 預算、頁面、素材、追蹤或跟進流程 | 一項變更、一位 owner、一個完成日期 |
| 最後 5 分鐘 | 怎樣知道行動有效？ | 基準值、目標、觀察期及停損條件 | 寫入 change log 及下次覆核日期 |
例如「表單數下降」不代表立即加廣告預算。先確認流量有沒有下降、Landing Page 是否正常、表單事件有沒有漏發、查詢是否轉到 WhatsApp，再看合資格率及成交。若同時改預算、素材、頁面和銷售流程，下月即使數字改善也難以判斷原因。
另一個常見情境是點擊與 sessions 增加，但合資格 leads 沒有增加。這時應按 campaign、搜尋字詞、Landing Page、裝置及表單答案分層，判斷是錯誤受眾、頁面承諾不一致、垃圾查詢，還是 CRM 分類未更新。Looker Studio 報告應把「要再查證」與「已確認原因」分開顯示，避免視覺上的相關性被誤當因果。
會後紀錄至少要寫低：觀察到的數據、目前解釋、仍待確認的證據、已批准行動、負責人、完成日期、預期影響及覆核日期。若下一次會議仍只重複討論同一異常而沒有責任人或驗收結果，問題通常不在 Dashboard，而在決策流程未真正落地。
交收前 12 項清單
- 報告、data source 及原始資料的 owner 已列明；
- 每個 connector、帳戶、property 及表格範圍已登記；
- KPI 字典包含公式、scope、時區、貨幣及限制；
- UTM、campaign ID、lead ID 與 order ID 規則一致；
- 已用固定個案對回廣告、GA4、CRM 或訂單；
- 日期、渠道、裝置及服務篩選均已測試；
- 零值、缺失值、錯誤值與 No data 顯示方式已定義；
- 每頁有清楚目的、資料來源與 last refreshed；
- 檢視者與編輯者權限分開，沒有公開敏感資料；
- credential owner 離職或被停用時有接管流程；
- 有版本紀錄、每月 QA 負責人及修正期限；
- 已列明 Looker Studio、connector、BigQuery 或維護的持續成本。
常見問題
Looker Studio 報告是否免費？
不要只用授權費判斷總成本。實際成本可能包括初次設定、付費 Community Connector、BigQuery 查詢、資料整理、維護、QA 及 Looker Studio Pro。簽約前應逐項列明一次性與持續費用，而不是假設「有 Dashboard 就沒有維護成本」。
Looker Studio 可否取代 GA4？
不可以。GA4 負責收集及處理網站／App 事件；Looker Studio 透過 data source 查詢並展示結果。事件沒有發送、同意設定不完整或維度定義錯誤，Looker Studio 不會自動補救。
可否把 Meta、Google Ads、GA4 與 CRM 放在同一圖？
可以，但先要有共同粒度及穩定 key，亦要接受各來源定義不同。簡單彙總可用 blend；涉及多對多、歷史快照、跨渠道身份或財務核數時，先在資料層建模會較可靠。
Dashboard 幾耐更新一次才合理？
按決策頻率而定。投放監察可能每日或更頻密；管理層商業結果通常每週或每月已足夠。Google 官方列明不同 connector 的 data freshness 選項不同；更新頻率愈高也可能增加查詢成本或 quota 壓力，並不代表數據更準確。
官方參考：Google Cloud：Looker Studio data sources、Data credentials、Manage data freshness、How blends work、Calculated fields、GA4 data compatibility及 User acquisition 與 Traffic acquisition。
如渠道命名未統一，先閱讀 UTM 參數設定指南；如 Meta 與 GA4 數據不同，參考 Meta Pixel 與 GA4 對數指南；如要管理供應商月報，可閱讀 Google Ads 代投報告指南。需要把渠道、網站與銷售資料整理成可行動報告，可了解 ITOB Group 數碼營銷服務。
編輯與審閱：ITOB Group 編輯團隊；由 ITOB Group 數碼營銷顧問團隊審閱。最後實質更新：2026 年 7 月 20 日。
本文依據 Google Cloud、Google Analytics 官方資料及 ITOB Group 的報告規劃與驗收流程整理。產品功能、連接器、權限、費用與介面會更新；Dashboard 只反映可取得及已定義的資料，不保證完整量度、固定歸因、查詢或收入結果。詳見編輯政策與資料更正原則。
