Agentic CDP 是在 Customer 360、身份解析、同意與行為資料之上，讓 AI Agent 協助查詢客戶、建立受眾、分析變化、提出建議，並在人工或政策核准後啟動行銷工作流。它不是「CDP 多一個聊天框」，而是把資料、洞察、決策、核准、行動與成效回饋連成受控閉環。
Agentic CDP 是什麼？
可摘錄定義：Agentic CDP 是以受治理的 Customer 360 為客戶脈絡，讓 AI Agent 在權限與政策邊界內協助分析、推薦及建立待審行動，並把結果回收到下一輪決策的工作架構。
傳統 CDP 的核心工作，是整合身份、行為、交易與偏好，建立可查詢、可分群、可啟動的客戶資料。Agentic CDP 則在這個基礎上增加一層目標導向的協作：使用者提出問題，Agent 找資料、解讀變化、產生受眾或候選行動，再依政策交給人核准或送進既有工具。
「Agentic CDP」目前仍是新興市場用語，尚不能視為已有一致標準的正式品類。企業評估時，不應只看產品名稱，而要檢查身份、同意、資料品質、工具權限、核准與成效驗證是否真的連成閉環。
為什麼 CDP 正從資料平台走向 Agent 工作基礎？
行銷團隊過去常在 Dashboard、SQL、Segment Builder 與 Campaign Tool 之間切換。Customer 360 若能提供一致的身份、行為、交易、偏好與同意資訊，就有機會成為 Agent 理解客戶問題的 Context，而不只是存放 Profile 的資料庫。
近期供應商公告反映這個方向：Databricks CustomerLake 把 Campaign Agents 標示為 Beta、Profile Agents 標示為 Private Preview；Amperity Pér 則提出從問題、證據、建議到核准後行動的流程。這些資料可以用來觀察產品方向，但 Beta、Private Preview 與供應商敘述不能寫成全面 GA，也不能拿具名客戶成效當作普遍保證。
傳統 CDP 與 Agentic CDP 有什麼差異？
| 面向 | 傳統 CDP | Agentic CDP |
|---|---|---|
| 資料基礎 | 統一 Profile、事件與 Segment | 沿用受治理 Customer 360 作為 Agent Context |
| 查詢方式 | 報表、SQL、固定介面 | 自然語言問題加可追溯查詢與證據 |
| 受眾建立 | 人工設定規則或模型分數 | Agent 提出 Segment 草案、條件與理由 |
| 行動 | 手動同步至行銷工具 | 核准後呼叫既有 Connector 或建立待審工作 |
| 治理 | 資料權限、同意、頻率與活動規則 | 再加入 Tool 權限、人工 Gate、Agent Log 與 Evaluation |
| 回饋 | 活動後報表 | 把成效、失敗與實驗結果帶回下一輪建議 |
兩者不是互相取代。沒有穩定的 CDP 與 Customer 360，Agent 只會更快碰到重複身份、錯誤同意狀態、過期事件與不一致 KPI。
Agentic CDP 的六層資料與治理基礎
- 身份解析與 Golden Record：知道不同裝置、會員編號、Email 與交易紀錄是否屬於同一人，並保留合併依據。
- 同意、偏好與使用目的：資料能被分析，不代表能用於任何行銷行動；目的限制必須能被系統執行。
- 資料時效與品質：流失、Next Best Action 或即時互動所需的更新頻率不同，不能把延遲資料當成即時事實。
- 商業定義與 KPI：活躍會員、轉換、流失與高價值客群要有共同口徑，避免 Agent 使用不同版本的定義。
- Activation Tool 與權限：把查詢、建議、建立待審活動與正式發送拆成不同能力，不要給一個工具包辦所有動作。
- 成效回饋與稽核：記錄資料版本、受眾條件、建議理由、核准者、發送結果、對照組與增量指標。
從問題到行動：可控的 Agentic Marketing Loop
- Ask：行銷或 CRM 團隊提出問題，例如「本月回購下降集中在哪些會員？」
- Investigate：Agent 在核准資料內比對客群、旅程、交易與活動變化，列出證據與資料限制。
- Recommend：提出受眾、可能原因、候選策略與風險，不把相關性直接寫成因果。
- Approve：由人或政策檢查同意、頻率、優惠、品牌規則、預算與受眾規模。
- Activate：核准後送到既有 EDM、簡訊、廣告或 CRM 工具；Agent 不應繞過既有發送控制。
- Measure：回收送達、互動、轉換、退訂、成本與增量效果，作為下一輪判斷依據。
實務情境：Agent 發現近 30 天高價會員回購下降，可以先建立「候選受眾＋證據＋排除條件」，但正式活動仍需檢查同意、近期接觸頻率、優惠成本與對照組。若未經驗證就直接發送，速度提升反而會放大打擾與錯誤歸因。
四個高價值情境，以及不能省略的人工 Gate
1. 流失會員辨識
Agent 可整理風險訊號與候選名單，但「為什麼流失」可能只是相關性推測。策略、優惠與發送範圍仍需人員確認。
2. 動態會員分群
Agent 可把自然語言需求轉成 Segment 草案，仍應檢查客群規模、條件衝突、偏差、可行動性與資料更新時間。
3. Campaign 異常分析
它可以比對渠道、素材、受眾與時段，快速指出變化；但若缺少實驗或對照，不能把同時發生的事件直接認定為原因。
4. Next Best Action
Agent 可提出候選行動與理由，但高影響優惠、敏感客群或跨渠道頻率仍需政策限制，避免以「個人化」之名造成歧視、過度打擾或不當使用資料。
LINKY360、CONNECT 與 REASON 如何分工？
以解決方案架構來看，LINKY CONNECT 可規劃廣告、會員、訂單、POS 與外部工具的接入；LINKY360 可承接身份、Journey、Segment、Attribution 與 Conversion 等 Customer Context；LINKY REASON 則可用來規劃 Agent、語意、Tool、Permission、Evaluation 與執行紀錄。
這些描述是產品與專案的架構方向，不是對所有能力成熟度的直接承諾。實際是否能即時更新、支援哪些 Connector、如何核准與回寫，仍需依企業資料環境、既有 MarTech 與專案範圍確認。
企業導入前的五項檢查
- 會員身份能否正確合併，且能處理誤合併與拆分？
- 同意、偏好、目的限制與接觸頻率是否可被系統執行？
- 資料更新頻率是否符合流失、推薦或即時互動的決策時效？
- Tool 是否拆分為查詢、建議、建立待審與正式發送？
- 是否能以對照組、增量轉換與長期指標驗證，而不只看點擊？
結論：價值不是更自動，而是縮短洞察到受控行動的距離
Agentic CDP 的真正門檻，不是模型是否會產生一個漂亮的客群名稱，而是 Customer 360 是否可信、同意是否可執行、工具是否分權、建議是否有證據，以及行動後能否量測增量效果。把這些基礎補齊，Agent 才能讓資料團隊與行銷團隊更快協作，而不是更快製造錯誤活動。
常見問題 FAQ
Agentic CDP 會取代傳統 CDP 嗎？
不會直接取代。Agent 需要 CDP 提供身份、事件、同意與商業定義；它改變的是使用資料與推動工作流的方式。
沒有 Customer 360 可以先做 Agent 嗎？
可做限定範圍的分析 Pilot，但若身份、同意與口徑不一致，不適合直接用於跨渠道啟動或高影響決策。
AI 建議名單能否直接發送？
不建議把「產生名單」與「正式發送」綁成同一權限。至少應檢查同意、排除條件、頻率、預算、品牌規則與受眾規模。
如何避免過度個人化與隱私風險？
採取目的限制、資料最小化、敏感屬性管控、可解釋的分群條件、人工 Gate、退出機制與完整稽核，並定期檢查偏差與負面影響。
參考資料與延伸閱讀
- Databricks｜CustomerLake Beta：Campaign Agents 為 Beta、Profile Agents 為 Private Preview；本文保留其產品狀態與供應商來源角色。
- Amperity｜Pér AI Agent：從客戶問題、證據、建議到核准後行動的供應商產品方向。