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 チームとハードウェアの詳細について話し合ってください。

要因

定義

最適化

リクエスト数

プロジェクトに表示されているデータを取得するために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以下です。

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

• 低
• Medium
• 高

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

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

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

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

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

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

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

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

要因

定義

影響元

最適化

セグメントの複雑度

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

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

• 演算子には「次を含む」、「次のいずれかを含む」、「一致する」、「次の語句で始まる」、または「次の語句で終わる」などがあります。
• 順次セグメント（特にディメンション制限（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 つの「次のいずれかと等しい」文に減らせる機会がないか探します。

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

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

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

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

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

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

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

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

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

-

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

同時クエリ

組織からアドビに同時にリクエストしているクエリの数。 各組織には最小 5 つの同時クエリの権利が付与されます。

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

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