ユーザー・フローとは、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分間)でユーザー・フロー・ステップを完了することが予期されます。 時間内に完了しないと、ユーザー・フローはアイドルとみなされます。 ただし、ステップによっては時間が長くかかることがあるため(たとえば、ビジターが情報を読むための時間が必要な場合など)、ユーザー・フローの各ステップについて許容されるビジターのアイドル時間を構成できます。
セッション・アイドル時間(「セッション・レポートの制御」)は、ビジターが非アクティブになってからセッションが終了したとみなされるまでの時間を指定します。 デフォルトでは60分です。 ただし、ステップのアイドル時間は、特定のユーザー・フロー・ステップ内でビジターが非アクティブになる時間のみを指します。 セッションのアイドル時間がユーザー・フローで経過すると、ユーザー・フローのタイムアウトとしてレポートされます。
新しいユーザー・フローを定義するには、ビジネス・レベルの完全権限が必要です。 次を実行します。
例9-1 イベント・ステップの処理方法の理解
レポートされるユーザー・フロー情報を分析するときは、RUEIがユーザー・フロー・アクティビティを処理する順序を理解することが重要です。 この順序をまとめると次のようになります。
RUEIは、ビジターがユーザー・フローで進んだかどうかを判別しようとします。 つまり、ビジターが次のステップに移動したかどうかを判別しようとします。 移動した場合、それに応じてレポートされる進捗が更新されます。
次のステップに直接進んでいない場合は、後続の各ステップ(オプション・ステップの場合)に進んだかどうかがチェックされます。 進捗が判別されると、レポートされます。
進捗が判別されなかった場合は、現在のステップがチェックされます。これが失敗すると、先行するすべてのステップ(オプション・ステップの場合)がチェックされます。 進捗が判別されると、レポートされます。
ここまですべてのチェックでユーザー・トランザクションの進捗が確認できない場合は、アボート条件がチェックされます。 条件が一致すると、ユーザー・フローがアボートされたとレポートされます。 一致しない場合、ユーザー・フローの現在のステータスが、外部アクティビティとしてレポートされます。
例9-2 ベスト・プラクティス
ユーザー・フローを定義するときは特に次の点に注意することをお薦めします。
ビジターが最後のステップに到達したときにユーザー・フローが完了したとみなされるため、最後のステップとして確認ページまたは完了のページを必ず定義する必要があります。
オプション・ステップを定義するときは、承認されたナビゲーションを規制するためにWebサイトが構成されていることを確認してください。
ユーザー・フローを定義するときはステップ・アイドル時間に特に注意することをお薦めします。 ステップのアイドル時間をセッションのアイドル時間よりも長く定義すると、セッションのアイドル時間が優先され、セッションのアイドル時間を超過したユーザー・フローがタイムアウトとしてレポートされます。
フリー・テキスト機能を使用する場合、ユーザー・フロー定義を慎重に確認して、すべての属性が定義済のデータ・アクセス制限内に配置されるようにすることをお薦めします。 属性(ページ名など)が1つでもこれらの制限外にある場合は、データ・アクセス制限の強制によって、それが使用できなくなります。
既存のユーザー・フローではステップの追加または削除を行うことはできません。 ユーザー・フローが基づいているデータ・アクセス権限も変更できません。 このため、ユーザー・フローを構成する前に、要件が反映されるように慎重に設計することをお薦めします。
ステップの条件およびステップの他の情報(名前、場所、アボート条件、通貨価値など)は変更できることに注意してください。 ユーザー・フローを変更する手順は、次のとおりです。
既存のユーザー・フローに行える変更は限られているため、ウィンドウの左側でユーザー・フローのコンテキスト・メニューの下にあるコピーオプションを使用すると便利です。 特に、このオプションを使用すると、問題のあるユーザー・フローのwhat-if分析を実行できます。
たとえば、ユーザー・フロー内の特定のステップでのアボート率が高い場合があります。 ビジターのブラウザの言語設定に問題が関係しているのではないかと考えます。 コピー機能を使用して、ユーザー・フローの複製を作成し、必要なステップ定義を変更します。 その後、元のユーザー・フローと変更したユーザー・フローの結果を比較して、ユーザー・フローの変更によって改善したかどうかを確認します。
重要
ユーザー・フローをコピーするときにデータ・アクセス設定を変更する場合、新規ユーザー・フロー定義を慎重に確認して、すべての属性が新規データ・アクセス制限内に配置されていることを確認することをお薦めします。 属性(ページ名など)が1つでもこれらの制限外にある場合は、データ・アクセス制限の強制によって、それが使用できなくなります。
新しいユーザー・トランザクションが作成されるたびに、そのトランザクションのステップにアイドル時間が割り当てられます。 これは、ビジターが非アクティブになってからステップがタイムアウトしたとみなされるまでの時間です。 デフォルトは10分です。 ただし、構成→一般→詳細設定→セッション処理→デフォルトのユーザー・フロー・ステップの時間の順に選択して、デフォルトを変更できます。 この設定の変更は、新しいユーザー・トランザクション定義にのみ適用されます。 既存のユーザー・フローには影響しません。
パフォーマンス問題の実際のコストを把握するために、終了したユーザー・フローに通貨価値を割り当てることができます。 終了したユーザー・フローとは、完了したユーザー・フロー、タイムアウトしたユーザー・フローまたはアボートされたユーザー・フローです。 たとえば、この機能を使用すると、ユーザー・フローの損失に関してサーバー・アップグレードのコストを判別できます。 通貨価値のソースは、カスタム・ディメンションと同様の方法で指定されます(「カスタム・ディメンションの操作」を参照)。 様々なユーザー・フローの通貨価値の比較例を図9-7に示します。
重要
ユーザー・フローに通貨価値を割り当てるときは、次の点に注意してください。
選択した要素の通貨価値を判別するとき、先行するスペースはすべて削除されます。 数字が出現してから次に数字以外の文字が出現するまでの部分が、値として取得されます。 たとえば、?Basket=99.99 US dollars
という要素は99と計算されます。
値が、負の数、232よりも大きい、または文字列であると判別されると、0が返されます。
基礎となる要素(リクエスト・ヘッダーなど)は、ユーザー・フローの間に変化することがあります。 図9-8に示す状況を考えます。 ユーザー・フローAが開始したとき、通貨価値は0でした。 ユーザー・フローが進行するにつれ、通貨価値は80、120、90と変化します。 完了時には通貨価値90がレポートされます。
このじょうご型の図では、選択したユーザー・フローに関する一般的な情報が得られます。 選択した期間のユーザー・フローでのビジターの推移が示されます。 例を図9-9に示します。
選択したユーザー・フローの最新ステータスのさらに詳しい情報は、じょうご型図で確認できます。 特に、現在各ステップを使用しているビジター数、ビジターがステップで行ったWebアクション(ページ・ロードやエラーなど)の状況、タイムアウトしたステップとアボートされたステップの数が表示されます。 レポートされた各アイテム(外部ページなど)をクリックして、セッション診断機能内に表示できます。 例を図9-10に示します。
ユーザー・フロー内のオプション・ステップは点線で示されます。 ステップで発生した特定のエラーに関する詳しいセッション情報を含む診断情報は、ステップ内のステップのエラー・インジケータをクリックすると表示されます。 レポートされた数の悪いページ・ビューの診断情報も使用できます。 この機能の使用方法の詳細は、「ユーザー・フローの理解」を参照してください。
ユーザー・フローの最も詳細な情報は、フロー遷移表示で得られます。 例を図9-11に示します。
ステップにおける外部アクティビティのレベル、アボート、タイムアウト、オプション・ステップのスキップなど、ステップ間の遷移について豊富な情報が提供されます。 アイドル・アイテムは、ステップを使用しているが、定義されたステップ・アイドル時間よりも非アクティブな状態が続いているビジター数を示します。 これらのビジターが1時間以内にアクティビティを再開すると、アイドル・リターン項目に表示されます。 再開しない場合は、タイムアウトとみなされてステップが停止します。
ユーザー・フロー・ステータス(図9-10)およびユーザー・フロー遷移(図9-11)にレポートされる数の導出方法を理解するには、図9-12に表示されているセッション情報の例を考慮してください。 3つのユーザー(X、YおよびZ)が参照するページが表示されます。 ユーザー・フローは監視され、ページP1、P2およびP3に対応する3つのステップで構成されます。
各ユーザー・セッションが進むと、各ステップの真上にある矢印がステップを開始するユーザーの数を示し、ステップ内の数が参照されたステップ・ページの合計数を示し、右側の3つの数値が外部、外部者リターンおよび停止したユーザー・フローの数を示します。 表示されたページに関連するエラーがある場合、ページ名の後にアスタリスク(*)で示されます。
P4はヘルプ・ページで、P5はアボート・ページとみなされます。 このため、P4が検出されると外部が(ステップAで)レポートされ、P5が検出されると停止したユーザー・フローがレポートされます。 ユーザーがP4から戻ると、外部リターンがレポートされることにも注意してください。
ユーザーXおよびユーザーYのユーザー・フローは10:20で完了し、ユーザーZはタイムアウトします。 このため、停止したユーザー・フローは11:20でレポートされます。 タイムアウトしたユーザー・フローをレポート・データに含める場合は、十分な期間を選択する必要があります。
ユーザー・フローの累積レポート
選択した期間のユーザー・フローのレポートおよびユーザー・フローの累積レポートの違いを理解してください。 選択したステップにレポートするページ・ロード時間を考慮してください。 これは、選択した期間中のステップのページ・ビューのロード時間(秒単位)を示します。 ただし、中断したステップの合計ページ・ロード時間がレポートされる場合、選択した期間に関係なく、そのステップのすべての中断したページ・ビューの合計ロード時間を表します。 停止したステップの合計ページ・ロードは、タイムアウトしたステップおよび中断したステップ・ページ・ビューのページ・ロードの合計を表します。
ローリング・サム・レポート
ファンネル・グラフ(ユーザー・フロー完了グループ内のユーザー・フロー・ビューで使用可能)内で、ローリング・サムの表示を値メニュー内で使用できます。 選択されると、ユーザー・フローの累積合計を示す追加の列が表示されます。 この列は、エクスポート時にも使用できます。
期間レポート
ユーザー・フロー完了グループ内の多くのビューにより、ユーザー・フローの期間を把握できます。 例を図9-14に示します。
これらのビューを使用する場合は、次の点に注意してください。
ユーザー・フローがアイドルになる場合(定義済のステップのアイドル時間に基づく)、最後のページ・ビュー時間およびステップのアイドル時間の間の時間がアクティブとしてマークされ、この後の時間がアイドルとしてレポートされます。 このため、異なる定義済のステップのアイドル時間の2つの同じユーザー・フローには、異なるフロー期間およびフロー・アイドル時間で同じセッションがレポートされます。
ユーザーがステップの後にアクティブになった後、ステップのアイドル時間がアクティブ時間に含まれます。 ユーザーがユーザー・フローの外部に移動して戻らなかった場合も、ステップ・アイドル時間がアクティブ時間に含まれます。 その場合は、セッションがタイムアウトとして報告されます。
サービス・テスト診断グループ(「サービス・テスト・トラフィックのレポート」)では、選択したサービス・テスト・セッションをRUEIユーザー・フローに変換できます。 こうすると、監視対象のユーザー・フローがすべてのユーザー・フロー・グループ内でレポートされるという利点が得られます。 監視対象の他のユーザー・フローと直接比較できるだけでなく、レポート機能が強化されます。
サービス・テスト・セッションをRUEIユーザー・フローに変換するには、ビジネス・レベルの完全権限が必要です。 次を実行します。
サービス・テスト・セッションをユーザー・フローに変換するときは、次の点に注意してください:
新規ユーザー・フローのステップは最大15に制限されます。この制限を超えるステップを含むサービス・テスト・セッションは、自動的に切り捨てられます。
変換されたユーザー・フローには少なくとも2つのステップが含まれる必要があります。