多步驟協調歷程
本指南提供使用Adobe Journey Optimizer (AJO)和Real-Time Customer Data Platform (RT-CDP)建置多步驟協調歷程的完整實作藍圖。 它專為需要協調分支、多點觸控客戶歷程，以隨著時間推移傳送多則訊息的解決方案架構師、行銷技術人員和實作工程師所設計。
它會顯示所有可行的實作選項、每個設定點的決定考量事項，以及Adobe Experience League檔案的連結。 使用本指南來規劃、設定和驗證您的多步驟歷程實作。
使用案例概述
多步驟協調的歷程會處理單一訊息不足以達成所要客戶結果的業務案例。 歷程不會是一次性傳送，而是透過一系列接觸點（電子郵件、簡訊訊息、推播通知或應用程式內訊息）引導每個設定檔，間隔為數天或數週，並根據設定檔屬性、行為訊號或事件資料調整路徑的分支邏輯。
這些歷程是AJO中最複雜的行銷活動模式。 它們結合受眾型或事件型進入與動作節點（訊息）、條件節點（分支邏輯）、等待節點（時間延遲）和退出條件（轉換事件或逾時）的畫布。 每個設定檔會以自己的步調獨立地完成歷程，在每個步驟接收內容相關的內容。
此模式包含更簡單的模式 — 針對單一傳送行銷活動批次傳出訊息啟用，以及針對單一事件回應的事件觸發訊息。 當使用案例需要隨時間透過多次互動來培養輪廓時，請使用此模式。
主要業務目標
此使用案例模式支援下列業務目標。
提升客戶保留率
透過價值導向的體驗和持續培養的關係，讓現有客戶持續參與並更新。
KPI：保留率、客戶期限值、參與度
改善客戶入門
透過簡化的個人化歡迎體驗和啟動歷程，加快新客戶的價值實現時間。
KPI：參與度、保留率、轉換率
與休眠客戶重新互動
使用根據行為訊號的目標重新啟用行銷活動，以贏回非作用中或失效的客戶。
KPI：參與度、保留率、轉換率
復原放棄的購物車和歷程
透過及時且個人化的後續追蹤，重新吸引在購買、應用程式或註冊流程中休假的使用者。
KPI：轉換率、遞增收入、參與
戰術使用案例範例
以下案例說明多步驟協調歷程模式的常見應用程式。
- 客戶入門系列 — 歡迎電子郵件，隨後是功能教育，然後在註冊後的前14天提供啟用提示
- 重新參與滴漏式行銷活動 — 先傳送提醒電子郵件，再傳送獎勵優惠方案，接著傳送逾期三週之失效客戶的最終通知
- 忠誠度里程碑歷程 — 層級升級通知，接著是專屬優惠，然後在會員資格週年臨近時收到續約提醒
- 贏回順序 — 「我們很想念您」電子郵件，接著透過電子郵件提供折扣優惠，然後是最後的SMS提醒，提醒買家購買失敗
- 產品採用歷程 — 試用歡迎、使用提示，然後隨著試用期進行而提示升級
- 訂閱續約順序 — 30天通知、7天提醒，然後是即將續約的到期日訊息
- 購買後的培養 — 感謝您電子郵件、使用指南、交叉銷售建議，然後在購買30天後提出檢閱要求
關鍵績效指標
使用下列KPI來評估您的多步驟協調歷程實作的成效。
使用案例模式
多步驟協調歷程
引導設定檔完成分支、多重接觸歷程，其中包含一段時間的等待、條件和多個訊息動作。
函式鏈：對象評估>歷程執行（多節點） >條件分支>訊息傳送(xN) >退出條件>報告
應用程式
以下應用程式可用來實作此使用案例模式。
- Adobe Journey Optimizer (AJO) — Journey Orchestration引擎、訊息製作、頻道設定、內容實驗、頻率和衝突管理，以及報告
- Adobe Real-Time Customer Data Platform (RT-CDP) — 歷程專案對象的對象評估和定義、個人化的設定檔資料和條件分支
- Adobe Experience Platform (AEP) — 設定檔存放區、身分服務、事件資料擷取和基礎資料基礎架構
基礎函式
下列基本功能必須為此使用案例模式準備就緒。 對於每個函式，狀態會指出它通常是必要的、假設為預先設定或不適用。
支援功能
以下功能可擴大此使用案例模式，但不是核心執行的必要功能。
應用程式函式
此計畫會從「應用程式功能目錄」中執行下列功能。 函式會對應至實作階段，而非編號步驟。
Journey Optimizer (AJO)
Real-Time CDP (RT-CDP)
先決條件
開始實作之前，請先完成下列必要條件。
- [ ] AJO沙箱已布建歷程建立和發佈許可權
- [ ]至少有一個管道表面（電子郵件、簡訊或推播）已設定且作用中
- [ ]設定檔結構描述包含條件分支和個人化所需的屬性
- [ ]體驗事件結構描述已針對退出條件中使用的轉換事件進行設定
- [ ]事件串流對用於退出條件或事件觸發的進入中的即時事件有效
- [ 已針對跨管道設定檔解析設定]個身分名稱空間和合併原則
- [ 為每個訊息接觸點準備]個內容資產（影像、復本、CTA）
- [ 定義並評估]進入對象（適用於對象讀取的歷程）
- [ ]已設定觸發事件結構描述（針對事件觸發的歷程）
- [ ]個測試設定檔可用於歷程測試模式驗證
- [ 已檢閱]隱藏清單，且所有使用的管道都已更新
實作選項
請檢閱下列選項，以決定多步驟協調歷程的最佳方法。
選項A：對象讀取協調歷程
最適合：已知對象進入歷程並透過排程的接觸點進行之時間型Nurture序列 — 上線序列、更新序列、重新參與點滴、忠誠度里程碑歷程。
運作方式：
在歷程專案讀取對象，無論為一次性讀取或定期排程。 所有符合資格的設定檔同時進入歷程，然後以自己的步調在畫布中前進，受等待持續時間和條件評估管理。 每個設定檔的歷程路徑都是獨立的 — 有些可能會採用「已參與」分支，有些會根據其行為或屬性採用「未參與」分支。
在讀取對象活動執行時評估對象。 對於循環歷程，會在每次循環時重新評估對象，新的合格設定檔會進入歷程，而已在歷程中的設定檔會繼續其路徑。 此方法提供可預測的進入時間，非常適合排程的生命週期方案。
主要考量事項：
- 在歷程啟動之前，必須定義並評估對象
- 循環讀取允許在每個週期輸入新的限定元
- 歷程中的設定檔不會重新讀取；後續讀取時只會輸入新限定詞
- 對於受眾讀取的歷程，等待步驟的最短持續時間為1小時
優點：
- 可預測的入門時間與業務排程一致
- 支援大型受眾數量（每秒最多20,000個設定檔的預設限制）
- 可輕鬆針對已知受眾人口進行測試和監控
- 可排程為週期性輸入（每日、每週、每月）
限制：
- 輸入以批次為基礎，而非即時 — 設定檔會在排程讀取時間輸入，而不是在符合資格時輸入
- 不適用於需要立即回應的行為起始序列
- 讀取之間的對象變更不會反映在歷程中的設定檔
Experience League：
選項B：事件觸發的協調歷程
最適合：即時事件開始歷程的行為起始順序 — 購物車放棄升級、購買後培養、里程碑觸發的忠誠度歷程、試用啟動順序。
運作方式：
單一事件（例如，購買、購物車放棄、表單提交或應用程式安裝）會即時觸發個別設定檔的歷程登入。 收到事件時，設定檔會進入歷程，然後隨著條件、等待和分支的接觸點序列前進。 此方法結合事件觸發訊息的即時性與完整歷程的多步驟協調。
觸發事件必須設定為歷程事件，並定義其結構和條件。 歷程會持續聆聽事件，並在事件到達時一次輸入一個設定檔。 後續歷程節點可評估設定檔的回應，以決定要遵循哪個分支。
主要考量事項：
- 需要即時事件串流才能生效
- 必須精確設定事件結構和條件，以避免誤觸發
- 重新進入規則是關鍵的 — 決定如果事件再次引發，設定檔是否可以重新進入
- 每個沙箱每秒最多可支援5,000個事件
優點：
- 以客戶行為為基礎的即時輸入 — 高度情境化
- 每個設定檔在事件發生時單獨進入，而不是按排程
- 適用於行為回應序列（放棄購買、購買後）的自然調整
- 可與設定檔資料結合，以便在輸入後進行個人化分支
限制：
- 需要串流事件基礎結構就位
- 事件結構描述設定和測試的更高複雜性
- 每個事件都會輸入一個設定檔 — 不適用於大量受眾啟用
- 偵錯需要追蹤個別設定檔歷程
Experience League：
選項C：多通道協調歷程
最適合：在每個接觸點使用不同頻道的跨頻道順序 — 先傳送電子郵件再傳送SMS，接著再傳送推播向上呈報，或傳送電子郵件加上應用程式內補充訊息。 可使用對象讀取或事件觸發的專案。
運作方式：
此選項擴充選項A或選項B，在同一歷程中結合多個傳訊通道。 歷程中的每個動作節點都可以鎖定不同的管道（電子郵件、簡訊、推播、應用程式內或網頁），每個都需要個別的管道表面。 歷程設計者在每個步驟選取適當的管道，以啟用向上呈報模式（例如，電子郵件優先，如果沒有參與，則使用SMS）或補充模式（例如，具有應用程式內加強功能的電子郵件）。
跨管道歷程使用的每個管道都需要管道表面，且必須考慮管道特定的個人化、字元限制和選擇加入要求。 條件節點可檢查與先前訊息（例如「已開啟的電子郵件？」）的互動 作為分支條件)來決定下一個管道。
主要考量事項：
- 歷程中使用的每個管道都需要作用中的管道表面
- 每個管道都有不同的個人化功能和內容限制
- 必須為每個頻道驗證同意 — 設定檔可以選擇加入以接收電子郵件，但不選擇簡訊
- 應設定通道特定的頻率上限，以防止跨通道過度傳送訊息
優點：
- 透過在設定檔的偏好頻道中吸引設定檔，最大化觸及率
- 針對無回應的設定檔啟用向上呈報策略
- 支援跨管道的補充傳訊功能，以便強化
- 儘可能提供最複雜的客戶體驗
限制：
- 最高的實作複雜性 — 需要針對每個管道進行設定
- 必須在每個接觸點為每個管道製作內容
- 跨管道的同意和頻率管理越來越複雜
- 測試需要跨所有管道表面進行驗證
Experience League：
選項比較
下表比較各個關鍵條件的三個實作選項。
選擇正確的選項
使用以下決定流程來選取正確的實作方法：
-
歷程是否由客戶行為或事件起始？ 如果是，請選擇選項B （事件觸發）。 如果歷程是由排程的已讀取對象啟動，請選擇選項A （已讀取對象）。
-
歷程是否使用多個傳訊通道（例如，電子郵件和簡訊）？ 如果是，請在您的輸入方法選擇（A或B）上套用選項C （多通道）。 如果歷程在整個過程中使用單一管道，僅選項A或B便已足夠。
-
您是否需要根據參與升級至其他管道？ 如果是，請選擇選項C，其條件節點會檢查與先前訊息的互動，並分支至替代通道。
-
對象是否預先知道並按排程處理？ 如果是，請選擇選項A。如果設定檔應在執行動作時進入歷程，請選擇選項B。
實作階段
以下階段會逐步進行多步驟協調歷程的端對端實作。
階段1：設定管道並準備對象
應用程式函式： AJO：頻道設定，RT-CDP：對象評估
在設計歷程之前，所有管道表面都必須是作用中，並且必須定義和評估進入對象（適用於選項A）。 此階段可確保基礎結構準備好進行訊息傳送。
決定每個接觸點的管道型別
歷程將在每個接觸點使用哪些傳訊頻道？
決定對象評估方法（選項A）
設定檔必須多久才符合登入受眾的條件？
決定子網域委派方法（電子郵件頻道）
應如何將傳送子網域的電子郵件委派給Adobe？
UI導覽
- 色版表面：管理>色版>色版表面>建立表面
- 子網域：管理>管道>子網域
- SMS設定：管理>管道> SMS設定
- 推播設定：管理>管道>推播通知設定
- 受眾：客戶>受眾>建立受眾>建立規則
關鍵設定詳細資料
- 確認電子郵件的IP集區暖機狀態 — 新的IP集區需要在2-4週內逐步進行暖機計畫
- 針對簡訊，設定提供者憑證並驗證寄件者號碼註冊
- 對於推送，上傳APNs憑證和FCM伺服器金鑰
- 使用區段產生器搭配涵蓋目標群體的區段規則來定義進入對象
- 在對象定義中包含隱藏規則（排除最近轉換的、全域取消訂閱的）
選項差異之處
選項A的（已讀取對象）：
定義並評估進入對象。 確認對象具有非零母體。 決定歷程將使用一次性對象讀取還是循環讀取排程。
選項B的（事件觸發）：
確認已設定觸發事件結構，且事件已串流至平台。 不需要預先定義的對象 — 設定檔會在事件接收時個別輸入。
選項C （多通道）的：
為歷程中使用的每個頻道（電子郵件、簡訊、推播、應用程式內）設定頻道介面。 驗證目標母體的每個管道的同意狀態。
Experience League檔案
階段2：建立訊息內容
應用程式函式： AJO：訊息製作
編寫歷程中每個接觸點的訊息內容。 每則訊息可能有不同的內容、個人化深度和頻道。 此階段會建立歷程動作節點將參考的所有交付專案內容。
決定內容方法
每則訊息應該從範本開始、從頭開始設計或匯入HTML？
決定個人化深度
每則訊息應包含多少個人化？
決定片段策略
共用的內容區塊（頁首、頁尾、合法文字）是否應建立為可重複使用的片段？
UI導覽
- 內容管理>內容範本>瀏覽
- 傳送Designer電子郵件（在行銷活動或歷程動作中）
- 內容管理>片段>建立片段
關鍵設定詳細資料
- 編寫歷程中每個訊息動作的內容–4步驟歷程可能需要4個個別的訊息設計
- 使用參照XDM設定檔路徑的個人化運算式（例如，
{{profile.person.name.firstName}}） - 為區段特定變數設定動態內容區塊
- 使用測試設定檔預覽每則訊息，以驗證個人化呈現
- 傳送校樣給內部利害關係人進行內容審查
- 對於SMS，請遵循字元限制（標準GSM編碼為160個字元）
- 針對推播，設定標題、內文、影像和深層連結/URL動作
Experience League檔案
階段3：設計和啟用歷程
應用程式函式： AJO： Journey Orchestration
設計多步驟歷程畫布，包括進入節點、動作節點（訊息）、條件節點（分支）、等待節點（時間延遲）和退出條件。 然後使用測試設定檔進行測試並發佈。
決定專案型別
設定檔應如何進入歷程？
決定重新進入原則
設定檔完成或退出後可以重新進入歷程嗎？
決定接觸點之間的等待持續時間
歷程應該在每則訊息之間等候多久？
決定分支條件
哪些條件決定了設定檔採用的路徑？
決定退出條件
什麼事件或條件會導致設定檔提早退出歷程？
決定歷程逾時
設定檔可以在歷程中保留的最大期間是多少？
UI導覽
- 建立歷程：歷程>建立歷程
- 歷程屬性：歷程畫布>屬性面板
- 進入節點：歷程畫布>拖曳「讀取對象」或事件活動
- 動作節點：歷程畫布>拖曳頻道動作（電子郵件、簡訊、推播）
- 條件節點：歷程畫布>拖曳「條件」活動
- 等待節點：歷程畫布>拖曳「等待」活動
- 退出條件：歷程屬性>退出條件>設定
- 測試模式： 「歷程畫布>測試模式」切換
- 發佈：歷程畫布>發佈
關鍵設定詳細資料
- 使用清楚的描述性慣例為歷程命名（例如「Onboarding_Series_Email_v1」）
- 設定歷程時區，以進行一致的等待步驟處理
- 使用適當的頻道介面設定每個動作節點，並連結至編寫的訊息內容
- 每個分支都必須以「結束」活動終止
- 設定適合使用案例的重新進入規則
- 使用測試模式搭配測試設定檔，在發佈前模擬完整的歷程路徑
- 驗證測試設定檔是否穿越預期路徑並接收正確的訊息
選項差異之處
選項A的（已讀取對象）：
- 拖曳「讀取對象」活動作為登入節點
- 選取階段1中定義的目標對象
- 選擇性地設定週期性讀取排程（每日、每週）
- 設定讀取速率限制（如果擔心下游系統負載）
選項B的（事件觸發）：
- 將觸發事件拖曳為進入節點
- 設定事件綱要和輸入條件
- 請謹慎設定重新進入規則，以避免重複事件中重複的專案
選項C （多通道）的：
- 使用選項A或B的輸入方法
- 在每個動作節點上，選取該接觸點的適當管道表面
- 在管道之間新增條件節點以檢查參與（例如「設定檔是否開啟電子郵件？」） 並路由至替代通道
Experience League檔案
階段4：設定治理和最佳化
應用程式功能： AJO：頻率與商業規則， AJO：衝突與優先順序管理， AJO：內容實驗， RT-CDP：同意與治理執行
套用頻率上限以防止過度傳訊、指派與其他作用中通訊衝突解決的優先順序分數、選擇性地在歷程訊息中設定A/B測試，以及驗證同意實施。
決定頻率上限設定
歷程訊息是否應遵循全球頻率上限？
決定優先順序分數指派
此歷程相對於其他作用中行銷活動和歷程應該如何？
決定內容實驗
歷程訊息是否應該包含A/B或多變數測試？
UI導覽
- 頻率規則：管理>商業規則>建立規則
- 優先順序分數：歷程屬性>優先順序分數
- 衝突偵測：管理>商業規則>衝突與優先順序
- 內容實驗：歷程畫布>選取訊息動作>內容實驗切換
- 同意政策：隱私權>政策>同意政策
關鍵設定詳細資料
- 設定特定頻道的頻率上限（例如，每週最多3封電子郵件、每天最多1個簡訊、每天最多2個推播）
- 將優先順序分數指派給歷程(0-100)，以反映其相對於其他作用中通訊的業務重要性
- 檢閱衝突偵測面板，以識別任何重疊的行銷活動或歷程
- 如果執行內容實驗，請定義處理變體、設定流量分配、選擇成功量度（開啟、點按或轉換），並設定信賴臨界值（通常為95%）
- 確認歷程中使用的每個管道的同意執行都有效
Experience League檔案
階段5：設定報告和監視
應用程式功能： AJO：報告及效能分析、監視及可觀察性、報告及分析
在啟動期間和之後監視歷程執行、檢閱每步驟傳送和參與量度、設定歷程處理失敗警示，以及選擇性地建置CJA工作區分析以實現深度funnel和流失視覺效果。
決定報告方法
此歷程需要哪些報告工具？
決定警示組態
哪些歷程失敗應該觸發警報？
UI導覽
- 歷程即時報告：歷程>選取歷程>即時報告
- 歷程所有時間報表：歷程>選取歷程>所有時間報表
- 警報：警報>警報規則>訂閱
- CJA工作區：專案>建立新專案
關鍵設定詳細資料
-
在歷程執行期間存取即時報告，以即時監控設定檔登入、退出和每個步驟的傳送量度
-
歷程完成後（或資料累積充足後），請檢閱「所有時間」報表以取得全面分析
-
針對歷程處理失敗和傳送問題設定平台警報
-
針對CJA分析，請確定CJA連線包含AJO體驗事件資料集（訊息回饋、電子郵件追蹤、歷程步驟事件）
-
使用以下專案建置CJA Workspace：
- funnel視覺效果顯示每個歷程步驟的設定檔計數
- 識別流失點的流失視覺效果
- 步驟轉換率計算
- 轉換時間分析
- 管道層級參與劃分（適用於多管道歷程）
Experience League檔案
實施考量
在實施之前和期間，請檢閱下列護欄、陷阱、最佳實務和權衡。
護欄和限制
- 每個沙箱最多500個即時歷程 — Journey Optimizer護欄
- 歷程持續時間的上限為91天 （全域逾時） — 在逾時時仍在歷程中的設定檔會自動退出
- 每個歷程畫布最多50個活動
- 每秒最多20,000個設定檔的讀取對象歷程程式 （預設限制）
- 單一事件歷程支援每個沙箱每秒最多5,000個事件
- 對於對象已讀取的歷程，等待步驟具有最短1小時的持續時間
- 歷程重新進入冷卻最少5分鐘
- 每個沙箱每個管道型別最多 10個管道表面
- 建議將電子郵件大小上限設為100 KB，以獲得最佳傳遞能力
- 每則訊息最多30個內容片段
- 每個實驗最多10個內容實驗處理 （變體）
- 每個沙箱最多10個上限設定
- 每個沙箱最多4,000個區段定義
常見陷阱
- 發佈而不測試：發佈之前請一律使用測試模式搭配測試設定檔，以驗證完整的歷程路徑。 驗證設定檔是否周遊預期的分支、等待步驟是否正確推進，以及訊息是否正確呈現。
- 分支上缺少結束活動：每個歷程分支都必須以End活動終止。 如果任何分支沒有終止節點，歷程將無法發佈。
- 過於寬泛的進入條件：定義鬆散的進入對象或事件條件可能會使歷程充斥著非預期的設定檔。 使用特定的屬性檢查和隱藏規則來調整輸入條件。
- 忽略重新進入規則：對於事件觸發的歷程，設定檔可能會多次觸發觸發事件。 如果沒有適當的重新進入設定（拒絕重新進入或縮短期間），設定檔可能會累積在歷程中，導致重複訊息。
- 等待步驟時區混淆：會以UTC處理等待持續時間。 在歷程屬性中明確設定歷程時區，以確保等待步驟在預期的當地時間推進。
- 無法直接編輯即時歷程：即時歷程。 若要進行變更、複製歷程、修改副本、停止原始版本並發佈新版本。 在上線之前規劃歷程版本設定。
- 未定義退出條件：若沒有退出條件，轉換歷程中間之設定檔將繼續接收後續訊息 — 可能無關或自相矛盾。 一律設定轉換事件的退出條件。
- 管道同意未對齊：個人資料可能會選擇加入電子郵件，但不會選擇簡訊。 多頻道歷程必須尊重每個頻道的同意。 確認同意欄位已填入並在每個管道表面強制執行。
最佳實務
- 開始簡單、重複：在新增複雜分支之前，先以線性2-3步驟歷程開始。 在條件和管道中分層之前，驗證核心流程是否有效。
- 使用描述性命名慣例：清楚地命名歷程節點、條件和等待步驟（例如「Wait_3_Days_After_Welcome」而非「Wait 1」）。 這可讓測試模式的偵錯和報表解譯更容易。
- 及早設定退出條件：在設計歷程路徑之前，將轉換事件定義為退出條件。 這能確保轉換的設定檔會從歷程中移除，無論其是在哪個步驟中。
- 設定有意義的等候期間：以客戶行為資料為基礎的等候期間 — 一般互動之間的時間、預期的回應視窗和適合頻道的步調（例如，電子郵件之間2-3天，簡訊之間1週）。
- 使用條件節點來檢查參與：在訊息動作之後，新增條件來檢查設定檔是否參與（已開啟、已點按）。 將參與的設定檔路由到單一路徑，將未參與的設定檔路由到提升或替代頻道路徑。
- 利用計算屬性進行分支：使用計算屬性（例如參與分數、購買頻率或上次活動後間隔天數）來進行以資料為導向的分支決定，而非任意。
- 反複監視和最佳化：在初始執行期間每週檢閱歷程報告。 根據每一步的效能資料，識別流失點、調整等待期間、調整條件，以及最佳化訊息內容。
- 將您的歷程版本化：進行變更時，請複製歷程以建立新版本。 維護版本變更記錄，以進行稽核和最佳化追蹤。
權衡決定
您應根據特定業務需求評估以下權衡。
對象讀取專案與事件觸發專案的比較
受眾讀取專案提供可預測、批次式處理，更易於管理和測試。 事件觸發式輸入可提供即時回應，與情境的關聯性更強，但需要串流基礎結構和更細緻的重新輸入管理。
- 受眾讀取偏好：可預測性、大量處理、排程的生命週期程式、較簡單的測試
- 事件觸發的偏好：即時關聯性、行為內容、個別設定檔步調、立即回應客戶動作
- 建議：針對時間受業務驅動的計畫生命週期方案（入門、續約），使用對象讀取。 若時間為客戶導向，針對行為回應順序（放棄購買、購買後）使用事件觸發。
單一管道和多管道歷程
單通道歷程的實作、測試和管理都更為簡單。 多管道歷程提供更廣泛的觸及範圍和問題上報功能，但會增加內容建立、同意管理和頻率控管的複雜性。
- 單一管道的好處：更快速的實作、更簡單的同意管理、更少的內容製作工作、更輕鬆的偵錯
- 多管道優惠：較高的參與潛能、無回應設定檔的管道提升、更全面的客戶體驗
- 建議：從單一管道歷程開始，並在展開至多管道之前驗證流程和業務影響。 以增量方式新增參與資料顯示主要管道未有效觸及對象的管道。
歷程複雜性與可管理性
包含許多條件和路徑的高度分支歷程可以處理更多情境，但越來越難以測試、偵錯和最佳化。 使用較少分支的簡單歷程更容易管理，但可能會提供較不個人化的體驗。
- 複雜歷程優先：精細個人化、區段特定路徑、完整情境涵蓋範圍
- 較簡單的歷程優先：部署更快、測試更輕鬆、報告更清晰、維護負擔更輕
- 建議：將歷程限製為3-5個主要分支和15-25個活動。 如果邏輯需要更多複雜性，請考慮使用跨歷程協調（而不是單一整體歷程）拆分為多個歷程。
頻率上限嚴格性與歷程完成的比較
嚴格的頻率上限會防止過度傳訊，但可能會抑制歷程訊息，導致設定檔略過步驟並降低歷程完成率。 寬鬆的帽子可確保傳送歷程訊息，但存在頻道疲勞的風險。
- 嚴格上限優先：客戶體驗保護、降低取消訂閱率、品牌信任
- 寬大字幕優先：歷程完成率、完整訊息順序傳遞、行銷方案有效性
- 建議：為關鍵歷程訊息（入門、續約）指派較高的優先順序分數，以便在達到上限時，優先於促銷活動。 只保留真正重要通訊的「劐免上限」。
相關文件
下列資源提供此實作中所使用功能的其他詳細資料。