Unica Interact Cross Section Contact Response

HCL Unica Interact, by default, tracks the contact and response events for treatment within a session. However, visitors may not always complete a transaction in a single visit to your touchpoint. In such cases, HCL Unica Interact can track Contact and Response events across sessions.  This is achieved by enabling the ‘Cross Session’ feature for Unica Interact.

What is it:

There are two scenarios where Cross session tracking may be needed.

1. Cross Session Contact Tracking:

A contact event is posted to Interact after an offer is presented to an end user. However, there are multiple scenarios when the Contact event may not be posted in the same session. You can enable ‘cross-session Contact tracking’ to track such treatments.

2. Cross Session Response Tracking:

You can enable cross-session response tracking to track an offer presentation in one session and match it with a response in another session.

How it is done:

3. Cross Session Contact Tracking:

By default, without cross session enabled, it is assumed that the end user acts as soon as the offer is presented. Thus, the contact event is posted within the same Interact session as the getOffers API request that returns the original offer. However, there may be scenarios when the contact event is not posted immediately in the same Interact session. In such scenarios,

When a new Interact session starts and a Contact event is directly posted without treatment, then such contact is tracked using the Cross session Contact process. For achieving this, the Interact engine stores necessary treatment data in a table as soon as a treatment is generated from a getOffers call.

Once the Interact engine can find a match in this existing data for a contact event newly posted, then it logs a contact event in the staging table. After this step, the regular Contact–Response History tracking process comes into the picture.

4. Cross Session Response Tracking:

As described in an earlier section, by default, a response is posted in the same session where a contact happened. However, consider a scenario in which the customer has put an item in the shopping cart on your website but didn’t complete the purchase. This offer has a promotional code generated at the time of display, valid for one week.

When the customer returns to your website and tries to purchase the item from the cart, you can simply post an accept event to the Interact engine by sending the promotional code in the request. In this case, the Interact engine cannot find a treatment or offer code to match the current session. It places the accept event with the available information in a cross-session response staging table. 

Note that if ‘Cross Session Contact’ is also enabled on your system, then the information from the ‘Cross Session Contact’ table is also used for handling the response. However, if in case, the original offer details do not exist in the table, then the response is written to the cross-session staging table.

There is a separate Interact service called ‘CrossSessionResponse,’ which is used in this scenario. This service is enabled and starts with Interact initialization. It periodically reads the CrossSessionResponse staging table and attempts to match the records with the available contact history data from Campaign history tables. It collects all the required data to log a proper response.

Thus, if you enable the cross-session response feature, then the runtime environment needs read-only access to the Unica Campaign contact history tables. The CrossSessionResponse service then writes the response to the response staging tables and, if learning is enabled, then to the learning tables. The successfully matched records are purged from the cross-session table, while others are marked to retry.

After this step, the regular Contact–Response History tracking process comes into the picture.

Offer suppression in case of CrossSessionResponse:

When the cross-session response is enabled, then the Offer suppression is handled in a special way. When the ‘CrossSessionResponse ‘process tries to match a record with existing treatment codes, but it can’t find the same, then it doesn’t know for which Offer the response is posted and hence cannot update that the offer should be suppressed.

Thus you need to make sure that the Contact-Response History ETL process has been run and the Contact history data is available in Campaign tables to match by the ‘CrossSessionResponse’ service to make sure that the offer gets suppressed.

Important Notes

• Both the cross-session contact and response processes need to be enabled explicitly if you want to track such events.
• There are various configuration parameters that supplement this functionality to suit your specific requirements.
• The cross-session tracking can match treatment codes or offer codes by default. You can also configure it to match any custom code of your choice.

You can refer to the product documentation here to learn more about cross-session contact and response processes in Unica Interact.