給行銷主管與新手：把數據交接寫成可驗收的六份文件（實作指南）

行銷團隊交接實務：避免只有「兩頁交接」的錯誤做法

交接不是給兩個帳號與一個報表連結就完事；完整應包含六份可驗收的文件與實作演練。本文示範常見但會出錯的做法，並逐項反駁與提供替代方案。

錯誤示範：離職當天只留兩頁紙（帳號密碼 + 報表連結）

看似合理的理由是「資訊簡潔、重點在帳密」，但這種做法會導致權限錯置、歷史資料無法取回、轉換定義不清，結果是新人要花數月重建。替代思路是把交接變成一套可重複驗收的流程，而非一次性的文件傳遞。

一、帳號與權限清冊（不要只傳帳密）

錯誤做法（表面合理）：把帳號與密碼寫在交接頁面或訊息裡，或把廣告帳戶綁在代理商管理帳號下，等有人要換再處理。

為何失準：帳密寫在文件會被複製或截圖，無法控制存取；帳戶若是代理商名下，歷史資料、受眾名單與廣告資產可能無法移轉，造成資料斷裂。

替代方案（實務步驟）：
1. 建立一張「帳號清冊表格」，每列一個帳號，欄位至少包含：平台名稱、帳號所有權登記名稱（擁有者）、目前權限清單、權限層級、付款方式綁定資訊（指向密碼管理工具的條目，而非明碼）。
2. 所有外部代理或外包帳號給予標準權限（非管理員）。公司內保留兩位管理員──行銷主管與資訊或財務，避免單點失效。
3. 每季更新一次清冊，並把清冊放在公司共用雲端（勿使用個人帳號或聊天記錄）。

注意事項：若發現帳戶登記在代理商或前任個人，應儘速備齊公司登記文件與網域所有權證明，向平台申請帳號回復並將付款方式改為公司帳戶（示例採原文建議的做法，具體流程需依平台規範）。

二、事件與轉換定義書（每一個數字都要有來源說明）

錯誤做法：把報表的轉換數字當成理所當然，不把觸發條件、起算日期或是否計入主要轉換記錄下來。

為何失準：沒有開始追蹤時間會誤判趨勢；事件名稱不一致導致不同系統比對錯亂；轉換是否計入主要指標影響 KPI 解讀。

替代方案（文件欄位樣式）：
– 事件名稱
– 觸發條件（例如：表單成功頁載入、按鈕點擊等）
– 觸發位置（網頁路徑或元件位置）
– 開始追蹤日期（務必標註）
– 是否計入主要轉換（是/否）

實作提示：每次新增事件時立即更新定義書；缺少開始日期會使年度或同期比較錯誤（某事件六月才開始追蹤，前五個月不應被計為零）。

三、資料來源對照表（同一指標可能有三個數字，先定義「哪個系統為準」）

錯誤做法：看到廣告後台、網站分析與訂單系統三個數字時，現場討論誰對誰錯，沒有事先的對照規則。

為何失準：三個系統的算法不同，數字皆可能正確但含意不同；沒有事先規則會浪費每月報表討論時間。

替代方案（原則與檢查）：
– 先訂原則：涉及金額以訂單系統為準、涉及用戶行為以網站分析為準、涉及媒體投放效率以廣告後台為準。
– 為每個重要指標寫清楚「以哪個系統為準」與「合理差異範圍」。示例：差異超過兩成需調查，兩成以內視為正常波動（此為原文建議，實際門檻可依公司風險承受度調整）。

實作檢查表：當月差異檢核流程（簡要步驟）
1. 從三系統匯出對應指標原始數據。
2. 比對範圍與時間窗是否一致（含時間區間、時區、歸因模型）。
3. 超出容許差異時執行根因查核並留存紀錄。

四、報表產出說明（把操作步驟寫清楚，並附範本）

錯誤做法：只給一份成品報表讓新人「照著看就會做」。

為何失準：成品看似直觀，但缺乏每一步的系統匯出依據與公式說明，新人無法在遇到例外時自行修正。

替代方案（要包含的內容）：
– 每份月報的完整操作流程：從哪個系統匯出、匯出時的篩選條件（日期、檢視類別）、資料貼到試算表的哪一個分頁、哪些欄位用公式計算、版本管理規則。
– 附上上個月或上季的完整範本檔案，範本勝過文字說明。

可驗收標準：新人在前任在場的最後一週，獨立完成一次完整月報，且產出與範本欄位一致，才算通過。

五、歷史數據封存檔（別只相信平台的保存期限）

錯誤做法：相信分析平台會永久保存資料，或者只在需要時匯出一次。

為何失準：多數分析平台會有資料保存或匯出限制；沒有定期封存，長期趨勢與同期比較會缺失。

替代方案（年度封存清單）：
1. 每年底匯出三份原始資料：分月的流量與來源、分月的轉換與事件、分月的廣告花費與成效。
2. 存成試算表，放在公司共用雲端資料夾（非個人帳號），檔名前加上編號與更新日期。

價值揭示：原文指出這件事的價值大多在第三年才顯現（原文估算），用以做同期比較與長期趨勢分析。

六、待辦與已知問題清單（把前任腦袋裡的坑寫出來）

錯誤做法：以為交接文件涵蓋所有，沒有把那些暫時的 workaround 與已知誤差寫下來。

為何失準：許多錯誤只存在前任腦袋裡，沒有書面化導致問題重複發生。

替代方案（寫法與欄位）：
– 每條問題應包含：問題描述、影響範圍、暫時處理方式、建議根本解法、提出日期與責任人。
– 多少條合理？原文提到通常有十到二十條（依實務情況而異）。

實務建議：在交接的前兩週開始持續記錄，想到一條寫一條；交接驗收時由接手者逐條確認是否能複現或已解決。

交接驗收與演練（實作重於簽收）

錯誤做法：以簽收文件為交接完成的證明。

為何失準：簽收只能驗證文件存在，無法證明接手者能操作或資料能重現。

替代方案（驗收流程，步驟化）：
1. 在前任在場的最後一週，要求接手者以自己的帳號獨立產出一份完整月報。過程中遇到的每個障礙都要立刻補進文件。
2. 權限演練：用接手者帳號登入每一個平台，確認功能與操作權限（包括匯出、設定事件、檢視付款資訊等）。
3. 完成後由行銷主管、資訊或財務其中一人簽章（系統記錄或文件備註），表示操作權限與報表產出都驗收通過。

補充（無前任或突發離職時的重建順序）：
– 優先順序：拿回帳號所有權 → 重建事件定義 → 補回歷史資料。帳號所有權最急，因為牽涉付款與資料取用權限。
– 拿回所有權的實務做法：備妥公司登記文件與網域所有權證明，向平台提出帳號回復申請，並把付款方式改為公司帳戶。
– 重建事件定義可採反推法：查看分析後台事件清單，檢視觸發次數與對應頁面，再在網站上實際操作確認對應行為。原文示例：二十個事件大約要花六小時，過程中可能發現三到五個可停用的事件。

存放位置、更新頻率與安全細節（不要放在個人雲端或聊天群）

存放：開公司共用資料夾，六份文件各自一檔，檔名加編號與更新日期，權限給行銷主管、資訊、財務三個角色。
更新頻率範例（可寫在資料夾第一頁）：
帳號清冊：每季一次
事件定義書：新增事件時當下更新
資料來源對照表：每年一次
報表說明：每次改版時更新
封存檔：每年底一次
已知問題清單：隨時更新
密碼處理：文件內不要寫明碼，改為指向密碼管理工具條目；密碼管理工具可在離職時一鍵移除存取權。
個資處理：表單內的姓名、電話、電子郵件等個資在封存或交接時需遮蔽或另行存放，存取權限僅給必要人員。

限制 / 例外：若公司與外部代理有合約規範帳戶所有權或工具存取，交接流程需先檢視合約條款；技術細節（例如平台特定的帳號回復流程、API 權限）需依平台官方文件操作，本文提供通用實務指引而非平台手冊。

常見問答（FAQ）

Q1：交接完成的最低可驗收標準是什麼？
A1：接手者能用自己帳號獨立完成一次完整月報並能登入各平台執行所需操作，且帳號清冊與事件定義書都已更新。

Q2：如果發現廣告帳戶在代理商名下，應該怎麼做？
A2：儘速備齊公司登記與網域證明，向平台申請帳號回復，並將付款方式改為公司帳戶；同時把此流程與所需文件寫入帳號清冊步驟中。

Q3：資料來源三方數字差異超過兩成，該怎麼辦？
A3：按資料來源對照表的檢查流程逐步比對時窗、歸因設定與匯出篩選，記錄調查結果並納入月報備註；若頻繁異常，進行更深入的資料稽核。

Q4：離職前只剩兩天能交接，該優先做什麼？
A4：優先確認帳號所有權與付款方式，至少把帳號清冊更新並把敏感密碼移至密碼管理工具，然後把事件定義的關鍵轉換（top 3）寫清楚。

Q5：六份文件需要多少時間可以完成？
A5：原文估算完成六份文件約需十六個小時（此為估算值，實際時間依公司規模與複雜度不同，需由讀者驗證）。

結語

把行銷數據交接從「一張紙的希望」變成「可驗收的流程」，關鍵在於把經驗化為文件、把文件做成可操作的步驟，並以演練驗收。這樣新人不必花三個月重建記憶庫，組織也能保有數據連續性。

若需更深入的實作協助或範本，我們在服務頁提供相關諮詢與工作坊，也有案例可參考（見下方連結）。

延伸閱讀：

參考資源：Web.dev