Tealeaf uses three types of attributes as part of its data collection: hit attributes, session attributes, and step attributes.

• A hit attribute is a request from a visitor's device to the application and the response from the application.
• A session attribute is a system or user-defined variable for storing data that pertains to a session. These variables can be updated at any time during the session. When the session is complete, the session variable data is stored as part of the session record.
• A step attribute is a single user action that is captured by one of the client frameworks and submitted for capture in JSON format.

Event definitions

• Active: Determines whether the event is active. Default is ON.
• Event name: Name of the event you are creating.
• Tags: Keywords to help you find this event in searches.
• Description: Description of the event.
• Trigger: Events can be triggered to start on sessions, hits, or steps. You can set the frequency by which hit events, step events, and session events are evaluated, as follows:
  • Hits
    • First hit: The event is evaluated when a new visitor's session begins.
    • Every hit: The event is evaluated before any part of a new hit is evaluated. Default option.
    • After every hit: The event is evaluated after all parts of a hit are evaluated.
  • Steps: To support step-based eventing, you can specify the trigger frequency for steps:
    • Every step: The event is evaluated with other events in each step. Default option.
    • After every step: The event is evaluated after every step is evaluated.
  • Sessions
    • At session end: The event is evaluated when a visitor's session ends, either as defined by event or by a system timeout.
• Frequency: How often you want the event to trigger.
• Published at: When you want to publish the events, either immediately or at the end of the session.
  • Immediate: Publish the event immediately with the dimension values as they are when the event fires. Data is extracted from the session data when an event is triggered. When an event fires, the values of the associated dimensions are published with the event value.
  • Session end: Publish the event at the end of the session. At the end of the session, the last known value for each dimension is back-populated to the event occurrences earlier in the session.

    The event values that were detected at the time the event was fired are recorded, but the publishing does not occur until the session is completed by the user, or session timeout. This method for event publishing enables the support of the capturing of the dimension values associated with the event from their last occurrence in the session.

    For example, suppose that you use a dimension to capture whether a purchase was made. Because that information is not known until the end of the session, you can delay the publishing of events and their related dimensions until the end of the session. This way, the definitive answer (Yes or No) is captured in the dimension value.

• Mode: Create the event by using basic and advanced modes.
  • Basic mode: Use existing data elements (hit attribute, step attribute, events, sessions attributes, dimensions) in the interface to create events).
  • Advanced mode: Manipulate system names and JavaScript in the event engine. Build out an event and see the JavaScript equivalent by selecting advanced mode. For example, create an advanced event to build a report that concatenates a string of values.
• Conditions: Conditions that determine when an event fires.
• Reference value: Variable that is associated with the event when it fires. Create a custom value or chose an event object. You can choose to treat it as text or numeric.
• Store metrics: Method for storing the metrics from your event. You can track the first occurrence, last occurrence, or all occurrences. If you chose to treat your reference value as numeric, you have the option of adding value metrics.
• Dimension groups: Dimension groups that are associated with this event. Geo analytics can be enabled for each dimension group in the event. Default is disabled.
• Dependencies: If there are dependencies between the event and other events or event objects, as well as alert or report dependencies, they are listed in the Dependencies section of an event definition.

  Dependencies, which are generated by the system, vary depending on the defined event.

  In addition to the dependency itself, the owner of the dependency is listed. Before you remove an event definition, you might want to notify whoever owns the dependent objects so that they can delete the dependencies.