There are things to consider when you build or review your web applications for use with Acoustic™ Experience Analytics (Tealeaf).
Generally, Acoustic Experience Analytics (Tealeaf) acquires most of its data from the real-time HTTP data stream between your web servers and the client computers. Upon capture, Acoustic Experience Analytics (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.
The browser-based replay feature supports the following browsers:
- Mozilla family of browsers
The Replay Server uses the Gecko browser control to render session content on the server for delivery to the browsers of Experience Analytics users. Replay of such sessions might still be supported through the Experience Analytics CX RealiTea Viewer, a desktop client that must be separately installed on each Experience Analytics user's desktop.
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 Experience Analytics 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.
Experience Analytics 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 of sensitive data is only necessary within the HTTP request.
If sensitive data is appropriately bracketed in the HTML responses generated by your web application, Experience Analytics includes some prebuilt privacy rules that automatically block or encrypt the data.
Because client-side pop-ups and client-side validation do not involve any communication with the web server, they can't be tracked with Experience Analytics CX Passive Capture Application.
If you need to track these types of client-side interactions for your web application, the Experience Analytics CX UI Capture for 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 web site||
Experience Analytics products require that web sites conform to W3C standards, including having properly formed HTML.
Make sure your web site complies to W3C standards to save time during the Experience Analytics integration process.
The processing that Experience Analytics 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 Experience Analytics.
|Use unique and common identifiers, as appropriate||
General principles of uniqueness:
|Avoid the use of encrypted or encoded field values||
Use of encrypted or encoded field data within the web site 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 Experience Analytics. 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 Experience Analytics, 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||
Experience Analytics can monitor user-visible error messages in your web site, 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.
Experience Analytics 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|
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||
Experience Analytics 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 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.
|Step identifiers in business processes||
Experience Analytics 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
<!-- A_UNIQUE_VAR_NAME=SOME_VALUE -->
Session tracking and cookies
Experience Analytics evaluates all of the request/response pairs (hits) between the servers and the clients to recreate the customer experience. From this interleaved data, Experience Analytics 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
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 Experience Analytics Cookie Injector can be deployed on your web server to provide an appropriate session-tracking cookie.