Event Monitoring Analytics を使用してユーザアクティビティに関するインサイトを取得する

学習の目的

この単元を完了すると、次のことができるようになります。

事前作成済みのダッシュボードを使用して、監査に関する質問の答えを見つける。
ダッシュボードをドリルダウンしてデータを検証する。
重要業績評価指標 (KPI) が特定の制限に達したときにメール通知を受信する。

Event Monitoring Analytics を使用して、主要なインサイトを取得しアクションを実行する

DTC Electronics の Salesforce システム管理者であるあなたは、Event Monitoring Analytics を設定しました。思ったとおり機能しているため、次は数日後に控えた最高情報責任者 (CIO) とのミーティングの準備に取りかかります。では、ダッシュボードを試してみましょう。

事前作成済みのダッシュボードを使用して、次の疑問に対する答えを見つけることにします。

レポートのダウンロードの推移に懸念すべき点はないか?
レポートのダウンロード数が最も多いのは誰か?
パフォーマンスに問題のあるレポートはないか?

CEO の Julie Chavez が納得のいく答えを求める人物であることをあなたは心得ているため、上記以外にも CEO に聞かれそうな質問を想定し、CEO が尋ねる前に説明できるようにしたいと考えています。また、このアプリケーションで実行できる他の優れた機能もいくつか試してみます。すると、Event Monitoring Analytics を使用すれば、主要なインサイトを簡単に収集してアクションを実行できることがわかりました。

レポートの利用状況に関する問題を検知する

では、Reports 事前作成済みダッシュボードを使用して、参照回数が上位のレポートを確認し、パフォーマンス上の問題を検知して、レポートを使用したユーザーを特定します。

Analytics for CIO (CIO 向け Analytics) アプリケーションをまだ開いていない場合は開きます。
[ダッシュボード] タブを選択して、[Reports] をクリックします。

Reports ダッシュボードページ

ダッシュボードの [Report Trends by User] 領域に目を向けます。グラフから、過去 30 日間に各ユーザーがダウンロードしたレポート数を読み取ることができます。どうでしょう…。11 月 1 日に Bob Bandit が多数のレポートをダウンロードしたようです。詳しく調べてみましょう。

ダッシュボードの日付は、あなたが Trailhead Data Manager を使用してイベントデータをアップロードした実際の日付が反映されるため、上記とは異なっていることがあります。

ダッシュボードの [Report Names by User] 領域を見てみます。

[Report Names by User] 領域を示す Reports ダッシュボードページ

[High Net-Worth Contacts] というレポートを多用しているユーザーがいます。誰でしょうか? グリッドのレポート名にマウスポインターを置くと、アクセスしたユーザーが表示されます。Bob Bandit です!

Bob は 11 月中に合わせて 150 回もレポートにアクセスしたようです。これは注意すべき情報で、今度のミーティングで CIO と協議することにします。

レポートのこのデータは非正規化されています。非正規化とは、ビジネスケースにおける意味やコンテキストを明確にする目的で、さらなるデータを追加して、ダッシュボードを最適化しているということです。この方法については、次の単元で説明します。

レポートのパフォーマンスを確認する

レポートのダウンロードの推移とセキュリティ侵害の可能性を検知することができました。次は、もう少し穏やかな話題に移り、組織のレポートのパフォーマンス上の問題を見つける方法について説明します。レポートのパフォーマンスにユーザーが不満を抱くようなことをあなたは望んでおらず、また、極めて長いクエリのために組織全体のパフォーマンスが低下することも望んでいません。もう一度 Reports ダッシュボードを見てみましょう。

[Report Performance] 領域を示す Reports ダッシュボード

[Report Performance] 領域には、maximum CPU_TIME に対する DB_TOTAL_TIME の比率が示されます。この 2 つは何を意味するのでしょうか?

DB_TOTAL_TIME はデータベースの往復処理の時間 (ナノ秒単位) です。
CPU_TIME は要求の完了に要した CPU 時間 (ミリ秒単位) です。この測定値は、アプリケーションサーバーレイヤーで実行されているアクティビティの量を示します。

DB_TOTAL_TIME を CPU_TIME と比較して、パフォーマンス上の問題がデータベースレイヤーと各自のコードのどちらで発生しているかを判断します。上記の例では、CES Top Prospects レポートでデータベース処理に時間がかかり、CPU でも時間を要していることがわかります。そのため、クエリを最適化すればこのレポートが向上する可能性があります。

パフォーマンスに関するアラームを設定する

前のセクションで、Reports ダッシュボードを使用してレポートのパフォーマンス上の問題を検知する方法を学習しました。Reports ダッシュボードの上部にデータベース時間と CPU 時間が重要業績評価指標 (KPI) として報告されていることにもおそらく気付いたことと思います。

Report ダッシュボードの KPI 領域

便利ですよね? DB 時間と CPU 時間が何のことかわかれば、KPI を定期的に確認してパフォーマンス上の問題を検知できます。

けれども、毎日ダッシュボードにドリルダウンする時間がない場合はどうすればよいでしょうか? KPI の測定値が設定した制限を超えたときにメール通知を受け取る簡単な方法があります。通知の設定です(他のユーザーに通知されるようにする場合は、そのユーザーが独自の通知を設定する必要があります)。

では、CPU の最大時間が 600 ミリ秒 (KPI では 0.60 と表示) に達したときにメールを送信してみましょう。

KPI の [最大 CPU 時間] にマウスポインターを置き、メニュー矢印をクリックして、[通知を設定] を選択します。
通知領域で、しきい値に「0.60」と入力して、演算子を [次の値より大きい] に変更し、他の値はそのままにします。通知日時もデフォルトのままにします。
[保存] をクリックします。

データを自動的に取得する

Event Monitoring Analytics アプリケーションを作成したときに、このアプリケーションに DTC Electronics のデータを取り込むデータフローを手動で開始しました。アプリケーションで常に DTC Electronics の最新データを使用するために、毎日データフローが実行されるようにスケジュールします。

イベントログファイルが生成されると Salesforce にアップロードされます。大半のデータセットのアップロードは毎日ほぼ同じ時刻に終了します。正確な終了時刻は、データセットのサイズや内容によって異なります。イベントログファイルが生成された後にデータフローが数時間実行されるようスケジュールします。こうすれば、アプリケーションに最新のデータが取り込まれるほか、データフローの更新によってアプリケーションの使用が妨げられることがありません。大規模なデータセットを扱うときは、毎日のアップロードに時間がかかることを見込んでおきます。大規模なデータセットは、中規模や平均的な規模のデータセットよりもアップロードの終了時間が遅くなる可能性が高くなります。

では、毎日午前 8 時に自動的に実行されるように設定しましょう。

右上のギアアイコンをクリックして、[データマネージャー] を選択します
[データフロー] サブタブを選択します。
[Analytics for CIO (CIO 向け Analytics)] アプリケーションに移動します。
アプリケーションのアイコンと名前の右端にあるメニューを開きます。[スケジュール] を選択し、時刻を [午前 8 時] に設定します。データフローによって業務が妨げられないように業務時間外にします。毎日 24 時間ごとに実行します。
[保存] をクリックします。

もう 1 つの方法として、イベントベースのスケジュールを設定することもできます。このオプションについての詳細は、「データフローをスケジュールして自動実行」ヘルプトピックを参照してください。