您位於此處：
Omnichannel 考量事項與最佳作法
在實作此解決方案前，請先考慮一些重要的層面和利幣得失。此指南僅是如何為客戶啟用 Omnichannel 體驗的其中一個範例。例如，使用者可以使用 Data Cloud 將一個旅程與所有的「電子郵件」、SMS 和 MobilePush 活動一起協調，而不是單獨的單一管道旅程。
在此解決方案中使用統一個人的潛在風險
此解決方案會假設您尚未實作 Marketing Cloud 以在 Marketing Cloud 中建立 Omnichannel 連絡人,供所有電子郵件、SMS 和 MobilePush 管道使用。此指南概述如何在 Data Cloud 中建立身分解析，以將個人 (電子郵件、SMS 和 MobilePush SubscriberKeys) 關聯至人員單一代表 (統一個人)。
一般而言，建議盡可能使用「個人」設定檔。建議將行銷活動中的「統一個人」使用限制於促銷使用個二，而非交易或事件觸發的使用個案。
將訊息傳送給不正確的人員
請將「統一個人」視為動態，並謹慎處理，因為這些統一個人可能會變更。「統一個人」會以「身分解析」中設定的規則和儲存在 Data Cloud 例項中的資料為基礎。根據從外部資料來源新匯入的資料或您在「身分解析」資料集中進行的變更，「身分解析」流程可能會從指定「統一個人」中新增或移除「個人」設定檔及其相關聯的連絡點地址。因此，您可能會將訊息傳送給錯誤人員。
範例：Data Cloud 可以有人員 John Smith 的「統一個人」。根據您的「身分解析」規則,John Smith 的「統一設定檔」一開始由三個不同的個人 (來自 Marketing Cloud 的 SubscriberKeys) 組成:John.Smith.Email、John.Smith.SMS 和 John.Smith.MobilePush。Cumulus 會啟用 Journey Builder 的「統一個人」，以在 Journey Builder 中使用。
| 源自 John Smith 的統一個人設定檔 | |||||
|---|---|---|---|---|---|
| 個人識別碼 | 電子郵件地址 | 全名 | 電話號碼 | 國家 | MobilePushSubscriberKey |
| John.Smith.Email | john.smith@example.com | John Smith | 555-123-1234 | 美國 | John.Smith.MobilePush |
| 從 John.Smith.Email 的「個人」設定檔中選取 | 從 John.Smith.SMS 的「個人」設定檔中選取 | 從 John.Smith.MobilePush 的個人設定檔中選取 | |||
在旅程的期間，「身分解析」會收到新資訊，這會進而決定「個人」John.Smith.MobilePush 不屬於 John Smith 的「統一個人」。事實上，此「個人」設定檔屬於相同名稱的個別人員 (統一個人 John Smith, Sr)。因此，旅程可能會將電子郵件和 SMS 訊息傳送給 John Smith，並將包含潛在敏感資訊的推送通知傳送給 John Smith, Sr。
選取選擇退出個人或連絡點
當 Data Cloud 分割「統一個人」時，其會符合「統一個人」資格，因為「統一個人」至少有一個符合條件的「個人」。
在「統一個人」上啟用時，Data Cloud 會使用您的來源優先順序和參與歷程記錄來選取要啟用的連絡人，無論其同意或偏好設定類型為何。客戶僅負責啟用連絡點和取得將訊息傳送給任何連絡點的同意。
例如，John Smith 的「統一個人」可以有與其相關的兩個「個人」，每個「個人」都會從個別資料來源匯入且每個「個人」都有其自己相關聯的 SMS 電話號碼：來自系統 A 的 John.Smith.1 與來自系統 B 的 John.Smith.2。如果 Cumulus 使用「統一個人」是否已選擇加入 SMS 訊息的條件來分割「統一個人」，則 John Smith 的「統一個人」便符合受眾的資格，即使 John.Smith.A 已選擇加入 SMS 傳訊，而 John.Smith.B 已選擇退出。作為啟用的一部分，如果 Cumulus 已選取排定來源系統「系統 B」中 SMS 連絡點的優先順序，則 Data Cloud 可從 John.Smith.B 選取選擇退出的電話號碼。
使用不正確的人員內容
當 Data Cloud 分割「統一個人」時，其會符合「統一個人」資格，因為「統一個人」至少有一個符合條件的「個人」。
在「統一個人」上啟用時，Data Cloud 會從「統一個人」設定檔內其中一個「個人」的管道連絡點選取。這些連絡點可能來自公司內的各種系統、品牌、分部或子公司。接著，Data Cloud 會根據公司所設定協調規則 決定的來源系統來選取屬性值。
此動作可能會導致使用不正確客戶內容的個人化客戶體驗，因為客戶可能在未預期的連絡點上收到目標內容或促銷。
負責品牌 A 的行銷小組會建立一個區段，以尋找可能升級居家保險的「統一個人」。作為啟用的一部分， Data Cloud 選取最常參與的電子郵件地址：john.smith@example3.com。
不過，這些品牌與地址不會在內容上相關聯。當 Cumulus 針對客戶傳送促銷以升級現有抵押貸款，該促銷會傳送至用於股票交易應用程式的電子郵件地址，而非與保險相關聯的電子郵件地址。
Cumulus 中的每個品牌的來源資料系統都不同，每個品牌會將資料會入至 Data Cloud。人員 John Smith 註冊公司品牌 A (保險品牌) 的Cumulus 電子郵件電子報。接著，John Smith 獨立註冊品牌 B (信用卡品牌)。最後，John Smith j註冊品牌 C (股票交易品牌) 的 Cumulus 行動應用程式。
負責品牌 A 的行銷小組會建立一個區段，以尋找可能升級居家保險的「統一個人」。作為此啟用的一部分，小組會選取電子郵件、SMS 和 MobilePush 連絡點的來源優先順序，讓這些連絡點先從系統 A 抵達、接著系統 B，最後到系統 C。
產生的資料延伸模組包含來自系統 A (保險品牌) 的電子郵件、來自系統 B (信用卡品牌) 的電話號碼和來自系統 C (股票交易應用程式) 的 MobilePush 金鑰。
不過，這些品牌與地址不會在內容上相關聯。當 Cumulus 針對客戶傳送促銷以升級其現有的抵押貸款時，則應使用保險品牌所用的電子郵件地址。但使用與信用卡品牌相關聯的電話號碼或股票交易品牌相關聯的應用程式並不適當。
每個管道的同意行為
Marketing Cloud 具有各種功能,可讓您用來管理客戶同意與偏好設定。
在此解決方案中，由於使用 MobilePush 金鑰作為 SubscriberKey 來協調旅程，因此會針對 John.Smith.MobilePush 的記錄檢查電子郵件 john.smith@example.com 的同意狀態。
SMS 訊息：Marketing Cloud 的 SMS 傳送的原生同意狀態會儲存在電話號碼層級 (與關鍵字),而非 SubscriberKey 層級 (不同於電子郵件)。在此解決方案中，電話 555-123-1234 的同意狀態已勾選，無論協調的 SubscriberKey 為何。請注意：如果您將訂閱所有連絡人的 SMS 活動設定為關鍵字，會覆寫原生同意並會選擇佳入連絡人。
僅限電子郵件活動
- 針對旅程中的每個「電子郵件」活動，建立抑制清單的關聯以防制傳送到指定電子郵件地址。建議僅對少於 200,000 個成員的旅程或清單使用此選項。傳送電子郵件之前，Journey Builder 會檢查與清單相關聯的電子郵件地址抑制狀態。
- 針對旅程中的每個「電子郵件」活動，建立發佈清單。傳送電子郵件之前，Journey Builder 會檢查與連絡人相關聯的發佈狀態，以瞭解是否已訂閱。
電子郵件、SMS 和 MobilePush 活動
- 在旅程中使用結束條件來監視「連絡人模型」中您所知道目前代表人員同意或偏好設定的屬性。Journey Builder 會在旅程持續時間監視這些值。
- 使用旅程項目的已啟用資料延伸模組前，請先在 Automation Studio 中執行自動化，以根據個別資料延伸模組，驗證每個連絡人或連絡點的同意或偏好設定狀態。無效的連絡人會在進入旅程之前遭到移除。
- 作為您旅程項目來源的一部分，請設定篩選條件以排除連絡人進入旅程。無效的連絡人會在進入旅程之前遭到移除。
替代 Omnichannel 協調流程方法
您可以使用 Data Cloud 篩選並協調一系列個別單一管道旅程，即可建立相似客戶體驗，而不是內含所有電子郵件、SMS 和 MobilePush 活動的旅程。
預設地址行為
此解決方案套件建議您更新「Journey Builder 設定」中的「預設傳送地址」，以覆寫 MobilePush 金鑰的預設電子郵件和 SMS 地址，改為傳送至儲存在已啟用資料延伸模組內的 EmailAddress 和 PhoneNumber。此作法會造成 Marketing Cloud 與 Data Cloud 系統中下游的更新。
MobilePush 金鑰 (MobilePush SubscriberKey) 連絡人記錄的更新
傳送中使用的電子郵件和 SMS 地址會新增至 Engagement 中的 MobilePush 金鑰 (MobilePush SubscriberKey) 連絡人記錄,進而產生具有電子郵件地址與 SMS 連絡點地址的 SubscriberKey。接著，此資訊會同步化至 Data Cloud 並反映在 MobilePush SubscriberKey 的「個人」記錄上，進而產生現在具有電子郵件與 SMS 連絡點地址的「個人」。
此洞最可能會造成更新衝突。參與可能會以新的預設電子郵件和 SMS 連絡點地址來更新「連絡人」記錄,而 Data Cloud 會使用相同連絡人的不同電子郵件和 SMS 連絡點地址來啟用新的受眾。
報告和疑難排解
- 所有傳送和旅程報告皆以用於旅程的 SubscriberKey 為基礎。針對此解決方案套件，MobilePush 金鑰的值會作為旅程的 SubscriberKey。
- 視您的報告策略而定，您可能需要其他流程來將此值轉化為旅程傳送所根據的電子郵件或 SMS SubscriberKey 或連絡點。
- 使用此解決方案的旅程無法使用啟用來依排程重新整理。重新整理會覆寫必要傳送關係設定以將 MobilePush 金鑰屬性關聯至訂閱者金鑰。如此一來，Journey Builder 會根據 MobilePush 金鑰 (代表 MobilePush SubscriberKey) 的值，預設所有協調流程、個人化和傳送對應。
