Customer Journey Analytics で使用するスキーマの設計 upgrade-schema-architect
-
推奨されるアップグレード手順（ほとんどの組織に推奨）
理想的な 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用のカスタム Experience Data Model （XDM） スキーマを作成することをお勧めします。 このスキーマの作成は、通常、実装の変更やコードに触れる前に行われます。 カスタムスキーマを使用すると、Adobe Analyticsから制約を継承することなく、企業固有の簡潔なデータコントラクトを設計できます。 組織で使用可能なスキーマの種類について詳しくは、Customer Journey Analyticsのスキーマを選択を参照してください。
スキーマは、データを長期的にどのように構造化するかを洗練したバージョンにすることを目的としています。 スキーマへの変更は、データ収集、検証、下流サービスに影響を与えるため、コストがかかります。 ビジネス要件に応じて、スキーマに時間をかけて追加できます。ただし、スキーマフィールドは、データの流れ込みが開始されると削除できません。
スキーマとデータビューの比較
Customer Journey Analyticsのデータパイプラインには、データの収集と解釈のために別々の領域が含まれています。 Adobe Analyticsからアップグレードする場合、よくある間違いは、XDMでpropとeVarをビヘイビアーで再作成しようとすることです。 代わりに、Web SDKを使用してデータを収集し、 データビューを使用して、そのデータがレポートでどのように解釈されるかを判断します。
スキーマとAdobe Analytics データ収集の比較
Customer Journey Analyticsが使用するExperience Data Modelは、他のほとんどのAnalytics ソリューション（Adobe Analyticsを含む）よりも大幅に高い柔軟性を実現します。 強固なスキーマを確立することは、他のAnalytics製品に存在する制約の回避に役立ちます。
eVar1-eVar250、prop1-prop75）search.term、content.category、user.membershipTier）を作成し、一貫して再利用します共通の属性を使用したスキーマの確立
多くのイベントにまたがって表示される再利用可能な属性のセットを標準化することで、チャネルをまたいだ統合スキーマを構築できます。 次に例を示します。
- エクスペリエンスのコンテキスト： サイト/アプリ名、環境、ロケール、チャネル、ブランド
- ジャーニーコンテキスト： キャンペーン ID、参照コンテキスト、実験ID
- ユーザーの状態： ログイン状態、メンバーシップ層、アカウントの種類
- 操作の詳細： インタラクション名/タイプ、UI領域、要素ラベル、エラーカテゴリ
重要なのは、チャネルに関係なく、フィールドが何を表しているかを標準化することです。 真に異なるコンセプトを表現しない限り、チャネルごとに同じコンセプトを異なる方法でモデル化することは避けましょう。 たとえば、web キャンペーン IDとモバイルキャンペーン IDに別々のスキーマフィールドを持つことを避けるのが賢明かもしれません。 別々のスキーマフィールドを使用すると、クロスチャネルの広告費用対効果を確立することがより困難になります。 レポートで差別化が必要な場合は、チャネル別にセグメント化するか、複数のフィールドを連結してその区別を提供できます。 同じスキーマフィールドは、任意の数のディメンションまたは指標で使用できます。
単一のスキーマ戦略を維持しながら複数のチャネルをサポートする実用的な方法は、コア + エクステンション パターンを使用することです。
- チャネルやチーム全体に広く適用されるCore: フィールド
- 拡張機能：必要な場合にのみ適用される、チャネルまたはドメイン固有のフィールドグループ（web インタラクション、コマース、モバイルライフサイクル、サーバーサイドの詳細）
このパターンは、チームに不要なフィールドへの入力を強制することなく、単一の組織スキーマ戦略をサポートします。
フィールドグループは自由に選択できます
Adobeでは、ニーズに合わせて標準化されたフィールドグループを使用し、企業固有のコンセプトにはカスタムフィールドを拡張することをお勧めします。
標準フィールドグループは通常、次のような場合に役立ちます。
- 既知のフィールドセマンティクスを使用して、あいまいさを減らす
- 部門間の連携を容易に
- Adobe Experience Platformアプリケーション全体で相互運用をサポート
カスタムフィールドは、次のような場合に適しています。
- 組織には、標準フィールドに完全にマッピングされない概念があります
- レポート、ガバナンス、アクティベーションの要件を満たすには、追加の属性が必要です
- ビジネス固有の分類（社内コンテンツカテゴリなど）を表す
指標のカウント方法の決定
Adobe Analyticsでは、多くのチームがevents変数を指標を追跡するための唯一の手段として扱っています。 Customer Journey Analyticsでは、数える必要があるものとその解釈に応じて、複数の方法で指標を追跡できます。
スキーマを構築するときは、事実に固執する必要があります。 例：error.type = "validation"、user.isLoggedIn = true、checkout.step = "shipping"。 データビューで指標をカウントとして定義し、それらの事実に対するフィルタリングされたカウントとして定義します。 次に例を示します。
-
checkout.step（列挙/文字列）は次の電力を使用できます：- “Checkout: Shipping step reached” （count where
checkout.step == "shipping"） - 「チェックアウト：支払い手順に達しました」
- “Checkout: Shipping step reached” （count where
-
error.type（列挙/文字列）は次の電力を使用できます：- 「検証エラー」
- 「認証エラー」
-
user.isLoggedIn（ブール値）は次の値に対して有効です：- 「認証済みセッション」
- 「認証済みコンバージョン」
スキーマ手荷物を持たずに、移行中にAdobe Analyticsとのパリティを維持
一部の企業では、Customer Journey Analyticsにアップグレードする際にAdobe Analytics レポートを続行する必要があります。 次のアプローチを使用すると、Analytics固有のアーティファクトを長期的なスキーマ設計に導入せずにパリティを維持できます。
- Adobe Analyticsが認識し、自動的にマッピングするXDM フィールドパスを使用する： Edge Networkを通じて認識されたXDM フィールドをAdobe Analyticsに送信すると、追加の設定なしで自動的にマッピングされます。
- 組織固有の概念にカスタム XDM フィールドを使用： Analytics変数に自動的にマッピングされていないXDM フィールドは、Adobe Analyticsで コンテキストデータ変数として転送されます。
- Adobe Analytics処理ルールを使用して、これらのコンテキストデータ変数をprop/eVar: 処理ルール にマッピングすると、カスタム XDM フィールドを任意のeVarまたはpropにマッピングできます。 このコンセプトは、Adobe Analyticsのパリティレポートをサポートし、スキーマをクリーンでCustomer Journey Analyticsを中心に保ちます。
関係者の特定と所有権の定義
フィールドの意味が合意され、維持されると、スキーマデザインは成功します。 組織構造は多岐にわたりますが、一般的に次の役割が関与します。
- Analytics管理者/アナリスト: レポートに関する質問を定義し、有意義な概念を表すフィールドを検証し、データ ビューで分析セマンティクスを確認します。
- 開発者/実装オーナー: Web SDKを使用してフィールドを確実に収集し、データレイヤー/アプリのインストルメントに合わせることができます。
- データアーキテクト/エンジニア: スキーマの一貫性、ドメイン間での再利用、ダウンストリームサービスとの互換性を確保します。
- プライバシー/ガバナンス関係者: データの最小化、同意の期待、データ使用の制約について確認します。
スキーマの変更に対して明確な所有者を定義します。 規則正しい変更管理を備えた安定したスキーマは、下流での破損を防ぎ、手戻りを減らします。 トラッキングガバナンスワークフローやツールを使用して、リクエストを民主化し、変更管理を長期的に管理することを検討する。
プライバシーとガバナンスに関する検討事項
スキーマの設計では、組織のプライバシーポリシーに従って、プライバシーとガバナンスに対する期待を反映する必要があります。 スキーマを設計する際には、次の点を考慮してください。
- 定義済みのユースケースをサポートするために必要な情報だけを収集。
- 同意とデータ使用要件が、収集戦略に反映されるようにします。 詳しくは、Web SDKを使用してお客様の同意データを処理するを参照してください。
- Adobe Experience Platformのガバナンスツール内で、機密性の高いフィールドがどのようにラベル付けされ、制御されているかを検討します。 詳しくは、Adobe Customer Journey AnalyticsとData Governanceを参照してください。
次の手順
スキーマアーキテクチャを確立して合意したら、Adobe Experience Platformでスキーマアーキテクチャの作成を開始できます。 詳しくは、Customer Journey Analyticsで使用するカスタムスキーマの作成を参照してください。