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.


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.

In the eCommerce industry, the states can be order_placed, confirmed, shipped, delivered, order_cancelled, and returned. In such a case, you may want to send emails at different steps. For example, a user places an order, you would like to send them an email and a text message. If a user confirms an order, may be you'd like to send them an email. You can use Blueshift's transaction modeling to create journeys like that.

In the sales industry, if your site tracks various steps of a transaction, a sales executive's interaction with a prospect may contain many steps. For example, the first interaction of an executive with a prospect may be a lead. Followed by an in-person message to someone from the prospect's team, validating if the prospect can truly lead to revenue, then you send an offer, negotiate on terms, and close the deal.  In such a case, you can use transaction modeling to create a journey that optimizes to convert the prospect into a deal. 

How it works

Transactions are special types 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 (for example, booking_id) that identifies the transaction.

Similarly, to solve an eCommerce problem, you can work with your Blueshift Success Manager to come up with events that have statuses like order_placed, confirmed, shipped, delivered, order_cancelled, and returned. You can use a unique identifier (for example, order_id) that relates to all of the events and can capture the entire transaction. 

To solve the sales problem, you can use a transaction ID called prospect_ID and this ID can relate to your service's events such as: lead, first_contact, validating_prospect, offer, negotiation, and deal. 

We store a transaction event per transaction 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.).

For more information on how to use transactions, see:

Was this article helpful?
1 out of 1 found this helpful



Please sign in to leave a comment.