Transaction records lie at the heart of Frakture's source code hub and almost certainly of your organization's operations as well: no matter how complex or straightforward your digital presence, no matter how many or few bots you deploy, it's the revenue that pays the bills.
A standard transactions stream creates a single table reflecting the transactions in your source system, capturing the amount, timestamp, and (crucially) source code of each gift for analysis. See a detailed description of the standard Frakture transaction table here.
From the raw transactions tables loaded from your donation platforms, we'll also create a cross-channel transaction_summary table indexing all transactions in your organization together with their source codes, metadata derived from those source codes, the message that gained each gift, and the past origin source code (aka “first touch”) that gained the supporter who eventually made this gift.
<aside> 💰 Note that some systems use the word "transaction" to denote a vast array of different supporter interactions, such as clicks, signups, or actions taken. In Frakture's parlance, "transactions" refers only to the monetary kind.
</aside>
Frakture is heavily oriented towards donation-type transactions. Software platforms vary in their handling of other financial events; generally, if something like a purchase fee or an event registration payment is recorded in the source system's transaction table, we'll retrieve the record with key details like the topline amount, timestamp, "donor" ID, etc. However, we will not necessarily capture particulars of the purchase terms such as item quantities, shipping fees, or ticket counts.