Transaction metrics are the very core of commerce reporting. They should be outlined clearly before going into detail with specific roles and business cases. The Commerce Reporting Standard Partners achieved consensus on the following logic:
Not the right language for you?
Complementary Notes
Time References:
Pick the Right Metric for the Right Question
Every transaction-related metric needs a defined time reference as there is not only one, but multiple dates assigned with an order – first of all: the order date, the invoice date and the return date. Depending on the selected time reference, the set of orders that is accounted for the chosen time span changes. Click here to read the detailed explanations in our forum.
Time References:
Acquisition Date
The Acquisition Date as a time reference refers to the date of the customer’s first touch point – not his or her first order. This time reference is about evaluating marketing cohorts.
Promotion Cost:
Gain a Comprehensive View of Marketing Investments
To understand the full extent of marketing investments, it can be extremely useful to have a total view of promotion-related spendings available in reporting. Generally, one metric should be sufficient to do the basic job – calculated by summing up marketing cost, markdowns and discounts. According to the Commerce Reporting Standard, it’s called Promotion Cost and is shown separately at the bottom of the transaction metrics matrix as it’s an additional view complementing the coherent logic of the matrix.
Taxes:
Stakeholder-Specific Reporting
The tax column shown in the above matrix should give you an indication of which metric levels are broadly considered relevant for being reportable with taxes included – in addition to the standard business view excl. taxes. Generally, the tax information is of minor value for business stakeholders, but there can be cases in which this information can gain relevance – especially in cases that have an intersection with financial reporting.
Cancellations:
Differentiation of System-Wise and Customer-Wise
As there can be huge differences in handling the one and the other, the cancellations column should be split up into two levels for most business models: system-wise cancellations and customer-wise cancellations. Especially for companies that build entire processes on the differentiation of who or what caused a cancellation, this differentiation can be crucial for reporting purposes.
Cancellations & Returns:
Differentiation of Full and Partial Cancellations/Returns
For many business models, it can be advisable to split cancellation and/or return number metrics up into two metrics each: Full Returns/Cancellations and Partial Returns/Cancellations. In most cases, it shouldn’t be relevant to differentiate quantity metrics or value metrics into those two groups, though, as those have no implication of whether they’re originating from full or partial cancellations/returns anyway – and for most business models, this information wouldn’t be of much value.