網站有流量無查詢診斷指南：7 層漏斗、30 日優化與 12 項驗收
直接答案：網站有流量無查詢，不應第一時間再買流量或重做全站。先確認查詢是否真的沒有被記錄，再逐層檢查流量意圖、Landing Page 配對、服務與報價說明、信任證據、手機體驗、CTA、表單、私隱說明及跟進流程。最有效的診斷不是看整站「轉化率」一個數字，而是找出訪客在哪一層停止，以及哪些來源、頁面、裝置與客戶類型出現問題。
網站有流量無查詢：先用 7 層漏斗定位
| 層次 | 要回答的問題 | 主要證據 |
|---|---|---|
| 1. 進站 | 哪些人由甚麼來源進入哪一頁？ | GA4 Landing Page、來源／媒介、UTM |
| 2. 意圖 | 訪客正在找答案、比較方案，還是準備查詢？ | 搜尋字詞、廣告訊息、頁面主題 |
| 3. 理解 | 首屏能否說清對象、問題、方案與下一步？ | 頁面訊息、錄影／訪談、客服問題 |
| 4. 信任 | 訪客有沒有足夠理由相信公司與承諾？ | 公司資料、案例、流程、限制、評論來源 |
| 5. 行動 | CTA 是否可見、清楚而符合訪客準備程度？ | CTA click、scroll、裝置測試 |
| 6. 提交 | 表單是否可用、合理、安心及成功送達？ | form_start、form_submit、端到端測試 |
| 7. 成交 | 查詢有否入 CRM、獲回覆、合資格及轉為商機？ | generate／qualify／working／close lead |
若第一層有足夠且合適的訪客，但第五至第七層沒有數據，問題可能是量度或營運；若第二、三層已不配對，縮短表單通常也救不到結果。
第一步：確認「零查詢」不是量度錯誤
- 逐一測試網站表單、電話、電郵、WhatsApp、預約及下載等查詢入口；
- 確認成功頁、通知電郵、垃圾郵件匣、CRM、Webhook 及自動化紀錄；
- 在手機、桌面、主要瀏覽器及無痕模式提交測試查詢；
- 檢查 GA4 Realtime／DebugView 是否收到相應事件，並避免同一提交重複計算；
- 把測試 Lead 標記清楚，再確認前台訊息、內部通知、分派與回覆全部完成。
Google Analytics 的自動表單互動可以提供 form_start 與 form_submit 訊號，但實際網站可能因 AJAX、嵌入式表單、Consent 或技術配置而需要額外驗證。合資格查詢應另以 Google 建議的 generate_lead 及後續 Lead 狀態事件量度。
建立一張可診斷的 Landing Page 表
GA4 Landing Page report 顯示每個工作階段最先到達的頁面。加入 Session source／medium，再按 Campaign、Device category、Country 或 Region 分段；不要把首頁、文章、服務頁及廣告 Landing Page 混成一個平均數。
| 欄位 | 用途 | 判讀例子 |
|---|---|---|
| Landing Page | 找出訪客第一個看到的答案 | 文章有流量，但服務頁沒有入口 |
| Source／Medium／Campaign | 分辨自然、廣告、電郵、社交及合作來源 | 展示廣告帶來大量低意圖訪客 |
| Device | 找手機與桌面差距 | 手機開始表單多，提交卻少 |
| CTA click／form_start | 分辨訊息問題與表單問題 | CTA 點擊正常但沒有人開始表單 |
| generate_lead | 確認有效提交 | 提交事件有，但 Lead 沒入 CRM |
| qualified／opportunity | 連接市場推廣與銷售質素 | 查詢多但目標客戶不合 |
若渠道命名不一致，先用UTM 與 GA4 命名指南統一資料，再建立Looker Studio 管理報告。
流量質素：訪客是否帶着正確意圖進站？
「流量多」不等於「潛在客戶多」。把自然搜尋查詢、Google Ads 搜尋字詞、Meta 受眾與創意承諾、Referral 來源及內容主題，對照公司真正服務的地區、預算、規模、決策角色及採購時程。
- 資訊意圖：只想了解定義或教學，適合提供下一步資源，不宜直接逼預約。
- 比較意圖：正在比較方法、供應商、費用與風險，需要流程、差異、案例及評估清單。
- 交易意圖：已有問題與時程，需要清楚服務範圍、所需資料、聯絡方法及回覆安排。
- 不合資格意圖：求職、免費工具、學生功課、不服務地區或預算完全不符，應在廣告、內容及表單前置篩選。
廣告、搜尋結果與 Landing Page 是否訊息一致？
訪客點擊前看到的關鍵字、標題、廣告創意或社交貼文，必須在 Landing Page 首屏得到一致答案。若廣告說「Google Ads 審核」，頁面卻只寫「一站式數碼營銷」，訪客需要重新猜測，流失並不意外。
逐一核對：服務名稱、目標客戶、地區、問題、交付成果、限制、CTA 與預期下一步。廣告活動可連同Google Ads 轉化追蹤指南驗證，不應只以平台點擊或表面 Lead 數作結論。
首屏要在數秒內回答哪四件事？
- 為誰：例如香港 B2B 中小企，而不是模糊的「所有企業」。
- 解決甚麼：把具體商業問題放在服務名稱之前。
- 怎樣做：列出可核實的範圍、流程或交付，不使用空泛「全方位」。
- 下一步：說明查詢後會發生甚麼、要準備甚麼及何時獲回覆。
首頁、服務頁與 Campaign Landing Page 的角色不同。需要分工時可參考Landing Page 與服務頁比較，避免所有流量都導向同一個泛用頁面。
服務與 Offer 是否足以讓人作決定？
| 訪客疑問 | 頁面應提供 | 不應用甚麼代替 |
|---|---|---|
| 是否適合我？ | 客戶條件、適用／不適用情況 | 「任何行業都適合」 |
| 會做甚麼？ | 範圍、交付、里程碑、雙方責任 | 一串服務名稱 |
| 多久及怎樣開始？ | 合理時程、所需資料、啟動步驟 | 無條件保證即時見效 |
| 費用如何形成？ | 定價因素、最低條件或報價流程 | 「歡迎查詢」四字 |
| 風險是甚麼？ | 限制、假設、依賴及不保證項目 | 隱藏所有限制 |
信任證據要真實、具體及可核對
公司名稱、地址、聯絡方法、團隊責任、服務流程、編輯政策及資料更正方法是基本實體訊號。案例應說明背景、工作範圍、量度口徑、時間及限制；如客戶名稱不可公開，可匿名但不應虛構數字、標誌或評語。牌照、認證、合作夥伴與獎項應連到可核實來源並標示年份。
對高考慮服務，訪客通常還需要知道誰負責、如何溝通、哪些工作不包括、失敗時如何處理。可信度來自可核實細節，不是增加更多「最佳」「領先」形容詞。
手機速度與互動是否阻礙 CTA？
用真實裝置檢查首屏、選單、字體、鍵盤、彈窗、Cookie banner、sticky bar、電話及 WhatsApp 按鈕。Google 的 Core Web Vitals 以 LCP、INP、CLS 分別量度載入、互動與視覺穩定，應以真實用戶資料的第 75 百分位、並分手機與桌面判讀；單次 Lighthouse 分數只適合作為實驗室診斷。
- 首屏主訊息或 CTA 不應被大型圖片、彈窗或 Consent 完全遮蓋；
- 點擊按鈕後要有即時狀態，避免訪客重複提交；
- 表單錯誤應指向具體欄位並保留已填資料；
- 避免版面移動令訪客誤按，或輸入時被 sticky 元件遮擋；
- 不要只測公司 Wi-Fi 與最新手機。
CTA 問題：不是越多按鈕越好
每頁設定一個主要下一步，再按訪客準備程度提供次要選項。例如主要 CTA 是「預約 20 分鐘需求評估」，次要 CTA 可以是「下載準備清單」或「查看服務範圍」。按鈕文字要說明結果，而不是所有位置都寫「了解更多」。
CTA 前後應補充預期：需要填多少資料、會否即時報價、由誰回覆、一般回覆時段，以及不會發生甚麼。電話與 WhatsApp 需在手機可直接使用，但亦要保留可追蹤及不依賴單一平台的聯絡方法。
表單長度應由銷售需要決定
| 欄位 | 保留條件 | 改善方法 |
|---|---|---|
| 姓名／公司 | 回覆與 B2B 分派需要 | 說明用途，避免重複輸入 |
| 電郵／電話 | 至少一個可靠回覆渠道 | 容許合適格式，清楚錯誤訊息 |
| 服務興趣 | 能改變負責人或回覆內容 | 用少量清楚選項 |
| 預算／時程 | 確實用於資格與方案 | 提供範圍及「未確定」 |
| 自由描述 | 讓客戶補充真正問題 | 給提示但不要求長文 |
| 敏感資料 | 首輪確有必要且合法 | 通常延後到安全流程收集 |
少欄位不一定較好；若因此收到大量不合資格查詢，銷售與客戶都浪費時間。每個欄位都要回答：「不用這項資料，能否完成首次回覆？」不能回答便考慮刪除或延後。
表單私隱與安心訊號要放在提交位置
香港私隱專員公署（PCPD）對《個人資料（私隱）條例》的概覽指出，DPP1 要求個人資料只可為與資料使用者職能或活動直接相關的合法目的收集；資料須必要、足夠但不超額，並須以合法、公平方式收集。直接向當事人收集時，應告知資料供應屬必須或自願、使用目的、可能接收資料的類別，以及查閱和改正權利與方法。若資料另用於直接促銷或轉交第三方作促銷，DPP3 另有同意要求，應按實際資料流程核對。PCPD：《個人資料（私隱）條例》概覽（DPP1–6）
私隱連結、公司身份、安全傳輸及提交後處理說明應在表單附近可見。本文只提供網站診斷框架，不是法律意見；實際聲明應按業務、資料流程及適用要求由合資格人士核對。
由表單開始到 CRM 的端到端測試
- 建立標記為測試的 Lead，記錄時間、頁面、來源、裝置及 consent 狀態。
- 確認瀏覽器顯示成功訊息，而且重新整理不會重複送出。
- 確認 GA4 只記一次正確事件，事件帶有需要而非敏感的參數。
- 確認表單資料進入正確 CRM 欄位，UTM 與 Landing Page 沒有遺失。
- 確認通知送達正確 owner，沒有落入垃圾郵件或未分派佇列。
- 確認自動回覆內容、承諾與實際服務一致。
- 由銷售實際更新 working、qualified、disqualified、opportunity 與結果。
自動分派與培育可參考Marketing Automation、CRM 與 Lead Nurturing 指南；Pipeline 階段及治理可參考CRM 銷售流程指南。
GA4 漏斗應怎樣設定？
Google 的 Funnel exploration 可以把一組事件或條件排列成步驟，並查看每步完成及流失。可建立「Landing Page view → CTA click → form_start → form_submit／generate_lead」的網站漏斗，再以裝置、來源、Campaign 或 Landing Page breakdown。若只想分析由指定入口開始的完整旅程，可用 closed funnel；若使用者可能在中段進入，可另建 open funnel比較。
漏斗最多可定義十個步驟，但不要為追求完整而混入不能可靠量度的事件。網站漏斗之後應接 CRM 的 qualified、working、opportunity 及 won；否則改善的可能只是表單提交，不是商業結果。
症狀對應根因與下一個測試
| 症狀 | 較可能根因 | 先做的測試 |
|---|---|---|
| 流量高、CTA 點擊低 | 意圖、首屏、Offer 或信任不配 | 按來源／頁面分段，重寫一個訊息假設 |
| CTA 點擊高、form_start 低 | 按鈕目的不清、表單載入或轉頁問題 | 真機點擊及網絡／錯誤測試 |
| form_start 高、submit 低 | 欄位、錯誤、私隱、手機或技術阻力 | 逐欄位與裝置測試 |
| submit 有、CRM 沒 Lead | Webhook、通知、欄位 mapping 或垃圾郵件 | 端到端測試及 log |
| Lead 多、合資格少 | 定位、關鍵字、承諾或資格條件錯 | 按來源回看 disqualify reason |
| 合資格多、成交少 | 回覆、銷售流程、方案或價格問題 | Pipeline aging 與失單原因 |
CRO 測試如何避免誤判？
每次測試先寫一個可被推翻的假設，例如：「手機訪客看不到首屏 CTA，將 CTA 移到服務利益後會增加合資格的 form_start。」同時定義主指標、質素指標及 guardrail，例如 generate_lead 上升但 disqualified lead 不可惡化。
- 不要同時更改標題、價錢、表單、版面及流量來源後宣稱知道原因；
- 不要因三兩個提交便宣布勝出，低流量網站可先做可用性測試及訪談；
- 測試跨越完整的銷售與星期周期，標記節日、Campaign 與網站事故；
- 保留版本、開始／結束日期、分流方法、數據口徑、結果及決定；
- 即使提交率改善，也要追到合資格、商機與成交。
30 日優化次序
- 第 1–3 日：完成所有查詢入口的端到端測試，修復遺失 Lead、重複事件及 P0 技術問題。
- 第 4–7 日：建立 Landing Page × Source × Device 表，找出最大流失與最高商業價值組合。
- 第 8–14 日：訪談銷售與近期客戶，重寫一個高價值頁面的首屏、Offer、證據及 CTA。
- 第 15–21 日：改善手機、表單、私隱說明與 CRM 分派；保留前後版本及測試紀錄。
- 第 22–30 日：評估 generate、qualified、opportunity 及副作用，再決定擴展、修改或回復。
12 項發布與驗收清單
- 每個查詢入口已用手機及桌面完成真實端到端測試。
- Landing Page、來源、Campaign、裝置及 Lead 結果可以連接。
- form_start、form_submit 與 generate_lead 定義清楚且不重複。
- 首屏清楚交代對象、問題、方案與下一步。
- 廣告／搜尋訊息與 Landing Page 承諾一致。
- 服務範圍、流程、限制、時程及定價因素可核對。
- 案例、評論、認證及數字沒有誇大或虛構。
- 主要 CTA 明確，次要 CTA 不會互相競爭。
- 表單每個欄位都有首次回覆或資格判斷用途。
- 私隱與個人資料收集資訊在提交位置容易找到。
- Lead 有 owner、回覆標準、狀態及失單／不合資格原因。
- 每次測試有假設、版本、日期、主指標、質素指標及決定。
常見錯誤
- 見查詢少便增加廣告預算，令低質流量與浪費同步增加；
- 只看全站平均，忽略高意圖頁面及手機訪客的具體問題；
- 把每個按鈕點擊都當 Lead，沒有驗證提交與 CRM 收件；
- 用假倒數、假名額、假評論或保證結果製造壓力；
- 只縮短表單，不處理服務不清、缺乏信任或回覆過慢；
- 大量發布換行業名的服務頁，沒有獨立證據與實際差異；
- 測試只追提交率，沒有追合資格、商機、成交及客戶價值。
常見問題
網站轉化率應該達到多少？
沒有適用所有網站的標準。渠道、意圖、服務價值、地區、頁面角色、裝置及 Lead 定義都會改變數字。先建立自己的合資格 Lead 基準，並在相同口徑下比較。
應該先改網站還是先增加流量？
先確保量度、查詢入口及高意圖頁面可正常轉化；否則增加流量只會放大未知問題。若現有流量本身不合資格，則要先修定位與獲客來源。
表單越短是否一定越多查詢？
不一定。短表單可能增加提交，也可能增加垃圾或不合資格 Lead。保留首次回覆真正需要的資料，並同時看提交完成率與 Lead 質素。
WhatsApp 可否代替表單？
可以是其中一個選項，但不宜成為無備援的唯一入口。要處理工作時間、分派、記錄、私隱、歸因及 CRM 同步，並提供電郵或表單等替代方法。
官方參考：Google Analytics：Landing Page report、Google Analytics：Funnel exploration、Google Analytics：Recommended events、web.dev：Web Vitals及香港私隱專員公署：《個人資料（私隱）條例》概覽。
需要把查詢質素變成共同定義，可配合Lead Scoring 指南；自然流量本身下跌時，另用自然流量下降診斷指南；考慮外部團隊前可用數碼營銷外判與代理商評估指南核對責任與驗收。
編輯與審閱：ITOB Group 編輯團隊；由ITOB Group 數碼營銷顧問團隊審閱。最後實質更新：2026 年 10 月 5 日。
本文按 Google 官方量度文件、香港私隱專員公署指引及 ITOB Group 的網站、分析、CRM 與內容治理驗收方法整理，不構成法律意見、轉化率或業績保證。實際結果受服務、流量、網站、團隊、需求、價格及銷售流程影響；上線前應先備份並按實際環境測試。詳見編輯政策與資料更正原則。
