This example provides beginning users with a simple scenario for getting started. By stepping through the steps, you can acquire valuable information about your web application, which you can publish to other stakeholders in your organization. You don't need previous experience with Experience Analytics to follow this example, but you should have some familiarity with terms used in Experience Analytics.
- Experience Analytics must be operational and gathering data for at least a day before you begin this scenario.
- You must have a user account to the Portal. This account requires access to the following features.
- Report Builder
- Event Activity report
- Browser Based Replay
- Drill-down searches
If you have an account but are unsure of your permissions, they are explained in detail in the scenario.
You want to identify major errors that your web application is issuing. You can track counts of these errors over time, generate reports that measure counts, narrow the criteria, and locate and replay the affected sessions to see what happened during the visitor's session.
This information can be provided to developers to assist in measuring the impact and locating the source of the issue.
When a request is made from a visitor's browser to a website server, the server returns a response that includes the HTTP status code, which indicates the category of the response. For example, when you open a web page, the status code that is returned in the response is
OK, which means that the request to open the page was successful. There are many status codes, but here are status codes that are used in this scenario:
The requested content wasn't found. These errors can be caused by a number of issues, of which your developers must be made aware.
Internal server error. Something happened on the server-side that prevented the response from being delivered. It could be part of the web server application, a piece of code that your developers created, or another problem.
At the end of this scenario, you'll have useful information to provide to your developers about these error codes and their frequency.
Let's get started.
Check event activity
You use the Portal to interact with Experience Analytics applications and databases. This interface enables you to complete the most common Experience Analytics user activities.
Through the Portal, you can perform the following basic actions:
- Report: Review or generate reports, scorecards, dashboards, and alerts.
- Search: Search for sessions that meet a specified set of criteria.
- Replay: Replay a session that you select, experiencing it as the visitor originally experienced it.
Verify that you can access the following options from the Portal menu:
- Analyze > Event Activity
- Analyze > Report Builder
You also need the URL to the portal. If you don't know it or if you don't see these menu items, contact your Experience Analytics administrator about enabling access to them.
For this example, let's begin with the Event Activity report. This report indicates the number of occurrences of all currently active events for a selected time period.
An event is an occurrence of a pattern of data in the captured data stream. In this example, we're looking for the occurrence of the
HTTP 404 - Not Found event. If that pattern is found, the count of occurrences increments. You can see the counts in the Event Activity report.
In the report, you can see the breakdown of counts for the selected event by day (if the focus period is greater than 1 day) or by hour (if the focus period is a single day). Because the report was generated for today, the hourly data is incomplete. But it does have enough to begin work.
- In your web browser, enter the address of the Portal for your company. This address is in the following pattern:
http://PortalServer/portalNote: Depending on how your Portal is configured, you might be automatically logged into the Portal. If not, log in with your Experience Analytics username and password.
- In the Portal menu, select Analyze > Event Activity.
- In the toolbar, select View by Labels.
- Under the list of Labels, open the Standard Events.
- Look for an entry for
Http 404 - Not Found.In the Event Count column on the right side, the number of occurrences of the event during the selected period is displayed.
- If the Event Count value is
0, you can do one of the following steps until you see a non-zero value:
- Locate a
Http 4xxevent that contains a non-zero count. These can include the following values:
Http 400 - Bad Request
Http 401 - Unauthorized
Http 403 - Forbidden
Http 404 - Not Found
- Look for the
Http 500 - Internal Server Errorevent.
- Change the reporting period. By default, the Event Activity report is configured to display event counts from the current date (today). Change the date in the corner of the report and click Apply.
You can select a range of dates. You might try to expand the range to the beginning of the month or even further.
- Locate a
The HTTP Status Code events rely on the presence of data that is inserted by Experience Analytics. When data is captured and passed through Experience Analytics, the Canister inserts preconfigured data in each request that is part of the session. This inserted data is then part of the session that is retained.
For Status Code events, data is inserted in the
[env] section of the request, which Experience Analytics creates. Here is an example that is set of data:
[env] REMOTE_ADDR=22.214.171.124 REMOTE_PORT=40177 LOCAL_ADDR=126.96.36.199 LOCAL_PORT=80 SERVER_NAME=188.8.131.52 SERVER_PORT=80 HTTPS=off CONNECTION_ID=13144 PCA_NAME=jupiter PCA_ADDR=127.0.0.1 PCA_UNAME_RELEASE=2.6.9-55.EL PCA_UNAME_SYSNAME=Linux REQ_BUFFER_ENCODING=UTF-8 REQ_BUFFER_ORIG_ENCODING=ISO-8859-1 REQUEST_METHOD=GET URL=/store/index.php/placeholder SERVER_PROTOCOL=HTTP/1.1 ResponseType=text/html; charset=UTF-8 StatusCode=404 StatusCodeText=Not Found
In this example, the last two entries (called name-value pairs) contain status code information that is inserted by the Canister. These name-value pairs are variable names and their values.
This event, which is evaluated for each request that is passing through the Canister, detects the presence of this
StatusCode entry in the request. If the entry is set to
404, the event fires, and all actions that are configured for the event are taken. The number of occurrences in the Event Activity report is incremented by one.
The event relies on the Status Code hit attribute, which is a Experience Analytics-defined data object that checks for the matching pattern in the request. According to the definition of the event, if the Status Code hit attribute is present and its value is
404, then the event fires.
Explore the Event Activity report
If you shared this report with your web developers, it wouldn't be informative. They might ask, "This is interesting, but where did all of these errors occur? Is it one problem or multiple problems? How are we expected to find the problem in our code?"
What is missing is the context. When the error occurred, what were other characteristics of the session that can help to locate the source of the problem?
Experience Analytics defines this contextual data and associates it with events through dimensions. A dimension is a value that is recorded when an event occurs. For example, at the moment when the event fired, what is the URL where it occurred?
Experience Analytics provides example dimensions, which you can apply to your reports to filter the data. Among the provided dimensions is the
URL (Normalized) dimension, which captures the normalized value for the URL where the event occurred. In a typical web site, the number of URLs can explode into the thousands, often because variable information, such as query parameters or timestamps, is inserted at the end of the URL. To identify locations on the web site, this information is rarely useful.
You can add the provided
URL (Normalized) dimension to your Event Activity report to filter the display to show only the URLs where these errors most frequently occur.
- In the Report Builder, click the Dimensions tab in the left panel.
You should see a list of items.
- In the left panel, locate the
URL (Normalized)dimension. Click and drag this dimension to the
Add X-Axisbox. A message displays, indicating that adding this dimension might create a very large data set.
- Click OK.
We can improve the chart display by filtering the dimension values down to the ones where the event has the highest values. This filtering also helps us to identify the URLs where the HTTP 404 error occurs most frequently.
- For the Maximum Number of Values to Display, enter 10. This entry means the chart is configured to display only the dimension values that were recorded most frequently when the event fired.
- Click Apply. The report is updated to show only the event counts for the 10 most frequently recorded dimensions.
- Click Save.
- Enter a name, such as
http 404 - not foundand click Save.
In the detail table, you can see the data values that are displayed in the chart. The outlier dimension values, called dimension constants, have a high number of counts. The dimension constants are recorded occurrences of limits on the number of permitted dimension values. For this example, ignore these values and focus on the actual captured and recorded values.
Search for and replay the session
The event and dimension combination is written into the request primarily for search purposes. When you run a search that looks for event occurrences, event values, or dimension values, you instruct Experience Analytics to look into the request records for this specific data.
We can ignore the following values:
||These entries may be related with how dimension data is defined and are not currently actionable.|
||These entries apply to the CX UI Capture for AJAX solution, which might not be properly installed. If the CX UI Capture for AJAX solution is implemented, these would be worth exploring, .|
That leaves the following two URLs of interest:
placeholder item may or may not be of interest. If this was a production system, you might be inclined to share that with your developers. The second one, though, looks like the URL that must not return an HTTP 404 - Not Found error.
In the Count column, you can see links for each entry. When you click a link, you run a search for the underlying sessions that compose the data in the metric. In our example, if you clicked the link for the
/services/customer-portal.phplogout_frame.asp entry, you would instruct the Report Builder to query the set of stored sessions for any session where the
HTTP 404 - Not Found event occurred on the listed page on the date(s) specified for the focus period.
These search queries are run just like you would perform a search for an ad hoc set of sessions. How you specify ad hoc searches for terms of your choosing is different and covered in a different scenario.
In the resulting session list, the matching sessions are displayed by default in revise order of the number of hits in them. In the Events column, you can see the icon for the
HTTP 404 -
Not Found event is listed. Since this session list is displaying the results of searching for this event only, no other events are listed in the column.
- If you move your mouse over one of the icons, additional information about the event is displayed.
- At the bottom of the session, you can see the search query that was specified to execute the search. Search queries do not need to be specified in this hard-to-read format, but you can copy and paste that text to save it for later use, if desired.
Use the Quick View option to see the page where the event was triggered.
We've narrowed our search to just sessions where the HTTP 404 error occurred on the /services/customer-portal.phplogout_frame.asp page in the specified time frame. But for this information to be of use to developers, we need to provide a specific session example and, potentially, the exact page where the event occurred.
Expanding the entry displays all of the dimensions that were recorded when the event fired. If you click the Page link, you can review the contents of many of the sections in the request of the selected page in the Page Detail. Use the breadcrumb trail to return to the Quick View page.
Replay the session
From QuickView, you can jump to the page where the issue occurred. In QuickView, click the Replay icon. In the dialog, click Browser.
In Browser-Based Replay, you can replay captured sessions through your web browser. This replay method enables all users to have immediate access to replay capability.
In this example, BBR has been opened to display the selected session at the page where the issue occurred. On Page 25, the last of the session, the Page Not Found error page was displayed. The event
HTTP 404 - Not Found occurred on this page.
This page itself isn't particularly informative. In fact, it can be the page that is universally served to all visitors of your web application when the HTTP 404 Status Code error occurs.
The page that is useful is likely to be the preceding one, where the visitor made the selection or performed another action that resulted in the web application generating the Page Not Found error. In the left navigation panel, click the page immediately preceding the Page Not Found error.
What you need to see now is the Replay view for the previous page. In Replay view, you can see the page as it is displayed to the visitor during the session.
For developers, the data, not the visual presentation, is more important. In the toolbar, click Request.
In Request view, you can review the contents of the request for the page. This data includes the data that was submitted to the web server to ask for the content, as well as additional data inserted by Experience Analytics during processing. This section typically includes application-specific information that is valuable for search purposes. All of this content is indexed for search.
Of the specific value in the
[appdata] section is the
TLT_URL value, which is the exact value that is recorded in the
URL (Normalized) dimension. In this case, the value is
/services/login-frame.php. This relative path indicates the location in the website's domain where the page is located. This provides to your developers the location of the page from which some action was taken to generate the Page Not Found error page.
Share the data
Now, you're ready to submit your report to the developers. Pull the data together and send an email with a link to the session.
- In Request view, highlight all of the
[appdata]section. Copy the content and paste it into a text editor.
- In the toolbar, click Response.
Response view shows the content that was sent by the web server to the client, based on the request. Your developers might be interested to know what was served.
- Click in the main pane, copy all of the content and paste into the text editor.
- From the drop-down menu in the toolbar, select Send Link by Email.
- In the dialog, write your message.
- Recipients: Enter a comma-separated list of email addresses. Aliases are allowed.
- Session Title: For session title, you might enter HTTP 404 - Not Found error.
- Message: You could enter something like the following text:
Dev Team-- Using Experience Analytics, we discovered a number of occurrences of HTTP 404 errors. Many of these errors occur when a request is made from the /services/login-frame.php page. Use the link in this email to open an example session. The Page Not Found error page is the last page of the session. The previous page generates the error. This error was detected 9 times on this page just today. Hope that this is helpful.
- Click OK to send.
Characterize the problem
You've done a good job in providing compelling evidence to your development team that a problem exists with your web application. However, that is a code-level issue. At the business level, the impacts aren't immediately known.
People outside the development team might find it useful to know how often these error codes are correlated with visitors abandoning their shopping carts. For example, what percentage of users who encounter an HTTP 404 error end up abandoning the site without completing a transaction? And how much in potential revenue was lost?
The process of "checkout" is generalized; it represents the general case of when a visitor to your web app begins the process to complete a funnel or designed goal . That goal can be to checkout of a retail site with a purchase. It can also be to download a document or complete a banking transaction.
- Define an event that identifies when a person begins the process to check out:
Checkout - Begin.
- Define an event that identifies when a person is successfully completed checkout:
Checkout - Success.
- Define an event
Checkout - Abandonedthat combines the two events.
Checkout - BeginAND
- NOT (
Checkout - Success)
- Define an event that combines two events:
Checkout - AbandonedAND
HTTP 404 - Not Found
The steps result in creation of an event that monitors general abandonment (
Abandoned) and the final step that tracks abandonment when an HTTP 404 error occurs.
These session-level events can be used to track real losses to your business through your web application. By identifying the problem, those losses can be turned into gains.
To apply a monetary figure to these losses, you can create a shopping cart event, which captures the value stored in the "shopping cart" for your web site. In a retail site, this value may be statically reported on each page. In other sites, this value may be tracked through different means.
As a substitute, your enterprise might have calculated average transaction values, which can be used for this computation.
For each occurrence of the Abandoned + HTTP 404 event, you can report the value of the shopping cart. When the occurrences of this value are summed in the Report Builder, you have provided an accurate measurement of the actual lost revenue due to the HTTP 404 error. This same methodology can be applied to any other event.
Experience Analytics provides a scenario that describes how to monetize these losses.
You can use the following ideas to expand your understanding of Experience Analytics and to make new discoveries.
- The Event Activity report provides a good entrance to exploring events and their behaviors through detailed, drill-down reporting. You can revisit this scenario by starting again with the Event Activity report.
- You can check other error events in the Standard Events, such as the
HTTP 500 - Internal Server Errorfor similar issues of interest to developers.
- You can explore the
One Hit Session Countevent that is provided by Experience Analytics, which tabulates the number of sessions that contained a single hit. These sessions are often sourced by bot traffic. You can add the dimension
Traffic Typeto the X-axis report to see the break-down of one-hit sessions by type of traffic.
- You can check other error events in the Standard Events, such as the
- Other events tabulate generation, network, and round trip times, which feed into the Performance reports. These reports provide a good way for exploring large or otherwise anomalous values in these key performance metrics. Like the Event Activity report, you can explore these metrics by URL.
- Experience Analytics provides a special event to help tracking user identifiers. The
Login ID Sampleevent must be configured to reflect how user identifiers are displayed in your web application. This event can be used as the basis of exploring individual user activities through Experience Analytics cxImpact.
This event must be configured as part of your initial cxImpact configuration. Contact your Experience Analytics administrator to find out whether the Login ID event is populated.
- When you are ready, you can begin creating your own events to track activities specific to your web application.
Note: Event creation is considered an administrative-level function.