Message types

Events that are captured from client frameworks are bundled together and submitted as a set of messages.

A message from a client framework is what defines a single step in Discover, which is a single event that is identified and captured by a client framework.

Multiple messages can represent a single action of the visitor. For example, clicking a radio button might result in two messages of different types: one for the click event and one for change event.

Note: If you do not want to double count actions, use both the event type AND the ID/name when you create events for a specific action. If you look only for ID = checkout method for example, then this event fires twice when you only wanted it to fire once.

The volume of messages can depend on the configured logging level, which is defined in the client frameworks.

You can review the raw format of a submitted set of JSON messages and the format in which they are displayed after processing in Discover.

Example message: Raw request body

The [RequestBody] following information includes a sample raw request, which contains a set of JSON messages.

Note: In the raw request, the following entry is a single paragraph. You cannot use this section to create step-based attributes.
  • While it is possible to create hit attributes from the [RequestBody] section, it is not recommended, as this format might change over time.

[RequestBody]
{"version":"12.1.0.0","serialNumber":1,"sessions":[{"id":"ID14H2M3S663R0.36228193
267311725","startTime":1326837723663,"timezoneOffset":480,"messages":[{"type":2,
"offset":2226,"count":1,"context":{"type":"LOAD","name":"root","renderTime":
2226}},{"type":6,"offset":2230,"count":2,"exception":{"description":"Unable to
get value of the property 'nodeValue': object is null or undefined",
"url":"http://hclswtech.com/store/",
"line":1}},{"type":4,"offset":24878,"count":3,"event":{"type":"click"},"target":
{"id":"[['main'],['DIV',1],['DIV',0],['TABLE',0],['TR',0],['TD',0],['DIV',0],
['P',0],['A',0]]","idType":-2,"type":"A"}},
{"type":2,"offset":24880,"count":4,"context":{"type":"UNLOAD","name":"root"}}]}]}

After the messages were passed through Discover, the raw request is stored in the [RequestBody] section of the request, which is viewable through Request View in Replay.

Example message: Formatted request body

When the JSON messages are received, Discover reformats them into a more legible format, which is listed here.

This information is available at the bottom of the request, which is formatted for view in Request View in Replay.

Click to view expanded example messages.


{
    "version": "12.1.0.0",
    "serialNumber": 1,
    "sessions": [
        {
            "id": "ID14H2M3S663R0.36228193267311725",
            "startTime": 1326837723663,
            "timezoneOffset": 480,
            "messages": [
                {
                    "type": 2,
                    "offset": 2226,
                    "count": 1,
                    "context": {
                        "type": "LOAD",
                        "name": "root",
                        "renderTime": 2226
                    }
                },

                {
                    "type": 6,
                    "offset": 2230,
                    "count": 2,
                    "exception": {
                        "description": "Unable to get value of the property 
                        'nodeValue': object is null or undefined",
                        "url":"http://hclswtech.com/store/",
                        "line": 1
                    }
                },

                {
                    "type": 4,
                    "offset": 24878,
                    "count": 3,
                    "event": {
                        "type": "click"
                    },
                    "target": {
                        "id": 
                        "[['main'],['DIV',1],['DIV',0],['TABLE',0],
                         ['TR',0],['TD',0],['DIV',0],['P',0],['A',0]]",
                        "idType": -2,
                        "type": "A"
                    }
                },

                {
                    "type": 2,
                    "offset": 24880,
                    "count": 4,
                    "context": {
                        "type": "UNLOAD",
                        "name": "root"
                    }
                }
            ],
        }
    ]
}

In the preceding example, the content after the following string is a set of four separate messages:


"messages": [

Each message is demarcated by a set of curly brackets.

  • Data that is defined at the same level as messages (such as serialNumber or timezoneOffset) is considered environmental data.

Each step message constitutes a single step.

  • Step-triggered events can fire per message step.
  • In the preceding example, there are four-step messages. As a result, step-triggered events can fire up to four times on this hit.
Note: Each step-triggered event also has access to the hit attribute data of its parent hit and the environmental data included for reference in each step.

When you create step attributes, the value that is extracted is the contents between the colon (:) and the final comma (,) on the line.

Suppose you want to monitor exception messages that are submitted from the client framework. In the example above, the data is in the following area.

  • In the following example, message data that was present in the previous example but is not relevant to the example is replaced with the <omitted> string.

"sessions": [
    {
    <omitted>
            "messages": [
           <omitted>
                {
                    "type": 6,
                    "offset": 2230,
                    "count": 2,
                    "exception": {
                        "description": "Unable to get value of the property
                        'nodeValue': object is null or undefined",
                        "url": "http://hclswtech.com/store/
											 ",
                        "line": 1

In the preceding example, you can see that the exception message is stored in the description value. To reference this value in step-based eventing, when you create the step attribute to monitor the above, the node in the tree is referenced by using the following structure:


sessions[0].message.exception.description

The naming structures for the sessions and messages nodes are changed, and the type identifier is omitted.

Note: When you create step attributes through Replay, you use the menu, which automatically pre-populates the attribute with the appropriate reference within the Event Manager. These steps are described later.