ドキュメントCustomer Journey AnalyticsCustomer Journey Analytics ガイド

Customer Journey Analytics で使用するスキーマの設計 upgrade-schema-architect

Last update: Sat Jan 10 2026 00:00:00 GMT+0000 (Coordinated Universal Time)

作成対象：

  • 管理者
NOTE
以前のアップグレード手順をすべて完了した後にのみ、このページの手順に従ってください。推奨されるアップグレード手順に従うか（ほとんどの組織に対して推奨）、Customer Journey Analytics アップグレードガイドで組織に合わせて動的に生成される手順に従うことができます。

  • 推奨されるアップグレード手順（ほとんどの組織に推奨）

    理想的な Customer Journey Analytics の実装に導く一連の手順です。

    詳しくは、Adobe Analytics から Customer Journey Analytics へのアップグレードを参照してください。

  • Customer Journey Analytics アップグレードガイド（お客様の具体的なニーズに合わせたカスタム手順）

    組織と一意の状況に合わせて調整されたアップグレード手順を動的に生成する新しいアップグレードガイドが使用できます。

    Customer Journey Analytics からガイドにアクセスするには、「Workspace」タブを選択し、左側のパネルで「Customer Journey Analytics にアップグレード」を選択します。画面の指示に従います。

Adobeでは、Adobe Experience Platform Data Collection を実装する際に、Customer Journey Analytics用のカスタム ​ エクスペリエンスデータモデル ​ （XDM）スキーマを作成することをお勧めします。 通常、このスキーマの作成は、実装の変更やコードに触れる前に行われます。 カスタムスキーマを使用すると、Adobe Analyticsの制約を継承したり、何千もの未使用フィールドを管理したりすることなく、簡潔で組織固有のデータコントラクトを設計できます。 組織で使用できるスキーマのタイプについて詳しくは、Customer Journey Analytics用のスキーマの選択 ​ を参照してください。

スキーマは、データを長期的に構造化する方法を洗練されたバージョンにすることを目的としています。 スキーマを変更すると、データ収集、検証、ダウンストリームサービスに影響が及ぶので、コストがかかります。 ビジネス要件に応じて、時間の経過と共にスキーマに追加できます。ただし、データがスキーマフィールドに流れ込み始めると、スキーマフィールドを削除することはできません。

スキーマとデータビューの比較

Customer Journey Analyticsのデータパイプラインには、データ収集とデータ解釈のために別々の領域が含まれています。 Adobe Analyticsからアップグレードする際の一般的な失策は、XDM で prop と eVar を動作に合わせて再作成しようとすることです。 代わりに、Web SDKを使用してデータを収集し、​ データビュー ​ を使用して、そのデータがレポートでどのように解釈されるかを判断します。

レイヤー
プライマリ目的
の所有物
に属さないもの
XDM スキーマ
収集されたデータの永続的な構造と意味の定義
イベントとエンティティの形状、フィールドの意味、関係、許可された値、チャネル間での再利用
番号付き「スロット」（eVar1/prop1）、アトリビューション/永続性ロジック、レポート固有の回避策
データビュー
分析での収集データの動作を定義
コンポーネント設定、アトリビューションおよび永続性動作、派生フィールド、フィルタリングされた指標、計算指標
フィールドの基本的な意味。その意味は、スキーマ内で安定している必要があります

スキーマとAdobe Analytics データ収集の比較

Customer Journey Analyticsが使用するエクスペリエンスデータモデルでは、他のほとんどの Analytics ソリューション（Adobe Analyticsを含む）よりも大幅に高い柔軟性が可能です。 堅牢なスキーマを確立することは、他の Analytics 製品に存在する制約の繰り越しを回避するための組織の機会です。

一般的なAdobe Analyticsの習慣
XDM とCJAのアプローチの改善
番号付きスロット周辺の設計（eVar1-eVar250、prop1-prop75）
安定した意味（search.term、content.category、user.membershipTier など）を持つフィールドを作成し、一貫して再利用する
データモデルへの永続性/割り当て/有効期限のエンコード
スキーマ内の永続的なファクトを取得します。データビューレベルでアトリビューションおよび永続性動作を適用します
複数の変数で同じ値を複製してレポート動作を実現
値を 1 回格納し、その値から複数のコンポーネント（ディメンション/指標）をデータビューで作成します
必要なカウントごとに一意の「指標フィールド」を作成する
適切なデータを 1 回（多くの場合、列挙、ブール値、文字列）取得し、データビューでフィルターされたカウントとして指標を定義します
レポートを「事前解決」する変数の設計
信頼性の高い方法で事実を把握するためのスキーマを設計し、データビューを使用してレポートセマンティクスを解決します

共通の属性を使用したスキーマの確立

多くのイベントに表示される再利用可能な属性のセットを標準化すると、チャネル間で統一されたスキーマが可能になります。 次に例を示します。

  • エクスペリエンスコンテキスト： サイト/アプリ名、環境、ロケール、チャネル、ブランド
  • ジャーニーコンテキスト： キャンペーン識別子、参照コンテキスト、実験識別子
  • ユーザーの状態： のログインステータス、メンバーシップ層、アカウントタイプ
  • インタラクションの詳細： インタラクション名/ タイプ、UI 領域、要素ラベル、エラーカテゴリ

重要なのは、チャネルに関係なくフィールドの表示内容を標準化することです。 本当に異なる概念を表さない限り、チャネル間で同じ概念を異なる方法でモデリングしないでください。 例えば、web キャンペーン ID とモバイルキャンペーン ID に別々のスキーマフィールドを使用するのは避けた方が良い場合があります。 スキーマフィールドを分けると、クロスチャネルの広告費用対効果データを確立するのが難しくなります。 レポートで区別が必要な場合は、チャネル別にセグメント化するか、複数のフィールドを連結して区別することができます。 同じスキーマフィールドを任意の数のディメンションまたは指標で使用できます。

1 つのスキーマ戦略を維持しながら複数のチャネルをサポートする実用的な方法は、コア +拡張機能 パターンを使用することです。

  • Core：チャネルやチーム全体に広く適用される フィールド
  • 拡張機能：必要な場合にのみ適用される チャネル固有またはドメイン固有のフィールドグループ（web インタラクション、コマース、モバイルライフサイクル、サーバーサイドの詳細）

このパターンでは、すべてのチームがチャネルに適用されないフィールドに入力しなくても、単一の組織スキーマ戦略がサポートされます。

適切な標準フィールドグループを優先

Adobeでは、標準化されたフィールドグループをニーズに合わせて使用し、組織固有の概念にはカスタムフィールドを使用して拡張することをお勧めします。

標準フィールドグループは、通常、次の場合に役立ちます。

  • 既知のフィールドセマンティクスを使用して、曖昧さを軽減する
  • チーム間の連携が容易になります
  • Adobe Experience Platform アプリケーション間の相互運用性をサポート

カスタムフィールドは、次の場合に適しています。

  • 組織に、標準フィールドに明確にマッピングされない概念があります
  • レポート、ガバナンスまたはアクティベーションの要件を満たすために、追加の属性が必要です
  • ビジネス固有の分類（内部コンテンツカテゴリなど）を表す場合

「指標の意味」が存在する場所の決定

Adobe Analyticsでは、多くのチームが events 変数を指標の移動先として扱います。 Customer Journey Analyticsでは、カウントする対象と解釈方法に応じて、複数の方法で指標をモデル化できます。

スキーマを構築する際は、事実に固執します。 例えば、error.type = "validation"、user.isLoggedIn = true、checkout.step = "shipping" です。 データビューの指標をカウントと定義し、それらのファクトに対するフィルター適用済みカウントを定義します。 例：

  • checkout.step （列挙/文字列）は次のことができます。

    • 「チェックアウト：発送手順に到達しました」（checkout.step == "shipping" をカウント）
    • 「チェックアウト：支払いステップに到達しました」

  • error.type （列挙/文字列）は次のことができます。

    • 「検証エラー」
    • 「認証エラー」

  • user.isLoggedIn （ブール値）は次を強化できます。

    • 「認証済みセッション」
    • 「認証済みコンバージョン」
TIP
何かを専用フィールドにするのか、後で派生フィールドにするのかを決定する場合は、広く有用で安定している場合は、スキーマで永続的な事実を取得することをお勧めします。 派生フィールドを使用して、コレクション後にデータを修正または形状を変更できます。

スキーマの手荷物がない移行中もAdobe Analyticsと同等の機能を維持

一部の組織は、Customer Journey Analyticsへのアップグレード中もAdobe Analytics レポートを続行する必要があります。 次のアプローチを使用すると、Analytics 固有のアーティファクトを長期的なスキーマデザインに導入しなくてもパリティを維持できます。

  1. Adobe Analyticsが認識し、自動的にマッピングする XDM フィールドパスを使用： 認識された XDM フィールドをEdge Networkを通じてAdobe Analyticsに送信すると、追加の設定なしで ​ 自動的にマッピング ​ されます。
  2. 組織固有の概念に対してカスタム XDM フィールドを使用： Analytics 変数に自動的にマッピングされない XDM フィールドは、Adobe Analyticsで ​ コンテキストデータ変数 ​ として転送されます。
  3. Adobe Analyticsの処理ルールを使用して、これらのコンテキストデータ変数を prop/eVars にマッピングする： ​ 処理ルール ​ を使用すると、最終的に、カスタム XDM フィールドを任意のeVarまたは prop にマッピングできます。 この概念は、スキーマをクリーンに保ち、Customer Journey Analyticsを中心に据えながら、Adobe Analyticsでのパリティレポートをサポートします。

関係者の特定と所有権の定義

フィールドの意味が合意され、維持された場合、スキーマデザインは成功します。 組織構造はさまざまですが、一般的に、次の役割が関与しています。

  • Analytics 管理者/アナリスト：レポートに関する質問を定義し、フィールドが意味のある概念を表していることを検証し、データビューで分析セマンティクスをレビューします。
  • 開発者/実装所有者:Web SDKを使用して確実にフィールドを収集でき、データレイヤー/アプリのインストルメンテーションに従っていることを確認します。
  • データアーキテクト/エンジニア：スキーマの一貫性、ドメイン間での再利用、ダウンストリームサービスとの互換性を確保します。
  • プライバシー/ガバナンスの関係者：データの最小化、同意の期待、データ使用の制約を確認します。

スキーマ変更の明確な所有者を定義します。 規則正しい変更制御を備えた安定したスキーマにより、ダウンストリームの破損を防ぎ、やり直しを減らします。 トラッキングガバナンスワークフローまたはツールを使用して、リクエストを民主化し、時間の経過に伴う変更制御を管理することを検討してください。

プライバシーとガバナンスに関する考慮事項

スキーマデザインは、組織のプライバシーポリシーに従って、プライバシーとガバナンスの期待を反映する必要があります。 スキーマを構築する際は、次の点を考慮してください。

次の手順

スキーマアーキテクチャを確立し、合意したら、Adobe Experience Platformでスキーマの作成を開始できます。 詳しくは、Customer Journey Analyticsで使用するカスタムスキーマの作成 ​ を参照してください。

recommendation-more-help
080e5213-7aa2-40d6-9dba-18945e892f79