The Author: Anne Golombek
Anne Golombek is COO and Marketing Lead at minubo, the Commerce Intelligence Company. As an expert in data-driven commerce, she is one of the initiators of the Commerce Reporting Standard project.
In our latest blog post, we introduced the Transaction Metrics Matrix: A systematization that shows the calculative relationships between the single transaction metric levels (values and quantities) and modifiers (e.g. returns, discounts or different kinds of costs). Today, we want to draw on that by going into greater detail with how these metrics are actually calculated – for, as you probably know, there is an important variable to consider: time reference.
Before we start looking at which time references are right for which metric, let’s start with some basic definitions to achieve a common understanding of what we talk about.
The Concept of Time References: Every transaction-related metric needs a defined time reference as there is not only one, but multiple dates assigned with an order: the order date, the invoice date and the return date (plus e.g. the shipping date or the delivery date which, though, are not relevant for the calculation of transaction metrics). Depending on the selected time reference, the set of orders that is accounted for the chosen time span changes:
- OD – Calculation by Order Date: If a metric uses the order date as time reference, all orders are considered for calculation that have been placed within the chosen time span.
- ID – Calculation by Invoice Date: If a metric uses the invoice date as time reference, all orders are considered for calculation that have been invoiced within the chosen time span.
- RD – Calculation by Return Date: If a metric uses the return date as time reference, all orders are considered for calculation that have been returned within the chosen time span.
- ID RD – Calculation by Invoice Date and Return Date: If a metric uses both the invoice date and the return date as time reference, all orders are considered for calculation that have been invoiced (and/) or returned within the chosen time span.
The Underlying Logic
Ultimately, it’s quite self-explanatory how the assignment of metrics with possible time references works: As we talk about changes in quantity here, not in value (which orders have been placed/which have been invoiced/which have been returned), assignment of metrics with time references happens in dependence of the metric’s quantity level:
- If you talk about metrics on order level, you are not interested in invoices or returns so far – the only reasonable time reference is the order date (OD).
- The same goes for metrics on open order or cancellation level – wouldn’t make sense to look for an invoice or return date here, so you only need the order date reference (OD).
- If you talk about metrics on sales level, you face a different situation: Either you want to account for all sales-level transactions that have been placed during the respective time span (other than with metrics on order level, you already deduct open orders and cancellations here) or you want to know which sales-level transactions have actually been invoiced during the respective time span. Depending on what you want to see, you either choose the order date reference (OD) or the invoice date reference (ID).
- If you want to look at metrics on return level, the situation changes again: Of course it makes sense to simply look at returns that came in during a given time span, so to just choose the return date as time reference (RD), but it’s also absolutely common (and important!) to ask for returns resulting from orders that have been placed in a certain time span – then you choose the order date as time reference for your return metrics (OD).
- Finally, if you want to look at metrics on net sales level (sales in consideration of returns), you face different premises again: Like with metrics on sales level or return level, you can use the order date reference (OD) for net sales metrics, if you want to learn about net sales that resulted from orders that have been placed in the given time span – but here, it’s also key to look at the combination of invoice date reference and return date reference (ID RD), as, of course, it’s important to know which transactions have either been invoiced or returned during a given time span (in some cases even both) to result in certain net sales.
To give you a better overview of this, we integrated the time references into our transaction metrics matrix:
Not the right language for you?
…and that’s how 56 metrics become 95 all of a sudden! If you use them in your reporting and analytics, you can just differentiate them by adding the token in the end – e.g. Merchandise Value in Sales (OD) vs. Merchandise Value in Sales (ID) or Net Profit on GMV (OD) vs. Net Profit on GMV (ID RD).
Tell us What you Think!
It’s time to discuss – tell us what you think about how we suggest to handle time references for transaction metrics! Do you do something in a different way? Are you missing something? We are looking forward to your replies in the comment area.