A user flow is a collection of web pages that define a logical task. It consists of a number of steps that need to be performed in order to complete the task. For example, a booking user flow might have the following defined steps:
Route and date details.
Passengers and vehicle details.
Payment details.
Confirmation.
Individual steps can consist of multiple web pages. For example, in the above Payment details step, separate pages may be defined for each available payment method (such as credit card, bank transfer, and so on). The user flow is considered completed when the visitor reaches the final step. In addition, while steps are primarily defined in terms of pages, they can also be defined in terms of other dimensions, such as Siebel methods, or EBS responsibilities and actions.
In order to facilitate administration, user flows are grouped into categories. For example, you could define separate categories for bookings, requests for brochures, CRM activities, and so on.
Conditions and Events
User flow steps are defined in terms of conditions. These represent the requirements that must be met in order for the step to be considered reached. Each condition is defined in terms of events. These are specified in terms of dimension values.
For example, consider the Payment details step described above. Typically, this could have several different conditions defined for it, with each condition representing an alternative method of payment. Only one of these conditions would need to be met during a user session in order for the step to be considered reached. Each condition is defined in terms of the events (that is, the specific dimension values) that must be achieved in order for the condition to be considered met. Note that all events defined for a condition must be met in order for the condition to be considered achieved.
Optional and Required Steps
Steps within user flows can be configured to be optional or required. For example, a user flow could be defined with the steps A, B, C, and D, and allow the paths A > B > C > D, A > B > D, A > B, and A > C > D. In this case, steps B and C are optional, and steps A and D are required. In the case of a visitor who followed the part A > B > D, the user flows would be reported as A > B > C (skipped) > D. Note that the first and last steps in a user flow cannot be defined as optional.
Outside and Abort Pages
While completing a user flow, a visitor might navigate to a page that is not defined as a step. These are referred to as outside pages. In this case, it is necessary to determine whether the visitor is actually aborting the user flow, or is still permitted to return to the user flow (for example, after seeking assistance from a Help page). However, you may want the user flow to be considered aborted when a visitor navigates to specific outside pages. These pages are referred to as abort pages.
Particular attention should be paid to the first step. If a visitor returns to the first step, you need to consider whether they are aborting the current user flow and starting a new one, or still intend to complete the current user flow. For example, in the booking user flow described earlier, if a visitor was on the Payment details step, and choose to return to the Route and date selection step, then it could probably be assumed that they were abandoning the current user flow, and starting a new one.
Idle Times and Time Outs
A visitor is expected to complete a user flow step within a certain period of time (for instance, five minutes). If they have not done so, then the user flow is considered to be idle. However, because some steps can taken longer to complete than others, (for example, they require more reading time by the visitor), the allowed visitor idle time can be configured for each step within a user flow.
Be aware that the session idle time (described in Controlling Session Reporting) specifies the amount of visitor inactivity after which a session is considered terminated. By default, this is 60 minutes. However, step idle time refers only to a visitor's period of inactivity within a specific user flow step. When the session idle time is elapsed within a user flow it is reported as timed out.
To define a new user flow, you must have Full Business level permission. Do the following:
Example 9-1 Understanding how Event Steps are Handled
When analyzing reported user flow information, it is important to understand the sequence in which RUEI attempts to processes user flow activity. This can be summarized as follows:
RUEI first attempts to determine whether a visitor has made progress through the user flow. That is, whether they have moved to the next step. If so, the reported progress is updated to reflect this.
If there is no direct progress to the next step, then each of following steps (as long as they are optional) are checked for progress. If progress is determined, this is reported.
If no progress has been determined, then the current step is checked and, if this fails, all previous steps (as long as they are optional) are checked. Any determined progress is reported.
If all checks until now have failed to identify progress through the user transaction, then the abort conditions are checked. If met, the user flow is reported as aborted. Otherwise, the user flow's current status is reported as an outside activity.
Example 9-2 Best Practices
It is recommended that you pay particular attention to the following points when defining your user flows:
Because a user flow is considered completed when a visitor reaches the last step, you should always define a confirmation or completion page as the final step.
When defining optional steps, ensure that the web site is structured in order to regulate the approved navigation.
It is recommended that careful attention be paid to step idle times when defining your user flows. Note that if the step idle time is defined as longer than the session idle time, the session idle time takes precedence, and user flows that exceed it are reported as timed out.
When using the free-text facility, it is strongly recommended that you carefully review the user flow's definition to ensure that all its attributes lay within defined data access restrictions. If an attribute (such as a page name) is outside these restrictions, it will never be reached because of data access enforcement.
Be aware that it is not possible to add or remove steps within existing user flows. The data access upon which a user flow is based can also not be modified. Therefore, it is recommended that you carefully design your user flows to reflect your requirements before configuring them.
Note that it is possible to modify step conditions, as well as other user flow information (such as its name, location, abort conditions, and monetary value). To modify a user flow, do the following:
Because only restricted changes can be made to existing user flows, it is very convenient to use the Copy option under the user flow context menu in the left-hand side of the window. In particular, it allows you to perform "what if" analysis of problem user flows.
For example, imagine that a particular step within a user flow has a high abort rate associated with it. You suspect that the problem may be related to visitors' browser language settings. Using the copy facility, you make a duplicate of the user flow, and modify the necessary step definition. Thereafter, you can compare the results of the original and modified user flows to see whether user flow conversions have improved.
Important
If you change the data access settings when copying a user flow, it is strongly recommended that you carefully review the new user flow's definition to ensure that all its attributes lay within the new data access restrictions. If an attribute (such as a page name) is outside these restrictions, it will never be reached because of data access enforcement.
Each time a new user transaction is created, the steps within that transaction are assigned an idle time. That is, the period of visitor inactivity after which the step is regarded as timed out. This has a default of 10 minutes. However, this default can be modified by selecting Configuration, then General, then Advanced settings, then Session processing, and then Default user flow step time. Note that any change to this setting only applies to new user transaction definitions. Existing user flows are unaffected.
In order to provide insight into the real cost of performance issues, monetary values can be assigned to ended user flows. That is, user flows that are completed, timed out, or aborted. For example, using this facility, you could determine the cost of a server upgrade in terms of lost user flows. The source of the monetary value is specified in a similar way to custom dimensions (see Working With Custom Dimensions). An example of a comparison between the monetary values of different user flows is shown in Figure 9-7.
Figure 9-7 Example Overview of User Flow Monetary Totals
Important
When assigning monetary values to user flows, you should consider the following:
When determining the monetary value form a selected element, all leading whitespace is removed from it. The value is taken from the first numeric character encountered up to the next non-numeric character. For example, the element ?Basket=99.99 US dollars
would be calculated as 99.
If the value is determined to be negative, greater than 232, or a string, zero is returned.
The underlying element (such as a request header) can change over the course of the user flow. Consider the situation shown in Figure 9-8. When user flow A starts, it has a monetary value of 0. As the user flow progresses, it has values of 80, 120, and 90. Upon completion, the monetary value of 90 is reported for it.
Figure 9-8 Calculation of Reported Monetary Value
The funnel view provides the most generic information about a selected user flow. It indicates visitor transition through the user flow during the selected time period. An example is shown in Figure 9-9.
More detailed information about the current status of a selected user flow is available through the Funnel view. In particular, it highlights the number of visitors currently engaged within each step, how they experienced web actions (such as page loading and errors) within those steps, as well as the number of timed out and aborted steps. Note that you can click each of the reported items (such as outside pages) to view them within the Session Diagnostics feature. An example is shown in Figure 9-10.
Figure 9-10 Example User Flow Status Details
Optional steps within a user flow are indicated with dotted lines. Note that diagnostics information with full session information about specific errors experienced on steps is available by clicking the Error on step indicator within a step. Diagnostics information on the reported number of poor page views is also available. The use of this facility is fully explained in Understanding User Flows.
The most detailed information about a user flow is available via the Flow transitions view. An example is shown in Figure 9-11.
Figure 9-11 Example User Flow Transition Details
It provides extensive information about transitions between steps, including the level of outside activity within steps, aborts, time outs, and the skipping of optional steps. Note that the Idle item indicates the number of visitors engaged in a step but who have been inactive for longer than the defined step idle time. If these visitors resume activity within one hour, this is indicated via the Idle returns item. Otherwise, the step is considered timed out and stopped.
In order to understand how the numbers reported in the user flow status (Figure 9-10) and user flow transitions (Figure 9-11) are derived, consider the example session information shown in Figure 9-12. It shows the pages viewed by three users (X, Y, and Z). A user flow is monitored that comprises of three steps, which correspond to the pages P1, P2, and P3.
As each the user sessions proceed, the arrow directly above each step indicates the number of users entering the step, the number inside the step indicates the total number of step pages viewed, while the three numbers to its right indicate the number of outside, outsider returns, and stopped user flows. If the viewed page had an error associated with it, this is indicated by an asterisk (*) after the page name.
Note that P4 is a help page, while P5 is regarded as an abort page. Therefore, an outside is reported (in step A) when P4 is encountered, while a stopped user flow is reported when P5 is encountered. Note also that an outside return is reported when a user returns from P4.
The user flows for users X and Y are completed at 10:20, while that of user Z timed out. Therefore, one stopped user flow is reported at 11:20. Note that if you want timed out user flows to be included in reported data, a sufficient time period needs to be selected.
Cumulative Reporting of User Flows
It is important to understand the difference between the reporting of user flows for a selected period, and the cumulative reporting of user flows. Consider the page load time reported for a selected step. This would indicate the load time (in seconds) for a step's page views during the selected period. However, when the total page load time for an aborted step is reported, this represents the total load time of all aborted page views for that step regardless of the selected period. Note that the total page load on stopped steps represents the sum of the page load of timed out and aborted step page views.
Figure 9-13 Understanding how Ended User Flows are Reported
Rolling Sum Reporting
Within the funnel graph (available from the User flows view within the User flow completion group), the Show rolling sum open is available within the Values menu. When selected, an additional column is displayed showing the cumulative total of user flows. This column is also available when exporting.
Duration Reporting
A number of views within the User flow completion group provide insight into the duration of user flows. An example is shown in Figure 9-14.
Figure 9-14 User Flow Active/Idle Time View
When using these views, be aware of the following:
When a user flow becomes idle (based on the defined step idle time), the time between the last page view and the step-idle time is marked as "active", while the time following this is reported as "idle". Therefore, two identical user flows with only a different defined step idle time would result in the same session being reported with different flow duration and flow idle times.
The step idle time is included as active time after the user becomes active after the step. The step idle time is also included as active time when a user went outside the user flow, and did not return. In this case, the session is reported as timed out.
Within the Service test diagnostics group (described in Reporting Service Test Traffic), you can convert selected service test sessions into RUEI user flows. This offers the advantage that the monitored user flows would then be reported within the All user flows group. This not only allows immediate comparison with other monitored user flows, but also enhanced reporting facilities.
To convert a service test session into a RUEI user flow, you must have Full Business access level permission. Do the following:
Example 9-3 Important
When converting service test sessions into user flows, be aware of the following:
The new user flow is limited to a maximum of 15 steps, and any service test session containing steps over is this limit are automatically truncated.
The converted user flow must contain at least two steps.