Shopify customer、CRM contact、Email subscriber、B2B company user 和客服 requester 不一定是一個實體。只用 Email 雙向覆寫，會合併共用信箱、拆散改信箱顧客，或把未同意的人加入行銷。CRM 整合先做 identity 與 consent 設計，再同步欄位。
每個資料用途、owner 和寫入方向需被文件化。
建立身分模型
保存 Shopify customer ID、CRM contact/account ID、company/location、Email/phone 與 external IDs。Email/phone 是可變識別，不直接當永久主鍵。合併、拆分與衝突需人工流程和 audit。
Guest checkout 可建立 order identity，不一定立即建立完整 CRM contact。B2B 一家公司多位 buyer，person 和 account 關係分開。
Consent 是帶時間的紀錄
Email/SMS consent 包含 status、source、timestamp、purpose、market、policy version 和 evidence。Shopify、CRM、ESP 與 CMP 哪個是 owner 要明確。Unsubscribe/withdrawal 優先快速傳播，不能被舊 batch 覆寫回 subscribed。
合法基礎和保存由法務/隱私 owner 決定。雜湊 Email 仍不是自由使用資料。
分開 profile 與事件
Profile 是姓名、語言、偏好、company 和 consent；event 是 customer created、order、refund、product view、support case 和 campaign response。事件保留 occurred_at、source、ID 和 version，不用每次事件覆寫所有 profile。
只傳入 CRM 真正會用於服務、分析或流程的欄位，避免把 Shopify 整包 customer/order payload 長期複製。
訂單資料定義清楚
CRM 需要 order ID、日期、market、currency、net value、items、status、refund 和 customer link。財務敏感、風險標記和完整地址依最小化處理。訂單修改與退款用 update/event，不建立第二筆 sale。
LTV、new/returning 和 lifecycle segment 在單一分析層計算，CRM 顯示結果與版本，不讓每個工具各算一套。
雙向回寫限制欄位
CRM account manager、lead status 或服務偏好可回 Shopify metafield；Shopify shipping address、marketing consent 或 order 狀態則可能有不同 owner。逐欄列方向和衝突，不採所有欄位雙向。
人工在 CRM 修正資料時，UI 說明哪些會回寫 storefront。批次變更先預覽和抽樣。
可靠性與冪等
Webhook 到 durable queue，使用 customer/order/event ID 去重；API rate limit、timeout 和 partial failure 進 retry/dead letter。每筆有 sync status、last success、error 和 safe replay。
每日用 updated_at watermark reconciliation，補 webhook 漏失。刪除、合併和匿名化也需同步，不能只處理 create/update。
隱私請求涵蓋下游
Customer data request、erasure 和 shop erasure 需能找出 CRM、ESP、warehouse/log 中的資料並按要求處理。Shopify App 的 mandatory compliance webhook 依官方要求驗證 HMAC 和回應。
Retention 按資料類型，備份和 dead letter 也納入。測試環境使用去識別資料。
用生命週期案例驗收
測 guest、註冊、同 Email、改 Email、合併、B2B buyer、首次訂單、退款、unsubscribe、re-consent、刪除和跨 market。每個案例比對 Shopify、CRM、ESP 和報表。
新客/回購分類可參考 新客與回購廣告。CRM 整合完成的證據，是身分和同意可追溯、事件不重複，且每個欄位都有清楚責任。