This section outlines a replay cookbook of preliminary steps that you can follow to diagnose common issues with replaying sessions through Experience Analytics CX RealiTea Viewer.
Overview of Replay
During replay, RTV loads a version of the target web page into an instance of Internet Explorer over which it has control. When objects required by the target page are requested, RTV intercepts the request in the IE instance and decides if it has the requested object in the loaded session or if it must get it from the original server, the web application.
If RTV can locate the object in the session data, it creates a version of it and requests it through a proxy server that it uses to deliver the requested object as if it came from an external web server.
When you look at the headers of the request, these proxied requests typically originate from
Check 1. Verify everything you need is in the session
In the Page Load Details page in RTV, you can see each object that the web page is requesting from the session and the origin server.
- If any item is, Page Load Details may give insight into the elements that are not replaying correctly.
- To access Page Load Details, select View > Page Load Details.
Many seemingly complex replay issues can be rectified by verifying that all required data is in the session data or accessible from the server. Often, a UI element that is missing or fails to replay is corrected as soon as a POST or JSON request missing from the session became available.
- Some files are created based on user credentials, like cookies or login accounts. If these files are not captured in the session data and are requested during replay, they usually do not complete successfully. In most cases, a generic version of the file is returned from the origin server, or a redirect occurs during the request, returning another unassociated page, such as the home page. This issue results in erratic replay.
- If POST data are required to dynamically affect UI elements of the web page, this data must be
captured in the session data.
- Common examples include drop-down lists that auto-populate based on previous choices or radio button groups toggled based on user input.
- Usually during replay, a request is issued when a UI element is changed. This request is usually a POST request that instructs the server to send the data that is required for the page. This request and the returned data must be in the session for replay to accurately portray what happened during capture.
- UI Capture may need to be implemented in order to capture these data.
captured in the session data for replay to work correctly.
- Good examples are ashx files for .NET websites, as these contain script code that is needed to control UI elements of the page.
- When in doubt, check Page Load Details.
Replay for sites requiring sign-In
If you have most of your static content, such as images, script, or objects, blocked from users who are not logged in, RTV is likely to have issues retrieving this content during replay.
- You can acquire the content and place it on a proxy server, such as the Portal server, which can store the content so it may be served during replay. This scenario requires a host/port remap rule to map the URLs for static content to your proxy.
- You can enable Business IT Mode in the PCA so that all images and static content are captured.
- You must remove blacklisted extensions and MIME types and add the file name extensions to the
- You must also verify that the Processing Servers have
DelImagesdisabled in the DataDrop pipeline agent so that the content is not dropped.Note: This functionality can be enabled in the PCA pipeline, which limits the volume of data that is processed and transmitted to the Processing Servers.Note: This configuration captures all content in the session. Operating in this mode dramatically increases the storage requirement and should only be used during POC or other temporary situations where Replay must be demonstrated. This solution is for temporary use only.
- You must remove blacklisted extensions and MIME types and add the file name extensions to the whitelist (like
Check 2. Verify needed data are not being blocked by Privacy
Privacy is used to obscure sensitive customer data. While privacy secures customer data, it can result in some data needed for replay being blocked.
A common rule that causes replay issues is
BlockURLFields. This rule blocks all
the parameters that are appended to the end of URLs following a
? character. If
during replay you notice many of the URLs in the Navigation list (upper left pane) have lists of
X characters following them, you may have privacy settings issues. If the URLs in
the Navigation list have any repeated character following them, privacy is usually the culprit.
The obscured URL parameters are needed by RTV to match the requests with the data in the session. If the requests cannot be matched, then they are requested from the origin server. The returned hits are not identical to the originally captured hits, which results in poor replay.
- When the main page request for the session has URL parameters, obscuring them can force RTV to request them from the origin server, which results in poor replay and artificially inflation of the hit count for the page.
- Because these pages commonly have the same name with different content (such as
WebResource.axd?xxxxxxx) for each request, the URL parameters are required by RTV to decide which version of
WebResource.axdin the session is needed for the page.
- Because these pages commonly have the same name with different content (such as
- If POST data are blocked by privacy or the POST request has URL parameters that are blocked by privacy, those POST requests are not matched correctly, and UI elements fail to replay.
- Replay is impeded for any URL if the parameters used to make that page unique were blocked by
privacy. At one customer site, dynamically generated GIF images of application forms were requested
pageparameter. When blocked, these parameters caused RTV to fail to find the image. The image failed to display, even if it existed in the session.
Check 3. Client UI Capture for Ajax is in use and its events are captured
Experience Analytics offers the CX UI Capture for AJAX to be deployed to the customer website and served to the visitors' browsers when they navigate the website.
After the UI events are captured, they are saved in the session to be used by RTV during replay. The events come in bundles of XML and can be seen in the REQ view of the session in RTV. Using timestamps and other parameters, RTV sorts these events and associates them with the pages in the session.
Because the events were captured while the user interacted with the web application, they can replay how the user interacted with each UI element on the web page and in the order of interaction. For replay of this type to work correctly, however, events must be correctly matched with the parent page, and the UI elements to which they pertain must be available at replay time in the UI of the page.
- A web page contains a form and is referencing the CX UI Capture for AJAX. The form is
either shown or hidden based on the values of a set of radio buttons. If replay of the radio button
event fails, the form is not displayed during replay.
In this case, all replay events to fill the form fields following that radio button click fail to replay as well, since the form does not exist in the UI. This common situation has many different variations.
- A web page has a set of drop-down lists. The choice from list 1 affects the content of list 2. If the request from list 1 fails due to privacy blocking needed data, the request resulting in an HTTP 404 error, or the event for list 1 failing to fire, then list 2 fails to replay. For example, if there is a list 3 dependent on list 2, events should fail for it as well. In this case, follow Checks 1 and 2 to verify the UI event data are captured in the session and that the requests are being matched up correctly (for example, no privacy blocking).
- There are several events that say
xpathin front of them, and they have a long list of members and may have no "value" data. These events do not do anything during replay, and all subsequent UI events don't do anything.
In this case, the
XPATHevent is missing a crucial piece of information that most likely cannot be matched to the content on the page, and RTV cannot send the event to the UI element.Note: This situation is complicated. Contact Support for assistance.
Check 4. Verify only one main page is requested for each page in the navigation list
A common issue regarding replay occurs when the RTV user clicks a page in the navigation list. The page displays and then disappears, replaced by an HTTP 404 or another, incorrect page.
- There is an overlay page that makes the rest of the screen inactive and displays a form with which you can interact.
Check 5. Verify frame content is configured correctly
In websites that use frames, replay can require some work to display the pages properly. A page in the session is likely to be the parent frame and subsequent pages after it in the Navigation list (upper left list) are the child frames that must be placed within the parent.
To allow proper replay of frames, you must enable the following RTV features:
- Tools > Options > Replay > Replay Frames (required)
- Tools > Options > Advanced > Replay Remote Frames (optional)
- Tools > Options > Advanced > Aggressive Frame Placement (optional)
Then, you must tell RTV the hierarchy of the frameset:
- Find the page that you expect to be the parent page. Click this page in the Navigation list and
click the RSP button to examine the HTML code of the response, which should
<FRAME>tag. Inside this tag, the URLs of the subsequent pages in the Navigation list should appear.
After they are found, you can right-click the parent page in the Navigation list and select Replay Rules > Place this page in a frame > _top. The parent page is configured to hold all subsequent child pages.
- Locate each page that must be placed in the parent page from the Nav list. Right-click each page
and select Replay Rules > place this page in a frame
and then select the frame ID that pertains to this element.
srcparameter that is located in the
FRAMEelement of the parent page contains the URL of the child element to be assigned. Then, use the
IDparameter of the
FRAMEelement in the parent page to assign the child.