CRM 有兩種那篇的開頭，是我用過的 CRM 工作流程：行銷開條件、工程師寫 SQL 撈名單、名單丟進 EDM 系統寄送。
上一篇把會員資料送進了業務型的 CRM。這篇走完後半段：把同一批會員送進行銷自動化系統，用條件分群，寄一封 EDM，再點退訂。
實驗環境
- 行銷自動化系統：Mautic 7.2.1，用官方 image 加 docker compose 在本機啟動。
- 寄信：Mailpit。它在本機假裝成寄信伺服器，把所有信攔下來，不會真的寄出去。
- 資料：跟上一篇同一批假會員，5 位會員、6 張訂單。
- 同步程式：一支 Node.js 腳本，透過 Mautic 的 REST API 寫入。
五個容器（資料庫、網站、排程、背景工作、Mailpit）合計大約 780 MB 記憶體，資料庫占了一半以上。
送進去：Mautic 用 email 認人
同步的寫法跟上一篇一樣：會員編號、姓名、近 90 天消費、最後下單時間。會員不願意收行銷信，就在 Mautic 標成「不聯絡」（Do Not Contact，簡稱 DNC）。
結果有兩點跟 EspoCRM 不同：
- 沒有 email 的會員直接跳過。 EDM 一定要有 email，這種會員進來也沒有用。5 位會員進去 4 位。
- 同一個 email 會被合併。 我事先手動建了一個同 email、沒有會員編號的聯絡人。同步之後，Mautic 用 email 把它跟會員合併成一筆，沒有重複。
Mautic 是行銷系統，email 就是它認人的方式，所以它把 email 設成唯一的識別欄位。我另外把會員編號也設成唯一識別。上一篇 EspoCRM 的重複資料問題，在這裡不會發生。
分群、寄信：退訂的人自動排除
建一個名單分群，條件是「近 90 天消費 ≥ 1000」，再建一封寄給這個分群的信。信裡放了 Mautic 的退訂連結。
按下寄送，結果是寄出 2 封。另外有一位已經退訂的會員符合另一個分群的條件，Mautic 自動把他排除了。
兩個觀察：
- 退訂的排除是系統內建的。 寄信的人不用在條件裡記得加「排除退訂」。這正是 CRM 會碰到哪些資料那篇說的：同意條件要內建，不能靠人記得加。
- 同一封信不會重寄。 我把同一封信再寄一次，寄出 0 封。收過的人不會再收到同一封。
撞到的第一件事：同步把退訂蓋掉了
接著從 Mailpit 打開寄給王小明的信，點退訂連結。頁面顯示「ming@example.com 不會再收到我們的信」。Mautic 在他身上加了 DNC，原因是「User unsubscribed」。
然後跑同步。這次我準備了兩個版本：
- 照抄來源：來源說他願意收信，就把 DNC 移除。結果王小明變回可以寄。
- 退訂優先：來源說願意，但 Mautic 已經退訂，就不動，並列出來回寫給來源。結果王小明維持退訂。
用「照抄來源」的版本同步後，我寄了一封新的十一月活動信。王小明收到了。 他明明點過退訂。
這跟上一篇在 EspoCRM 撞到的是同一件事，只是換了系統。差別在於，這次是真的寄出了一封信。個資法第 20 條規定，當事人拒絕行銷後應立即停止。一支同步程式就能讓公司違反這條，而且寫同步的人不會發現，因為每一步看起來都正確。
規則跟上一篇一樣：退訂優先，而且退訂要回寫給同意的唯一來源。
撞到的第二件事：名單不是即時的
Mautic 的名單分群不是寫入資料時馬上更新。它靠排程工作，官方 docker 範例預設每 15 分鐘跑一次。
實測：新增一位消費 5000 的會員，立刻查「高消費會員」名單，他不在裡面。手動跑一次分群更新，他才出現。
這對檔期活動的影響是：
- 寄送前要先更新分群。 不然最後 15 分鐘內符合條件的人會漏掉，已經不符合的人還留在名單裡。
- 「下單後 10 分鐘推薦加購」這類需求，不適合用分群做。 要用事件觸發，見企業系統之間怎麼交換資料。
撞到的第三件事：消失的 0
這是這次實驗最意外的發現。
有一位會員的訂單在 6 月，超過 90 天，所以近 90 天消費是 0。同步送進 Mautic 之後，他的消費欄位是空的，不是 0。
再做幾個測試：
| 寫入方式 | 存進去的值 |
|---|---|
| 新會員，送 0 | 空白 |
送字串 "0" | 空白 |
| 原本 1500，同步改成 0 | 還是 1500 |
| 加上「空白值也要覆蓋」的參數，再送 0 | 空白 |
Mautic 把 0 當成「沒有值」。新會員的 0 變成空白，已經有值的會員改成 0，則會被直接忽略。
這會讓名單出錯：
- 「低消費會員」（消費 < 1000）漏掉消費 0 的人。 空白不符合「小於 1000」。如果這份名單是要喚醒沉睡會員，最該寄的人反而不在裡面。
- 消費掉到 0 的會員，一直留在「高消費會員」裡。 他的欄位還是舊的 1500。
CRM 有兩種那篇說 Mautic 的名單是活的，不符合條件的人會自己掉出去。這句話成立的前提是：欄位的值真的有更新。
解法：分群不要直接用數字欄位篩選，改用同步程式算好的等級。 我加了一個文字欄位「消費等級」，同步程式算好 none、low、high 三種值送進去，分群改用這個欄位。結果消費 0 的會員正確地進入了 none 那一組。數字欄位還是顯示舊的 1500，只能拿來看，不能拿來篩選。
這其實就是 名單和報表的 ETL 怎麼規劃的做法：條件在自己這邊算好，再把結果推給 EDM 系統。這次實驗多了一個理由：EDM 系統對資料的解讀，不一定跟你想的一樣。
收：送名單進 EDM 的檢查清單
| 項目 | 這次實驗的做法 |
|---|---|
| 認人 | EDM 系統用 email 認人；沒有 email 的會員不送 |
| 退訂 | 系統內建排除；同步不能移除退訂，退訂要回寫給來源 |
| 分群時間 | 寄送前先更新分群，不要依賴排程剛好跑過 |
| 數字欄位 | 先測 0 和空白怎麼存；分群改用算好的等級 |
| 寄信測試 | 用 Mailpit 這類工具攔下所有信，不會寄給真的人 |
兩篇實驗做下來，最常出事的都是同一件事：退訂。它在 CRM 被蓋掉一次，在 EDM 又被蓋掉一次。每一次的原因都一樣，都是同步程式把來源的舊值寫了回去。
相關主題
- 會員資料怎麼進 CRM：上一篇，同一批資料送進 EspoCRM
- CRM 會碰到哪些資料：同意一定只能有一個來源
- 名單和報表的 ETL 怎麼規劃：條件在倉儲算好，再推給 EDM