Transactions

Transaction Modeling is an advanced Blueshift capability that allows you to connect and segment lifecycle events/behaviors through a common identifier. You stream in multiple events with the same transaction identifier and Blueshift models the "state" of the transaction based on these events. You can use the transaction state to drive a consistent set of communications for a given transaction.

For instance, in the hospitality industry, a hotel booking could go through multiple "states" like booked, canceled, checked_in, checked_out etc. In this example, you might want to send a series of emails, SMS or mobile notifications related to the transaction state - an email before the customer checks in, and a thank-you notification after they check out. Blueshift's Transaction Modeling makes it easy for you to orchestrate these messages that are all related to the same transaction.

 

How it works

Transactions are special type of events which are inferred from existing events. Your Blueshift Success Manager will work with you to configure a list of events (Ex: purchase, cancelled, check_in, check_out) that may relate to a specific transaction type (Ex: booking), as well as to capture the unique identifier (Ex: booking_id ) that identifies the transaction.

We store a transaction event per order_id and any attributes from the new event will get appended to the transaction event. We also store the most recent state (transaction_state) of your transaction (Ex: purchase, cancelled etc.).

 

Using the Transaction State in Segments & Campaigns

You can use Transaction Modeling in the following ways:

  • Segmentation
  • Muti-step campaigns (Journeys)
    Journey filters can use the triggering-event attributes in transaction filters. For event-triggered campaigns, transaction filters support the use of event attributes as filter values. You can use dynamic filter conditions to filter based on other transaction specific attributes related to the current transaction id.

For instance, you may want to send a booking review reminder only if the user has not reviewed already.

21bd4d4-event_tr.png
 

Example:

This is how a sample transaction event looks like, apart from appending the existing attributes from the event we infer some additional attributes too.

For each event we receive, we infer the following attributes:

  • status - lets you know whether your received an event Ex: purchase_status
  • timestamp - this is the timestamp when when you received an event Ex: purchase_timestamp
  • transaction_state - the most recent event received: Ex: cancelled
 

1. Purchase Event

  • JSON
{
  "email": "test@test.com",
  "event": "purchase",
  "order_id": "order-testxyz",
  "timestamp": "2017-05-15T05:18:35Z"
}

Inferred Transaction Event

  • JSON
{
  "email": "test@test.com",
  "event": "bookings",
  "order_id": "order-testxyz",
  "purchase_status": true,
  "purchase_timestamp": "2017-05-12T04:18:35Z",
  "timestamp": "2017-05-12T04:18:35Z",
  "transaction_state": "purchase"
}
  • JSON
{
  "email": "test@test.com",
  "event": "cancelled",
  "order_id": "order-testxyz",
  "timestamp": "2017-05-17T07:18:35Z"
}

Inferred Transaction Event

  • JSON
{
  "email": "test@test.com",
  "event": "bookings",
  "order_id": "order-testxyz",
  "purchase_status": true,
  "cancelled_status": true,
  "purchase_timestamp": "2017-05-12T04:18:35Z",
  "cancelled_timestamp": "2017-05-17T07:18:35Z",  
  "timestamp": "2017-05-17T07:18:35Z",
  "transaction_state": "cancelled"
}
Was this article helpful?
0 out of 0 found this helpful