If your online shop analytics stops with the order, it is stopping short. Some product groups like Fashion tend to have high return rates, so looking at refunds can give you a different view of your shop and marketing performance.

What are Refunds?

Refunds are orders that were fully or partially refunded – either the customer returned one or all products of an order (Returns) or the order was cancelled (Cancellations) due to fraud, inability to deliver the product, change of mind by the customer, “no” by the bank, or other reasons.

How to Implement Refund Tracking

First, you need an export from your shop system with all Order IDs (also called Transaction IDs), the same product IDs that you use in your Analytics tools, the purchase price per product, the refunded revenue and, if you want to be able to distinguish Cancellations and Returns, the “Refund Reason”.Here an example of what such an export may look like:

Before importing these into Analytics tool, make sure that you only import the Order IDs that the Analytics tools were able to track because ad blockers usually block some Analytics requests.

1. Track Purchases on your site with the standard E-Commerce variables (s.products, s.purchaseID, the “purchase” event) PLUS s.transactionID (contains the Order ID that identifies the Order ID in your refund imports, usually the same as s.purchaseID).

2. Tell Customer Care to activate “Transaction ID Recording”. It takes a day or two to do that. It allows you to tie any online action tracked with s.transactionID to any other off-site action (e.g. a refund, a brick-and-mortar store purchase after an online lead, approved bank account openings after online lead forms etc.). We will see later what this means in detail.

After activation, you should see this text in your Data Sources start screen (go to Admin -> Data Sources“):

3. Create a “Generic Data Source (Transaction ID)” (see guide on Data Sources, specifics on Transaction ID Data Sources here). You can theoretically import any metrics and dimensions you would like to. The only mandatory field is the TransactionID itself. As flexible as this is, it requires you to think first what exactly you need and in which format it should be.In our case, the templates we created to import looked more or less like the following:

The first three rows you can download after going through the Data Source Creation Wizard, the rows after that with the data you have to fill in yourself.

Date: When the transaction happened (in format MM/DD/YYYY)

Refund Reason: cancel or returnProd SKU: unique product identifier

Refunded Revenue: Total sum refunded for this product (not sum per product!)

Refunded Orders: counts whenever an order had at least one product returned or cancelled so we can have a “Refunded Orders” metric in Analytics. No product data (product quantity or revenue) data is reported for this metric because that would count them twice (you see that the rows where the Refunded Orders is counted have only the Date, the Transaction ID and the Refunded Orders columns filled). It is not necessary to have this metric. We just wanted something that allows us to get a metric that quickly tells us how many percent of orders are affected by refunds. One reason for this is that looking at product quantities alone can be harder to interpret because it has to do a lot with the way products tend to be bought: For example, people rarely buy one beer, they tend to buy a box with 20 or 24 bottles, thus the quantity is 24. But people rarely by 24 iPhones at once. So “Refunded Orders” “normalizes” this effect a bit, but therefore you cannot break it down by product-based dimensions like product name, category or brand.

Analyzing Refunds

In Adobe Analytics, refunds are counted as if they had happened at the same time as the order. Maybe that sounds counterintuitive, but it is a huge advantage in terms of reporting.

Firstly, you can analyze orders and refunds in the same time range even if the refunds happened later. You can correlate any data from the order session (e.g. Visitor data, Campaign data) with refund data, e.g. to analyze the refund rates per Marketing Channel.

Second, refunds are all attributed to the Traffic Source “(direct) / (none)”, even though (as you can see in the following screenshot) Transaction ID 0004-3244 was actually referred by “google / cpc” (AdWords). So if both refund and transaction time fall into the analyzed time range, you get two rows per Transaction ID – one for the refund and one for the order. Also, Refunds will not appear in any Traffic-Source-based reports, they also won’t appear in segmented reports etc.

In Adobe Analytics, we can use the refund metrics just like any other and break them down by any dimension or segment. For example, here we look at Refund Rates by Campaign Source and we see, that, for a given day and a given Campaign Source, the refund rate for “Return Customers” (Customers with at least 2 Orders) was higher than for “New Customers”. Maybe it is the free refunds that are offered that makes people buy (and return) again.

When analyzing marketing campaigns, you may be stopping short if you don’t take refunds into account. Create a “ROAS incl. Refunds” (ROAS = (Return on Ad Spend)) metric that is based not only on the Revenue, but on the Revenue after Refunds, so it shows what effectively remained in your pockets after all was said and done. See the last two columns in the following screenshot:

In Adobe Analytics it is easy to differentiate Returns from Cancellations. Because we import the “Refund Reason” as a dimension, we can create Calculated Metrics based on the value of this dimension. Example: How to build the “Return Rate” :

1. Create a Hit-based Segment for “Return Hits” with just one condition: Refund Reason equals “return”

Don’t worry that the Data Preview on the top right says 0, that is actually correct as the Refunds did not happen in any online Visit nor did they generate a Page View.

2. Then create the Calculated Metric (in our example, the “Return Rate” in terms of Revenue). Here you take the segment you have just created, put the Refunded Revenue Success Event (Custom Metric) from your Data import inside of that segment and divide the output by the Revenue:

This allows something that is very useful for a marketplace: Instead of just looking at Refund Rates, we can look at individual merchants’ Return and Cancellation Rates. That way, we can identify merchants who often cancel orders (some may just say yes at first to get as many orders as possible and later cancel), and reach out to those who encounter a high return rate (because we might be attracting them to the wrong customers):