1. Acoustic Help Center
  2. Experience Analytics (Tealeaf) On Premises
  3. Version 10
  4. Capture behaviors
  5. APIs and client-side framework

APIs and client-side framework

See more

Web application development considerations

Avatar
Aleksandra Grochowska
  • Updated

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.

Experience Analytics 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 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.

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 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 -private so 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.

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.

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 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.

Table 1. Considerations for web application development and request and response data

Considerations for web application development and request and response data
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:
  • Objects that must be specifically identified by Experience Analytics, such as screen elements or JavaScript items, require unique identifiers.
  • Groups of objects that must have common actions performed on them inside of Experience Analytics should have a shared tag in them for easy identification. For example, sensitive data that must have privacy applied to them could have the tag -private as part of the identifier.
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.
  • Where data can be decoded, Experience Analytics can extract information with some additional configuration work.
  • In cases where the data is truly encrypted, Experience Analytics might not be able to extract that information.

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 Account, Company, and Geographic Region.
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 ID or name attribute.
Table 2. Objects in your web application that should be unique

Objects in your web application that should be unique
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: 
/deposits/moneymarket/accountsetupStep2.jsp

Where possible, please observe the following guidelines:

  • Unless a coding, security, or other standard requires otherwise, each viewable page should have a unique URL path, which includes a distinct application directory structure defining the application (section) of the site and specific page in that application.
  • If unique URL paths are not permitted or feasible, then a consistent request or response header, request field, response field, or response text on all pages can perform the same function.
  • The application (section) of the site should define each section of the site on which a report could be delineated.
  • Regardless of technique, for each viewable web page and the application of the site, a consistent unique parameter displayed in either the request or response should be created.

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.
JavaScript identifiers

To simply replay of sessions, please use unique identifiers for JavaScript elements.
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:

  • a unique URL
  • a Web Analytics tag
  • an HTML comment
  • a breadcrumb trail indicator such as text or an image to indicate the step in the process that the user has reached

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. Development of these types of applications has additional recommended practices. 
<!-- 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 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 Experience Analytics Cookie Injector can be deployed on your web server to provide an appropriate session-tracking cookie.

Was this article helpful?
1 out of 1 found this helpful
Return to top

Related articles

Comments

0 comments

Please sign in to leave a comment.