HTTPS communications with target page

Client frameworks provide a configurable means of submitting captured events to the Experience Analytics target page by HTTPS.

There is a performance overhead in sending data over HTTPS. The performance impacts depend on the type of application, the network bandwidth, and the network load.

To deploy HTTPS communications, you might deploy any of the provided Experience Analytics target pages and configure on the server the directory permissions for HTTPS access.

This table lists what you do to deploy HTTPS communications:

Disabling local storage cache

If needed, some client frameworks can be configured to disable the local storage cache, which is used to gather client events for submission to Experience Analytics.

During cached operations, if the client framework is unable to connect to the target, events are queued in a local memory buffer. If the buffer fills before the connection is restored, the last event that is stored in the buffer is discarded. This buffer is cleared on restart or power down.

When the local storage cache is disabled, client events are sent as soon as they are detected by the client framework. Since there is a data overhead for submitting a package of events, the data overhead increases when sending a single event per package, which might affect client and network performance.

This table lists what you do to disable the local storage cache:

Data masking

Each client framework enables the masking of sensitive data on the client before it is submitted to Experience Analytics. Through configuration, you can identify for the client framework the objects in the monitored application that must be masked. For example, you can indicate that each numeral in a credit card field must be replaced by an X:

credit_card_num=XXXX-XXXX-XXXX-XXXX

This table lists what you do to configure data masking:

Data blocking

Data blocking removes all values that are related to the blocked field.

As needed, you can configure the data for individual items to be blocked altogether. If the data in the data masking example was blocked, the submitted item would be:

credit_card_num=

JSON-based values are not stored in name/value format. As a result, the configuration that is required to block JSON-based data is different. In the example below, the value of the textbox (myLoginID) must be masked:

{
                    "type": 4,
                    "offset": 14953,
                    "screenviewOffset": 14953,
                    "count": 5,
                    "fromWeb": true,
                    "target": {
                        "id": "qty",
                        "idType": -1,
                        "name": "qty",
                        "tlType": "textBox",
                        "type": "INPUT",
                        "subType": "text",
                        "position": {
                            "width": 36,
                            "height": 21,
                            "relXY": "0.6,0.6"
                        },
                        "currState": {
                            "value": "myLoginID"
                        },
                        "isParentLink": false,
                        "prevState": {
                            "value": ""
                        },
                        "dwell": 1609,
                        "visitedCount": 1
                    },

Since this value is stored as the value of a JSON path, you must specify the path that uses a different method of identifying its location in the JSON data.