A transaction is defined as the transition of a joining key pk_1 from an initial state (primary event) tnx_initiated to a terminal state (secondary event) tnx_completed.
Transactions help you track the behaviour of your application in the context of the goals it is trying to achieve. Consider an example of a 3rd party payment provider API which is a part of your product journey. While it’s important to be able to track the error rate of outgoing API and webhook callbacks by the vendor, tracking relative behaviour helps identify anomalies faster.
Transactions vs events-based metrics:
The key benefit of using “transaction” instead of tracking start and completion separately using 2 different markers is that the correlation is easily tracked. If you do not have any common key between the two states, the only next best option is to add custom metrics at the individual checkpoints.
Unique Properties of a Transaction:
Compared to individual events, here are some properties, unique to a transaction:
Transaction time: The time to go from primary state to secondary state in a transaction.
Transaction status: Active or Finished, depending on whether it has reached the terminal state or not.
Transaction triggers: Rule-based alert configured on the transaction time, status or any other attribute associated with the transaction
What can you do with transactions?
Once you define a transaction, here are some out-of-the-box capabilities that we provide:
Alert rules on transactions success rate:
You can configure triggers on transaction success/failure rates, at both aggregate levels as well as individual transactions. Read more about triggers and their details here.
Track metrics related to the transaction and any of its associated attributes:
What are the currently active transactions?
Search transactions by any variable, irrespective of whether they are in the primary event or secondary event
To get started with setting up a transaction, click here.