In Experience Analytics, you can create two types of objects to monitor events that are captured from a client framework and passed as messages to Experience Analytics.
- Step attributes are hit attributes that acquire its data from a step. Step attributes are specified in a slightly different manner but complete an identical function.
- Step-based events are standard Experience Analytics events that are configured to fire on one of the steps triggers. As conditions, they can use any standard type of Experience Analytics condition, and also step attributes.
Step trigger types
To support step-based eventing, the Event Manager provides two trigger types:
Every Step: Event is evaluated with other events in each step.
After Every Step: Event is evaluated after every step is evaluated.
Note: This trigger is rarely used.
In the previous example, any event triggered to fire on
Every Step is checked for each combination of JSON
message and environmental data. In the previous example, any
Every Step event is checked for the load, unload, exception, and other data message.
Note: Step attributes are permitted to reference objects from the parent hit. As a result, you can reference hit attributes in step events, but not vice versa.
In the event definition, the trigger can be selected from the Evaluate drop-down:
Available triggers are displayed in the order of evaluation. For a particular hit with underlying steps, each
Every Hit event is evaluated first, followed by each
Step event and
After Every Step event. Then, the
Hit events are evaluated.
Note: The events that fire on each trigger determine the availability of data. An event can use data from any event that fired before the current event. In a multi-hit session, the
Hit trigger fire on the previous hit before the events configured to fire on
Hit from the next hit. The same applies to step-based triggers.
The order of firing is more accurately displayed as a nested structure:
* First Hit of Session * Every Hit * Every Step * After Every Step * After Every Hit * Last Hit * End of Session
Considerations for using the
After Every Step trigger
In almost all cases, when you create step attributes, you are interested in the current context of the session. You create attributes to monitor the current data that is available as of the current step. As a result, the
After Every Step trigger is rarely used.
In the example below, the
After Every Step trigger is used. This scenario mirrors the
After Every Hit trigger usage, except that it applies to steps instead of hits.
After Every Step trigger is useful when you must compare the current state with the previous state. For example, suppose you want to know whether users clicked the same object twice in a row.
- To test this scenario, you must know both the object currently being click, and the previously clicked object. If the events that track both the current and previous states fire on the same trigger, they are updated at the same time and therefore always have the same value.
- However, if the previous state event fires just after the current state value by using the
After Every Steptrigger, the previous state event is not updated when the current state event fires. Therefore, you can compare the current state with the previous state by using an event that fires on the
Note: Form messages contain the
prevState properties within a step. The
currState property refers to the final value of the form field after editing, and
prevState refers to the default value before editing. These references do not work for testing if the same action occurred twice, since the default value can be reset to blank each time it is accessed.
To manage blocking or masking of sensitive data, Experience Analytics provides privacy mechanisms to manage specific data before it is transmitted to Experience Analytics.
Important: Application of privacy blocking or masking in the PCA or in the Windows™ pipeline requires complex regular expressions, which can cause significant performance degradation if improperly specified. Use the privacy solution that is provided with your client framework to manage sensitive data.
Indexing and step-based events
Step-based event data is not indexed by default. You can, however, search for events through BBR and RTV.
It is possible to move data from one location in the request into another section which is automatically indexed for search.
Note: If you must index some JSON-based session data for search, you must use a privacy rule to insert the data into the
[appdata] section. Creation of the rule requires configuration of a regular expression to locate the data. Regular expressions are considered an advanced configuration option, as if they are poorly specified, they can significantly impact system performance.