There are things to consider when you build or review your web applications for use with Tealeaf.
Generally, Tealeaf acquires most of its data from the real-time HTTP data stream between your web servers and the client computers. Upon capture, Tealeaf parses this text data to:
- Organize hits into the related session.
- Detect user-defined event patterns.
- Generate indices for searching.
- Create reports.
- Replay the sessions.
All of these functions require clear, easily parsed request and response data. Tealeaf does not require JavaScript tags to be implemented in your web application.
Browser support
The browser-based replay feature supports the following browsers:
- Mozilla family of browsers
- Gecko
The Replay Server uses the Gecko browser control to render session content on the server for delivery to the browsers of Tealeaf users. A replay of such sessions might still be supported through the CX RealiTea Viewer, a desktop client that must be separately installed on each Tealeaf user's desktop.
Data privacy
To facilitate the blocking, encryption, or hashing of sensitive data points, you should install code that minimizes the instances of sensitive data passed between the web server and the client.
For each potentially sensitive data point:
- Identify whether the data is required for reporting or alerting purposes.
If the data is required for reporting or alerting purposes, it must be made available to some Tealeaf users in some way. Review the data with your security team.
- Verify with your security team the conditions under which the data must be blocked.
- Add a consistent tag to the unique identifier for the data point, such as
-privateso that all sensitive data can be easily identified using configured privacy rules.
As a security practice, do not display any sensitive data such as credit card details or site passwords in the HTTP response. Instead, you can echo this type of data in the response after the visitor has encountered an error, such as a credit card authorization error, to assist the visitor in completing the transaction.
Note: Some industry standards expressly limit the transfer of this data in the response. For example, the Payment Card Industry (PCI) Data Security Standard permits the presentation of the first six or the last four digits of a credit card number only.
Tealeaf can be configured to block this data. However, this configuration is expensive in terms of processing and may be complicated to successfully complete.
As a best practice, develop your Web application such that blocking sensitive data is only necessary within the HTTP request.
If sensitive data is appropriately bracketed in the HTML responses generated by your web application, Tealeaf includes some prebuilt privacy rules that automatically block or encrypt the data.
Note: To use these prebuilt rules as they are configured by default, you must bracket sensitive data in your HTML responses with specific comment tags.
Pop-up windows
Because client-side pop-ups and client-side validation do not involve any communication with the webserver, they can't be tracked with CX Passive Capture Application.
If you need to track these types of client-side interactions for your web application, the CX UI Capture for the AJAX library can be deployed to gather this information. This library requires additional deployment, configuration, and maintenance and might involve Professional Services.
Request and response data
When developing your web applications, employ the following developing practices.
| Do this | For this reason |
|---|---|
| Run W3C validation services on your website |
Tealeaf products require that websites conform to W3C standards, including having properly formed HTML. Make sure your website complies with W3C standards to save time during the Tealeaf integration process. The processing that Tealeaf performs on web pages is significantly more complex than a simple rendering; meaning that just because web pages render correctly in a web browser, does not guarantee that they will replay with Tealeaf. |
| Use unique and common identifiers, as appropriate |
General principles of uniqueness:
|
| Avoid the use of encrypted or encoded field values | The use of encrypted or encoded field data within the website application can complicate and slow down the extraction process.
Encryption refers to application-level encryption of specific data items such as form field or cookie values. |
| Avoid the use of client-generated data |
Applications should avoid using date and timestamps generated on the client, as these values are different from the values recorded by the server at the time of capture by Tealeaf. For best results, use server-side data for generating values such as timestamps. |
| Embed report segmentation data in requests |
Provide hidden fields or name and value pairs in the request for data that may be used for report segmentation. For example, when a customer logs in to the web application, submit in the request hidden fields such as |
| Insert name/value pairs in response data |
In the response, inserting name/value pairs as HTML comments near the top of the response makes them efficient to find and easy to read for the analyst. |
| Provide server errors |
If possible, pass server errors in the response. Please provide some mechanism to identify application servers that are generating errors or exceptions. In Tealeaf, events can be created to monitor errors passed in the response, which enables the reporting of them. |
| Identify language-dependent or frequently-changing text using HTML markup |
Tealeaf can monitor user-visible error messages in your website, which provides useful insight into customer behavior and web application friction points. Depending on the web application, its error messages may frequently change, as well. Tealeaf events can be configured to track errors by detecting the text of the error messages in the response data. However, this approach can result in a high overhead to maintain events when error messages are frequently changed. This overhead is compounded on multilingual sites, where the number of events affected by a change is equal to the number of changed error messages multiplied by the number of languages supported by the site. To minimize event maintenance, you can identify frequently changing text such as error messages with some HTML markup, such as an |
| These objects should be unique | For this reason |
|---|---|
| Name/value pairs |
In general, the key to easy creation and management of accurate events is to create explicit name/value pairs in your web data. Generate unique and parsable field names. |
| Page URL paths |
Intentionally or accidentally, many sites are designed with non-unique URL paths (URI stems) to identify page locations. This lack of uniqueness creates a challenge when analyzing a specific data point on a specific web page of the site. An example URL path might be the following:
Where possible, please observe the following guidelines:
Ensuring this uniqueness should be a joint effort between the developers and content owners of your site. |
| Form field names or IDs |
Tealeaf can extract and display a wealth of data from captured sessions. A large proportion of this information is obtained from data provided by the user in the form of the information entered in form fields. The use of unique form field names across the site avoids confusion in event definition and improves the accuracy of the reported data. |
| JavaScript identifiers |
To simply replay of sessions, please use unique identifiers for JavaScript elements. |
| Step identifiers in business processes |
Tealeaf provides the Business Process Scorecard report, which can provide insight into the effectiveness of site business processes and factors affecting the conversion rate of those processes. The foundations of a process scorecard are step events, which track the user's progress through the steps of the process. To track this progress, configured events must be able to unequivocally identify each process step. The process of creating these events can be dramatically simplified if the web application provides unique step identifiers that do not change between web application revisions. Some examples of step identifiers are:
|
Rich internet applications
When developing a site that includes one or more Rich Internet Applications utilizing AJAX, Flex, or significant client-side script, you must deploy the CX UI Capture for AJAX to capture client-side user interface events. The development of these types of applications has additional recommended practices.
<!-- A_UNIQUE_VAR_NAME=SOME_VALUE -->Session tracking and cookies
Tealeaf evaluates all of the request/response pairs (hits) between the servers and the clients to recreate the customer experience. From this interleaved data, Tealeaf requires all requests and responses of the session and a common key to join them to the session.
Typically, this identifier is a session-level cookie defined by the web application, such as ASP.NET_SessionId or JSESSIONID.
In some cases, such as landing pages, this session-tracking cookie is not set on each hit. This case can result in orphaned, standalone hits that are not assigned to a specific session. To limit these orphaned hits, verify that session tracking information is available on every web page served by the web application.
If the web application cannot provide this identifier, the Tealeaf Cookie Injector can be deployed on your webserver to provide an appropriate session-tracking cookie.