多品牌集團的會員資料該不該打通？拆成識別、分析、行動三層再決定

一個會員池，好幾套義務

假設一個零售集團旗下有三條線，分別由集團內三家公司經營：開在百貨的連鎖服飾、只做線上的美妝品牌、一條保健食品。三個品牌共用同一套會員系統、同一支 APP、同一批客服。從經營角度看，它們是一家公司。

從個資法規的角度看，它們是三家。

依經濟部零售業個人資料檔案安全維護管理辦法第三條，適用對象限於從事實體店面、或實體店面兼營網際網路方式銷售商品的零售業者，且資本額達新臺幣一千萬元以上、有招募會員或可取得交易對象個人資料。那個純線上的美妝品牌不落在這裡，它歸數位發展部的數位經濟相關產業個人資料檔案安全維護管理辦法管。至於保健食品那條線會不會落進經濟部辦法第三條的但書（該但書排除應經特許、許可或受專門管理法令規範的行業），要看它實際登記的營業項目與適用的專門法令，光看賣什麼商品判斷不出來。

翻成營運語言：內部看起來只有一套會員系統，但真的出事的時候，通報窗口、要維護的安全計畫、要應付的檢查，可能各自成立。

會員池合成一個，義務不會跟著合成一份。這是多品牌集團在資料治理上最容易踩空的地方。

（如果三個品牌其實同屬一家公司，下面關於跨法人提供資料的判斷不能直接套用，但「原本蒐集時告知的目的決定後續能怎麼用」這件事，一樣要逐個品牌檢查。）

會議室裡兩派人都對，只是講的不是同一層

我們陪集團型客戶討論資料架構時，最常出現的畫面是會議桌上分成兩派。資訊部說技術上很快就能接完，法務說先別動。行銷主管夾在中間，覺得兩邊都在拖進度，又不敢真的按下去。

兩邊其實都沒說錯，只是講的不是同一層事情。這篇想做的，就是把那張桌子上被混著講的三件事拆開。

打通這件事，其實是三個獨立的決定

以下是本文為了拆解集團資料決策而提出的三層框架。

三層像是同一件事的三種說法，但它們的主要煞車不一樣。要先說清楚的是，三層不是三個法規區隔，而是三種使用深度；目的與法源、資料品質、權限治理、資安與委外管理這幾件事橫跨全部三層，差別只在哪一項的權重最重。

識別層的主要難題是工程與資料品質。要把同一個人在不同品牌的紀錄接起來，靠的是手機號碼、電子郵件、會員卡號這類識別碼的清洗與比對。這跟 OMO 歸戶要處理的是同一類問題：身分匹配、資料合併、即時同步，三步缺一不可。多數集團在這層卡的是資料品質。要提醒的是，識別層不是法律豁免區：跨品牌比對識別碼本身就是個資的處理與利用，各公司之間有沒有權限提供與接收，要在啟動比對前確認，不能因為還沒對客戶做任何事就跳過。

分析層的主要難題是治理規則。技術上，把三個品牌的交易紀錄放進同一張表就能跑模型。但算出來的分數給誰用、能不能回寫到各品牌的名單、模型出錯了誰負責，這些工程再強也解不掉。集團在這層最常見的爭議是資料貢獻不對等：貢獻最多交易紀錄的那個品牌，往往不是最需要模型的那個品牌，於是「這個品牌的資料，憑什麼拿去養別人的模型」就成了推不動的理由。同樣要注意，把 A 品牌資料當成 B 品牌模型的輸入，已經是一次新的利用；如果輸出的標籤還能對應回個人、或會回寫到 B 品牌的會員帳號，目的與法源的檢查不能因為「還沒投放」就省略。

行動層的主要難題是你當初對顧客說過的話。這一層最常被跳過，出事的時候也最貴。

底下三個案例，剛好照到不同的角度。

買下一個品牌，也買下了它的資料庫和它的歷史

先講清楚這個案例能證明什麼、不能證明什麼。它不是「資料合併造成外洩」的案例，入侵發生在併購之前；它能支撐的，是接手或共用資料系統時會一併接手的安全責任。

2016 年 Marriott 併購 Starwood，把對方的訂房系統與會員資料一併接手。當時沒有人知道，Starwood 的訂房資料庫早在 2014 年就已經被入侵，而這件事一直到 2018 年 9 月才被發現。

英國資訊委員辦公室（ICO）在 2019 年 7 月 9 日發出意向裁罰通知，金額 9,920 萬英鎊。最終處分在 2020 年 10 月 30 日出爐，金額降為 1,840 萬英鎊。事件涉及約 3.39 億筆全球訂房紀錄，其中約 700 萬筆屬於英國、約 3,010 萬筆屬於歐洲經濟區。

有個細節值得集團經營者注意。ICO 在 2019 年的公開說法提到 Marriott 併購時的盡職調查不足，但最終處分書並沒有對「併購過程中能不能完成這種深度調查」下判斷，裁罰基礎改放在 2018 年 5 月 25 日 GDPR 生效之後，Marriott 對系統測試與評估的不足。監理機關最後保留了模糊空間。

對要做併購或多品牌整合的集團來說，可帶走的結論很直接：整合前的資料盤點如果只盤「有幾筆會員、欄位長什麼樣」，那份盤點不夠。真正該問的是另外幾題：

• 這些資料當初是用什麼名義蒐來的，告知的對象與目的寫了什麼
• 系統這幾年有沒有被人動過，誰還握有存取權限
• 有沒有已知但一直沒處理的漏洞

處分書裡還有一段對集團特別有意義。Marriott 曾主張，相關系統的資安維運委外給第三方廠商執行，這一點應該納入責任評估。ICO 不同意，認為受託處理者負責實作或維運系統的某些環節，並不減輕 Marriott 自身的責任。集團常見的作法是好幾個品牌共用同一家系統商或代操夥伴，這種安排能省成本，卻省不掉責任。要補一句的是，共用同一家受託廠商，也不代表各品牌之間可以彼此取得資料；廠商受誰委託、能為哪些目的處理哪些資料，仍然要分別界定。

資料用途要變更，顧客得在場

Google 在 2007 年併購廣告聯播網 DoubleClick 時，對外承諾把兩池資料分開：DoubleClick 累積的瀏覽紀錄，預設不會跟 Google 帳號的身分資料合併。這個分界維持了將近十年。

2016 年 6 月 28 日，Google 修改隱私權政策，把「不合併」改成「可能合併」。ProPublica 當年的報導指出，政策條文裡承諾分開的那幾行字被直接劃掉。新註冊的帳號預設啟用，既有使用者則在該年夏天收到提示，被引導同意。

重點在合併之前它做了什麼：改政策、通知、取得同意。資料池的合併同時是一次資料庫操作，也是一次對顧客的重新告知。

這個案例只能用來說明「用途變更需要面向使用者處理」，它是美國科技公司的政策操作，不能當成台灣個資法的法遵範本，也不表示走完那三步就一定足夠。

不過對集團來說，它點出一個很常見的失誤：把用途變更當成純內部流程。A 品牌的會員當初在 A 品牌的註冊頁勾同意，勾的是那一版條款寫的目的與對象。今天集團把資料合進總池，接著用 B 品牌的名義發促銷簡訊，這則簡訊的正當性不在總池裡，它在兩年前那張註冊頁上。

同一個集團，通報窗口可能不只一個

回到台灣的實務。前面提到的分流不只是名義上的差別，兩套辦法要求的動作也不同。

以數位發展部那套為例，數位經濟相關產業個人資料檔案安全維護管理辦法第八條要求，發生個資事故時應於知悉後七十二小時內依規定格式通報數位發展部；第十八條規定資本額達一千萬元以上、或保有個人資料達五千筆以上的業者，至少每十二個月要就安全維護計畫的部分措施實施檢討改善一次。

經濟部那套的細節另有規定，該辦法最近一次修正發布是 2024 年 11 月 13 日，並從原本的綜合商品零售業擴大到專責特定商品的大型零售業。對品牌主的意思是：過去覺得「這是百貨和超商的事」而沒有動作的零售品牌，現在要重新確認自己在不在適用範圍內。

於是集團會遇到一個很具體的狀況。如果品牌分屬不同公司、又分別受不同主管機關與辦法管轄，同一起橫跨兩個品牌的事故，可能觸發不只一個通報窗口與不只一份安全維護計畫；如果品牌同屬一家公司，則要依該業者的營業型態與適用規範判斷。這不是把系統合併就會自動消失的成本，反而因為資料合併，一起事故波及的品牌數量變多了。

至於統一的主管機關，目前還沒到位。個人資料保護委員會官方網站截至本文撰寫時仍掛著「籌備處」的名稱。按目的事業主管機關分流的現況，短期內還會是集團要面對的日常。

擋住集團的很少是技術，是當初蒐集時說了什麼

把三個案例的共同點抽出來，會看到集團資料整合的真正約束，很少來自技術。

第一道檢查在蒐集當下。個資法要求蒐集個人資料時要告知特定目的，那個目的與告知的利用對象，構成後續利用的範圍。集團合併資料池的動作不會回頭擴大這個範圍。要說明的是，特定目的是第一道檢查，卻不是唯一判準：跨品牌利用之前，還要確認提供與利用的法律依據、原告知涵蓋的對象與範圍、是否構成目的外利用，以及直接行銷本來就有的拒絕與停止機制。需要重新取得同意時，再設計告知與同意流程。這些題目請讓法務參與判斷，不要由資訊或行銷單方拍板。

跨境展店會再疊一層。個人資料保護法第二十一條規定，非公務機關為國際傳輸個人資料，遇有涉及國家重大利益、國際條約或協定另有規定、接受國對個人資料保護未有完善法規致有損當事人權益之虞，或以迂迴方法向第三國傳輸規避本法等情形之一，中央目的事業主管機關得限制之。

這條不是備而不用的條文。勞動部就曾在 2023 年 2 月 20 日訂定限制人力仲介業將當事人個人資料國際傳輸至大陸地區的規定。對正在或準備跨境的零售集團來說，傳輸路徑是可能被行政命令改變的變數，架構設計時就該預留切換空間。

數位發展部那套辦法的第十條也給了三件具體工作：檢視是否受數位發展部依第二十一條所為的限制、告知當事人個人資料所欲國際傳輸的區域、以及對資料接收方就處理利用的範圍類別目的期間地區對象方式，還有當事人行使權利的相關事項為監督。第二件事特別值得畫線：告知當事人傳輸區域。海外倉、海外客服中心、海外的行銷工具供應商，都可能構成這件事。

最後一層約束來自組織。資料 owner 是誰、跨品牌帶來的業績算哪個品牌的、整合的錢由誰出，這些問題沒談好，資料架構圖畫得再漂亮也推不動。這跟 OMO 推行時遇到的阻力是同一種：組織制度摩擦、資料破碎化、系統不整合，其中最難的往往是組織那一項。集團層的版本又更複雜，因為分潤要跨的不只是線上線下，還跨了損益表。

讓每一筆資料帶著它的來歷一起走

三層拆開之後，對資料平台的要求也跟著清楚了。

在識別層，要的是跨通路、跨品牌的歸戶能力，把線上線下、不同品牌的紀錄收斂到同一個會員身分。這是 91APP CDMP 在做的基本工，也是集團要回答「我們到底有多少不重複顧客」的前提。集團規模的資料整併會延伸到更上層的架構討論，我們在談零售集團的資料中台時處理的就是這一段。

到了分析層，關鍵轉向受控的跨品牌運算。CDMP 用NAPLRS 生命週期分群、DCIU 購買意圖判讀、XGBoost 轉換機率預測這幾層描述一個會員，集團情境下值得多做一件事：讓模型輸出的每個標籤都看得出它算進了哪些品牌的資料。所謂受控，具體是三件事要先講清楚：哪些品牌的資料可以進運算、算出來的結果可以回寫到哪些品牌、以及誰有權調整這兩條規則。這三件事寫下來只有幾行，沒寫下來的集團，通常會在第一次跨品牌投放前臨時開會吵一輪。

行動層則要求可追溯。名單被輸出去投廣告、發簡訊、推播之前，這份名單裡的每一筆都應該說得出自己的來歷。只帶「來自哪個品牌」和「當初的目的」兩個欄位是不夠的，實務上至少要維護：蒐集的公司主體、來源品牌與系統、蒐集時間、當時的告知條款版本、目的代碼、可利用的品牌與對象、各通路的同意與退訂狀態、保存期限、資料所在區域。欄位齊了，系統才擋得住不該圈進來的人，而不是靠行銷企劃自己記得。這些欄位是判斷的材料，判斷本身仍然要有人負責。

一個資料平台對集團的價值，在於合起來之後，每一筆資料還說得出自己的來歷。

先盤點告知範圍，再談資料架構

集團要動會員資料之前，順序建議這樣安排。

1. 盤點各品牌的蒐集告知與經營主體：把每個品牌現行註冊頁、會員條款、線下入會單寫的特定目的與利用對象抓出來排在一起，同時標記每個品牌由哪一家公司經營。這份盤點決定後面每一層能走到哪，所需時間取決於品牌數與歷史條款版本數，建議在任何系統整併專案啟動前完成。
2. 讓法遵檢查當識別層的前置閘門，不要當事後補件：先確認各公司有權提供與接收識別碼，再進行跨品牌歸戶測試。歸戶結果先只用於去重統計；跨品牌消費輪廓已經屬於分析層，要另外過一次檢查。對客的行動再按品牌逐一開通。
3. 把主管機關對應表寫進治理文件：列出每個品牌的經營公司、營業項目、適用哪一套個資檔案安全維護辦法、通報窗口與期限、內部負責角色、上次檢討日期。至少每年更新一次，遇到併購、新品牌成立、營業項目變動或資料流改變時立即更新。多品牌集團常見的失分是有計畫，但只寫了一份。
4. 準備不交換個人層級資料的替代路徑：如果盤點結果顯示某些品牌之間短期內無法交換明細，仍然可以先用匿名彙總報表、各品牌內部建模只交換模型結果、或查詢不搬移原始資料的方式取得一部分價值。跨境的部分同樣要先畫出資料流向圖、接收方與次處理者清冊、以及供應商或區域切換的測試方式。

順帶一提，多數集團在整合專案上跌倒的原因並不特別，跟一般品牌導入顧客資料平台失敗的那幾種高度重疊，只是集團的版本每一項都乘上品牌數。

集團能合的是資料

回到開頭那個集團。三個品牌、一個會員池、好幾套義務。

把資料合起來這件事本身沒有錯，它確實會讓集團第一次看清楚顧客的全貌。要小心的是合併的動作太順手，順手到讓人忘記這些資料是分別從三個不同的承諾裡收來的。

集團能合的是資料，合不掉的是當初對每一位顧客說過的話。先把那些話找出來排好，再決定架構圖怎麼畫，順序對了，後面每一步都會比較好走。

品牌最常問的多品牌集團資料治理問題

Q1：集團旗下多品牌的會員資料，法規上到底能不能合併

A1：能不能合併，至少要先確認四件事：各品牌是不是同一家公司經營、原本蒐集與利用的法律依據是什麼、當初告知的特定目的與利用對象包含哪些、以及合併後打算怎麼用。這幾題的答案會決定能合到哪一層。實務上識別層的歸戶通常最先具備條件，但要拿 A 品牌的名單去發 B 品牌的行銷訊息，需要原告知範圍撐得住；撐不住就要重新告知並取得同意。這題請讓法務參與，不要由資訊或行銷單方判斷。

Q2：舊會員當初的註冊條款沒寫到集團其他品牌，現在還有救嗎

A2：有，但要分批處理。先把歷年條款盤出來，看哪些品牌、哪些時間區間的告知範圍撐得住跨品牌利用，撐得住的部分照原範圍使用。撐不住的部分需要重新告知並取得同意，常見作法是在會員本來就會登入或互動的時機併入新版條款說明，例如資料更新、續會、活動報名，而不是另外發一封只講條款的信。過程中要保留同意的版本與時間紀錄，之後才說得清楚哪一批名單能用在哪裡。

Q3：規模比較小的集團，只有兩三個品牌也需要做到這麼細嗎

A3：品牌數少反而更容易做完整，因為要盤點的告知文件只有兩三份。建議至少完成兩件事：把各品牌的蒐集告知排在一起比對，以及確認每個品牌落在哪一套個資檔案安全維護辦法。這兩件事不需要買任何系統，成本主要是人力時間。

Q4：跨境展店的時候，資料放在台灣還是放在當地比較好

A4：沒有一體適用的答案，決定因素是當地市場的法規要求與集團的營運需求。要注意的是台灣端的義務不會因為資料放在海外就消失：個人資料保護法第二十一條讓中央目的事業主管機關可以限制國際傳輸，數位經濟相關產業的安全維護辦法也要求業者告知當事人資料所欲傳輸的區域，並對接收方進行監督。架構設計時建議預留傳輸路徑可切換的彈性。

Q5：集團導入顧客資料平台，多久看得到成效

A5：很難給一個通用的月數，因為決定時程的是品牌數、經營公司數、歷史條款版本數與資料來源數量，這些每個集團差很多，建議先完成告知範圍與主體盤點再估期。可以先預期的是順序：識別層通常最先產出結果，分析層要等可用的行為資料累積，行動層的時程不取決於系統，取決於盤點結果與必要時的重新告知作業，這一段有可能比前兩層加起來還久。

Q6：這件事該由誰負責，資訊部還是行銷部

A6：三層各有主責比較務實。識別層由資訊或資料團隊主責，分析層由集團層級的資料治理角色主責，行動層則由各品牌行銷加上法務共同把關。最常出問題的情況，是整件事被當成資訊部的專案，等系統上線才發現行動層開不了。集團規模較大時，建議設一個跨品牌的資料治理窗口，負責維護主管機關對應表與告知範圍盤點。

延伸閱讀

• Gartner 2026 CDP Magic Quadrant 解讀：整合生態 vs AI 自主執行
• 一次搞懂 CDP、CRM 與 DMP 的核心價值與選型策略
• 破除 OMO 業績互搶迷思：全通路消費者的真實終身價值與實戰策略

集團旗下多品牌的會員資料現況能整合到哪一層，是可以先盤點出來的。需要有人陪著一起看資料架構時，歡迎找 91APP CDMP 團隊聊聊。