The Tealeaf software running on computers in your data center is configured to see every byte of data exchanged between your web servers and the browsers on your visitors' computers. Tealeaf passively captures the bi-directional data stream and forwards a copy of each relevant packet of that data to a server running the Tealeaf system.
- Capture Server
The Passive Capture software reassembles TCP/IP packets into HTTP requests and responses for each exchange between visitor and web application. Optionally, uninteresting data can be dropped, and sensitive data can be deleted. The captured combinations of requests and responses (called hits) are then forwarded to another server running the Tealeaf processing software.
- Processing Server (also called Canister Server)
Individual hits sent from the Capture Server are grouped together into a Tealeaf session, which is assembled hit-by-hit to include all web page interactions between a specific visitor and your website. The data contained in this session is scanned for keywords and codes that you have defined. When matches are found, a record of this event is stored for additional processing, including generation of reports and alerts. When the session is complete, the session is indexed for search and written to disk.
- Tealeaf Portal (also called Report Server)
This server's Web-based interface allows data analysts, business owners, IT staff, and administrative users to view the status of interactions with your website, with aggregate data reports that display what visitors are doing on your site. Tealeaf users can search the saved visitor sessions and analyze them for common attributes, such as order completion. Individual visitors' sessions can be replayed with the actual data that was sent and received, so a high-fidelity recreation of the visitor's experience can be reviewed.
How DOM Capture and Replay works
DOM Capture relies on the Document Object Model (DOM), which provides a structured representation of the web page (document). The DOM Capture Service captures a "snapshot" of the rendered DOM. The "snapshot" is sent to the server as a Type 12 JSON message. The Replay server processes the DOM for Browser Based Replay (BBR).
Note: DOM Capture can be enabled or disabled on a per page basis. For pages, which do not have DOM Capture enabled, the classic capture and replay process is used.
Stages of DOM Capture and Replay
There are four stages of DOM Capture and Replay:
Stage | Processing |
---|---|
Capture | During this stage, UI Capture processes the DOM message into a UI hit request. |
PCA Processing | During this stage, PCA handles decompression of the compressed POST data. |
Pipeline Processing | During this stage, the pipeline moves the captured DOM from the UI hit to a virtual hit that uses the captured DOM as the hit response. |
Replay | This stage processes the session on the replay server according to the defined rules. |
Capture
After the raw DOM is captured, Tealeaf updates input variables and applies privacy masking according to the UI Capture privacy masking rules. Inline script elements are deleted.
If the captured DOM is below the configured size limit, the capture is serialized into JSON Type 12 message format. The message is compressed or not, depending on the settings. If the captured DOM is over the configured size limit, the capture is discarded and an error message is logged.
PCA processing
- JSON text with no compression
- JSON text with .gzip compression
Pipeline processing
The Windows™ pipeline moves the captured DOM from the UI hit into a virtual hit with the captured DOM as a response. The DOM Capture data is removed from the JSON and metadata is modified. The virtual hit has the same PAGE URL as the UI hit that had the DOM captured data.
Replay
The replay server processes the session according to the defined rules. For pages on which DOM Capture is enabled, the replay server goes through the UI events and identifies those events that have a captured DOM associated with them. The Replay server uses the page ID and token of the captured DOM to identify the virtual hit and the rendered DOM for the UI event.
Replaying sessions with captured DOM
Replay rules are used to determine whether DOM Capture replay is enabled or disabled for a particular page URL. Replay processes the session according to the rules.
For pages on which DOM Capture is enabled, the Replay identifies those UI events on the page that have captured DOM associated with them.
Note: If there is no DOM Capture associated with a UI event, Replay does not display the event in the BBR navigation list.
Replay uses the page id and the token associated with the captured DOM, to identify the virtual hit in the session that is tagged with the same information in its request headers. Replay associates the response of the virtual hit as the rendered DOM for the UI event.
The Capture field in the page statistics bar of the BBR user interface indicates the "type" of capture. Pages with captured DOM have a Capture type of DOM.