Marketing Cloud 建置重點：客群分眾、Journey 與自動化

行銷旅程愈多，企業愈需要清楚的客群條件、資料依據與溝通規則。Salesforce Marketing Cloud 建置不能只完成流程畫面。本文整理分眾、Journey 設計、內容與自動化維護的核心重點，協助團隊把行銷構想轉成可驗證、可持續營運的流程。

摘要

Marketing Cloud 建置的核心，是讓資料、客群、訊息與後續行動保持一致。本文以 Marketing Cloud Engagement 的 Journey Builder 為主要情境，說明分眾規格、進入與退出條件、內容測試及日常維護。企業應先完成一條規則清楚的旅程，再根據營運能力擴展；不同 Marketing Cloud 產品的工具與資料模型，需依實際方案分別確認。

1. Marketing Cloud 建置先釐清使用情境

同樣是行銷自動化，新會員歡迎、活動提醒與商機培育的目標並不相同。企業應先定義溝通對象、觸發原因與希望完成的行動，再決定需要多少分眾及旅程分支。

Salesforce 的行銷產品包含不同產品線。若需求以 Journey Builder、Data Extensions 與 Automation Studio 為核心，應核對是否屬於 Engagement，以及企業取得的功能與通路。不要因產品名稱相近，就直接套用另一產品的設計方法。

首期範圍宜聚焦一個團隊能維護的情境。評估時除了功能，也要看資料能否取得、內容是否有人製作、異常是否有人處理。流程可以自動執行，營運責任仍需要清楚安排。

2. 客群分眾要同時回答三個問題

這群人是誰

先用一致的識別方式連接不同來源的聯絡人資料，再選擇與情境有關的屬性。職務、地區或客戶階段可以協助理解需求，但每個條件都應有清楚定義、來源及更新時間。

電子郵件地址可能變更或由多人共用。Engagement 的 Contact Key 與 Email Studio 的 Subscriber Key 涉及聯絡人識別，建置時要確認跨通路與資料表之間的關係，避免把同一人分成多個無法對應的紀錄。

為什麼現在溝通

靜態屬性說明背景，事件與狀態則說明當下原因。參加活動、提出查詢與購買產品代表不同意圖，不能只因同屬一個產業，就一律收到相同內容。

行為條件需要時間範圍。企業應說明事件何時發生、資料何時更新，以及多久後不再具有溝通價值。若資料延遲，原本合理的提醒可能變成過時訊息，應有排除或替代處理。

是否符合溝通條件

符合商業條件的人，不一定符合該通路的寄送條件。訂閱偏好、排除名單與企業核准規則，應與分眾一起設計，並確認變更如何同步及生效。

不要只在名單建立時檢查一次。旅程可能持續數日，期間發生退訂、服務問題或業務接手，都可能改變後續安排。企業需確認每個重要步驟如何使用最新可用資訊。

圖 1：有用的客群分眾，需要同時確認對象、時機與溝通資格。

3. 把客群規則寫成可驗收的分眾規格

分眾名稱應讓行銷與資料團隊有相同理解。「高意向客戶」若沒有具體條件，難以測試，也容易在不同活動中出現不同定義。規格應記錄條件、時間窗口、排除規則與擁有人。

每個分眾至少準備符合、不符合與資料缺漏的樣本。測試不只核對總人數，也要抽查個別紀錄為何被納入或排除。這能把討論從感覺轉成可追蹤的判斷。

資料來源之間可能有不同粒度。會員資料是一人一筆，活動報名可能是一人多筆，交易則可能包含多項商品。先確認關聯與去重方式，避免資料連接後放大名單或混用事件。

交付時保留分眾規則與實際設定的對照。若業務定義更改，團隊便能找到受影響的資料準備、Journey 分支與報表，而非只修改一個看得到的篩選條件。

也要定義分眾重新計算的節奏。每天更新、活動前更新與事件發生後更新，服務的需求不同。建立資料完成標記與人數異常檢查，可避免在資料只更新一半時啟用名單。

4. Journey 設計要涵蓋進入、等待與重新進入

進入條件與事件關係

先決定旅程以人還是特定事件為起點。同一人參與兩場活動時，可能需要兩次不同提醒；但新會員歡迎通常有另一套規則。不能只因操作方便，就讓所有情境採用相同模式。

Journey Builder 提供不同重新進入模式，企業需依情境選擇。選擇後要測試同一聯絡人在不同時間與旅程版本中的行為，確認不會無意中重複溝通或阻擋合理的後續流程。

等待時間與資料時點

等待安排要服務使用者情境，例如讓對方有時間閱讀或完成下一步。企業應考慮時區、內容有效期與來源更新節奏，避免一律使用固定間隔而忽略實際需求。

分支判斷也要說明使用哪個時間點的資料。Journey Data 與 Contact Data 的用途不同，設計前需確認應使用進入時的事件資料，還是之後更新的聯絡人資訊，並驗證對應資料關係。

預設分支與退出規則

每條分支應有明確條件，並處理空值、不符合任何條件與資料尚未更新的情況。預設分支不宜直接視為可寄送對象；有疑問時，可以等待、排除或交由負責人處理。

退出條件則說明何時已完成目標或不宜繼續。規則的評估時點需要實際驗證，不能假設任何資料變更都會立即中止所有動作。必要時，在關鍵動作之前再確認適用條件。

5. 行銷自動化要管理資料與旅程的依賴

資料匯入、轉換、客群計算與旅程進入具有先後關係。企業應記錄每個步驟的完成條件，而不只是排定時間。上游延誤時，下游要能等待、停止或採用經核准的處理方式。

Automation Studio 與 Journey Builder 的工作需要協調，但不能把排程成功當成旅程正確。即使工作執行完成，來源可能為空、資料可能過期，或分眾結果與預期不符。

錯誤處理應涵蓋重試與重送。尤其對觸發溝通的事件，要確認重送資料不會再次啟動不必要的訊息。紀錄事件識別、處理狀態及時間，有助於追查與恢復。

監控可分為技術與業務兩層。技術層觀察工作失敗與延遲，業務層檢查人數、排除原因及流程停滯。異常門檻應根據活動特性建立，不必把所有變動都視為故障。

企業也需要跨旅程的協調方式。同一客戶可能同時進入活動、產品與服務相關流程。溝通優先序、頻率與互斥條件，應由行銷負責人決定，再落實到可驗證的設定。

資料字典與維護清單

為常用欄位建立簡明資料字典，記錄商業定義、型別、允許值、空值含義與主責來源。例如「客戶階段」是銷售團隊人工維護，還是依交易狀態計算，會直接影響分眾的可信程度。

同樣的欄位若出現在不同資料表，不代表可以任意互換。團隊應標示旅程實際使用哪個欄位，以及上游如何產生它。當來源改名或停止提供時，便能及早找出需要調整的流程。

再建立旅程清單，列出目的、擁有人、入口、資料依賴、內容資產與檢視日期。這份清單能幫助團隊辨認重複用途、過期活動與無人維護的流程，避免只新增而不整理。

6. 內容與測試決定旅程能否安全運作

個人化內容需要可靠資料與替代文字。姓名缺漏、語言不同、連結失效或活動日期變更，都應有測試樣本。不能只用一筆完整的內部測試資料代表所有收件人。

內容審核應涵蓋主旨、正文、行動按鈕與落地頁。若旅程有多個分支，建立內容清單與版本關係，確認每條路徑使用正確訊息，也讓後續更新知道要修改哪些資產。

測試時先以有限範圍核對預期，再查看完整執行紀錄。除正常流程外，也應包含停止條件、重複事件與偏好更新，避免只確認訊息有寄出，卻未檢查是否寄給正確對象。

• 驗證進入資格、事件時間與聯絡人識別。
• 核對每條分支、預設路徑及缺漏資料的結果。
• 測試重新進入、重送事件與不同旅程的重疊。
• 確認語言、個人化、連結與替代內容。
• 檢查偏好更新、退出及暫停後的處理。
• 保留測試證據、負責人與正式啟用條件。

圖 2：旅程測試應涵蓋進入、分支、重新進入與退出。

7. 從單次活動建立持續改善方式

成效評估應連回旅程目標。除了寄送或互動指標，也要確認後續行動是否被記錄，以及觀察期間是否一致。單一數字上升，未必代表整條旅程產生預期價值。

改善時先區分資料、規則與內容問題。若客群錯誤，先修正來源或條件；若客群正確但下一步不清楚，再檢查訊息與落地頁。一次改動太多，會增加判讀原因的難度。

假設一家 B2B 企業建立活動後續旅程，可先區分出席與未出席者，提供相應內容。若業務已接手某位參與者，則依核准規則調整後續溝通。這是假設情境，並非實際客戶成效案例。

在這個情境中，驗收應包含活動資料晚到、同一人參與多場活動，以及偏好中途更新。當團隊能說明每筆資料走過哪條路徑，才有較可靠的基礎擴展更多分眾。

每次改版都應記錄原因、範圍與預期結果，並保留可比較的觀察期間。若沒有版本紀錄，後續人員可能只看到設定差異，卻不知道哪些屬於必要修正，哪些仍是待驗證的假設。

建立可交接的營運節奏

日常維護應說明每天要看哪些異常、活動前要確認哪些設定，以及改版後由誰驗證結果。責任可以分配給行銷、資料及資訊團隊，但每一類問題都應有明確的第一位接手者。

異常通報需要附上時間、影響範圍、旅程版本及處理狀態。若只回報「名單不對」，其他人難以重現。以一筆代表紀錄沿資料來源、分眾與旅程追查，通常比同時更改多項設定更容易找出原因。

交接時讓接手人員實際完成一次內容替換、一次異常查找及一次核准流程。文件可以說明操作，演練則能確認團隊是否理解判斷方式，也能找出仍依賴個人記憶的步驟。

對於需要業務跟進的旅程，應約定交接資訊與接手結果如何回傳。行銷平台建立了待跟進對象，不等於業務已接收；若沒有後續狀態，系統可能繼續發送與人工對話重複的內容。

停用旅程也要有程序。確認是否仍有參與者、相關資料工作是否另有用途，以及內容與報表需要保留多久。不要因活動結束，就直接移除其他流程仍依賴的資料或資產。

建立上述習慣後，團隊可把重複問題轉成下一次建置的檢查項目。例如曾發生活動時間混用，就加入事件日期與時區檢查；曾出現錯誤語言，就補足語言缺漏的替代策略。改善因此能累積為共同方法。

8. 常見問題（FAQ）

9. 結語

Salesforce Marketing Cloud 建置的品質，取決於客群定義、旅程規則與日常維護是否連貫。先建立可追蹤的分眾與測試證據，再擴展通路和情境，有助於降低後續調整成本。

LeadsTech 可協助企業梳理行銷自動化需求、資料整合及旅程設計，把優先情境轉成具體建置範圍。

了解 Salesforce Marketing Cloud

如需檢視現有分眾或旅程，可先整理目標、資料來源與目前遇到的例外情況，與團隊討論改善方向。

聯繫我們，討論你的企業需求

10. 延伸閱讀

• 什麼是 Marketing Automation？

  了解行銷自動化的基本概念與企業應用。

• 如何選擇 Marketing Automation 平台？

  以選型角度檢視需求、資料與營運條件。