客戶歷程通常跨越多個資料來源、管道和階段,因此非常複雜。這些最佳做法提供清晰的框架,可簡化歷程設計和執行,確保行銷團隊能有效運作而不會被壓垮。

簡介

每個客戶歷程都是個人的,會隨著每個人的需求和行為而改變。若做法正確,我們的行銷就會滿足客戶的需求,同時推動他們完成里程碑,以實現更深層的參與。透過傾聽客戶訊號,每個人都能依照自己的步調完成歷程,其中每個接觸點都是個人化的,並與其獨特內容相關。

鑑於此複雜性,多步驟歷程可能會以和傳統行銷活動不同的方式,挑戰行銷和行銷營運團隊。

此框架有助於管理此複雜性。它涵蓋有效歷程策略的關鍵元件,包括:

減少移動部分,簡化資料管理

清潔的資料是改善客戶體驗的燃料。您越能簡化資料管理實務,就越能專注於最佳化構成整體客戶體驗的歷程。歷程類似於機器,而且就像機器一樣,維護的複雜程度會隨著移動部分數量的增加而增加。若要簡化,請儘可能減少移動部分的數量。

請思考兩個關鍵部分以降低複雜性。首先,用於將資料帶入 Experience Cloud 資料湖並儲存在該處的資料集。第二,需要啟用的資料集,才能對即時客戶輪廓做出貢獻。雖然運用這些功能有許多好處,但若要成功運用這些功能,仍需圍繞下列考量進行謹慎規劃:

從高層面來看,減少資料管理中移動部分的最佳方式,就是仔細考慮您利用的每個資料來源的使用案例。從這裡,您可以決定在 Experience Platform 中擷取和管理該資料的最簡單方法,同時仍可啟用使用案例所需的所有功能。

讓我們來比較在客戶歷程中擷取及運用資料的選項。

選項 1 - 透過 Journey Optimizer 中的自訂動作存取外部資料來源

此方法可讓您直接連線至外部資料來源,而無需儲存在 Experience Platform 資料湖中。

若要運用此方法,請考慮下列有關您使用案例的問題:

選項 2 - 未針對資料湖中的輪廓啟用擷取到資料集的資料

此方法可讓您根據相關事件資料觸發並個人化您的歷程,而無需讓資料來源直接貢獻給即時客戶輪廓。

若要運用此方法,請考慮下列有關您使用案例的問題:

選項 3 - 擷取到資料湖中啟用輪廓的資料集的資料

此方法可讓您建立客群、身分圖表和輪廓,然後在 Journey Optimizer 中的多個歷程以及任何其他 RT-CDP 目的地中運用這些元件。

選項
支援的資料類型
資料持續儲存在資料湖中?
為輪廓啟用的資料集?
1 – 透過自訂動作的外部資料來源
時間序列資料和記錄序列資料
2 – 未針對即時客戶輪廓啟用資料集
時間序列資料
3 – 已啟用輪廓的資料集
時間序列資料和記錄序列資料

將您的客戶歷程劃分為小型歷程

在歷程中,行銷管道會引導客戶了解對整體客戶體驗重要的里程碑。客戶可能會按照自己的步調完成這些里程碑,而他們收到的行銷接觸點可能會因他們自己是否已完成某些里程碑而有所不同。在 Journey Optimizer 中,行銷接觸點之間的時間可以使用「等待」活動控制,而個人化的整體協調流程則可透過「分割」活動管理。

即使是簡單的客戶歷程,也可能迅速讓負責建立和管理這些歷程的行銷和行銷營運團隊不知所措。

在此範例中,系統會使用兩個行銷管道,引導客戶完成三個里程碑。歷程策略很簡單:系統會傳送初始通訊,如果客戶在該期間內未完成預期的里程碑,系統會在幾天後傳送提醒。

在此歷程中,客戶透過加入忠誠度方案來進入。接著,系統會鼓勵他們下載行動應用程式,然後進行行銷工作,引導他們完成第一筆和第二筆忠誠度交易。

上述歷程的圖表如下:

雖然此歷程看似簡單,但範例包括客戶可選擇的 20 多個獨特路徑 (20 只是計算變得過於困難的點)。一位客戶可能只接收前兩個行動應用程式通訊,而另一位客戶則可能接收歷程中的每個通訊。第三位客戶可能會完成歷程,但只接收與忠誠度交易相關的通訊。

單一歷程中可能發生的多種體驗會導致複雜的情況,可能會減慢負責建立和管理歷程的團隊的速度。由於引進了其他行銷管道或接觸點,這種複雜性會以指數方式增加。

為了協助管理此複雜性,下列技術可用來將歷程分成更小且更容易管理的子歷程。

步驟 1 – 將端對端歷程視覺化

一旦完整的端對端客戶歷程以視覺化方式呈現後,您便可清楚識別歷程中的高階階段與里程碑。

階段 1:下載行動應用程式

階段 2:進行第一筆交易

階段 3:進行第二筆交易

步驟 2 – 為歷程圖加上階段註釋

使用清楚標示的階段,將每個階段分隔成其自己的個別「子歷程」。清晰地標示要隨著這些子歷程一起推進的業務目標可能也很有用。當團隊開始執行所需的工作時,這將進一步協助保持一致性。

步驟 3 – 透過單獨的「子歷程」建立較大的端對端歷程

隨著大型客戶歷程細分為較小的子歷程,請專注於將這些高階圖表轉換為更具技術性的需求和設計,以便在 Journey Optimizer 中建立。

透過此方法,可開發三個相對簡單的客戶歷程。然後,這些較小的歷程結合以建立原本說明的更大、更複雜的歷程。

透過此方法,可以建立複雜的客戶歷程,並降低導致不必要的複雜性的風險。

標記您簡化歷程維護的方式

一旦歷程上線,工作就不會停止。必須監視其傳遞和績效,並應建立完善的新版本,作為持續最佳化的一部分。這通常需要透過同時執行多個歷程以及在不同業務單位或行銷團隊中完成。

在這種情況下,必須在組織的 Journey Optimizer 執行個體的整組即時歷程中快速檢閱及找到歷程。

達成此目標的常見方法是使用命名慣例。雖然這些命名慣例通常都是經過審慎思考且出於好意而建立,但有時候,它們可能會增加客戶歷程管理的複雜性,而非降低複雜性。

以下範例可說明這種情況是如何發生的。

標記歷程時,典型的命名慣例會使用已定義的結構。該結構中的許多元素包含中繼資料,其範圍超出正在建立的客戶體驗。範例命名慣例結構旨在方便根據所選中繼資料識別歷程,詳情如下所示:

<行銷利害關係人團隊> - <行銷目標> - <行銷活動/歷程名稱> - <階段/里程碑名稱> - <上市日期>

正確套用時,運用此慣例的歷程可能具有以下名稱:

生命週期行銷 – 教育 – 客戶入門 V2 – 應用程式教育 – 2025 年第 3 季度

如果單一團隊成員正在管理和標記所有歷程,則慣例可能會成功套用。但是,當工作範圍跨越多個團隊成員或多個團隊時,套用慣例時不出錯的可能性會大幅降低。

以下展示了運用此命名慣例同時執行許多歷程時的 Journey Optimizer 執行個體:

雖然這是常見的方法,但有更好的方式。

Journey Optimizer 中的標記和標記類別可讓您完成與命名慣例相關的許多指定目標,而且沒有上述範例中所述的複雜性。團隊可以篩選這些標記和類別,而歷程名稱可以更清楚地聚焦於所驅動的客戶里程碑。

請依照下列步驟,運用這些功能,將您的命名慣例方法轉換為較簡單的方法。

步驟 1

請平台管理員為您用來組織歷程的任何屬性建立標記類別。良好的候選標記類別是您的團隊可能會以更複雜的命名慣例實作的額外中繼資料。

步驟 2 - 在每個類別中,建立建立歷程時可供應用程式使用的標記。這些標記值應代表描述該類別中可能歷程的中繼資料。

步驟 3 - 啟動新歷程時,請確定每個已建立的標記和標記類別皆已正確套用。每個歷程可能有多個分類標記。

步驟 4 - 使用歷程名稱來表示由歷程驅動的里程碑。現在,透過即時歷程檢視是一項輕鬆得多的工作。此外,我們並未喪失根據先前透過命名慣例儲存在歷程名稱中的中繼資料來找出歷程的能力。我們可以篩選這些標記和標記類別來執行此操作。

結論

雖然客戶歷程是一個激動人心的機會,讓行銷團隊可以利用技術建立豐富、個人化客戶體驗,但建立這些歷程的團隊仍有可能因為複雜度過高而無法勝任。為避免出現此結果,請留意下列簡化領域: