Define the events that are triggered by visitor actions

An event is an action, which is taken by a visitor, that triggers an action in the runtime environment. The action might place a visitor into a segment, present an offer, or log 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.

Example events

For example, you might create any of the following events:
  • End Session. Mark the end of a visitor's interactive session.
  • Get Offer. Request a list of recommended offers to serve to a visitor.
  • Get Profile. Request visitor profile data that is stored in the session, including includes temporal data and data read in from the profile table.
  • Set Audience. Change a visitor's audience level within the interactive session.
  • Set Debug. Override the current logging level for a visitor's interactive session.
  • Start Session. Mark the start of a visitor's interactive session.

Event naming and 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. The name of the event must start with an alphabetic character. The following characters can be letters, decimal digits (half-width or full-width), or underscores. This name is not case-sensitive.

Monitor events

To monitor how often all of these events occur on your touchpoint, see Channel Event Activity Summary report.

Pre-defined actions

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, 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.

Events, logging, and the Interact API

If you create an event with more than one log offer action, the Interact API completes the same action for the associated offer. For this reason, do not create an event that 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.