Working with events

An event is one of the three elements of the Interact configuration in the design environment that interacts directly with the Interact API. When coding your touchpoint to work with the Interact API, you use the postEvent method to reference events. The name of the event used in the Interact API must match the name of the event as configured in the design environment. This name is not case-sensitive.

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 associated with the interactive channel again, using the current data in the visitor's session.

When designing your interaction, remember that unless you specify a specific flowchart, re-segmentation runs all interactive flowcharts associated with this interactive channel with the current audience level again, and that any request for offers waits until all flowcharts have finished. Excessive re-segmentation within a single visit may impact the performance of the touchpoint in a customer-visible way.

You should place the customer in new segments after significant new data has been added to the runtime session object. This new data can come 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, best practice is to log 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 which were 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.

If you create an event with more than one log offer action, remember that the Interact API performs the same action for the associated offer. Therefore, you should 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 may 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, using the accept and reject configuration properties.

The Interact API can also use events to trigger actions that you define 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 may need 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 may 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 exactly the same (have the Log Offer Acceptance action), but the names are different so that the person working with the Interact API can distinguish between them.

Or, you could create a single event with the Log Offer Acceptance action that you use for all custom response types. For example, name it LogCustomResponse.

When working with the Interact API, there is no functional difference between the events, but the naming conventions may 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.

System defined events

The Events tab contains the default category, System Defined Category. You cannot edit, add, or delete events in this category. This category contains events which correspond to the Interact API. You can monitor how often all of these events occur on your touchpoint with the Channel Event Activity Summary report.

These events include:

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 stored in the session; this includes temporal data as well as data read in from the profile table.

Set Audience — Change a visitor's audience level within his or her 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.