About cross-session response tracking

Visitors may not always complete a transaction in a single visit to your touchpoint. A customer may add an item to their shopping cart on your web site and not complete the sale until two days later. Keeping the runtime session active indefinitely is not feasible. You can enable cross-session response tracking to track an offer presentation in one session and match it with a response in another session.

Interact cross-session response tracking can match on treatment codes or offer codes by default. You can also configure it to match any custom code of your choice. Cross-session response matches on the available data. For example, your web site includes an offer with a promotional code generated at the time of display for a discount good for one week. A user may add items to their shopping cart, but not complete the purchase until three days later. When you use the postEvent call to log an accept event, you can include only the promotional code. Because the runtime cannot find a treatment or offer code to match in the current session, the runtime places the accept event with the available information in a cross-session response (XSessResponse) staging table. The CrossSessionResponse service periodically reads the XSessResponse table and attempts to match the records with the available contact history data. The CrossSessionResponse service matches the promotional code to the contact history and collects all the required data to log a proper response. The CrossSessionResponse service then writes the response to the response staging tables, and if learning is enabled, the learning tables. The contact and response history module then writes the response to the Campaign contact and response history tables.