10 分
style
article-header-section

Adobe Analytics から Customer Journey Analytics（CJA）への移行には、データ収集、プラットフォームの設定、統合に至るまで、綿密な準備が必要です。このガイドでは、スムーズな移行を実現し、Adobe Experience Platform 内で CJA の潜在能力を最大限に引き出す主な手順について説明します。

Adobe Analytics（AA）から Customer Journey Analytics（CJA）への移行は、複雑ながらも価値ある変換で、企業は Adobe Experience Platform（AEP）内でより高度な分析機能を活用できるようになります。移行前のプロセスは、主にデータ収集、現在の Adobe Analytics の設定、既存の統合によって異なります。

このガイドでは、スムーズな移行計画プロセス、つまり CJA の準備ステージを確実に進める 3 つの主な考慮事項について説明します。

1. データ収集要件について

データ品質の重要性

「ゴミを入れれば、ゴミしか出てこない」。高品質のデータ収集は、分析の基盤となるので不可欠です。移行前にトラッキング実装を徹底的にレビューし、精度と一貫性を確保する必要があります。

Web SDK と AppMeasurement の比較

移行の最も重要な側面の 1 つは、現在のデータ収集設定を評価することです。

データレイヤーと Tag Management システムのレビュー

移行は、次のデータ収集アプローチを見直し、最適化する機会となります。

アプローチ

幸いなことに、既にすべてのプラットフォームを Web SDK に移行し、AEP の概念にも精通していました。さらに、データレイヤーと Tag Management の設定はすべてのプラットフォームで標準化されていました（CEDDL と EDDL を組み合わせたハイブリッドデータレイヤーアプローチを使用しています）。それでもなお、ローンチプロパティと SDR の徹底的な監査を実施しました。ページデータやイベントデータといった主な属性が、高いデータ品質で一貫して追跡されていることを確認しました。SDR では、すべての属性を批判的に評価し、その必要性を検証し、CJA の新機能（派生フィールドなどのコンポーネント設定の可能性）を活用してどのように改善できるかを評価しました。

2. Adobe Analytics 設定の評価

現在の Adobe Analytics 環境は、移行の複雑さに大きく影響します。主な考慮事項は次のとおりです。

データ移行戦略

Adobe Analytics から CJA にデータを移行する際には、移行するデータと適切な期間（バックフィル長）を決定することが重要です。すべてを移行するのではなく、この機会に分析設定とトラッキング計画を調整し、関連データのみが移行対象に含まれるようにしてください。

アドビでは、デフォルトで 13 か月分の履歴データを CJA に読み込むことができます。ただし、ビジネスニーズによっては、より長いデータ保持期間が必要になる場合があります。例：

データ保持のニーズとストレージに関する考慮事項のバランスを取ることは、CJA の設定の最適化に重要です。

データ移行方法の選択

CJA へのデータ移行方法の決定も重要な手順です。次の 2 つの主なオプションがあります。

適切な方法の選択は、特定のデータニーズとインフラストラクチャによって異なります。データ移行に関して学んだ教訓について詳しくは、この記事を参照してください。

コンポーネントの移行

Adobe Analytics から CJA へコンポーネントを 1 対 1 で移行するのではなく、この移行は新たなスタートの機会となります。Adobe Analytics の実装では、多くの場合、時間の経過と共に、冗長なコンポーネント、古いコンポーネント、ドキュメントが不十分なコンポーネントが蓄積されます。

アプローチ

コンポーネント移行ツールの使用を回避し、代わりに効率化された新しい設定を構築しました。スムーズな移行を実現する、関係者による分析を行い、必須のダッシュボードを特定しました。これにより、ダッシュボードの合計数が 50％以上削減され、重複または未使用のレポートとコンポーネントが削除されました。また、セグメント、指標、その他のコンポーネントをレビューし、調整することで、レガシー要素が引き継がれるのを防ぎました。

データ移行では、Adobe ソースコネクタの制限（新しい CJA 設定では eVar や prop は不要だったので）を考慮し、データフィードを選択しました。以前の複雑さをシンプルに新しいシステムに移行するのではなく、移行をクリーンアップと最適化の機会と捉え、最終的にはより効率的な分析環境を構築し、セルフサービス分析の強化にもつなげました。

3. カスタム統合とデータ変換

これは、多くの場合、移行の中で最も困難な部分です。多くの組織では、Adobe Analytics を次のようなサードパーティシステムと統合しています。

CJA は AEP 内で動作するので（書き出しに関していくつかの制限があります）、これらの統合は、次の使用可能なオプションを使用して再設定する必要があります。

データ変換の課題

データ変換は、移行時の大きな課題です。標準コネクタはある程度の変換を提供しますが、API ベースのアプローチ（クエリサービスなど）では、オブジェクト指向の AEP データをリレーショナル構造（例：テーブル、ビュー、データレイク）に変換する際に、慎重に処理する必要があります。これらのプロセスを適切に構造化し、最適化することは、異なるプラットフォーム間でデータの使いやすさを確保する上で不可欠です。

アプローチ

データの読み込みと書き出しの設定は比較的簡単でしたが、一部のデータは内部データレイクに移行していました。このため、FTP と Data Warehouse API を通じた毎日のデータウェアハウスの書き出しに依存していました。CJA には現在、このような書き出しのオプションが限られているので（例えば、10 個のディメンションと 10 個の指標の完全なテーブル書き出しのサポートなど）、AEP からデータセット単位でデータを書き出すことにしました。

ニーズにとって、Query Service API と AEPP を組み合わせることが最も効果的なアプローチであることがわかりました。これにより、内部データレイクからデータセットにアクセスし、必要に応じて保持できるようになりました。ただし、データは CJA ではなく AEP から取得されていたので、ラストクリックアトリビューションや訪問ベースの指標など、永続的な属性が欠けていました。このギャップを埋めることを目的に、SQL と Python を使用して、これらの要素を再作成しました。幸いにも、アドビには訪問特定用の事前定義済みの関数が用意されており、標準の SQL ウィンドウ関数を使用することで、CJA で使用可能なすべての要素を再構築できます。

これらのプロセスを変更するには、内部の IT リソースが必要なので、データパイプラインを事前に計画することは重要です。読み込み／書き出し操作が増えるほど、複雑さが増し、メンテナンスの労力とリソースの需要が増大します。プロセスを可能な限り効率化することで、データの一貫性を確保しながらオーバーヘッドを最小限に抑えることができます。

最終的な考察

Adobe Analytics から Customer Journey Analytics への移行は、シンプルなリフト＆シフトプロセスではありません。綿密な計画、データの最適化、戦略的な意思決定が必要です。データ収集のレビュー、コンポーネントの調整、統合の慎重な管理によって、企業は不要な複雑さを回避しながら、CJA の潜在能力を最大限に引き出すことができます。

移行を成功させることで、AEP 内でより強力で柔軟性が高く、今後実証される分析環境の基盤が構築されます。

style
article-content-section