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

要因

定義

最適化

リクエスト数

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

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

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

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

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

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

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

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

フリーフォームセルの数

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

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

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

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

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

使用済みコンポーネント

プロジェクトで使用されるコンポーネントの合計数。ガイドラインは 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 つの「次のいずれかと等しい」文に減らせる機会がないか探します。

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

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

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

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

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

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

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

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

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

-

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

同時クエリ

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

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

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