Through the Events tab in the Event Manager, you can define, edit, test, and organize events to monitor specific conditions in your visitors' sessions. Tealeaf events provide a flexible and powerful mechanism for tracking at the most granular level what is happening during a visitor's session.
Save changes
When you create events, you might need to create multiple events, hit attributes, or other objects at one time. The Event Manager allows the creation of multiple objects and their testing against an actual session to verify the wanted behavior before saving the changes. By testing before you deploy, you ensure that your created objects operates properly on live data.
Saving changes to any object in the Event Manager is a three-step process:
- Save Draft: When you create or edit an object, you first save a draft of the object to the server memory, where it is stored temporarily. In the Event Manager, objects that were saved in draft form are highlighted in the display list in each tab. Tabs that contain saved drafts are highlighted in red.
- Save Changes: When you are ready to commit all changes that were saved in draft mode, you can click Save Changes, which saves all uncommitted changes in each tab to the database. These changes are immediately available for all Tealeaf servers in the Tealeaf environment. When saved drafts of objects are committed to the server, the draft indicators are removed.
- The saved changes are applied immediately to hits passing through the Short Term Canister, which may have unexpected implications.
Save drafts
You can save your work in progress, as needed. If you have unsaved changes, the Save Draft button is red.
- To save your changes in draft form, click Save Draft.
- Events can be tested if they are saved in draft form. You do not need to commit the changes to the server before testing your events.
Note: If you opened multiple browser tabs in the Event Manager, changes saved in one browser tab may take 10 seconds to be reflected in the other browser tabs.
Unsaved changes in the Event Manager are discarded if you log out of your Portal session or close your web browser.
Before you commit your changes to the server, you may be informed if changes you made in draft mode conflict with changes made by other users to the same object. You can undo changes.
Undo changes
Uncommitted changes are saved in the session cache on the server. They remain in the cache as long as the session is available. The changed object is highlighted in the tab UI, and the Save Changes button is highlighted in red to indicate that there are changes to save.
You may undo the change depending on the following circumstances:
- To undo changes to an item you edited but were not committed to the server, right-click the item and select Revert. The changes are discarded, and the local version in memory reverts to the same version on the server.
- To undo changes to a newly created item, right-click it and select Delete. The new item is discarded.
To undo all unsaved changes in all tabs, click Revert All in the lower-right corner. All local changes in all tabs are discarded.
Commit changes
After you saved the drafts of one or more objects in the Event Manager, you must commit the changes to the server before the changes to the objects are applied to the captured session data.
Note: Before you commit any changes to event definitions to the server, you should test them thoroughly using the Event Tester.
To commit changes, click Save Changes. The Confirm Changes dialog is displayed.
- The description next to each object is displayed when you select it and then click the object's History button in the toolbar.
- The Change Description at the bottom applies to the saving of all objects. It is displayed when you click the global Change History button.
You can add notes for each item that is being committed, as well as a description of the entire set of changes.
- To commit your changes to the server, click Commit.
- To cancel changes, click Cancel.
Note: To revert all changes to the last unsaved state, you must click Revert All. Otherwise, your unsaved changes remain queued for saving.
Note: If you have enabled automatic creation of Top Movers, a Top Mover is immediately created and enabled to track changes in values each new event or dimension after your changes are committed to the server. You may wish to disable one or more of these new Top Movers.
Each new Top Mover is created after the new event is committed to the server. No record of a changed or new Top Mover is displayed in the Top Movers tab.
Saved changes and timestamps
After you saved changes to any objects through the Event Manager, the changes are immediately applied to any subsequent hits passing through the Short Term Canister.
Note: When a hit is evaluated in the Short Term Canister, the STC has no awareness of when the active events were created or last saved. As a result, some hits may be evaluated by events whose creation timestamp occurs after the hit timestamp.
The Short Term Canister has no awareness of revision history and maintains one set of event and event-related definitions, which is applied to all hits at the time of evaluation.
- If the STC is spooling, when spooled hits are finally evaluated, the event definitions that are applied to them may be significantly different from they were at the time that the hit was created.
- There may be effects on reporting. Some reports bucket data into hourly segments. If you define and save a new event in the 10AM bucket when hits are being spooled, those hits may be evaluated against this new event and reported into earlier time buckets. This evaluation process may result in event counts and other event-related outcomes appearing in report buckets that occurred earlier than the hourly time bucket in which the event was created.
The key to remember is that the current set of events is applied to each hit at the time it is evaluated.
Deleting an event
Before you can delete an event, you must remove the dependencies between the event and other event-related objects.
To delete an event, right-click the event and select Delete. The event is deleted.
Important:
- Deleting an object removes it from the server. A deleted object cannot be restored. To remove the object from use, make it inactive.
- Deleting an event also deletes any data that is associated with the event from the reporting database. This deletion occurs on the next scheduled run of the Data Collector.
- Deleting an event does not remove the recorded instances of the event and associated dimension values from the session data that is retained in each Canister.
- When an event is deleted, any associated Top Mover is also deleted automatically.
- You cannot delete Tealeaf system objects.
Event dependencies by trigger
Events are evaluated in the order of event dependencies within each trigger. Events that are referenced by another event are evaluated before the dependent event is referenced.
In the following table, you can see event dependencies that are permitted by trigger. For each trigger listed in column 1, the table displays the triggers containing events that can be evaluated as a condition in the event trigger in the left column. Read the table in the following manner:
Events in event trigger <Column 1> can use as conditions the events that are available in trigger(s) <Column 2> through <Column 6>.
Depends on events in trigger ->
Event trigger: |
First Hit | Every Hit | After Every Hit | Last Hit | End of Session |
---|---|---|---|---|---|
First Hit | Y | ||||
Every Hit | Y | Y | Y | ||
After Every Hit | Y | Y | Y | ||
Last Hit | Y | Y | Y | Y | |
End of Session | Y | Y | Y | Y | Y |
Note: Events with incompatible dependencies or circular dependencies always write a null value as the value to record. Since the conditions cannot be evaluated, there is nothing to record.
Circular dependencies
Events whose output is used as an input for the event itself create circular dependencies. The Event Manager does not prevent the specification of circular dependencies through the UI, even though they cannot be resolved.
Below are examples in which event outputs are used as the conditions (inputs) for other events:
event A > event A
event A > event B > event A
event A > event B > event C > event A
All of the above references are flagged as errors in the following locations:
- Event tester when any of the events are tested
Note: If you pass newly created or edited events through the Event Tester, any circular references are flagged for review and correction. During event execution, an error is logged in the system event log, and the event is never evaluated.
- canister reports an error message in the system event log when event definitions are loaded
- error message logged in system event log during execution
Purging event data
If needed, you can purge data for a selected event and all related report groups and dimensions. Suppose when you are configuring events, you discover that you captured inaccurate or bad data for the event. You can purge the data for a selected event and all recorded dimensional data that is related to the event.
In the Details panel, you can review the related report groups and dimensions whose values are purged.
Important: Purging data is an irreversible step. Do not purge data unless you are sure that it is no longer needed. Purging event data removes event counts and occurrences of the event from the reporting database. It does not remove event occurrences and dimension data that were recorded in the sessions and are currently stored in the Canister.
You can also purge dimensional data.