前兩篇講了 CRM 會碰到哪些資料，以及行為紀錄怎麼產生。這些資料各自住在不同系統裡：消費紀錄在 ERP，開信紀錄在 EDM 系統，退訂紀錄可能在 EDM 也可能在會員中心。
要撈一份名單，它們就得搬到同一個地方。這篇講怎麼搬。
先講一個常見的誤會：這不是在選技術，是在選「這份資料多晚到可以接受」。 同一家公司裡，消費紀錄晚一天到通常沒關係，退訂紀錄晚一天到就可能寄錯人。所以一家公司常常同時用好幾種方法，每一類資料用最適合它的那一種。
六種方法
1. 匯出檔案。 來源系統定時匯出 CSV，放到共用位置，目標系統定時匯入。最古老，也最常見。好處是兩邊完全不用認識對方，只要約好檔案格式。壞處是慢，而且格式一改，對方隔天才會發現。
2. 直接讀對方的資料庫。 目標系統（或 ETL 工具）直接連來源系統的資料庫，定時查詢「上次之後新增或修改的資料」。很快就能做起來，但等於把對方的資料表結構當成合約。對方改一個欄位名稱，你的同步就壞了，而且常常是「靜默地壞」：不報錯，只是資料不見。Logstash 從 MySQL 同步到 Elasticsearch 就是這種做法，實際會踩到哪些坑，可以看（Logstash JDBC 同步的七個坑）。
3. 呼叫對方的 API。 需要資料時，直接問對方的 API。資料永遠是最新的，因為每次都是當下去問。代價是對方掛了你也跟著掛，而且不適合大量資料：要撈十萬個會員的消費紀錄，一筆一筆問會非常慢。
4. Webhook。 反過來，由來源系統在事情發生時主動通知你。例如會員在 EDM 系統點了退訂，EDM 系統立刻打一個 HTTP 請求到你的會員中心。即時，但你要處理「對方通知了但你剛好掛了」的情況，也要驗證這個通知真的是對方發的（見Webhook 設計：發送可靠性與接收安全驗證）。
5. 事件與訊息佇列。 來源系統把「發生了什麼」丟進一個訊息佇列，需要的系統各自去訂閱。跟 Webhook 一樣即時，但來源不用知道有誰在聽，多一個系統要用也不用改來源。代價是多一套基礎設施要維運，而且要處理重複送達和順序問題（見從 API 到 MQ 的七站投遞路徑、Consumer 端冪等性）。
6. CDC（變更資料擷取）。 不改來源系統的程式，直接從資料庫抓出每一筆變更。以 Debezium 為例，它「記錄每張表每一列的變更，輸出成變更事件流」，讀的人可以依變更發生的順序看到它們（Debezium 文件）。適合「來源系統是舊的、不能改、但又需要即時資料」的情況。
比一比
| 方法 | 資料多晚到 | 兩邊綁多緊 | 壞了誰先知道 | 適合 |
|---|---|---|---|---|
| 匯出檔案 | 小時到天 | 很鬆，只約定格式 | 常常是隔天用資料的人 | 大量、不急、跨公司 |
| 直讀資料庫 | 分鐘到小時 | 很緊，綁對方的表結構 | 常常沒人知道 | 快速上線、短期過渡 |
| 呼叫 API | 即時 | 中，綁對方的 API 合約 | 呼叫的那一方，馬上 | 少量、要最新值的查詢 |
| Webhook | 即時 | 中 | 要看有沒有重試和紀錄 | 單一事件要立刻通知 |
| 事件佇列 | 秒級 | 鬆，來源不用知道誰在聽 | 要監控佇列堆積 | 多個系統都要知道同一件事 |
| CDC | 秒級 | 綁資料庫結構，但不用改程式 | 要監控延遲 | 舊系統、不能改程式 |
表裡的「多晚到」是常見的量級，不是保證值，實際要看排程和系統負載。
照資料的性質選
回到CRM 會碰到的四類資料，每一類適合的方法不一樣：
- 身分：變動不頻繁，但合併規則複雜。通常用匯出檔或事件同步到負責合併的那一層，不建議每個系統各自直讀。
- 交易：量大，分群時多半看彙總。用匯出檔或 CDC 進資料倉儲，在那裡算好再給 CRM。
- 互動：量最大。直接進資料倉儲，CRM 只拿算好的指標。
- 同意與偏好：量最小，但一定要即時。用 Webhook 或事件，退訂一發生就通知唯一的來源系統。這一類不能用一天一次的匯出檔。
你會發現，最即時的需求反而落在資料量最小的那一類。這也是為什麼不能「全公司統一用一種方法」。
反方向：算好的名單推回去
前面講的都是資料「搬進來」。撈名單還有一個反方向：在資料倉儲算好的名單，要推回 CRM 或 EDM 系統，行銷才能在熟悉的介面上用。
這個方向有人叫它 reverse ETL。技術上它跟前面六種是同一套方法，只是方向相反。要特別注意的是 I01 講過的那個坑：推回去的名單不能覆蓋掉退訂紀錄。 推回 EDM 系統之前，要用唯一的同意來源再過濾一次。
搬完之後：怎麼知道搬對了
不管用哪種方法，都會遇到同一個問題：資料搬了，但有沒有搬完整、有沒有搬對？
我經歷過的系統，前面六種裡用過三種：匯出檔案、直讀資料庫或 ETL、API 或 Webhook。同步壞掉的經驗也有，而且是用資料的人先發現的，不是負責同步的那一方。回頭看上面那張表的「壞了誰先知道」那一欄，這其實是最常見的情況：沒有刻意設檢查，最先發現的就是拿資料做事的人。
最基本的檢查是對帳：兩邊各算一個數字，例如「昨天的訂單筆數」「昨天的消費總額」，對不上就告警（見對帳不是會計的事）。直讀資料庫和 CDC 特別需要這一步，因為它們壞掉時常常不報錯。
這部分下一篇會完整談。
AI 和 MCP 的角色
MCP 本身也是一種資料交換方法：它最接近第 3 種「呼叫 API」。AI 需要資料時，透過 MCP 當下去問系統。
所以第 3 種方法的優缺點，MCP 全部都有：
- 好處：拿到的是當下的值，不會是昨天的副本。
- 代價：不適合大量資料。讓 AI 透過 MCP 撈十萬筆會員明細，又慢又耗資源，也不需要。比較好的設計是 MCP 工具在系統內部算好，只回人數或摘要。
- 對方掛了你也掛：MCP 背後的系統沒回應時，AI 要能說「查不到」，而不是用舊的印象回答。
另一個實用的方向是讓 AI 幫忙讀懂現有的資料流。一家公司用了哪些交換方法、哪些資料從哪裡到哪裡，常常沒有人畫得出完整的圖。把各系統的排程設定、ETL 腳本、Webhook 設定交給 AI 整理，產出一張資料流的地圖，是很省時間的起點。
相關主題
- ETL：資料搬運與轉換：ETL 的冪等、重跑、checkpoint
- Outbox pattern：事件和資料庫寫入怎麼保持一致
- 下一篇：怎麼觀察資料有沒有正常進來