從 Adobe Analytics 移轉至 Customer Journey Analytics (CJA) 需要跨資料收集、平台設定和整合進行謹慎的準備。本指南概述在 Adobe Experience Platform 中確保順利轉換並解鎖 CJA 完整潛力的關鍵步驟。

從 Adobe Analytics (AA) 移轉至 Customer Journey Analytics (CJA) 是複雜但極具價值的轉換，可讓企業運用 Adobe Experience Platform (AEP) 中更進階的分析功能。移轉前流程主要取決於您的資料收集、目前的 Adobe Analytics 設定和現有的整合。

本指南探討三個關鍵考量因素，以確保順暢的移轉規劃流程，或我們稱之為 CJA 準備階段。

1. 了解資料收集需求

資料品質的重要性

「垃圾進，垃圾出。」確保高品質的資料收集至關重要，因為它是您分析的基礎。移轉前，必須對追蹤實作徹底審查，以確保正確性和一致性。

Web SDK 與 AppMeasurement 的比較

移轉最重要的一個方面是評估目前的資料收集設定：

• 如果您的平台 (Adobe 標記屬性) 已在 Web SDK 上執行，移轉作業會更簡單明瞭。
• 如果您的平台仍使用 AppMeasurement，則還需要更多時間進行調整，因為 Web SDK 引進了數個新概念，例如體驗資料模型 (XDM) 結構描述、身分識別和資料集。雖然 AppMeasurement 在技術上可搭配 AEP 使用，但會不斷增加複雜性。我們強烈建議您只使用 Web SDK。

檢閱資料層和標記管理系統

移轉提供重新檢視及最佳化資料收集方法的機會：

• 調整並標準化不同平台上的資料層。選擇正確的資料層設定。您可能想要將資料層從傳統的客戶體驗數位資料層 (CEDDL) 更新為事件導向 (EDDL) 或混合方法。
• 確保 Adobe 標記 (Launch) 或任何其他標記管理系統已最佳化，以支援 AEP/CJA 需求。
• 檢閱解決方案設計參考 (SDR) 並調整資料收集策略以符合 CJA 需求。

方法

幸運的是，我們已將所有平台移轉至 Web SDK，而且熟悉 AEP 概念。此外，我們的資料層和標記管理設定已跨所有平台標準化 (我們使用結合 CEDDL 和 EDDL 的混合資料層方法)。儘管如此，我們還是徹底稽核了 Launch 屬性和 SDR。我們已確保以高資料品質一致地追蹤關鍵屬性，例如頁面和事件資料。在 SDR 中，我們嚴格評估了每個屬性，質疑其必要性，並評估如何使用 CJA 的新功能 (元件設定的可能性，例如衍生欄位) 來改善。

2. 評估您的 Adobe Analytics 設定

您目前的 Adobe Analytics 環境在移轉複雜性方面發揮了重要作用。關鍵考量事項包括：

資料移轉策略

將資料從 Adobe Analytics 移轉至 CJA 時，必須決定應該移轉哪些資料以及適當的時段 (回填長度)。使用此機會來調整您的分析設定和追蹤計劃，而非傳輸所有內容，以確保只包含相關資料。

預設情況下，Adobe 允許將 13 個月的歷史資料匯入 CJA。不過，根據您的業務需求，可能需要更長的資料保留期。例如：

• 如果您的業務經歷季節性高峰 (例如，9 月至 11 月)，並以 3 個月的分析週期運作，則可能需要 15 個月的歷史資料。此考量不僅對於分析用途很重要，對於授權需求也很重要。
• 更長的資料保留期可提供更佳的逐年比較和趨勢分析，但也會增加資料量、儲存成本及處理複雜性。仔細評估您要透過 CJA 涵蓋的使用案例。

在資料保留需求與儲存考量之間取得平衡，是最佳化 CJA 設定的關鍵所在。

選擇資料移轉方法

決定如何將您的資料轉移至 CJA 是另一個關鍵步驟。您有兩個主要選擇：

• Adobe Analytics 來源連接器：使用 CJA 整合的更簡單、自動化程度更高的方法。
• 資料摘要：更靈活但更複雜的方法，允許更深入的自訂資料轉移。

選擇正確的方法取決於您的特定資料需求和基礎結構。如需資料移轉的相關課程，請參閱本文。

元件移轉

此轉換不會將元件從 AA 一對一移轉到 CJA，而是提供重新開始的機會。長期下來，Adobe Analytics 實施通常會累積冗餘、過時或記錄不全的元件。

方法

我們避免使用元件移轉工具，而是建立全新的簡化設定。為了確保順利轉換，利害關係人分析指出哪些儀表板是必不可少的。如此一來，總數減少了 50% 以上，且消除了重複或未使用的報告和元件。我們檢閱並完善區段、量度和其他元件，以防止舊版元素轉移。

針對資料移轉，由於其限制，我們選擇使用資料摘要，而非 Adobe 來源連接器 (我們新的 CJA 設定中不想要任何 eVar 和 prop)。我們不只是將舊的複雜性轉移到新系統中，而是將移轉視為清理和最佳化的機會，最終建立一個更有效率的分析環境，這也促進了自助服務分析。

3. 自訂整合與資料轉換

這通常是移轉中最具挑戰性的部分。許多組織都將 Adobe Analytics 與第三方系統整合，例如：

• 資料倉儲 (透過 API、FTP 或自訂管道)
• 郵寄系統、行銷自動化工具和建議系統
• CRM 和個人化引擎

由於 CJA 在 AEP 內運作 (且對匯出有一些限制)，因此必須使用可用的選項重新設定這些整合，包括：

• AEP 資料擷取 API
• Adobe 建置和自訂連接器
• 用於轉換和路由資料的資料準備管道

資料轉換挑戰

資料轉換是移轉期間的一大挑戰。雖然標準連接器提供了一定程度的轉換，但 API 型方法 (例如查詢服務) 在轉換為關聯式結構 (例如表格、檢視或資料湖) 時，需要謹慎處理物件導向的 AEP 資料。正確建立和最佳化這些流程，對於確保不同平台上的資料可用性至關重要。

方法

雖然我們確實將部分資料轉移至內部資料湖，但我們的資料匯入和匯出設定仍相對簡單明瞭。為此，我們依賴透過 FTP 和資料倉儲 API 的每日資料倉儲匯出。由於在 CJA 中目前此類匯出的選項有限 (例如，10 個維度和 10 個量度的完整表格匯出支援)，我們選擇從 AEP 以資料集為基礎匯出資料。

根據我們的需求，查詢服務 API 結合 AEPP 已被證明是最有效率的方法。這可讓我們從內部資料湖存取資料集，並視需要保留這些資料集。不過，由於資料源自於 AEP 而非 CJA，因此缺少持續存在的屬性，例如上次點按歸因或造訪型量度。為了彌補這個差距，我們使用 SQL 和 Python 重新建立這些元素。幸運的是，Adobe 為造訪識別提供了預先定義的函式，而標準 SQL 視窗函式使得在 CJA 中重新建構所有可用的內容成為可能。

預先規劃資料管道非常重要，因為修改這些流程需要內部 IT 資源。相關的匯入/匯出作業越多，複雜性就越高，這會增加維護工作與資源需求。讓流程儘可能簡化有助於將開銷降至最低，同時確保資料的一致性。

結語

從 Adobe Analytics 移轉至 Customer Journey Analytics 並非簡單的提升與轉換流程，而是需要周全的規劃、資料最佳化及策略決策。企業可檢閱資料收集、調整元件並謹慎管理整合，藉此發揮 CJA 的完整潛能，同時避免不必要的複雜性。

成功的移轉為 AEP 中更強大、更靈活、更符合未來需求的分析環境奠定了基礎。