In web analytics, a transaction is a finalized commercial event with a unique order ID and verifiable money flow: totals, discounts, taxes, shipping, currency, and purchased items. Unlike a Session, which is a time-bounded visit, a transaction is a business event that can happen during a visit or via deferred flows (pay-by-link, invoice).
Why it matters: transactions feed your core commercial metrics. Two staples ride on them: Conversion Rate and Average Order Value (AOV). Revenue analysis also hinges on clean order data (Revenue).
Short formulas
- Conversion Rate = Transactions ÷ Sessions
- AOV = Revenue ÷ Transactions
Mini example
If you had 120 transactions and 3,000 sessions, conversion rate = 120 / 3,000 = 4%. With $18,000 revenue, AOV = $18,000 / 120 = $150.
Practical notes (data hygiene)
- Idempotency: deduplicate by
order_idto avoid double counts on retries/refresh. - Completeness:
revenue_totalshould equal line items + tax + shipping − discounts. - Status changes: post refunds/voids as separate events to compute net revenue cleanly.
- Attribution: document how transactions are attributed vs. sessions and campaigns.
Typical transaction payload (minimum viable)
| Field | Description |
|---|---|
order_id | Unique identifier (string/UUID) |
revenue_total | Final paid amount (post-discount) |
currency | ISO-4217 code (e.g., USD, EUR) |
tax, shipping, discount | Monetary components (≥ 0) |
items[] | Array of { sku, name, qty, price } |
Distinctions
- Transaction ≠ Event Count: many UI events can occur in checkout; they should roll up to one transaction.
- Macro vs. micro: “Add to cart” and similar are micro-steps; purchase is the macro outcome (Macro Conversion / Micro Conversion).
- Denominator nuance: Ecommerce Conversion Rate may use sessions or users—define it once and stick to it.