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

要因

定義

影響元

最適化

Adobe への接続

パフォーマンスページを開いた際、アドビでは 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 です。

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

フリーフォームセルの数

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

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

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

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

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

使用済みコンポーネント

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

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

最長の日付範囲

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

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

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

要因

定義

最適化

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

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

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

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

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

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

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

ここでリクエストの速度が低下している場合はおそらく、プロジェクト内の文字列セグメントが多すぎるか、一致の可能性がある一般的な値を持つ文字列が多すぎることが原因です。

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

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

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

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

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

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

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

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

• 低
• 中
• 高

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

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

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

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

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

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

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

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

要因

定義

影響元

最適化

セグメントの複雑度

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

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

• 演算子には contains（次を含む）、contains any of（次のいずれかを含む）、matches（次と一致する）、starts with（次で開始する）、または ends with（次で終わる）などがあります。
• 順次セグメント化（特にディメンション制限（Within／After）が使用されている場合）
• セグメントで使用されているディメンション内の一意のディメンション項目の数（例えば、ページに一意の項目が 10 個ある場合は Page = 'A' の方が、一意の項目が 100,000 個ある場合の Page = 'A' より速くなります）。
• 使用されるディメンションの数（例えば、Page = 'Home' と Page = 'Search result' は、eVar 1 = 'red' と eVar 2 = 'blue' の場合より速くなります）
• 多くの OR 演算子（AND の代わりに）
• 様々なスコープの入れ子になったコンテナ（例えば、「訪問者」内にある「訪問」内のヒット）

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

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

多くの OR 文を 1 つの​equals any of（次のいずれかと等しい）文に減らせる機会がないか探します。

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

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

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

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

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

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

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

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

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

-

Adobe Analytics の全体的なエクスペリエンスを改善するために実装の改善が行われるかどうかについては、実装チームまたはアドビのエキスパートにお問い合わせください。

同時クエリ

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

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

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