During the client capture process, Tealeaf formats captured events into JSON structures that are easily processed by Tealeaf. The section provides information about the JSON schema that is used by Tealeaf client frameworks, including format, features, and any differences in the supported features between individual client frameworks.

This feature affects the clients generating logging data to a standardized format. The current clients are the following:

• UI Capture j2
• UI Capture for Ajax
• Tealeaf Android Logging Framework Reference
• Tealeaf iOS Logging Framework Reference

Design features

The JSON schema data format supports new data sources and new features in existing sources when they appear in the capture stream. The data interchange format can be modified to accommodate the new data. This data normalization simplifies the event and step attribute creation process.

Normalized interactions

The data format normalizes captured interactions across all client frameworks. For example, the JSON message that indicates when the visitor changed a form field value has the same structure for each of the supported client frameworks.

Compatibility with an earlier version

By design, the schema enables the capture across multiple versions of the client frameworks. Version number information is included whenever client environmental data is submitted.

Ease of use

To economize on space and network bandwidth, JSON messages are bundled together and submitted in a compact structure. In the native frameworks, the request payload is also compressed in compressed format.

When the data is received by Tealeaf, it is decompressed by the PCA and inserted into the request of the parent hit with which it is associated.

When you replay the session in Browser-Based Replay, the request of each hit that contains JSON messages includes a reformatted easier-to-read version of the JSON messages.

Internationalization

UTF-8 is the supported string format because this is the format of the request buffer.

Other generalized features

JSON is the format of choice because:

• It is a native format for JavaScript™ engines, including the Tealeaf event engine.
• It is replacing XML as a de-facto standard in RIA.
• Latest browser versions have native support for JSON.

Unified header format

Each client framework submits data to Tealeaf for capturing by using a consistent header format.

Identifying client framework sessions

The header format is in the following structure:

X-Tealeaf: device (platform) Lib/libversion

This header identifies the client framework and the version of the framework from which the hit was submitted. Below, you can see examples from each of the supported client frameworks:

X-Tealeaf: device (Android) Lib/0.0.7
X-Tealeaf: device (iOS) Lib/0.1.3
X-Tealeaf: device (UIC) Lib/2008.3.6.1

In the PCA pipeline, this header is detected and rendered as a request variable. This is an example of one of the request variables:

HTTP_X_TEALEAF=device (Android) Lib/0.0.7

Content-encoding and content-type headers

To reduce network traffic, the native client logging frameworks are compressing the request data into compressed format before submitting them to Tealeaf for capture. For each submitted hit, its Content-Encoding header is set to the value gzip.

This content encoding type is automatically captured for you. Additionally, each client framework submits hits by using this content-type header:

Content-Type=application/json

If you deployed a Tealeaf CX UI Capture for AJAX solution that is configured to submit user interface data through XML, this header has different values.

Session identifiers

Depending on the type of client framework, the identifier for the session information varies. Consider this example:

[StepAttributes]
{
    "serialNumber": 1,
    "messageVersion": "0.0.0.2",
    "sessions": [
        {
            "startTime": 1331346014596,
            "id": "C4B290A5E3EB4E28FA8CE6DCCDDE6CF5",

...

For the id value:

• In the Tealeaf Android SDK, the id value identifies the session. It is created automatically, or the application user passes a unique ID that is used for sessionization. This value is the same for each hit of a single session.
• In the Tealeaf iOS SDK, the id value identifies the session. It is created automatically, or the application user passes a unique ID that is used for sessionization. This value is the same for each hit of a single session.

  This data is not submitted by CX UI Capture for AJAX.

The id value for sessions is not a consistent value for identifying sessions. Use TLSID, which is inserted into the request of each parent hit of a set of step attributes.

Count steps

Each step includes a count property, which identifies the number of the step for the current hit.

In the example below, you can see the count properties in each of the two steps for this hit: type=LOAD and type=UNLOAD. For the count properties, values start at 1 and are automatically incremented.

"messages": [
        {
            "type": 2,
            "offset": 0,
            "screenviewOffset": 0,
            "count": 1,
            "fromWeb": true,
            "screenview": {
                "type": "LOAD",
                "name": "root",
                "url": "/",
                "referrer": ""
            }
        },

        {
            "type": 2,
            "offset": 40824,
            "screenviewOffset": 0,
            "count": 12,
            "fromWeb": true,
            "screenview": {
                "type": "UNLOAD",
                "name": "root",
                "url": "/",
                "referrer": ""
            }
        }

Performance measurement

Tealeaf has the ability to capture individual hits from the client enables a unique ability to monitor the performance of your web application, the network, and the client browser.

Connection type messages

In the submitted JSON messages, connection type information is submitted as message type=3.

The connection type message is not sent by CX UI Capture for AJAX.

For example:

{
    "offset": 0,
    "type": 3,
    "connection": {
        "statusCode": 200,
        "responseDataSize": 0,
        "initTime": 0,
        "responseTime": 0,
        "url": "http://www.example.com",
        "loadTime": 0
    }
}

From the iOS Logging Framework, some of the properties are not available for capture.

Time offsets from page load and start of session

In framework messages, time events are measured based on the page load for each page.

[StepAttributes]
{
    "serialNumber": 1,
    "messageVersion": "0.0.0.2",
    "sessions": [
        {
            "startTime": 1331346014596,
            "id": "C4B290A5E3EB4E28FA8CE6DCCDDE6CF5",

...

In this example, the value for startTime indicates the time offset in milliseconds since Jan 1, 1970 UTC when the page was loaded from which the set of attributes was generated.

Each individual attribute has a time value in the offset property:

"messages": [
        {
            "type": 2,
            "offset": 0,
            "screenviewOffset": 0,
            "count": 1,
            "fromWeb": true,
            "screenview": {
                "type": "LOAD",
                "name": "root",
                "url": "/",
                "referrer": ""
            }
        },
        {
            "type": 2,
            "offset": 40824,
            "screenviewOffset": 0,
            "count": 12,
            "fromWeb": true,
            "screenview": {
                "type": "UNLOAD",
                "name": "root",
                "url": "/",
                "referrer": ""
            }
        }

In these example messages, the offset property contains two different values:

• For the first message, it indicates that the LOAD event occurred 0 milliseconds after page load.
• For the second message, it indicates that the UNLOAD event occurred 40824 milliseconds after page load, approximately 41 seconds after the page has loaded.

renderTime offsets

In the first message, the renderTime property indicates that the time taken to render the page required 254 milliseconds, which should match the value for the offset property for the message.

In UI Capture, the renderTime property is reported in the Performance message in milliseconds.

Dwell time

Dwell time is applicable for control types where the visitor can spend time within the control. For example, when the visitor clicks in a text input control, the dwell time measures the time in milliseconds between when the control receives focus and when the focus switches to a different control.

• Controls that do not support a visitor spending time in them do not contain the dwell time property.
• From UI Capture, dwell time is not provided for change events that are not associated with a blur event. For example, if a user clicks several times in a row on a check box, no dwell time value is provided.

In this example, the dwell property measures this value in milliseconds for a textbox.

{
    "type": 4,
    "offset": 8465,
    "count": 8,
    "event": {
        "type": "change"
    },
    "target": {
        "id": "billing:lastname",
        "idType": -1,
        "type": "INPUT",
        "subType": "text",
        "name": "billing[lastname]",
        "dwell": 5620,
        "currState": {
            "value": "asf"
        }
    }
}

Link image targets

UI Capture j2 can capture the content of the href target element if the element:

• Is a link
• Has a parent that is a link (isParentLink=true)

In this example, the href value records the link destination. In this case, the link is listed for the parent object, as isParentLink is set to true.

{
    "type": 4,
    "offset": 13456,
    "screenviewOffset": 13455,
    "count": 9,
    "fromWeb": true,
    "target": {
        "id": "logo",
        "idType": -1,
        "name": "",
        "tlType": "IMG",
        "type": "IMG",
        "subType": "",
        "position": {
            "width": 18,
            "height": 20,
            "relXY": "0.6,0.5"
        },
        "currState": {
            "href": "http://example.com/mypage.html#logo_link"
        },
        "isParentLink": true,
        "visitedCount": 1
    },
    "event": {
        "tlEvent": "click",
        "type": "click"
    },
    "focusInOffset": 3207
},

Previous state and current state tracking

Each control object submits information to identify its previous state before the change to the current state. If a field is empty, no value is submitted for it. As a result, no value for currState is recorded.

"target": {
    "position": {
        "y": 0,
        "height": 100,
        "width": 200,
        "x": 0
    },
    "id": "nameTextBox",
    "dwell": 232313,
        "noFilled": 2,
    "type": "MyEditText",
    "prevState": {
         "text": ""
    },
    "currState": {
                 "text": "MyName"
    },
    "subType": "EditText",
    "tlType": "textBox"
},"screenViewOffset": 1253,"offset": 67676876,"screenViewOffset": 4556,"type": 
    4,"event": {
    "type": "click",
    "subType": "subclick"
}

Exceptions

The Tealeaf client frameworks capture exceptions that are recorded in the client application and submits them in a specific message type (type=6).

Mobile native client frameworks

When a stack trace is detected on the client application, a JSON message of type=6 is submitted, including the entire stack trace of the exception in the stackTrace property, as in this divide-by-zero example:

{"offset": 0,"type": 6,"exception": {
    "description": "divide by zero",
    "stackTrace": "java.lang.ArithmeticException: divide by zero\n\tat 
com.tl.uic.test.model.JSONTest.testException(JSONTest.java:391)\n\tat 
java.lang.reflect.Method.invokeNative(Native Method)\n\tat 
java.lang.reflect.Method.invoke(Method.java:507)\n\tat 
android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:204
)\n\tat 
android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:194)\
n\tat 
android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTe
stCase2.java:186)\n\tat 
junit.framework.TestCase.runBare(TestCase.java:127)\n\tat 
junit.framework.TestResult$1.protect(TestResult.java:106)\n\tat 
junit.framework.TestResult.runProtected(TestResult.java:124)\n\tat 
junit.framework.TestResult.run(TestResult.java:109)\n\tat 
junit.framework.TestCase.run(TestCase.java:118)\n\tat 
android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:169)\n\tat 
android.test.AndroidTestRunner.runTest(AndroidTestRunner.java:154)\n\tat 
android.test.InstrumentationTestRunner.onStart(InstrumentationTestRunner.java:5
29)\n\tat 
android.app.Instrumentation$InstrumentationThread.run(Instrumentation.java:1448
)\n",
    "name": "java.lang.ArithmeticException"
}

Some stack trace messages cannot be captured from the iOS Logging Framework.

Form field monitoring

Tealeaf client frameworks provide superior insight into specific activities on the form fields of each page of your web application. Once per hit, the client framework submits information about the form fields that were left blank or were unchanged, as well as information about which fields were changed multiple times. You can also monitor how long the visitor spent in an individual form field.

Message on form fields that were unchanged

To monitor form fields that were not changed, the client frameworks submit a message of type=4. This message is for a synthetic event of type=unchanged. This synthetic event message is submitted whenever the control value for an object on logical page unload is the same value as detected during logical page load.

Reported along with this information is the set of form fields on the hit that were not changed, as described in the target set of properties in this example:

{
    "type": 4,
    "offset": 5469,
    "count": 7,
    "event": {
        "type": "unchanged"
    },
    "target": {
        "id": "cb1",
        "idType": -1,
        "type": "INPUT",
        "name": "cb1",
        "subType": "checkbox",
        "visitedCount": 0,
        "currState": {
            "checked": false,
            "value": "red"
        }
    }
}

This message is submitted when an ScreenView is unloaded, which might not correspond to when the page is unloaded. If the ScreenView can be unloaded multiple times per page in your application, the unchanged message might be reported multiple times, which might affect reporting.

Show fields completed more than once

Tealeaf client frameworks can also monitor the form fields that were visited multiple times on a single page. In this example, the visitedCount property is inserted into the target message, and its value (2) indicates the number of times the form field (id=nameTextBox) was visited:

{"target": {
    "position": {
        "y": 0,
        "height": 100,
        "width": 200,
        "x": 0
    },
    "id": "nameTextBox",
    "dwell": 232313,
    "visitedCount": 2,
    "type": "MyEditText",
    "prevState": {
        "text": ""
    },
    "currState": {
         "text": "MyName"
    } ,
    "subType": "EditText",
    "tlType": "textBox"
},"offset": 67676876,"screenViewOffset": 4556,"type": 4,"event": {
    "type": "click",
    "subType": "subclick"
}
}

Message on form fields that were left blank

For each form field control that was not entered, the Tealeaf client frameworks submit a message that indicate that the form field was left blank.

• This message is submitted when the user selected the field but did not enter any value.
• The visitedCount for this message is a value greater than 0.