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

要因

定義

影響元

最適化

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

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

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

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

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

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

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

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

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

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

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

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

多くのOR ステートメントを1つの「いずれかに等しい」ステートメントに減らす機会を探します。

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

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

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

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

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

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

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

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

クエリは、API リクエスト、レポート UI （Analysis Workspace、Report Builderなど）、スケジュールされたプロジェクト、スケジュールされたアラート、レポート要求を行う同時ユーザーから取得できます。

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

Connectionに収集されるデータの量。

導入チームまたは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 秒です。

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

すべてのリクエストの処理に同じ時間が必要なわけではありません。 リクエストの複雑さは、リクエストの処理に必要な時間をおおまかに把握するのに役立ちます。 ガイドラインは「中」以下です。

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

• 低
• 中
• 高

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

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

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

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

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

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

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

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