Event and event patterns

Event

An Event represents an occurred user activity that can trigger an action in runtime environment. Examples of an event can be visiting website, opening a checking account, calling customer service, etc.

Events are first created in Interactive Channels through Interact Design Time UI and then posted to Interact runtime environment by calling runtime API postEvent.

Event Patterns

An Event Pattern consists of series of events that occur in a particular way. Marketers can use event patterns to track and record pattern of customers' activities in real-time and act accordingly. A pattern starts with pattern state “condition-not-met”. By posting events to Interact at selected stages of customers' activities, the pattern state is checked and updated. When all defined events for the pattern occur in the defined way, the pattern state is changed to "condition-met", and configured actions are triggered. Event patterns can be used in customer segmentations and offer arbitration logics.

Interact supports the following 11 types of event patterns.

Match all: It is a pattern that fires (being set to “condition-met” state) when all composing events occur. For example, "Event A" and "Event B" and "Event C" must all occur, then pattern's condition is met. The sequence of event occurrence does not matter.

Counter: It is a pattern that fires if each composing event occur more than a predefined number of times. For example, "Event A" occurs >= 5 times and "Event B" occurs >= 5 times, then pattern's condition is met. The sequence of event occurrence does not matter.

For patterns types of Match all, Counter and Weighted Counter, there are no time constraints for them. As long as events posted fall into defined Start and End date, they are evaluated for the pattern. If Start date is not defined, the pattern starts be effective immediately once deployed. If End date is not defined. pattern is effective forever. Marketers can use Pattern Reset feature to reset pattern state for these three types of patterns. In contrast, Time Bound patterns and Rolling Time patterns are time bounded patterns.

Sequence: It is a pattern similar to "Match all" pattern, but the sequence of event occurrences matters. The pattern fires when all composing events occur restrictively in a defined sequence. For example, "Event A" must occur before "Event B" and "Event B" must occur before "Event C", then the pattern's condition is met. The dependency cannot have a cyclic nature. In other words, eventA->eventB->eventA is not allowed. The "Event A" is a dependent event of "Event B", while the "Event B" is the depending event of "Event A". A time frame between a minimum and maximum duration can be optionally defined for a depending event, namely, only a depending event occurred in this time frame after its dependent event occurred is counted in the pattern evaluation. This provides the marketers' a flexibility to limit that only events occurred in a specific time window are valid to the pattern's state evaluation. Both minimum and maximum duration are relevant duration from time when its dependent event occurrs. The both are optional. If none or either one is not specified, there is no time limit respectively. Only sequencing for qualifying events are supported, not for suspending (negative) events.

Rolling Time pattern: A rolling time pattern can be a "Match all", "Counter" or "Weighted counter" pattern, but all composing events must occur within a time window. At any time when a composing event is posted to Interact Runtime, Interact checks the occurrences of pattern’s all composing events in the time window starting from the current time point. If event occurrences do not meet pattern definition, the pattern state stays as “condition-not-met”. Otherwise, if all events are occurred within the time window, the pattern state is set to “condition-met” (may trigger actions if configured). After that, the pattern’s state is continuously re-evaluated in same way as above and is repeated on rolling base

Time Bound Pattern: A time bound pattern can be a "Match all", "Counter" or "Weighted counter" pattern, but all composing events must occur within a time window. At any time when a composing event posted to Interact Runtime, Interact checks the occurrences of pattern’s all composing events in the time window starting from current time point. If event occurrences do not meet pattern definition, the pattern state stays as “condition-not-met”. Otherwise, if all events occur within the time window, the pattern state is set to “condition-met” (may trigger actions if configured). Now Interact checks another setting called “Extend true state for additional period of time" and keeps the pattern as “condition-met” state for the additional period of time (no pattern evaluation in this period of time). When the additional time passes, pattern state is reset to “condition-not-met” and the evaluation starts another cycle. In other words, Time Bound Pattern allows pattern to pause for a certain time after condition-met. The setting “Extend true state for additional period of time" is only applicable to Time Bound pattern.

For example, P1 is a Time Bound pattern and P2 is a Rolling Time pattern. Both patterns consist of “Event A” and “Event B”, and they must occur within 7 days. In run time, “Event A” occurred on Monday and “Event B” occurred on Saturday. When “Event B” occurred, the pattern state is changed to “condition-met” for both P1 and P2 because two events occurred within 7 days. Now for P1, if the setting "Extend true state for additional period of time" is 4 days, then P1 stays in “condition-met” state till Wednesday, and then all the occurrences of two events are cleared and the pattern starts from the scratch on Wednesday. On the contrary, the state of P2 is evaluated continuously after Saturday. If “Event B” happens on Tuesday, P1’s state will become “condition-not-met” because “Event A” did not occur from the last Wednesday to this Tuesday.

Qualifying Event and Suspending Event: An event pattern is composed of series of events. The events that make the pattern’s state change to "condition-met" is called Qualifying Events. While the events that make the pattern pausing for evaluation is called Suspending Events. For example, a pattern has two events, “open_bank_account”, “ATM_activity” and “offer_credit_card”, all must occurs in 2 months. If a customer has already applied and got bank’s credit card at the time of 1 month from time opening account, marketers would not want bother the customer again by offering card. Therefore, marketers can define a suspending event “got_card” in the pattern which will pause the pattern for evaluation. The marketers can also use setting “Effective duration” to set if the pattern being suspended forever or just for a period of time.

Event Macro: Besides events that customers define, Interact also supports six event macros that can participate in pattern definition, as either Qualifying Events and Suspending Events. The following are the six macros.

• offerAccepted
• offerContacted
• offerRejected
• offerAcceptedInCategory
• offerContactedInCategory
• offerRejectedInCategory

offerAccepted, offerContacted or offerRejected for an offer can be served as an event in a pattern. offerAcceptedInCategory, offerContactedInCategory, or offerRejectedInCategory can have all offers that have similar attribute value as an event in a pattern.

Pattern in-activity: A pattern not only can be evaluated for “condition-met”, but also “condition-not-met”. Marketers can use this feature to track customers’ in-activities. For example, a pattern has two events, “add_item_to_cart” and “checkout”, all must occur in seven days. Marketers can add check point on 3rd day, if customer has not checked out the item yet, that is, pattern’s state is “condition-not-met”, then an action of “send_reminder_email” would be executed for the customer.

Event Category

Events or Event Patterns can be organized into categories for your convenience in the design environment. Event categories have no functional purpose in the runtime environment.

Actions

An Action can be triggered when an event occurs or when event pattern's conditions are met or not met. They are configured in Interact Design Time when you define events or event patterns.

• Trigger re-segmentation: The runtime environment runs all or a selective subset of 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. This is useful to place the visitor into new segments after significant new data is changed to the runtime session object, such as new data from requests of the Unica Interact API (such as changing the audience) or customer actions (such as adding new items to a wish list or shopping cart). It is worth noting that excessive re-segmentation within a single visit can affect the performance of the touchpoint in a customer-visible way.
• 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 specify the treatment code for the offer that Unica 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 where you can define the value of a session variable by using profile attributes, real-time attributes, together with Unica Interact macros, including functions, variables, and operators, including EXTERNALCALLOUT. You can assign the return value of the expression to any profile attribute
• Trigger events: You can use the Trigger Events action to trigger another one or multiple events upon source event occurs. This allow marketers have chained events.
• Suppress offers. Offer suppression can be triggered from events and event patterns. The suppression rules can be defined based on specific offers or a group of offers having the same attribute values. The difference of offer suppressing action and existing suppression rules are that the former can be triggered without relating to treatment rules.
• Qualify segments. User can specify which segment is enabled as result of an event or event pattern.

Besides invoking actions immediately when event occur or pattern condition is met, actions can also be invoked with a delay, either delayed after period of time or at scheduled date and time. This give marketers’ control on executing actions at preferred times. Action delay is not applicable to ‘Offer Suppression’ and ‘Qualifying Segments”

Even Patterns Attribute Aggregation

There are many such scenarios. The common point is some sort of aggregation on the top of an event parameter was required as a part of the pattern condition.

The format for using the paramters is _AGG_<aggregation type>::<attribute name> and you must use this by adding it during composing events of event patterns.