一頁結論
給不會讀完整份報告的決策者。200 字內，而且必須先講錢。
Deliverable · 健檢交付物
一份報告。但決定它值不值這個價的不是頁數，是寫作規則—— 下面這六條，違反任一條我就重寫。
寫作規則
不是展示查得多仔細。查了三十項只有四項會影響決策，報告就該長得像那四項的報告。
報告結構
給不會讀完整份報告的決策者。200 字內，而且必須先講錢。
哪些期間不可用於評判成效（改版、門市裝修、人員異動），以及本報告使用的 ROAS 口徑定義。放在對帳之前，不是附註——這章決定後面所有數字能不能看。
平台回報 vs 你的訂單系統，逐項差距與判定。差距歸因到各個成因，無法歸因的殘差誠實列出——硬把 100% 拆完是假的。
每條固定八個欄位，格式見下方範例。超過八條會分成「本次要修」與「記錄備查」——一次丟 20 條問題給你，結果是一條都不會修。
含前置依賴與建議排程。只排真的該現在做的。
至少兩項。看起來像問題但不是的東西，以及動了會怎樣。
交付清單、你需自行保管的憑證、權限回收期限、建議的定期複查頻率。
逐條列出查了什麼、判定是通過／問題／不適用。你要看得到「我查了什麼卻沒發現問題」，才知道這份報告的覆蓋範圍。
可重跑的查詢與腳本。你三個月後想自己複查時，從這裡開始。
問題清單的一則
數字與情境為說明用途虛構，不是任何真實客戶的資料或成果。 真實報告中的每一格都會填入你自己帳戶的實測值。
P-01 嚴重度：高
dataLayer 中出現兩筆 purchase，來源分別為 GTM 代碼與網站原始碼內嵌的 Pixel。dataLayer.filter(e => e.event === 'purchase')最後一格是這份報告最容易被跳過、卻最重要的一格。 有些問題修好只是數字變準，成效不會動。 不先說清楚，修完就會變成一場沒有人想承擔的意外。
第 5 章
幾個常見的、看起來像問題但不該動的例子：
為什麼不是問題 這是回傳斷了，不是廣告沒效果。
動了會怎樣 把 campaign 關掉會失去一組實際有在成交的受眾，而且要重新累積學習期。
為什麼不是問題 各平台的歸因窗口不同，同一筆成交本來就會被兩邊各自認領。
動了會怎樣 它們本來就不能相加，沒有東西需要「修」。真要合併看，得改用單一口徑重算，那是另一件事。
先聊 30 分鐘。通話結束你會拿到一份初步判斷——問題可能在哪、值不值得處理。 就算最後沒有合作，那份判斷也是你的。
免費 · 不推銷 · 不適合我會直說