Working with events
An event is an action, which is taken by a visitor, that triggers an action in the runtime environment such as placing a visitor into a segment, presenting an offer, or logging data. Within the Interact design environment, you can create an event as one of the elements of configuration that interacts directly with the Interact API.
When you are coding your touchpoint to work with the Interact API, you use the postEvent method to reference events. The name of the event that is used in the Interact API must match the name of the event as configured in the design environment. This name is not case-sensitive.
For example, you might create any of the following events:
*
*
*
*
*
*
An event triggers one or more of the following pre-defined actions:
*
Trigger Re-segmentation. The runtime environment runs all the interactive flowcharts for the current audience level that is associated with the interactive channel again, by using the current data in the visitor's session.
When you design your interaction, remember that unless you specify a specific flowchart, a resegmentation action runs all interactive flowcharts that are associated with this interactive channel with the current audience level again, and that any request for offers waits until all flowcharts are finished. Excessive resegmentation within a single visit can affect the performance of the touchpoint in a customer-visible way.
Place the customer in new segments after significant new data is added to the runtime session object, such as new data from requests from the Interact API (such as changing the audience) or customer actions (such as adding new items to a wish list or shopping cart).
*
Log Offer Contact. The runtime environment flags the recommended offers for the database service to log the offers to contact history.
For web integrations, log the offer contact in the same call where you request offers to minimize the number of requests between the touchpoint and the runtime server.
If the touchpoint does not return the treatment codes for the offers that Interact presented to the visitor, the runtime environment logs the last list of recommended offers.
*
Log Offer Acceptance. The runtime environment flags the selected offer for the database service to log to response history.
*
Log Offer Rejection. The runtime environment flags the selected offer for the database service to log to response history.
*
Trigger User Expression. An expression action is an action that you can define by using Interact macros, including functions, variables, and operators, including EXTERNALCALLOUT. You can assign the return value of the expression to any profile attribute.
When you click the edit icon next to Trigger User Expression, the standard User Expression editing dialog is displayed, and you can use this dialog to specify the audience level, optional field name to which to assign the results, and the definition of the expression itself.
*
Trigger Events. You can use the Trigger Events action to enter an event name that you want to be triggered by this action. If you enter an event that is already defined, that event is triggered when this action is run. If the event name you enter does not exist, this action causes the creation of that event with the specified action.
If you create an event with more than one log offer action, remember that the Interact API completes the same action for the associated offer. For this reason, do not create an event which logs both offer acceptance and offer rejection since they contradict each other. However, creating a single event to log offer contact and acceptance or offer contact and rejection can be useful in your environment.
By default, the runtime environment can track two types of responses, offer acceptance and offer rejection. You can modify the response types that the Log Offer Acceptance and Log Offer Rejection events record by setting the accept and reject configuration properties.
The Interact API can also use events to trigger actions that you define by using event parameters in the API. These events include logging to a custom table, tracking multiple response types, and specifying a specific flowchart to run. You might have to create some events with no defined System Reaction, or several with the same System Reaction, such as Log Contact, for use with the reserved event parameters.
You might want to create several events with the Log Offer Acceptance action, one for every response type you want to log, or a single event with the Log Offer Acceptance action you use for every postEvent call you use to log separate response types.
For example, create an event with the Log Offer Acceptance action for each type of response. You define the following custom responses in the UA_UsrResponseType table [as Name (code)]: Explore (EXP), Consider (CON), and Commit (CMT). You then create three events and name them LogAccept_Explore, LogAccept_Consider, and LogAccept_Commit. All three events are the same (have the Log Offer Acceptance action), but the names are different so that the person who works with the Interact API can distinguish between them.
Or, you might create a single event with the Log Offer Acceptance action that you use for all custom response types. For example, name it LogCustomResponse.
When you are working with the Interact API, there is no functional difference between the events, but the naming conventions can make the code clearer. Also, if you give each custom response a separate name, the Channel Event Activity Summary report displays more accurate information.
For more information about reserved parameters and the postEvent method, see the Interact Administrator's Guide.
To monitor how often all of these events occur on your touchpoint, see About the Channel Event Activity Summary report.
Event reference
To add an event
Working with categories and events