CRM 會碰到哪些資料：身分、交易、互動、同意，各自誰說了算

在 CRM 有兩種那篇，我提到自己用過的 CRM 是請工程師寫 SQL 撈名單。回頭想，那段 SQL 之所以要工程師寫，不只是因為條件複雜，而是它要碰的資料散在好幾個系統裡。

一個很普通的條件：「近 90 天買過保養品、上一檔有開信、而且還願意收行銷信的會員」。這一句話就碰到四個地方：

這四類資料的來源不同、更新頻率不同，最麻煩的是：同一件事，兩個系統可能記得不一樣。

四類資料

類別	例子	通常從哪來	誰說了算
身分	姓名、電話、email、會員編號、生日	會員註冊、POS、官網、APP	要先指定一個系統
交易	訂單、消費明細、退貨、發票	ERP、POS、電商後台	交易系統
互動	開信、點擊、網站瀏覽、客服紀錄	EDM 系統、網站追蹤、客服系統	各自產生它的系統
同意與偏好	是否同意收行銷信、退訂紀錄、偏好的聯絡方式	註冊勾選、退訂連結、客服登記	只能有一個

同一個人，在 POS 留的是手機，在官網註冊用的是 email，在 APP 用社群帳號登入。三個系統各有一筆資料，CRM 要先回答：這三筆是不是同一個人？

這個問題叫身分合併。做不好的後果很具體：

所以身分資料要先指定一個系統當「說了算」的那一方，其他系統的資料以它為準來合併。當資料來源多到 CRM 自己處理不來，就會另外放一層專門做這件事，這一層常被叫做 CDP（顧客資料平台）或主資料管理（MDM）。

這個問題我遇過，當時是用手機或 email 當依據，把重複的人合起來。這是最直接的做法，但它有一個前提：手機和 email 要真的能代表一個人。換了手機號碼、一家人共用一個 email，合併規則就會把不同的人併在一起，或把同一個人拆開。所以合併規則本身也要能被檢查和修正。

消費紀錄是分群最常用的條件，但它不是 CRM 產生的。訂單在電商後台成立、在 ERP 開發票、退貨在客服或 ERP 處理。

這帶來兩個實際問題：

這兩個問題沒有標準答案，取決於名單要多即時、條件要多彈性。這也是下一篇要談的：資料在系統之間怎麼搬。

開信、點擊、瀏覽，每個會員每天都可能產生好幾筆。它們的特性是：

所以互動資料通常不會整批搬進 CRM，而是轉成幾個「有沒有」「幾次」的指標，例如「上一檔有沒有開信」「近 30 天點擊幾次」。

這一類資料量最小，但出錯的代價最大。

個人資料保護法第 20 條規定：非公務機關用個人資料行銷時，「當事人表示拒絕接受行銷時，應即停止利用其個人資料行銷」；第一次行銷時，也要提供拒絕的方式（全國法規資料庫：個人資料保護法第 20 條）。

想像一下這個流程哪裡會出錯：

會員在 EDM 系統點了退訂
  → EDM 系統記下「已退訂」
  → 但 CRM 的會員資料沒有同步到
  → 下一檔，工程師從 CRM 撈名單
  → 名單又匯進 EDM 系統，覆蓋了退訂紀錄
  → 已經退訂的人又收到行銷信

每一步單獨看都沒錯，問題出在退訂這件事有兩個地方在記。所以同意與偏好一定要指定唯一的來源，其他系統寄送前都要回頭查它，而不是各自保留一份副本。

這不只是 CRM 的問題。簡訊、APP 推播、電話行銷，只要是對同一個人行銷，都要查同一份紀錄。

整理到最後，最重要的不是資料怎麼搬，而是先講清楚每一類資料由哪個系統負責：

這張分工講不清楚，後面不管用什麼方法搬資料，都會搬出「兩邊不一樣」的問題。

當行銷用自然語言問 AI「撈出近 90 天買過保養品、還願意收行銷信的會員」，AI 透過 MCP 查資料。這四類資料的分工，直接決定 MCP 該怎麼設計：

同意條件要內建，不能交給 AI 記得加。 任何「撈行銷名單」的工具，都應該在工具內部自動排除已退訂的人，而不是靠 AI 每次在條件裡補上「還願意收行銷信」。AI 漏加一次，就違反第 20 條。
身分要用合併後的結果。 MCP 背後如果直接查各系統的原始資料，同一個人會被算成好幾個。
個資欄位要分級。 能只回人數就不要回明細；要回明細，就限制欄位，例如不回完整電話和地址。
說清楚資料新鮮度。 交易資料如果是一天同步一次，AI 回答時要能說「資料截至昨天」。