派生フィールドガイドライン
Customer Journey Analytics 派生フィールド を使用すると、ソースデータセットを変更することなく、クエリ時にデータを変換、分類、エンリッチできます。 そうした柔軟性を確保できなければ、複雑さ、パフォーマンスの問題、保守のオーバーヘッドを招く可能性があります。
この記事では、派生フィールドを操作するためのガイドライン（ベストプラクティス、ガードレール、一般的な落とし穴）について説明します。 対象となるオーディエンスは、データアーキテクト、製品管理者、アナリストで、次のことをおこなう必要があります。
-
パフォーマンスを最適化: クエリの実行を遅らせるパターンやシステム制限に達するパターンを特定して、ジョブに適したツールを選択します。
-
メンテナンス性を向上：明確で、モジュール化され、更新しやすい派生フィールドロジックを構築します。
-
正確性の確保：分類、属性、データ変換で一般的な論理エラーを回避します。
この記事では、次のテーマに関するセクションを整理します。
各セクションには、次のものが含まれます。
- パターンを使用して、派生フィールド定義で観測可能なシグナルを検出します。
- リスク診断：パターンに問題がある理由 考えられる理由は、パフォーマンス、データ品質、または メンテナンス に対する悪影響です。
- 推奨事項：実装をリファクタリングまたは改善するための具体的な手順。
これらのガイドラインは、Customer Journey Analyticsの効率的で拡張性の高い、セマンティックに正しい実装を作成するのに役立ちます。 既存のデータビューを監査したり、新しい派生フィールドをデザインしたり、ガバナンスツールを構築したりする際に、これらのガイドラインを適用します。
高基数の派生フィールド
この節では、高基数の派生フィールドを参照するデータビューのデフォルトセグメントについて説明します。
パターン
リスク診断：パフォーマンス
- ページ URLやその他の基数の高いディメンションに接する派生フィールドでフィルタリングされるデフォルトセグメントは、データビューに対するすべてのクエリに遅延を追加します。
レコメンデーション
- ページ全体のURLや、同様にカーディナリティの高いコンポーネントを、データビューのデフォルトセグメントで直接参照することを避ける。 重いURL ロジック（複雑な ケース When、正規表現Replace、複数の文字列関数）を データ準備または ルックアップデータセット にプッシュすると、結果として得られる分類は、よりシンプルで基数の低い次元に到達します。
- 正規化されたページ名、サイトセクション、事前分類されたURL グループなど、基数の低いキーを優先する。
- 既存のデータビューのデフォルトセグメントと派生フィールドを定期的に監査して、基数の高いディメンション（ページ URL、キャンペーン ID、生のクエリ文字列）への参照を確認し、正規化またはグループ化されたキーにリファクタリングします。
ルールチェーンの場合のケースが複雑すぎる
この節では、Case When規則の複雑すぎるチェーンについて説明します。
Customer Journey Analyticsでは、派生フィールドごとに明示的な関数および演算子制限が適用されます（例えば、演算子の最大数、型ごとの関数の最大数）。 関数内の複雑な関数とチェーンは、維持が困難で、エラーが発生しやすくなります。
パターン
-
非常に大きなCase Whenは、複雑な If およびElse If チェーンで機能します。
- 多くの条件（例：20を超える演算子）またはディープネスティング（ネストされた ケースの3または4 レベルを超える ケース When Ifおよびその他If ロジック）。
- 同じフィールドで異なる値を持つ条件を繰り返しました。
-
定数文字列のマッチングを繰り返しました。
accordion 例 
リスク診断：パフォーマンス、データ品質、高いメンテナンス
- メンテナンス性とエラーのリスク：モノリシックルールブロックとしてエンコードされたロジックは、デバッグと更新が困難です。
- 潜在的なパフォーマンスと制限のリスク：演算子または関数の制限をヒットまたはアプローチする可能性があります。特に、分類のようなパターンの場合です。
レコメンデーション
- 複数の派生フィールドに分割する： 例えば、すべてを1つの巨大なルールにまとめるのではなく、キャンペーン正規化 （一貫性のないキャンペーン識別子を規範的な値にマッピング）をチャネルグループ化から分離します。
- ルックアップデータセットの使用： 多くの If Value _value_条件_criterion_次に、_value_をvalue に設定します。この条件は、長いCase When チェーンを使用する代わりに、Lookup関数と組み合わせた ルックアップデータセット としてより適切に実装されます。
- データビューコンポーネントフィルターを使用します。 ロジックの一部が単純に不正な値を除外する場合は、そのロジックを派生フィールドに埋め込む代わりに、データビューコンポーネントレベルでinclude excludeを使用します。
誤った使用
この節では、派生フィールドの誤った使用について説明します。 特に、代替案がより良い解決策である場合。
パターン
-
派生フィールドは、コンポーネント設定で既に使用可能な動作をレプリケートします。
-
ケースの正規化、トリミング、または単純なフィルタリング（例：
unknown、undefinedまたはnullを除く）で、追加の複雑さはありません。 -
数値範囲の基本的なグループ化。
accordion 例 
代わりに、データビューのディメンションで値のグループ化を使用してください。
-
次または前でコーディングされた永続性またはアトリビューションロジック、またはデータビュー アトリビューション と有効期限の設定で十分な手動シーケンスロジック。
-
条件の下にある既存の指標を単純にカウントする派生指標。
accordion 例 
このアプローチは、フィルタリングされた指標または除外値を含めるが達成できる指標を再現します。
-
リスク診断：データ品質、高いメンテナンス
- 冗長な複雑さ：派生フィールドは、よりシンプルな組み込みのデータビュー機能が存在する場合に使用されます。
- ガバナンスリスク：他のユーザーは、ネイティブ設定ではなく派生フィールドが存在する理由を理解できない場合があります。 このパターンは、派生フィールドの管理における混乱を増加させます。
- 再利用性の低下：条件付きフラグを派生フィールドとしてエンコードすると、プロジェクトをまたいで異なるフィルターを使用したベース指標の再利用が難しくなります。
レコメンデーション
-
トリミング/小文字：マルチステップの変換を組み合わせる必要がない限り、部分文字列および ビヘイビアー コンポーネントの設定を使用します。
-
値の除外：派生フィールドではなく、データビューコンポーネントレベルの指標またはディメンション値に除外値を含めるを使用します。
-
属性と永続性：次または前またはその他のシーケンシャルロジックを使用して派生フィールドでディメンションをシミュレートする代わりに、データビュー 永続性 設定（配分モデルおよび有効期限）を使用します。
-
数値のグループ化：派生フィールドを数値のままにし、データビューで、Case When チェーンのハードコーディング範囲ラベルではなく、上部にグループ化されたディメンションを作成できるようにします。
-
条件付きロジック：単純な0または1のフラグロジックを次のいずれかに変換します。
- Analysis Workspaceで適用される「値を含める」または「値を除外」フィルターロジックを含む元の指標。
- データビューコンポーネント設定の設定を使用したフィルタリングされた指標。
指標とディメンションの誤分類
この節では、指標とディメンションの誤分類について説明します。
パターン
-
派生フィールドは、次の要素を明確に生成します。
- 数値の出力（カウント、比率、または算術）ですが、コンポーネントはディメンションとして設定されます。
- カテゴリ出力（ラベルまたは文字列）ですが、コンポーネントは指標として設定されます。
-
派生フィールドは、0/1 フラグを文字列としてエンコードします。
Customer Journey Analyticsでは、データビューレベルで数値フィールドをディメンションに、文字列フィールドを指標に変換することができますが、不整合があると混乱を招くレポートが作成される可能性があります。
リスク診断：データ品質
- セマンティックの不一致：コンポーネントタイプが派生結果の性質と一致しないため、コンポーネントタイプの分析や集計が困難になります。
レコメンデーション
-
出力が数値の場合：
- データビューでコンポーネントタイプを 指標 に設定します。
- コンポーネントがサブセット指標（例：チェックアウトページビュー）を表す場合は、派生文字列と計算指標を上部に追加する代わりに、データビュー内でフィルタリングされた指標を使用します。
-
出力がラベルの場合：
- コンポーネントタイプを Dimension に設定し、それに応じて永続性設定（配分モデルおよび有効期限）を設定します。
マーケティングチャネルとキャンペーンロジックの落とし穴
このセクションでは、マーケティングチャネルとキャンペーンロジックの落とし穴について説明します。
パターン
-
Customer Journey Analyticsのマーケティングチャネルは、多くの場合、派生フィールドを使用して実装されます。
- URL パラメーター、リファラー、ランディングページなどにもとづいて、マーケティングチャネルやキャンペーンのバケット化を実装する派生フィールド。
- 不審な順序：より特定のルールを適用する前に、汎用的なキャッチオールルールが表示されます。
- 考えられるすべてのオプションの処理が不完全です。参照ドメインの明示的なブランチが設定されていません、またはクエリパラメーターが設定されていません。
リスク診断：データ品質
- ロジック順序付けエラー：特定のチャネルを上書きし、トラフィックが誤って分類される可能性があるチェーン内の後のルール。
- 直接トラフィックのラベル付けミス：一致しないトラフィックが意図しないチャネルに入るか、
Otherというラベルが付けられます。
レコメンデーション
- トップダウンの優先順位付けを実施。 最も強いシグナルを最初に配置します（例：有料キャンペーンのパラメーターを除外する内部ドメイン）。
- 最終的な明示的なを含めます。それ以外の場合は、値を ケースに設定します。 フォールバックを No value に設定して、以前のチャネルを上書きしないようにします。 このキャッチオール手順では、値を カスタム文字列値 に設定し、次に カスタム文字列値 を
Direct、NoneまたはUnclassifiedに設定しないでください。 - テンプレートの利用： 可能な場合は、マーケティングチャネルの派生フィールドテンプレートを活用します。 Adobeの推奨マーケティングチャネルのベストプラクティスにロジックを合わせることもできます。
参照で使用される正規化されていない文字列キー
この節では、ルックアップでの正規化されていない文字列キーの使用について説明します。
パターン
- ルックアップデータセットをフィードするイベントまたはプロファイルフィールドに対する ルックアップ 関数。
- 前の小文字、 トリム 、または正規表現の置換は、キーを標準化しません。
- 共通の候補：URL、キャンペーン ID、メール、アカウント ID。
リスク診断：データ品質、高いメンテナンス
- データ品質のリスク：キーの大文字と空白がルックアップテーブルと異なると、ルックアップが失敗し、一致しない値とレポートのギャップが発生します。
レコメンデーション
- 大文字または小文字を保持する文書化された理由がない限り、 ルックアップ 関数の前に小文字関数と トリム 関数を追加します。
- 複数の変換が既に連結されている場合は、その順序を確認します。まず正規化してから検索します。
Regexの誤用またはオーバーリーチ
この節では、派生フィールドの正規表現機能の誤用またはオーバーリーチについて説明します。
パターン
リスク診断：パフォーマンス、データ品質、高いメンテナンス
- パフォーマンスとメンテナンス性に関するリスク：複雑な正規表現パターンはデバッグが困難で、動作が遅くなる可能性があります。
- 正確性リスク：過度に広い正規表現は、意図しない値をキャプチャする可能性があります。
レコメンデーション
- 正規表現ではなく、標準URL要素（ドメイン、パス、クエリパラメーター）にURL解析を使用します。
- 単純なパターンチェックの場合は、正規表現の代わりに、Containsの、 Starts with または Ends with logicを使用してCase Whenを使用します。
- 単純なパターンに対して、複数のネストされたグループまたは代替を使用する正規表現にフラグを付けます。 派生フィールド文字列関数を使用して置き換えることができる正規表現などがあります。
派生フィールドの計算指標スタイルロジック
この節では、派生フィールドでの計算スタイルロジックの使用について説明します。
パターン
-
計算指標のように見える、派生フィールド（合計、減算、除算）内の数値フィールドに対する純算術。
accordion 例 
-
文字列操作や分類は使用されません。ロジックは純粋に数値です。
リスク診断：データ品質
-
ガバナンスとデザインに関する質問：算術演算は、次のように配置する方が適しています。
- 派生フィールド指標（派生フィールドをすべてのユーザーの管理された標準指標として使用する場合）。
- Analysis Workspaceの計算指標（計算指標が分析固有の場合）。
レコメンデーション
- 算術結果がユーザーやプロジェクト全体で一般的に有用な場合は、結果を派生フィールド指標として保持します。 コンポーネントタイプが指標であり、書式（通貨、パーセント）がデータビューレベルで設定されていることを確認します。
- 結果がニッチまたはアナリスト固有の場合は、結果を計算指標に移動し、データビューを簡素化します。
次または前の関数または連続関数の過剰な使用
この節では、NextまたはPreviousまたは連続関数の過剰な使用について説明します。
パターン
リスク診断：データ品質、高いメンテナンス
- 複雑さと脆弱性：重いシーケンシャルロジックは理由を考えるのが難しく、セッション化のルールや順序の変更が発生すると壊れる可能性があります。
- ディメンションの永続性を持つ冗長性：ディメンションのデータビュー永続性設定（配分モデル）は、一部のユースケース（セッションのラストタッチチャネルなど）をより効果的にカバーします。
レコメンデーション
セッションと個人レベルのコンテキストを無視している
この節では、派生フィールドを定義する際のセッションおよび個人レベルのコンテキストの無視について説明します。
パターン
-
派生フィールドは、特定の コンテナレベル （イベント、セッション、またはユーザー）を暗黙的に想定していますが、
- 派生フィールドは、セッションまたは個人レベルの属性を参照しません。
- データ ビューのセッション設定が、意図したロジックと競合しています。
リスク診断：データ品質
- 概念の不一致：派生フィールドのセマンティクスは、アナリストが期待する集計レベルと一致しない可能性があります（例：イベントごとに変更できるペルソナベースのフィールド）。
レコメンデーション
- ロジックがセッションレベルを意図している場合：session settingsが適切に設定されていることを確認し、Analysis Workspaceまたは統合BI ツール でセッションスコープのコンポーネントまたはサマリーを使用することを検討します。
- ロジックが個人レベルを対象としている場合：プロファイルデータセットまたはルックアップデータセットを使用し、派生フィールド内でこれらのデータセットを参照します。
- Analysis Workspaceのセッションスコープのセグメントと個人スコープのセグメントのどちらが、派生フィールドよりも単純に同じ結果を得られるかを評価します。
文書化された関数の制限に近づいているか近づいている
この節では、文書化された派生フィールド関数の制限を達成または近づくことの意味について説明します。
カスタム顧客ジャーニー分析 ドキュメント 派生フィールドごとの最大関数と演算子（関数タイプごとの制限を含む）**
リスク診断：パフォーマンス、高いメンテナンス
- スケーラビリティリスク：フィールドが関数制限に達した場合、将来の追加が失敗したり、予期しない動作したりする可能性があります。
レコメンデーション
- 使用状況がしきい値を超えた場合（例：関数または演算子の制限の70%を超える場合）にプロアクティブにフラグを付けます。
- ロジックを、連結された複数の派生フィールドに分割します（例：検索キーを正規化する派生フィールド A、正規化された検索キーを使用してラベルを検索する派生フィールド B）。
- 特に大規模な分類が必要な場合は、外部データ準備またはルックアップデータセットを使用します。
データビュー固有の最適化ルール
この節では、派生フィールドのデータビュー固有の最適化ルールについて説明します。
また、派生コンポーネントごとにデータビュー設定を確認します。
パターン
- 派生ディメンションにはデフォルトの属性（例：セッションの有効期限を含むラストタッチ）がありますが、派生フィールド名は別のセマンティックを意味します（例：
First Campaign of Visit、Original Source）。 - 派生ディメンションにはデフォルトの永続性設定（例：最新の割り当て、有効期限セッション）がありますが、派生ディメンションの名前は別のセマンティック（
First Campaign of VisitまたはOriginal Source）を意味します。
リスク診断：データ品質
- セマンティックミスマッチ：ディメンションのラベルは、実際に設定されているものとは異なる割り当てや有効期限の動作（例えば、元の割り当てや人物レベルの有効期限）を示します。
- この不一致により、アナリストがレポートを誤って解釈したり、名前は似ていますが異なる割り当てモデルを使用するコンポーネントを比較したりするリスクが高まります。
レコメンデーション
- そのディメンションの配分モデルと有効期限を調整して、名前と動作を調整します。 例えば、
Original Sourceという名前の派生フィールドディメンションでは、有効期限がPersonに設定されたファーストタッチアトリビューションを使用する必要があります。 - ディメンションの 永続性 設定の 配分モデル と有効期限を調整して、名前と動作を調整します。 例えば、
Original Sourceでは、配分モデルを 元 に設定し、有効期限を 人物 に設定する必要があります。