| Oracle® Real User Experience Insightユーザーズ・ガイド リリース11.1 for Linux x86-64 B63041-01 |
|
 前へ |
 次へ |
この章では、ネットワーク・トラフィックを監視するときのユーザー・フローの役割について説明します。また、ユーザー・フローを構成する要素(ステップ、条件、イベントなど)やRUEIでのそれらのレポートについても説明します。
ユーザー・フローとは、1つの論理タスクを定義したWebページの集合です。タスクを完了するために実行する必要がある複数のステップで構成されます。たとえば、予約ユーザー・フローには次のステップが定義されます。
航路と日付の詳細。
乗客と船舶の詳細。
支払いの詳細。
確認書。
個々のステップは複数のWebページで構成される場合があります。たとえば、上記の支払いの詳細ステップでは、使用できる支払い方法(クレジット・カードや銀行振込みなど)ごとに独立したページを定義できます。ユーザー・フローは、ビジターが最後のステップに到達したときに完了したとみなされます。また、ステップは主にページに関して定義されますが、他のディメンション(SiebelのメソッドまたはEBSの職責やアクションなど)に関しても定義できます。
管理を容易にするために、ユーザー・フローはカテゴリにグループ分けされます。たとえば、予約、パンフレット請求、CRMアクティビティなどのために個別のカテゴリを定義できます。
条件とイベント
ユーザー・フローのステップは条件に関して定義されます。条件は、ステップに到達したとみなされるために満たす必要がある要件です。各条件はイベントに基づいて定義されます。イベントはディメンション値を使用して指定されます。
たとえば、上記の支払いの詳細ステップについて考えてみます。通常、このステップにはいくつかの異なる条件が定義され、それぞれが別の支払方法に対応しています。ステップに到達したとみなされるためには、ユーザー・セッション中にこれらの条件の1つだけが満たされる必要があります。各条件はイベント(つまり、特定のディメンション値)を使用して定義されます。条件が満たされたとみなされるためには、イベントが実現する必要があります。ある条件が満たされたとみなされるには、その条件について定義されたすべてのイベントが実現する必要があることに注意してください。
オプション・ステップと必須ステップ
ユーザー・フロー内のステップは、オプションまたは必須として構成できます。たとえば、ユーザー・フローのステップA、B、CおよびDを定義し、パスA > B > C > D、A > B > D、A > BおよびA > C > Dが可能とします。この場合、ステップBおよびCがオプションで、ステップAおよびDが必須です。パスA > B > Dを進んだビジターの場合、ユーザー・フローはA > B > C(スキップ) > Dとレポートされます。ユーザー・フローの最初と最後のステップはオプションとして定義できません。
外部ページとアボート・ページ
ビジターがユーザー・フローを完了する途中でステップとして定義されていないページにナビゲートすることがあります。このようなページは外部ページと呼ばれます。この場合、ビジターがユーザー・フローを実際にアボートしようとしているのか、ユーザー・フローに戻ることが許可されるのかを判別する必要があります(たとえば、ヘルプ・ページで操作方法を調べた後など)。ただし、ビジターが特定の外部ページにナビゲートしたときは、ユーザー・フローがアボートされたとみなす必要があります。このようなページはアボート・ページと呼ばれます。
最初のステップには特に注意する必要があります。ビジターが最初のステップに戻った場合、現在のユーザー・フローをアボートして新しいユーザー・フローを開始しようとしているのか、現在のユーザー・フローを完了する意図がまだあるのかを判別する必要があります。たとえば、上記の予約ユーザー・フローでは、ビジターが支払いの詳細ステップにいたときに、航路と日付の選択ステップに戻ることを選択した場合は、現在のユーザー・フローを中止して新しいユーザー・フローを開始しようとしていると考えられます。
アイドル時間とタイムアウト
ビジターは特定の時間内(たとえば5分間)でユーザー・フロー・ステップを完了することが予期されます。時間内に完了しないと、ユーザー・フローはアイドルとみなされます。ただし、ステップによっては時間が長くかかることがあるため(たとえば、ビジターが情報を読むための時間が必要な場合など)、ユーザー・フローの各ステップについて許容されるビジターのアイドル時間を構成できます。
セッション・アイドル時間(12.7項「セッション・レポートの制御」を参照)では、ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間が指定されることに注意してください。デフォルトでは60分です。ただし、ステップのアイドル時間は、特定のユーザー・フロー・ステップ内でビジターが非アクティブになる時間のみを指します。セッションのアイドル時間がユーザー・フローで経過すると、ユーザー・フローのタイムアウトとしてレポートされます。
新しいユーザー・フローを定義するには、ビジネス・レベルの「Full」権限が必要です。次を実行します。
「Configuration」→「Applications」→「User flows」の順に選択します。現在定義されているユーザー・フローのカテゴリがウィンドウの左側にリストされます。ツールバーの「New user flow」コマンド・ボタンをクリックします。ダイアログが表示されます。
「Add User Flow」ダイアログ|
注意: 既存のユーザー・フローではステップの追加または削除を行うことはできません。ユーザー・フローが基づいているデータ・アクセス権限も変更できません。したがって、ユーザー・フローを構成する前に、要件を反映するように注意深く設計することをお薦めします。 |
ユーザー・フローの名前を指定します。名前はすべてのユーザー・フローを通じて一意にする必要があり、長さは255文字までに制限されます。定義できるユーザー・フローの最大数は200であることに注意してください。
「Category」メニューを使用して、ユーザー・フローを収めるカテゴリを選択します。新しいカテゴリに収める場合は、「New category」ボタンをクリックして新しいカテゴリの名前を指定します。
「Data access」メニューを使用して、ユーザー・フローを特定のアプリケーションまたはスイートにバインドするか、汎用にするかを指定します。データ・アクセス・フィルタの使用方法は、14.7項「モジュールにおける許可データの有効範囲の管理」に記載されています。
必須ユーザー・フロー・ステップごとに、「Add new step」をクリックします。図9-1に示すダイアログが表示されます。1つのユーザー・フローに含めることができるステップの最大数は15であることに注意してください。
ステップの名前を指定します。これはこの新規ユーザー・フロー内で一意にする必要があります。ユーザー・フロー・レポートで読みやすくするためにステップ名は短くすることをお薦めします(9.7項「ユーザー・フローのレポート方法の概要」を参照)。
ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間(分)を指定します。デフォルトでは10分です。ステップのアイドル時間は、ステップで必要な読取りの時間やビジターが実行する必要がある他の操作(計算や選択など)に対応できるようによく検討することをお薦めします。デフォルトのユーザー・フロー・ステップのアイドル時間は、9.5項「デフォルトのステップ・アイドル時間の指定」に記載される手順を使用して指定できます。
このステップがユーザー・フローの最初または最後のステップでない場合は、「Optional」チェック・ボックスを使用して、ユーザー・フローの一部としてビジターがこのステップを完了する必要があるかどうかを指定できます。デフォルトでは、ステップは必須です(チェック・ボックスは選択されていません)。
ステップに到達したとみなされるために満たす必要がある最初のステップ条件を指定します。条件のイベントごとに、「Dimension level」および「Value」メニューを使用して、チェックされるディメンションと保持する必要がある値を選択します。目的の値が「Value」メニューにない場合は、横にある「Search」アイコンをクリックして探すことができます。
オプションとして、「Exclude」チェック・ボックスを使用すると、定義したディメンション・レベル=値のペアを除外するように適用できます。つまり、定義したイベントが満たされない場合に、イベントが達成されたとみなされます。たとえば、特定のページが表示されない場合です。次に、「Save」をクリックします。元のダイアログに戻ります。
必要に応じて、新規ステップの下の「Add new condition」をクリックして、ステップで必要な追加の条件を定義します。図9-2に示すダイアログが表示されます。
必要な条件イベントごとにディメンション・レベル=値のペアを指定します。次に、「Add」をクリックします。ステップに到達したとみなされるためには定義された1つの条件のみを達成する必要がありますが、条件が満たされたとみなされるためには条件内のすべてのイベントが達成される必要があります。次に、「Save」をクリックします。元のダイアログに戻ります。
「Abort conditions」タブをクリックして、ユーザー・フローがアボートされたとみなされる状況を指定します。図9-3に示すダイアログが表示されます。
次のチェック・ボックスがあります。
First user flow step: ビジターが最初のステップに戻った場合にユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。
All outside pages: 選択されたユーザー・フロー内のステップとして定義されていないページにビジターがナビゲートした場合に、ユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。
All other first user flow steps: 別のユーザー・フローの最初のステップとして定義されているページにビジターがナビゲートした場合に、ユーザー・フローがアボートされたとみなすかどうかを指定します。デフォルトでは選択されていません。
必要に応じて、「Add new condition」をクリックして、ビジターがナビゲートした場合にユーザー・フローがアボートされたとみなす特定のページ(またはディメンション)を指定します。
必要に応じて、「Monetary value」タブをクリックし、図9-4に表示される「Monetary source」メニューと「Source value」フィールドを使用して、ユーザー・フローでレポートされる通貨価値が基づくソースを指定します。この機能の使用方法の詳細は、9.6項「ユーザー・フローへの通貨価値の割当て」に記載されています。
通貨価値は、URL引数、XPath式、ヘッダー、Cookie、カスタム・タグまたはカスタム関数から導出できます。XPath問合せの使用方法の詳細は、付録F「XPath問合せの使用」に記載されています。
次に、「Save」をクリックします。新規ユーザー・フローの監視は5分以内に開始されます。新しいユーザー・フローの概要が表示されます。
イベント・ステップの処理方法の概要
レポートされるユーザー・フロー情報を分析するときは、RUEIがユーザー・フロー・アクティビティを処理する順序を理解することが重要です。この順序をまとめると次のようになります。
RUEIは、ビジターがユーザー・フローで進んだかどうかを判別しようとします。つまり、ビジターが次のステップに移動したかどうかを判別しようとします。移動した場合、それに応じてレポートされる進捗が更新されます。
次のステップに直接進んでいない場合は、後続の各ステップ(オプション・ステップの場合)に進んだかどうかがチェックされます。進捗が判別されると、レポートされます。
進捗が判別されなかった場合は、現在のステップがチェックされます。これが失敗すると、先行するすべてのステップ(オプション・ステップの場合)がチェックされます。進捗が判別されると、レポートされます。
ここまですべてのチェックでユーザー・トランザクションの進捗が確認できない場合は、アボート条件がチェックされます。条件が一致すると、ユーザー・フローがアボートされたとレポートされます。一致しない場合、ユーザー・フローの現在のステータスが、外部アクティビティとしてレポートされます。
ベスト・プラクティス
ユーザー・フローを定義するときは特に次の点に注意することをお薦めします。
ビジターが最後のステップに到達したときにユーザー・フローが完了したとみなされるため、最後のステップとして確認ページまたは完了のページを必ず定義する必要があります。
オプション・ステップを定義するときは、承認されたナビゲーションが行われるようにWebサイトを構成してください。
ユーザー・フローを定義するときはステップ・アイドル時間に特に注意することをお薦めします。ステップのアイドル時間をセッションのアイドル時間よりも長く定義すると、セッションのアイドル時間が優先され、セッションのアイドル時間を超過したユーザー・フローがタイムアウトとしてレポートされることに注意してください。
フリー・テキスト機能を使用する場合は、ユーザー・フローの定義を慎重に確認して、すべての属性が定義済のデータ・アクセス制限内にあるようにすることを強くお薦めします。属性(ページ名など)が1つでもこれらの制限外にある場合は、データ・アクセス制限の強制によって、それが使用できなくなります。
既存のユーザー・フローではステップの追加または削除を行うことはできません。ユーザー・フローが基づいているデータ・アクセス権限も変更できません。したがって、ユーザー・フローを構成する前に、要件を反映するように注意深く設計することをお薦めします。
ステップの条件およびステップの他の情報(名前、場所、アボート条件、通貨価値など)は変更できることに注意してください。ユーザー・フローを変更する手順は、次のとおりです。
「Configuration」→「Application」→「User flows」の順に選択します。ウィンドウの左側で適切なカテゴリとユーザー・フローをクリックします。選択したユーザー・フローの概要が表示されます。例を図9-5に示します。
「Edit」コマンド・ボタンをクリックします。ダイアログが表示されます。
オプションとして、ステップのコンテキスト・メニューで「Edit」を選択し、名前、アイドル時間またはオプションと必須の設定を変更します。前述のように、ユーザー・フローは少なくとも2つのステップを含む必要があります。最初のステップと最後のステップは必須です。次に、「Save」をクリックします。
オプションとして、個々のステップ条件をクリックして変更することもできます。または、横にある「Remove」アイコンをクリックすると削除できます。ステップ内の「Add new condition」項目をクリックして、ステップに追加の条件を定義することもできます。
次に、「Save」をクリックします。ユーザー・フロー定義の変更は5分以内に有効になります。
既存のユーザー・フローに行える変更は限られているため、ウィンドウの左側でユーザー・フローのコンテキスト・メニューの下にある「Copy」オプションを使用すると便利です。特に、このオプションを使用すると、問題のあるユーザー・フローのwhat-if分析を実行できます。
たとえば、ユーザー・フロー内の特定のステップでのアボート率が高い場合があります。ビジターのブラウザの言語設定に問題が関係しているのではないかと考えます。コピー機能を使用して、ユーザー・フローの複製を作成し、必要なステップ定義を変更します。その後、元のユーザー・フローと変更したユーザー・フローの結果を比較して、ユーザー・フローの変更によって改善したかどうかを確認します。
重要:
ユーザー・フローをコピーするときにデータ・アクセス設定を変更する場合、新規ユーザー・フローの定義を慎重に確認して、すべての属性が変更後のデータ・アクセス制限内にあるようにすることを強くお薦めします。属性(ページ名など)が1つでもこれらの制限外にある場合は、データ・アクセス制限の強制によって、それが使用できなくなります。
新しいユーザー・トランザクションが作成されるたびに、そのトランザクションのステップにアイドル時間が割り当てられます。これは、ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間です。デフォルトは10分です。ただし、「Configuration」→「General」→「Advanced settings」→「Session processing」→「Default user flow step time」の順に選択して、デフォルトを変更できます。この設定の変更は新規ユーザー・トランザクション定義のみに適用されることに注意してください。既存のユーザー・フローには影響しません。
パフォーマンス問題の実際のコストを把握するために、終了したユーザー・フローに通貨価値を割り当てることができます。終了したユーザー・フローとは、完了したユーザー・フロー、タイムアウトしたユーザー・フローまたはアボートされたユーザー・フローです。たとえば、この機能を使用すると、ユーザー・フローの損失に関してサーバー・アップグレードのコストを判別できます。通貨価値のソースは、カスタム・ディメンションと同様の方法で指定されます(3.11項「カスタム・ディメンションの使用」を参照)。様々なユーザー・フローの通貨価値の比較例を図9-6に示します。
重要:
ユーザー・フローに通貨価値を割り当てるときは、次の点に注意してください。
選択した要素の通貨価値を判別するとき、先行するスペースはすべて削除されます。数字が出現してから次に数字以外の文字が出現するまでの部分が、値として取得されます。たとえば、?Basket=99.99 US dollarsという要素は99と計算されます。
値が、負の数、232よりも大きい、または文字列であると判別されると、0が返されます。
基礎となる要素(リクエスト・ヘッダーなど)は、ユーザー・フローの間に変化することがあります。図9-7に示す状況について考えます。ユーザー・フローAが開始したとき、通貨価値は0でした。ユーザー・フローが進行するにつれ、通貨価値は80、120、90と変化します。完了時には通貨価値90がレポートされます。
このじょうご型の図では、選択したユーザー・フローに関する一般的な情報が得られます。選択した期間のユーザー・フローでのビジターの推移が示されます。例を図9-8に示します。
選択したユーザー・フローの最新ステータスのさらに詳しい情報は、「Flow status」表示で確認できます。特に、現在各ステップを使用しているビジター数、ビジターがステップで行ったWebアクション(ページ・ロードやエラーなど)の状況、タイムアウトしたステップとアボートされたステップの数が表示されます。例を図9-9に示します。
ユーザー・フロー内のオプション・ステップは点線で示されます。ステップで発生した特定のエラーに関する詳しいセッション情報を含む診断情報は、ステップ内の「Error on step」インジケータをクリックすると表示されます。この機能の使用方法の詳細は、9.1項「ユーザー・フローの概要」に記載されています。
ユーザー・フローの最も詳細な情報は、「Flow transitions」表示で得られます。例を図9-10に示します。
ステップにおける外部アクティビティのレベル、アボート、タイムアウト、オプション・ステップのスキップなど、ステップ間の遷移について豊富な情報が提供されます。「Idle」項目は、ステップを使用しているが、定義されたステップ・アイドル時間よりも非アクティブな状態が続いているビジター数を示すことに注意してください。これらのビジターが1時間以内にアクティビティを再開すると、「Idle returns」項目に表示されます。再開しない場合は、タイムアウトとみなされてステップが停止します。
「Service test diagnostics」グループ(3.2.6項「Oracle Enterprise Managerのサービス・テスト監視」を参照)では、選択したサービス・テスト・セッションをRUEIユーザー・フローに変換することができます。こうすると、監視対象のユーザー・フローがすべてのユーザー・フロー・グループ内でレポートされるという利点が得られます。監視対象の他のユーザー・フローと直接比較できるだけでなく、レポート機能が強化されます。
サービス・テスト・セッションをRUEIユーザー・フローに変換するには、ビジネス・レベルの「Full」権限が必要です。次の手順を実行します。
「Browse data」、「Service tests」グループの順に選択し、「Service test diagnostics」機能を選択します。カレンダ・コントロール(2.5項「カレンダの使用方法」を参照)を使用して、目的の期間を選択します。表示範囲としては1日(または未満)を選択する必要があります。この制限外で検索しようとするとエラーが発生します。図9-11に示す検索パネルが表示されます。
診断機能の概要は、4.1項「概要」を参照してください。
必要に応じて、使用可能な基準を使用し、指定期間についてリストされるサービス・テスト・セッションを制限します。次に、「Search」をクリックします。検索結果がウィンドウの主要部に表示されます。例を図9-12に示します。
ユーザー・フローに変換するサービス・テスト・セッションをクリックして選択します。そのセッションの詳細が表示されます。例を図9-13に示します。
ツールバーの「Create user flow」コマンド・ボタンをクリックし、選択したサービス・テスト・セッションをRUEIユーザー・フローに変換します。図9-14に示すダイアログが表示されます。
図9-14 「Add User Flow From Service Test Session」ダイアログ
新しいユーザー・フローの名前を指定します。これは選択したユーザー・フロー・カテゴリ内で一意にする必要があります。デフォルトは、監視対象のサービス・テスト名です。
新しいユーザー・フローを収めるするカテゴリを指定します。既存のカテゴリでも新規カテゴリでもかまいません。デフォルトは「Service test」です。
変換処理では、基礎となるサービス・テスト・セッションから論理ユーザー・フローを構築することに注意してください。そのため、ステップ内で同じページ名が複数回出現すると、それらはページごとに統合され、ステップ内で個別の条件を構成します。また、サービス・テスト・セッション内で前後にスキップするように見えるステップは、オプション・ステップとみなされます。したがって、新規ユーザー・フローの構造を慎重に確認して、それが要件を満たしていることを確実にする必要があります。次に、「Save」をクリックします。
重要:
サービス・テスト・セッションをユーザー・フローに変換するときは、次の点に注意してください。
新規ユーザー・フローのステップは最大15に制限されます。この制限を超えるステップを含むサービス・テスト・セッションは、自動的に切り捨てられます。
変換されたユーザー・フローには少なくとも2つのステップが含まれる必要があります。
