Analysis Workspace のパフォーマンスの最適化

要因

定義

影響元

最適化

Adobe への接続

パフォーマンスページを開いた際、アドビでは 10 のテスト呼び出しを送信します。これらの呼び出しは、Adobeに対する呼び出しが成功した割合を表します。

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

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

インターネット帯域幅

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

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

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

インターネット待ち時間

パフォーマンスページを開いた際、アドビでは 10 のテスト呼び出しを送信します。これらの呼び出しは、各リクエストがAdobeに到達して戻るまでの時間を表します。 そして、あなたの場所とAdobeの間のインターネットの速度の尺度です。 ガイドラインは 1 秒未満です。

この要因には、ローカルネットワークの問題、開いているブラウザータブの多さ、Adobeの問題などが影響します。

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

要因

定義

影響元

最適化

計算速度

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

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

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

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

使用済みメモリ

Google Chrome でのみ使用できます。Google Chrome ブラウザー内のすべての Workspace タブは、合計 4GB のメモリを共有します。この値は、現在のプロジェクトで消費されたメモリ許可の割合を表します。 このガイドラインは 3500 MB で、Workspaceがメモリエラーに直面し始める時点です。

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

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

使用済みローカルストレージ

データは、ブラウザーで使用するためにコンピューターにローカルに保存されます。 各オリジン（experience.adobe.comなど）の許容量は 10 MB です。

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

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

レンダリング速度

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

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

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

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

要因

定義

最適化

リクエスト数

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

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

展開されたパネル（パネルの合計数のうち）

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

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

展開されたビジュアライゼーション（ビジュアライゼーションの合計数のうち）

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

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

フリーフォームセルの数

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

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

利用可能なコンポーネント

プロジェクトの左パネルで取得した、（プロジェクト内のすべてのレポートスイートにわたる）コンポーネントの合計数。この値は、左側のレールの読み込み速度と、その中で返される検索結果の速度に影響します。 ガイドラインは 2000 です。

カスタマイズされたコンポーネントのセットを含む、厳選された仮想レポートスイートの作成については、製品管理者にお問い合わせください。

使用済みコンポーネント

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

使用されるコンポーネントの数は、パフォーマンスに直接影響を与えるものではありません。 ただし、これらのコンポーネントが複雑になると、プロジェクトのパフォーマンスが向上します。 詳しくは、以下の追加要因の節の最適化 参照てください。

最長の日付範囲

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

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

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

要因

定義

最適化

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

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

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

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

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

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

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

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

リクエストが処理されるまでのキュー内の待機時間の合計。 ガイドラインは 5 秒です。

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

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

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

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

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

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

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

• 低
• 中
• 高

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

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

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

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

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

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

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

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

要因

定義

影響元

最適化

セグメントの複雑度

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

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

• contains、contains any of、matches、starts with、または ends with/の演算子
• 順次セグメント（特にディメンション制限（Within/After）が使用されている場合）
• セグメントで使用されるディメンション内の一意のディメンション項目の数（例えば、ページに一意の項目が 10 個ある場合のページ = 'A'は、ページに一意の項目が 100000 個ある場合のページ = 'A'よりも速くなります）。
• 使用される様々なディメンションの数（例：ページ = 「ホーム」、ページ = 「検索結果」は、eVar 1 = 「赤」、eVar 2 = 「青」よりも高速）
• 多くの OR 演算子（AND の代わりに）
• 範囲が異なるネストされたコンテナ（訪問者内の訪問の内部をヒットなど）

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

• コンテナの場合、セグメントの上部で単一のコンテナを使用する方が、ネストされた一連のコンテナよりも高速です。
• 演算子を使用すると、equals の方が contains よりも高速であり、equals any of の contains any よりも高速です。
• 多くの条件がある場合、AND 演算子は一連の OR 演算子よりも高速です。

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

分類を使用すると、多数の値を簡略化されたグループに統合し、それらのグループからセグメントを作成できます。分類グループでのセグメント化は、多くの OR 文を含むセグメントや 含む 条件を含むセグメントよりもパフォーマンスが向上します。

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

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

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

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

プロジェクトの読み込みに想定よりも時間がかかる場合は、可能であれば一部のセグメントを eVar とフィルターに置き換えます。

業務上重要なデータポイントに対してセグメントと計算指標を使用することが多い場合は、そのデータポイントを現在よりも直接的に把握できるように実装を改良することを検討します。Adobe Experience Platform のタグとアドビの処理ルールを使用すると、実装の変更を素早く簡単に行うことができます。

レポートスイートのサイズ

レポートスイートで収集されるデータの量。

-

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

同時クエリ

組織から同時にリクエストされたクエリの数。 各組織には最小 5 つの同時クエリの権利が付与されます。

レポートに長い時間がかかる場合、レポートは他のレポートとともにキューに入っている可能性があります。 組織が特定のレポートスイートに対して同時に実行するリクエストが多すぎます。 クエリは、API リクエスト、レポート UI （Analysis Workspace、Report Builder）、スケジュール済みプロジェクト、スケジュール済みレポート、スケジュール済みアラート、およびレポートリクエストをおこなう同時ユーザーから送られる場合があります。

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