For web applications that use or require user authentication, capturing login IDs can be a useful means for tracking visitor behavior. While a login ID is not a guaranteed indicator of a unique visitor, it does provide insight into the activities on your web application that are engaged through specific user accounts, which is useful for addressing customer service issues.

Note: Use the Tealeaf Cookie Injector to generate unique, persistent cookies for individual visitors.

As part of the installation, Tealeaf provides a number of pre-defined data objects that you can use for tracking basic activities, metrics, and other useful information about your web application. Among these are two objects for capturing Login IDs. This end-to-end scenario describes how to configure the provided Login ID data objects for your web application's needs and then to surface that information in search through the Portal.

As part of the set of provided data objects, Tealeaf includes a hit attribute, an event, and a session attribute for detecting the login ID displayed in your web application.

• A hit attribute is used to define the hit attributes in request or response data that demarcate an element of data that you wish to track through an event.
• An event is triggered by a condition. In this case, the condition is the presence of the Login ID hit attribute. When this hit attribute is detected, the event is fired, which stores the Login ID value in the session attribute Login ID.
• A session attribute is a session-level variable that can be populated and updated based on events. The Login ID session attribute is the first one in your system. Tealeaf supports the creation of up to 64 session attributes.
• When the hit attribute for Login ID is detected, the event is triggered, and the session attribute Login ID is updated with the value.

The scenario begins with how to configure the Login ID hit attribute and test if the session attribute is being properly populated.

User agents

Before you begin, you should familiarize yourself with user agents and the tools for managing them. User agent detection relies on two user agent public standards:

• Browscap: This public standard is used to track fixed desktop and bot user agents.
• WURFL: This public standard is used to track mobile user agents for Mobile Web sessions.

To capture user agent information, extended user agent parsing must be enabled.

Note: Extended user agent parsing is enabled by default in the Tealeaf Reference session agent, which is included in the default pipeline. This session agent must be included in each Canister pipeline that processes session data in your Tealeaf environment.

To track sessions sourced from a mobile web browser, you must download, convert, and deploy the WURFL public standard for use by the Tealeaf Reference session agent.

Note: Mobile user agent detection is a component of the Tealeaf CX Mobile component. For more information, contact your Acoustic representative.

To track sessions that are sourced from mobile native applications, you must deploy one of the Tealeaf client frameworks.

Note: Mobile user agent detection is a component of the Tealeaf CX Mobile component. For more information, contact your Acoustic representative.

Available hit attributes

A hit attribute is the data object that is used to gather patterns of data from the request or response of each hit passed through the event engine.

Tealeaf provides several hit attributes that are configured to look for the name-value pairs that are inserted into the request that contains user-agent data. In the table below, you can review the request variables that are mentioned and the name of any applicable hit attribute that is provided by Tealeaf.

Table 1. Available hit attributes

REQTEXT

Request Variable	Common	Mobile Web	Mobile App	Default Hit Attribute	Description
TLT_TRAFFIC_TYPE	Y	Y	Y	Traffic Type	Type of traffic. See TLT_TRAFFIC_TYPE request variable in Request data.
TLT_BROWSER	Y	Y	Y	Browser	Visitor browser type. Example: Firefox
TLT_BROWSER_VERSION	Y	Y	Y	Browser Version	Visitor browser type and version. Example: Firefox 66.0.4
TLT_BROWSER_PLATFORM	Y	Y	Y	Browser OS	Visitor browser operating system. Example: WinXP
TLT_BROWSER_JAVASCRIPT	Y			None
TLT_BROWSER_COOKIES	Y			None
TLT_BROWSER_VERSION		Y	Y	None
TLT_SCREEN_WIDTH		Y	Y	None
TLT_COLOR_DEPTH		Y	Y	None
TLT_PICTURE_SUPPORT		Y		None
TLT_VIDEO_SUPPORT		Y		None
TLT_STREAMING_SUPPORT		Y		None
TLT_BRAND			Y	None
TLT_MODEL			Y	None

Data source considerations

Consider the following information about data sources.

• Although it is possible to create a dimension that is populated directly from the source hit attribute, Tealeaf does not recommend this approach.
• By creating an event that is populated from the hit attribute first, you can apply modifications to the conditions and states in which the event is triggered, limiting the processing.
• If the dimension is populated directly from the hit attribute, the dimension is updated with each hit, which is not necessarily in most cases.
• Particularly for user agent data, which can not change from hit to hit, it is a best practice to create an event source from the hit attribute, which is used in turn as the source of the dimension.

Create hit attributes

There are some user agent variables that are not captured by any default hit attribute. However, creating these hit attributes is a simple process.

For this example, one of the most useful attributes to surface in reporting is the Browser Version attribute. This attribute is provided by Tealeaf. It pulls data from the TLT_BROWSER_VERSION request variable.

Because this data is already created for you, the following steps describe how you can review this information, highlighting the key values to specify. You can modify these steps to create new hit attributes for the other request variables that are inserted in extended user agent parsing.

1. Log in to the Portal.
2. From the Portal menu, select Configure > Event Manager.
3. Click the Hit Attributes tab.
4. In the left navigation panel, click the System Hit Attributes label.
5. In the steps below, you review the configuration for the Browser Version hit attribute. In the main panel, locate and right-click Browser Version. Select Edit Hit Attribute....
6. To create hit attributes to capture request variable data, the following values are important to specify:
   • Search in. User agent values are stored in the Request.
   • Use Start Tag/End Tag. Select this value to specify the start and end patterns of text that define the beginning and end of the value to capture.
   • Start Tag. Enter:

     
     \r\n<request_variable_name>=
     

     where <request_variable_name> is the corresponding TLT_ value in the preceding table.

     Note: Be sure to include the terminating equals sign in the Start Tag.
   • End Tag. Enter:

     
     \r\n
     

   • Case Sensitive. Select this check box.
   Note: Since this object is a system hit attribute, it can't be modified.
7. For a hit attribute that you create, click Save Draft now. The draft is saved.
8. Repeat the preceding steps for other request variables you want to track. Instead of reviewing the values, you must create new values for each setting.
9. You can locate test data and test your drafted hit attributes in the Event Tester before you save it.
10. To commit your changes to the server, click Save Changes.

The hit attributes are now detecting user agent information that is written to the associated request variables.

Create an event to fire in the presence of user agent values

After you create the hit attributes to locate user agent information in the request, you must create events to record this information.

In this step, you create an event to record the value of the browser version, which is tracked in the Browser Version hit attribute created in the previous example. The hit attribute, in turn, is populated by values in the TLT_BROWSER_VERSION request variable, which is inserted by Tealeaf.

1. Log in to the Portal.
2. From the Portal menu, select Configure > Event Manager.
3. Click the Events tab.
4. Click New Event.
5. In the Add Event window, you specify the definition of your new event through a series of tabs.

   Setting	Description and notes
   Name	Note: For easiest identification, use the same name for the hit attribute, event, and dimension that use the same source data, if possible.
   Description
   Labels	You can use event labels to organize your events. An event can have multiple labels that are associated with it. Note: You can create and use the label User Agent to store all of your user agent-related events. You can also add this event label to the standard user agent events provided by Tealeaf.
   Evaluate	This value defines the trigger when the event is checked. For this one, you must check this event on the first hit of the session. Some bot traffic is known to switch user agent strings during a session, so you can choose to make this event fire on every hit. However, depending on the data volume, this configuration change could significantly increase the data storage requirements. To begin, set this event to be evaluated once per session. Note: Since the browser version of a device does not change during a session, there is no need to check for this event on any hit other than the first one, unless for some reason user agent information is not reported in the first request of the session. For data that changes from request to request, you can change the trigger for the event.
   Track	Your selection identifies the instance or instances of the event occurrence that are recorded for the event. This value is set to be First Per Session for the event to be evaluated on the first hit of the session. No other configuration is permitted.
   Value type	This setting defines the type of value to record. The count of the event is always recorded. Note: For the User Agent - Browser Version event, the data that is captured is text data.
   Active check box	Select this check box. When selected, the event is used to process session data as soon as the event is committed to the server.
   Searchable & Reportable check box	Select this check box. When selected, the event can be used for search and reporting purposes in the Portal.

6. Condition Step: Click the Condition tab. This area is used to configure the condition or conditions that are evaluated when the event is evaluated. When the conditions in this step collectively evaluate to true, then the event fires.
   1. For the User Agent - Browser Version event, you add the Browser Version hit attribute as the condition.
   2. Click the Hit Attributes panel.
   3. Click the System Hit Attributes category.
   4. Select the Browser Version hit attribute as the condition for your event.
   5. Set the hit attribute to be tested to Hit Attribute Found and is true.

      This configuration means that whenever the hit attribute is detected, the event fires. Since the request data is written only when a corresponding user agent is matched, you can build the condition to detect only for the presence of the request variable.

7. Value Step: In the Value step, you define the value that is recorded.
   1. The values to record are dependent on the Value Type selection you made in the Summary.
   2. For each Value Type selection, the event count is always recorded.
   3. In the User Agent - Browser Version example, the Value Type is configured to be Text, which means that data that is recorded is defined as text data.
   4. In the Value step, click Select Item to Record.
   5. In this case, you want to record the browser version value, which is stored in the Browser Version hit attribute. Select this hit attribute.
   6. The hit attribute is selected. From the drop-down, select First Match per Hit, if it is not already selected.
   7. The Value step will have the following information:

      Selected Value Type: Text

      If the Conditions are true, the following is recorded if it is configured:

      • Event occurrence
      • Value specified below:

      Select Item To Record. . . x Browser Version First Match per Hit.

8. Report Groups Step: In the Report Groups step, you can specify any report groups whose contextual data is recorded with each instance of the event.

   A report group is a collection of dimensions. A dimension is a contextual piece of data that is recorded when the event is recorded. The data is stored with the event in the session.

   1. For the User Agent - Browser Version event, you can record the URL/Host/App/Server report group, which is provided by Tealeaf. This report group records the URL, host name, application name, and server name at the time that the event is triggered. Note: For events that are evaluated on every hit and record values on most of them, adding report groups can affect the volume of recorded data. Add report groups only as needed.
   2. Click Add Report Group.
   3. Click URL/Host/App/Server.

      The Report Groups window will haveURL/Host/App/Serveralong the top of the window and the following will be displayed in the display area:

      Dimensions:      URL (Normalized)
                                Host
                                Application
      			     Server

9. More Options Step: In the More Options step, you can specify additional actions that are completed when the event fires.
10. For the User Agent - Browser Version event, verify that the following settings are specified. Note: These options are specified in greater detail elsewhere. For this event, the default settings must be applied.

    Setting	Value
    Display in Portal check box	Selected
    Display in Session List check box	Selected
    Flag Every Occurrence in Replay check box	Selected
    Send to Event Bus check box	Clear this item, unless you deploy the Event Bus and want to send user agent data to the external system.
    Minute Data On check box	Cleared
    Update Session Attribute	There is no need to update a session attribute with these values.
    Update Session Timeout check box	Cleared
    Additional Actions	Select None.

11. You are done specifying the event. Click Save Draft.
12. Before you commit events to the server, you must test them in the Event Tester. Draft versions of event-related objects can be tested.

Create a dimension to store user agent values

You can create a dimension object to store information so that it can be used for report segmentation.

You have now reviewed or created the objects necessary to report the values for the TLT_BROWSER_VERSION request variable, which captures browser versions reported from the client. Now, you can report on the counts of the number of instances where the User Agent - Browser Version event occurred. You can also generate reports on the different recorded values (IE7.0, and so on). Collectively, this information is not useful.

What is more useful is how this data can be used to segment reports. For example, you can create a report in which the counts for a different event, such as one tracking your application's errors, is segmented based on the recorded browser versions. This report would create a chart in which each detected browser version is represented by a vertical bar that indicates the occurrences of the event in the reporting period

To create the dimension object to store the browser version information so that it can be used for this report segmentation:

1. Log in to the Portal.
2. From the Portal menu, select Configure > Event Manager.
3. Click the Dimensions tab.
4. Click New Dimension.
5. In the Add Dimension dialog, populate the following properties:
   1. Name: User Agent - Browser Version
   2. Click the Populated By button. Click the Hit Attributes tab. Open the group that contains the hit attribute that you created. Select the Browser Version hit attribute.
   3. Populate With: First Value in Session
   4. Click the Advanced Options caret.
   5. For the Values to Record entry, select Whitelist + Observed Values.
6. The window Add Dimension: User Agent - Browser Version will have the following settings:
   • Name: User Agent-Browser Version
   • Description: Records values from User Agent - Browser Version event, which extracts values from user agent.
   • Populated By: User Agent Browser Version.
   • Populated With: First Value in Session.
   • Advanced options
     • Values To Record: Whitelist + Observed Values
     • Default Value: [Others]
     • Max Values Per Hour: 1000.
     • Allow Empty values: Check box is cleared.
     • Set Value Display Order: Check box is cleared.
7. Click Save Draft.

   You have now configured the dimension to capture data from the capture stream.

   Before the dimension is operational, you must:

   1. Associate the dimension with a report group.
   2. Associate the report group with an event.

Associate the dimension with a report group

The dimension that you just created must be associated with a report group.

1. In the Dimensions tab, click New Report Group.
2. In the Add Report Group dialog, enter a user-friendly name and description. These entries must reflect the function of the report group. For our example, enter the following code: User Agent - Browser Version.

   More dimensions can be added as needed, and you can change the name of the report group then without affecting reporting.

3. For the Template value, select Standard.
4. Click Add Dimensions.
5. Select User Agent - Browser Version.
6. Click Save Draft.

Associate the report group with an event

Now, the newly created report group must be associated with an event. When the event occurs, the contextual data that is captured in the dimensions within the report group is recorded at the same time.

1. Click the Events tab.
2. Select the event with which you would like to record the User Agent - Browser Version dimension.

   In our example, you might associate it with the Http 404 - Not Found event that is provided by Tealeaf. This event is stored in the Standard Events.

3. Right-click the event and select Edit Event.
4. Click the Report Groups step.
5. Click Add Report Group.
6. Select the User Agent - Browser Version report group.
7. Click Save Draft.

Managing dimension values

The hit attribute scans for occurrences of the TLT_BROWSER_VERSION request variable. When it occurs, the event fires, recording the request variable value as a numeric value.

Note: When the Http 404 - Not Found event occurs, the current value of the event is recorded as the value for the User Agent - Browser Version dimension.

The dimension values are being gathered directly from the capture stream. Each value that is detected in the capture stream is recorded into the database, which presents some issues.

For the TLT_BROWSER_VERSION request variable, the range of value is extensive. For each browser known through the browscap public standard, there can be multiple versions. But each detected value can be a repeat of a value that is already known to Tealeaf through previously recorded dimension values. As a result, a great deal of replicated data is recorded. Each time a session is captured from a device that is using Firefox 72.0.2, another instance of the dimension value is recorded in the database. For high-volume dimensions, this unnecessary recording is expensive.

Note: For user agent data, the landscape of available browsers is constantly changing. As a result:

• You must regularly update your browscap and WURFL (if CX Mobile is licensed) standards so that you have the latest user agent information.
• You must review your dimension data regularly to see whether new values are being recorded.

  These habits are good workflow habits to apply to your dimensional data.

Create a white list

As an alternative to this recording method, you can create a whitelist of values, which contains the values that are allowed to be recorded for the dimension. Recording instances from the whitelist requires a much smaller volume of data.

Note: Over time, a dimension that is configured to record Whitelist + Observed Values grows without bound. For data storage purposes, you must always try to convert these dimensions to Whitelist Only.

There are three ways to create a whitelist:

• Specify the whitelist manually: If you know the acceptable values for a dimension, you can specify the list through the Event Manager. This method is useful only for dimensions with a limited number of dimensions.
• Upload list of values: If you know the acceptable values for a dimension, you can create a whitelist of values in a local file and upload it to the Portal.
• Gather whitelist values from dimension logs: Through the Event Manager, you can enable logging of dimension values in to a database log. After enough values are captured, you can download the logged values to a local text file, edit it, and then load it into the dimension as the whitelist through the Event Manager.

This method is the easiest to manage and is described in the following sections.

Enable logging

The first step for managing dimension values is to enable logging. To enable logging on the dimension:

1. In the Event Manager, click the Dimensions tab.
2. Select the User Agent - Browser Version dimension.
3. Right-click and select Edit Dimension?.
4. Click the Advanced Options caret.
5. Click Turn On Logging.
6. Click Save Draft.
7. Click Save Changes.

Detected values for the dimension are now stored in the dimension logs.

Note: After you enable dimension logging, you must wait for a sometime to collect a sufficient volume and range of values to populate your dimension whitelist. For this exercise, wait 1 hour.

Download log file

After sufficient time, you can download the logs to your local workstation, where you build the whitelist of values.

1. In the Event Manager, click the Dimensions tab.
2. Select the User Agent - Browser Version dimension.
3. Right-click and select Edit Dimension?.
4. Click the Advanced Options caret.
5. Click Edit Whitelist?.
6. In the Edit Whitelist window, click Download Log Values.
7. Save the file locally.
8. Click Cancel twice.

After you create the value lists, you must reformat them into single-column text files and then import them as whitelisted values in a dimension you create in the Event Manager.

Import the data into the Event Manager

The following steps outline the general workflow for importing value lists into the Event Manager.

1. Click the Dimensions tab.
2. Select the User Agent - Browser Version dimension.
3. Edit the dimension.
   1. Click Edit Whitelist....
   2. In the Edit Whitelist window, click Import File.
   3. In the Import Whitelist dialog, click Browse. Navigate your local environment to select the text file you created. Click Open.
   4. To import the selected file, click Import.
   5. The imported files are displayed in the whitelist.
   6. You may edit the values and their properties or add additional values as needed.
4. Click Done. Click Save Draft to save a draft of your new dimension.
5. To save the changes to the server, click Save Changes.
6. After 10 minutes or so, some completed sessions should be populated based on this dataset.

Note: If you are satisfied with your whitelist, you should switch over to Whitelist Only for the dimension. Any values that are detected but do not appear in the whitelist are recorded as [others] for the dimension. When this dimension value begins recording counts, you can revise the whitelist to capture the newly detected values.

Search for the event

To search for sessions in which the event occurred, complete the following steps.

1. From the Portal menu, select Search > Completed Sessions. Note: You can also complete this search against active or all sessions.
2. Clear all of the search fields.
3. Select the default completed search template.
4. Under the Basic Search Fields category, click the Events link.
5. In the main panel, click Select Event.
6. In the Event Selector, click the event label under which the User Agent - Browser Version event was stored.
7. Select the event. Click Select.
8. To run the preceding search, click Search.
9. Results are displayed in the session list.

Search for specific values for the event

1. From the Portal menu, select Search > Completed Sessions. Note: You can also complete this search against active or all sessions.
2. Clear all of the search fields.
3. Select the default completed search template.
4. Under the Basic Search Fields category, click the Event Values link.
5. In the main panel, click Select Event.
6. In the Event Selector, click the event label under which the User Agent - Browser Version event was stored.
7. Select the event. Click Select.
8. The event is added to the search criteria.
9. To search for a specific value for this event:
   1. Set the operator to includes, if it is not already selected.
   2. Set the value for the event for which you want to select.
10. The search terms must look like:
11. To run the preceding search, click Search.
12. Results are displayed in the session list.

Locating instances in returned results

When the sessions are returned in the search results, you can locate the instances of the event or the event and dimension combination by using Quick View.

1. To locate, click the Quick View icon next to the session of interest to you in the search results.
2. In Quick View, from the Order By drop-down, select Event Name.
3. If there are too many event names to review, click the link next for the Event Label. Select the event label that contains the event for which you searched.

Locate the event.

• The 1 link indicates the page number. You can select this link to review page details about the page in question.
• Beneath the listed event (Http 404 - Not Found), you can review all of the dimension values that were recorded when the event occurred.
• If it is present, the [Others] value is a dimension constant that is recorded when the detected value does not match any values on a listed whitelist.
• For the User Agent - Browser Version dimension, you can see that a value of IE8.0 was recorded.

Replay the session

To begin replay of the session on the page where the event occurred, click the Replay icon next to the event name.

From the dialog, select Browser to replay the session in your web browser through Browser Based Replay. When the session is loaded in BBR, it is displayed in Replay view. At the top of the screen, you can see an extra bar is added with additional information about the session.

The information is extracted from the user agent information that is submitted from the client. When a user agent match is found, these properties are displayed in BBR to help identifying the source of the session.

User agent property	Source request variable
Browser	TLT_BROWSER
Browser Platform	TLT_BROWSER_PLATFORM
Best Replayed Using	TLT_BROWSER_VERSION Note: This data source corresponds to the source for the User Agent - Browser Version event and dimension objects that you created in this tutorial.
Traffic Type	TLT_TRAFFIC_TYPE
Screen	TLT_SCREEN Note: Screen data is only visible if you have a Tealeaf CX Mobile license.
Replay Renderer	TLT_REPLAY_RENDERER

Mobile replay

For mobile-based sessions, user agent information can be used to determine the surrounding trim (or skin) to apply during replay. A skin is applied during BBR replay to emulate the sizing of how the visitor experienced your web application through a mobile device.

Note: This option is only enabled if you have an Tealeaf CX Mobile license.

Request data

To see user agent information in BBR, you must be in Request view. Select Request in the BBR toolbar.

In Request view, you can review the raw request data for the hit you selected. Tealeaf augments the raw request with additional data, including the user agent information that is retrieved if a user agent string submitted in the request is matched in one of the public standards.

User agent information in inserted in the [ExtendedUserAgent] section of the request. This information is inserted by the Tealeaf Reference session agent.

[ExtendedUserAgent]
TLT_BROWSER=IE
TLT_BROWSER_VERSION=IE8.0
TLT_BROWSER_PLATFORM=Windows
TLT_TRAFFIC_TYPE=BROWSER
TLT_BROWSER_JAVASCRIPT=true
TLT_BROWSER_COOKIES=true

Include user agent data in a report

You can include user agent data in a report as a dimension, as described in the following sections.

The most interesting use of user agent data in reporting is including it as a dimension. In our example, we created the User Agent - Browser Version dimension and associated it with the Http 404 - Not Found event.

Create a report in Report Builder

In the steps below, you create a report in the Report Builder on the Http 404 - Not Found event, which is filtered by the User Agent - Browser Version dimension. You can determine these HTTP Status Code 404 errors from this report, which indicate that a resource was not found by the dimension added to it. In this case, you can review the counts of these 404 errors by the browser versions of devices that access your web application.

1. In the Portal menu, select Analyze > Report Builder.
2. Click the New icon in the toolbar.
3. From the left panel, click the Events tab.
4. Click Add Event.
5. In the Event Selector, select the Standard Events label.
6. From the Standard Events, select the Http 404 - Not Found event. Click Select.

   The reporting data is incomplete in the chart. By default, the Report Builder displays data from the current date. If you created these data objects before today, you can review data from a previous date. Click the date that is displayed in the toolbar, and select the last business day before the current date.

7. Now, you can apply the dimension to it. In the left panel, click the Dimensions tab.

   The dimensions that are listed in the Dimensions tab are the only ones that are compatible with the currently displayed set of events.

8. Click and drag the User Agent - Browser Version dimension to the <Add X-Axis> box below the chart in the report display.

   The chart might be obscured by several instances of [Null] values. In a dimensional report, a null value is recorded if the specific item of data is not recorded when the event was recorded. In these cases, the user agent information is not available. If you created the dimension and began recording values to it at some point during the day, all recorded instances of the Http 404 - Not Found event recorded null values for the dimension.

9. To make the chart more meaningful, you might want to filter out the null values. You can use the following steps to filter out values in general from a displayed dimension.
   1. Next to the dimension that is added to the X-axis, select the Down caret to open the context menu for the dimension. From the context menu, select Filter.
   2. In the Dimension Filter dialog, click the Filter By Value check box at the top.
   3. From the drop-down, select Exclude Only Selected Values.
   4. Click Add Values. Select All Values.
   5. From the Dimension Value Selector, click the check box next to [Null].
10. Click Apply.

In the report, you can now visually identify that HTTP Status Code 404 errors are divided among various browser version values.

If this report is useful to you, click the Save icon in the toolbar to save the report.

• If you want to see the counts of the HTTP 404 - Not Found event for the dimension as it is configured, click the dimension entry in the X-axis and drag it to the <Add Segment> box at the top of the screen. In our example, this report now shows just the Http 404 - Not Found event counts for the selected date in which the User Agent - Browser Version dimension is not null.
• To segment the vertical counts of the event by the dimension values, click and drag the dimension as it is configured to the Y-axis box.

Review the report

You can determine how often the user agent event occurred by performing the steps listed here.

1. Click the New icon in the toolbar.
2. In the left panel, click the Events tab.
3. Click Add Event.
4. In the filter box, enter User Agent or other string to help locate your user agent event or events.
5. Select the event. In our example, the event was User Agent - Browser Version.
6. Click Select.

The report shows all instances when the event was fired, even instances when a null value was recorded for the dimension. Using this particular event for making assessments is not meaningful.