When processing hit data, the event engine searches each hit for patterns of text. These patterns can signify an event of interest, such as the occurrence of the word Sorry in the response, or can bracket a text string of interest, such as the value of a form field. These patterns can be explicitly specified or can be defined using the start and end tags for which an event should look when evaluating a condition or setting a value.

For example, suppose you want to configure an event to fire whenever a visitor goes to the Contact Us page. You can use one of the pre-defined Tealeaf patterns to identify the URL in the request that matches the page.

• In the URL example, Tealeaf provides the predefined hit attribute URL, which is built upon the URL hit attribute that is provided by Tealeaf.
• Tealeaf provides an extensive set of pre-defined hit attributes that can be used as conditions for an event or as text or numeric inputs into event values and dimensions. For a complete list of provided hit attributes, click the System Hit Attributes group in the left panel.

To monitor the behaviors of your web application, you should create hit attributes specific to your site. Through the Hit Attributes tab of the Event Manager, you can create and edit application-specific hit attributes.

Types of hit attributes

Note: Tealeaf maintains a hidden, fifth set of hit attributes, which is derived from other hit attributes, system attributes, and events. These types are defined by the system and cannot be created or edited by users.

Hit attributes may be configured to match:

• Data in the request or data in the response
• Data between start and end tags or exact data
• Values that are stored in JSON message nodes that are submitted by client-side frameworks.

The following matrix indicates the four kinds of hit attributes and how they interact with the example data listed below:

• Request data: REMOTE_ADDR=63.194.158.158
• Response data: You have no items in your cart

	Request Tags	Request Match	Response Tags	Response Match
Start Tag/End Tag	Start Tag: \r\nREMOTE_ADDR= End Tag: \r\n (denotes end of line)	63.194.158.158	Start Tag: \r\nYou have End Tag: items in your cart\r\n	no
Exact Match	Start Tag: 63.194.158.158 End Tag: (nothing)	63.194.158.158	Start Tag: You have no items in your cart End Tag: (nothing)	You have no items in your cart

Hit attribute evaluation

When a hit attribute defined with a start tag and an end tag is evaluated against a text buffer, the results are returned according to the following criteria:

REQTEXT

Start Tag	End Tag	Returns
found	found	correct value is returned
not found	found	returns: Not found
found	not found	returns: Not found
not found	not found	returns: Not found

How patterns are matched

When the event engine is evaluated, a pattern is compared against the request or response buffer to look for start tag/end tag patterns. Matches are found only for the innermost tags. For each found start tag, matching text is found only if the nearest end tag appears before another start tag.

Note: For exact matches that use start tags only, the following does not apply.

For example, you define a pattern definition with the following tags:

• Start Tag: foo=
• End Tag: bar

The text in the buffer looks like the following:

foo=1foo=2foo=3barfoo=4bar

In the above example, match values are the following:

• 3
• 4
• The number of matches is 2.

Other potential matches (foo=3 and barfoo=4bar) are not recorded because the end tag overlaps another start tag.

Note: Using well-defined start and end tags enables efficient extraction of data from the hit. Using common start and end tags such as < and /> impacts hit processing performance because of the numerous matches. To reduce the number of returned matches, additional processing of the data is likely to be required.

Hit attribute availability

Hit attributes and any values recorded for them are available in any trigger for individual hits:

• First Hit of Session
• Every Hit
  1. Every Step
  2. After Every Step

     Note: Step-based eventing captures events submitted from one of client-side capture solutions.

• After Every Hit
• Last Hit

Note: In the End of Session trigger, hit attributes and their values are not available for evaluation. Report groups containing dimensions populated by hit attributes can be used by end of session events, but the hit attribute value is not recorded for that dimension.

Create and edit hit attributes

You can create and edit hit attributes through the Hit Attribute tab.

Hit Attributes that are part of the System Hit Attributes and System Step Attributes groups are provided by Tealeaf. These hit attributes can be reviewed through the Event Manager, but you cannot change the hit attribute. You may create a copy of them as needed.

If you create hit attributes from the request buffer, the [HitType] section and [TLFID_*] sections (where * is the identifier for the fact) are generated by the event engine and cannot be detected in live sessions.

As a result, any events using these hit attributes do not fire in the Windows™ pipeline and are therefore not available for searching. They do fire, however, when they are evaluated in the Event Tester on sessions that already passed through the Canister.

Saving a draft saves the item to the session cache on the server. Changes must be committed before they are applied to the incoming session data.

Note: The maximum length for selected values of text for step attributes, hit attributes, and events is 256 characters.

Use regular expressions in hit attributes

In many situations, the start and end tags of a hit attribute cannot provide an exclusive and unique match to an item of interest on the page.

For example, suppose you have the following HTML on the page:

<error id="35">Coupon Code is invalid<\error>

In the above case, the value for the id may change with each message. As a result, a basic hit attribute cannot be constructed to retrieve this error message every time.

Optionally, you can apply a regular expression to the strings that are matched by the hit attribute. After the hit attribute beginning and end tags found one or more matches in the scanned text, the optional regular expression can be applied to the matching strings to further refine the results, returning one, or more values for the hit attribute after the regular expression was applied.

When configuring a hit attribute as an event condition, the Match Count and Hit Attribute Found operators are based on the number of values that are returned by the hit attribute after the regular expression was applied.

Suppose the hit attribute is defined with the following tags:

• Start tag: <error id="
• End tag: </error>

In a hit, the following error messages are detected by the hit attribute:

<error id="35">Coupon Code is invalid<\error>
<error id="15">Please enter a zip code<\error>
<error id="12">Please enter a state<\error>
<error id="13">The credit card is invalid<\error>

Suppose you wanted the hit attribute to track error messages on the page where a required text entry was not provided at all. If these messages begin with Please enter, the regular expression matches this string:

^Please enter

In the above example, the regular expression matches errors 12 and 15. If the event specifies to record the match count, the count is 2.

• The first returned value is Please enter a zip code, and the second/last value is Please enter a state.
• If a regular expression is not applied to the above set, the match count is four. The first value is 35">Coupon Code is invalid, and the last value is 13">The credit card is invalid.

  Note: When using the hit attribute as a condition in an event, the values that are returned after the regular expression was applied are available for the evaluation.

After you defined the regular expression, you can test the hit attribute in the Event Tester.

If the configured hit attribute was functioning properly, you could create a copy of it and modify the regular expression to detect invalid entry error messages. If these messages all end with invalid, the following regular expression matches the string:

invalid$

In the above example, the regular expression matches errors 13 and 35.

Note: Regular expressions are considered a developer-level method for matching strings. When improperly specified, they can consume significant resources. Apply them cautiously.

Note: You may also use regular expressions in conditions through Advanced Mode.

Limitations in the use of regular expressions in hit attributes

The hit attribute matchCount() returns the number of strings in the hit that passed the regular expression filtering.

• If the hit attribute matches multiple times in a single string, the first matching instance in the string is returned. The Match Count, however, is still the number of matches for the hit.
• Regular expressions may be up to 256 characters in length.

  Note: Avoid creating regular expressions that match multiple instances in a single string.

If a grouping operator, which is specified by enclosing parentheses, is present in the regular expression, the first group pattern is returned. Grouping operators beyond the first group are not returned.

• If no grouping operators are specified, the entire matching string is returned.
• If a grouping operator is required before the wanted group pattern, a non-capturing group operator can be specified with a ?: after the opening parenthesis, as in the following example, which matches on content after the first group operator:

  
  (?:not capturing this group)
  

Case-sensitive regular expression filtering is controlled by the Case Sensitive check box in the Hit Attribute definition.

Example start and end tags

Suppose you want to locate the URL variable that is listed in the request:

REQUEST_METHOD=GET
URL=/company/contact.asp
HTTPS=off

• Start Tag: \r\nURL=

  The \r\n markings indicate a new line and are used to differentiate this specific URL from other possible URLs that are embedded in the page somewhere.

• End Tag: \r\n

  The end tag \r\n indicates that the included text is everything after the start tag until the end of the line.

To create an event that looks for the contact.asp page, the event must use this hit attribute and set the value for the event to be /contact.asp. The event is then configured to look for /contact/asp between the tags \r\nURL= and \r\n in the request.

Hit attribute limits

When you create a hit attribute, here are some important limits to consider:

• Start tags and End tags may be up to 256 characters in length.
• There is no effective limit to the number of characters between the start tag and end tag.
• The maximum length of a value that is used as an event condition is 128 characters.

  Note: Other Tealeaf objects may impose limits on the captured data. For example, dimensions that are populated by hit attributes may contain values up to a maximum of 256 characters in length.

The above limitations have the following implications:

• If you create a hit attribute that uses only a Start Tag, the value of the Start Tag is the exact pattern that you are trying to match. Even though this pattern may be up to 256 characters, the event condition may only be 128 characters in length. So, a found pattern of length that is greater than 128 characters cannot be matched in an event condition.
• If your hit attribute contains start and end tags, the effective limit on the content to be matched between the tags is 128 characters for the same reason as above.