Customer Journey Analyticsと Analysis Workspace のパフォーマンスの最適化

要因

定義

影響元

最適化

プロジェクト内のフリーフォームテーブルのセルの合計数。すべてのテーブルの行 x 列で計算されます。非表示のデータソースは除外します。ガイドラインは 4000 です。

テーブルの列数を減らし、最も重要なデータポイントのみを表示します。表示される行数の調整、テーブルセグメントの適用またはセグメントの適用により、テーブルの行数を減らします。

プロジェクトで使用されるコンポーネントの合計数。ガイドラインは 100 です。

使用されるコンポーネントの数は、パフォーマンスに直接影響を与えません。ただし、これらのコンポーネントの複雑さは、プロジェクトのパフォーマンスに影響を与えます。以下の「その他の要因」の節の最適化を参照してください。

この係数は、プロジェクトで使用されている最長の日付範囲を表示します。ガイドラインは 1 年です。

できるだけ、必要以上のデータを取り込まないようにします。パネルカレンダーを分析に関連する日付に絞り込むかフリーフォームテーブルで日付範囲コンポーネント（紫のコンポーネント）を使用します。テーブルで使用される日付範囲は、パネルの日付範囲より優先されます。例えば、先月、先週および昨日をテーブルの列に追加して、特定の範囲のデータをリクエストできます。Analysis Workspace での日付範囲の扱いについて詳しくは、 こちらのビデオ を参照してください。

また、プロジェクトで使用される前年比の比較数を最小限に抑えます。前年比の比較を計算すると、対象となる月の間の完全な 13 ヶ月分のデータが調べられます。これは、パネルの日付範囲を過去 13 ヶ月に変更した場合と同じ影響を与えます。

複雑なセグメントはプロジェクトのパフォーマンスに大きな影響を与える可能性があります。

セグメントを複雑にする要因には、以下のものがあります（影響の大きい順）。

• 演算子には「次を含む」、「次のいずれかを含む」、「一致する」、「次の語句で始まる」、または「次の語句で終わる」などがあります。
• 順次セグメント化（特にディメンション制限（Within/After）が使用されている場合）
• セグメントで使用されているディメンション内の一意のディメンション項目の数（例えば、ページに一意の項目が 10 個ある場合は Page = 'A' の方が、一意の項目が 100,000 個ある場合の Page = 'A' より速くなります）。
• 使用されるディメンションの数（例：Page = 'Home' と Page = 'Search result' は、eVar 1 = 'red' と eVar 2 = 'blue' の場合より速くなります）
• 多くの OR 演算子（AND の代わりに）
• 範囲が異なるネストされたコンテナ（例：「人物」内の「セッション」内の「イベント」）

複雑さの要因には回避できないものがありますが、セグメントの複雑さを軽減できないか検討してください。一般に、セグメント条件を具体的に指定するほど良くなります。 次に例を示します。

• コンテナの場合、セグメントの上部で単一のコンテナを使用する方が、ネストされた一連のコンテナよりも高速です。
• 演算子を使用する場合、「次に等しい」は「次を含む」よりも高速であり、「次に等しい」は「次のいずれかを含む」よりも高速です。
• 多くの条件がある場合、AND 演算子の方が一連の OR 演算子よりも高速です。

多数の OR 文を 1 つの「次のいずれかと等しい」文に減らす機会を探します。

ビジュアライゼーションの複雑さ （セグメント、指標、フィルター）

プロジェクトに単独で追加されるビジュアライゼーションのタイプ（フォールアウトとフリーフォームテーブルなど）は、プロジェクトのパフォーマンスにはあまり影響しません。 処理時間が増加するのは、ビジュアライゼーションの複雑さです。

ビジュアライゼーションの複雑さが増す要因は、以下のとおりです。

• リクエストされるデータ範囲
• フリーフォームテーブルの行として使用されるセグメントなど、適用されるセグメントの数
• 複雑なセグメントの使用
• フリーフォームテーブルでの静的項目の行または列
• フリーフォームテーブルの行に適用されるセグメント
• 含まれている指標（特にセグメントを使用する計算指標）の数

アドビデータセンター内で、自社と他の顧客が共有するレポート容量。

これは、組織およびデータセンター内の他の組織によって行われる同時クエリの数の影響を受けます。

組織は設定した容量を利用する権利を有します。システムの負荷が軽い場合、アドビはお客様の契約許容量を超える容量を移行します。

組織から同時にリクエストされているクエリの数。 各組織には少なくとも 5 つの同時クエリの権利が付与されます。 レポートに長い時間がかかる場合は、通常、他のレポートが一緒にキューに入っていることが原因です。 つまり、組織が特定のデータビューに対して同時に実行するリクエストが多すぎます。

クエリは、API リクエスト、レポート UI （Analysis Workspace、Report Builderなど）、スケジュール済みプロジェクト、スケジュール済みアラート、レポートリクエストをおこなう同時ユーザーから送られる場合があります。

データビューのリクエストやスケジュールを、1 日を通じて均等に配分します。 また、可能な場合は、リクエストをピーク外の時間に切り替えます。 月曜日の朝、火曜日の朝、および毎月 1 日は、レポートのピーク時間です。

接続に収集されたデータの量。

Customer Journey Analyticsの全体的なエクスペリエンスを向上させるために実装に関する改善点があるかどうかを判断するには、担当の実装チームまたはCustomer Journey Analyticsのエキスパートにお問い合わせください。

非常に複雑なディメンションは、プロジェクトのパフォーマンス、特に複雑なカスタムフィールドに基づくディメンションや指標に大きな影響を与える可能性があります。

カスタムフィールドの数を減らすか、個別のディメンションを作成します。

高基数ディメンションとも呼ばれ、これらのディメンションはレポートのパフォーマンスに影響を与える可能性があります。

​ 高基数ディメンション ​ を参照してください。

​ 高基数ディメンション ​ を参照してください。

要因

定義

影響元

最適化

パフォーマンスページを開いた際、アドビでは 10 のテスト呼び出しを送信します。これは、成功したアドビへの呼び出しのパーセンテージを表します。

ローカルネットワークの問題やアドビの問題は、この要因に影響を与えます。

サービスに関する既知の問題があるか、status.adobe.com で確認します。次に、ローカルネットワーク接続を検証します。

Google Chrome でのみ使用できます。自分の場所における、ブラウザーの帯域幅の推定値です。ガイドラインは 2.0 Mb/秒です。

ローカルネットワーク接続は、この要因に影響を与えます。

ローカルネットワーク接続を検証します。

パフォーマンスページを開いた際、アドビでは 10 のテスト呼び出しを送信します。これは、リクエストがアドビに送信されて返されるまでの平均時間を表します。簡単に言うと、自分の場所とアドビの間のインターネット速度を測定する尺度です。ガイドラインは 1 秒未満です。

ローカルネットワークの問題、開いているブラウザーのタブが多い場合、またはアドビの問題は、この要因に影響を与えます。

サービスに関する既知の問題があるか、status.adobe.com で確認します。次に、ローカルネットワーク接続を検証し、使用していないブラウザータブを閉じます。

要因

定義

影響元

最適化

コンピューターが処理テストを実行する速度。ガイドラインは 750 ミリ秒未満です。

お使いのハードウェアと同時プログラムが、この要因に影響を与えます。

コンピューターのタスクマネージャー（PC）またはアクティビティモニター（Mac）を開き、プログラムを閉じることができるか確認します。次に、使用していないブラウザータブまたは他のプログラムを閉じます。

これらのアクションで問題が解決されない場合は、IT チームとハードウェアの詳細について話し合ってください。

Google Chrome でのみ使用できます。Google Chrome ブラウザー内のすべての Workspace タブは、合計 4GB のメモリを共有します。これは、現在のプロジェクトで消費されているメモリ許容量のパーセンテージを表します。ガイドラインは 3500MB で、この時点から Workspace がメモリエラーの表示を開始します。

複数のタブで作業する場合や 50000 行のデータをダウンロードする場合は、メモリ使用量が増加します。

メモリエラーが発生した場合は、他の Workspace タブを閉じ、50000 行のダウンロードを一度に実行します。

ブラウザーで使用するため、コンピューターでローカルに保存されたデータ。各接触チャネル（experience.adobe.com など）には 10MB の余裕があります。

Analysis Workspaceは、自動保存（既存）プロジェクト、ユーザ設定、機能フラグの保存など、いくつかの機能でローカルストレージを使用します。

Analysis Workspace の機能が中断されないようにするには、experience.adobe.com ドメイン用のローカルストレージをクリアします。

FPS は、「フレーム/秒」の略で、1 秒間にブラウザーが画面にページを描画できる枚数を表します。人間の目で認識できるのは一般的に 24 FPS です。FPS がそれよりも低い場合、Workspace でレンダリングの問題が発生します。

FPS は、多数の Workspace プロジェクトをまたいで一度におこなわれるマルチタスクや、表示されるプロジェクトのサイズの影響を受けます。コンピュータ上で実行している他のプログラム（ストリーミング、バックグラウンドスキャナーなど）に影響が及ぶ場合もあります。さらに、お使いのハードウェアもこの要因に影響を与えます。

コンピューターのタスクマネージャー（PC）またはアクティビティモニター（Mac）を開き、プログラムを閉じることができるか確認します。次に、使用していないブラウザータブまたは他のプログラムを閉じます。

これらのアクションで問題が解決されない場合は、IT チームとハードウェアの詳細について話し合ってください。

要因

定義

最適化

プロジェクトに表示されるデータを取得するため、アドビに対しておこなわれたクエリ（リクエスト）の合計数。クエリには、テーブルのランク付け要求、異常値検出要求、スパークライン要求、左パネルに表示されるコンポーネントなどがあります。折りたたまれたパネルとビジュアライゼーションを除外します。ガイドラインは 100 です。

データを特定の目的または関係者のグループに対応する複数のプロジェクトに分割することで、可能な限りプロジェクトを簡素化します。タグを使用してプロジェクトをテーマに整理し、ダイレクトリンクを使用して内部の目次を作成して、関係者が必要なものをより簡単に見つけられるようにします。

プロジェクト内のパネルの合計数のうち、展開されたパネルの数。ガイドラインは 5 です。

プロジェクトを簡略化する手順を実行した後、読み込み時に表示する必要のないプロジェクト内のパネルを折りたたみます。プロジェクトを開くと、展開されたパネルのみが処理されます。折りたたまれているパネルは、ユーザーが展開するまで処理されません。

プロジェクト内の合計のうち、展開されたテーブルおよびビジュアライゼーションの数（非表示のデータソースを含む）。ガイドラインは 15 です。

プロジェクトを簡略化する手順を実行した後、読み込み時に表示する必要のないプロジェクト内のビジュアライゼーションを折りたたみます。レポートの利用者にとって最も重要なビジュアルを優先し、必要に応じて補助ビジュアルを、さらに詳細なパネルまたはプロジェクトに分割します。

上記の「クエリ要因」の表を参照してください。

上記の「クエリ要因」の表を参照してください。

上記の「クエリ要因」の表を参照してください。

要因

定義

最適化

リクエストが開始されてから完了するまでに必要な時間。 ガイドラインは 15 秒です。

上の ​ リクエスト処理 ​ 図では、リクエスト時間は、Analysis Workspace リクエストの開始 から Analysis Workspace リクエストの完了 までの完全なプロセスを表しています。

リクエストが開始されてから完了するまでに必要な時間。

上の ​ リクエスト処理 ​ 図では、リクエスト時間は、Analysis Workspace リクエストの開始 から Analysis Workspace リクエストの完了 までの完全なプロセスを表しています。

Analysis Workspaceには、任意のセグメントで使用される文字列のハッシュのみが保存されるので、プロジェクトを処理するたびに、ハッシュと適切な値を照合するために 検索 が実行されます。 ガイドラインは 2 秒未満です。

ハッシュと一致する可能性がある値の数によっては、これはリソースを大量に消費するプロセスになる可能性があります。

上記の ​ リクエスト処理 ​ 図では、参照時間は 参照 フェーズ（「リクエストエンジン処理 フェーズ の時点）で表されています。

ここでリクエストの速度が低下する場合は、プロジェクトに含まれる文字列セグメントが多すぎるか、汎用的な値を持つ文字列に一致する可能性が高すぎることが原因です。

要求が処理されるまでキュー内で待機している合計時間。 ガイドラインは 5 秒です。

上記の ​ リクエスト処理 ​ 図では、キュー時間は リクエストエンジンキュー フェーズと サーバーキュー フェーズで表されています。

ここでリクエストの速度が低下する場合は、組織で同時に実行されているリクエストが多すぎることが原因である可能性があります。 ピーク外の時間にリクエストを実行してみてください。

リクエストの処理にかかる平均時間。

上記の ​ リクエスト処理 ​ 図では、平均サーバー処理時間が サーバーキュー フェーズと サーバー処理 フェーズで表されています。 ガイドラインは 10 秒です

ここでリクエストの速度が低下する場合は、プロジェクトに長すぎる日付範囲や複雑なビジュアライゼーションが含まれている可能性があります。 処理時間を短縮するには、プロジェクトの日付範囲を短くしてみてください。

すべてのリクエストの処理に同じ時間が必要なわけではありません。リクエストの複雑さは、リクエストの処理に要する時間の一般的な考え方を提供するのに役立ちます。 このガイドラインはMedium以下です。

指定できる値には以下のものがあります。

• 低
• 中
• 高

この値は、次の列の値の影響を受けます。

• 月の境界
• 列
• セグメント

リクエストに含まれる月数。月の境界が増えると、リクエストがより複雑になります。 ガイドラインは 6 以下です。

ここでリクエストの速度が低下する場合は、プロジェクトの月の境界が大きすぎることが原因である可能性があります。 月数を減らしてみてください。

リクエスト内の指標と分類の数。列が増えると、リクエストがより複雑になります。 ガイドラインは 10 以下です。

ここでリクエストの速度が低下する場合は、プロジェクトの列が多すぎることが原因である可能性があります。 列数を減らしてみてください。

リクエストに適用されるセグメントの数。セグメントが増えると、リクエストがより複雑になります。 ガイドラインは 5 以下です。

ここでリクエストの速度が低下する場合は、プロジェクトのセグメントが多すぎることが原因である可能性があります。 セグメントの数を減らしてみてください。