Analytics Market Chart

Editing Transactions - Refunds, Returns, Cancellations

One of the most valuable things in Google Analytics is the ability to tie an actual transaction value to campaigns and other activities. Unfortunately, Google Analytics doesn't take into account refunds, returns or cancellations. If there are enough of these, you may find that your ecommerce reports don't line up with reality.

The good news is there is a clean way of editing transactions after they have been reported in Google Analytics. It requires some custom coding, but it will bring your reports closer to reality.

How to Edit Transactions

To edit a transaction after it's been reported to GA you need to execute the ecommerce code again. All three elements of the code need to be there (_addTrans, _addItem and _trackTrans), and you must reference the transaction ID that needs to be modified.

When you execute the code the second time, all the values will be added to the previous order values. For example, if the original order total was $10 and you create a second transaction worth $15 using the same transaction ID, GA will report the transaction total to be $25 ($10 + $15).

It doesn't matter if the second transaction is from a different visitor or traffic source. It will still edit the original transaction information, but with some caveats (explained below).

Add Items To an Order

To add items to a transaction, call _addTrans, using the same transaction ID and using the additional shipping, tax and total costs.

Then call _addItem as normal for each new item you are adding. If you are adding more of an item that was in the original order, pass all the same information and for quantity just list the additional number, not the new total. (eg. A visitor orders one hat in their first order. Later they ask for two more hats. You would call _addItem the second time with quantity two. In the reports, it will show three total hats for the transaction.)

Delete Items From an Order

To delete items from a transaction without canceling the entire transaction, call _addTrans, using the same transaction ID and giving negative numbers for shipping, tax and total costs. The reports will subtract these negative numbers from the original order totals to give the new order total. (eg. Original order total $10. Second order total -$3. GA will report the order total to be $7.)

Next, call _addItem for each item being deleted. Give the normal dollar amount (as a positive number), but make the quantity negative. Google Analytics will subtract this quantity (and the corresponding item cost) from the original order.

Delete Entire Transaction

To delete an entire transaction from the reports so that it won't be listed at all, call _addTrans, using the same transaction ID and giving the same numbers for shipping, tax and total, but as negative numbers.

Next, call _addItem for each product in the order. Again, list all the information the same, but make the quantity a negative number.

The transaction ID won't appear in the reports anymore.

Zero Out a Transaction

To zero out a transaction without deleting it entirely from the reports, follow the instructions for deleting an entire transaction with one exception: for each item, list a negative dollar amount and a positive quantity. Or, list a separate item, like "refund" with a negative dollar amount exactly equal to the order total.

Zeroed out transactions will still be reported, but with a total of $0. Drilling into these transactions will still show all the items, including the refund.


Transactions can be edited like this regardless of whether the second transaction is from the same visitor, day or traffic source. However, the second transaction will be counted as another transaction in all the transaction totals (unless the whole thing was deleted, as explained above). And it will be attributed to the second day and traffic source.

For example, imagine a visitor makes a transaction on Monday after coming to the site from a banner ad. On Wednesday you refund his order and create a second transaction in GA. Your visit will show up as a direct visit. The following will be true:

  • The original transaction value will be attributed to the banner ad.
  • The second transaction value (a negative number) will be attributed to direct traffic.
  • If the date range includes Monday but not Wednesday, the transaction will be reported as it was originally put through. No refund information will show.
  • If the date range includes Wednesday but not Monday, the original transaction will not be reported. Only the negative transaction will show.

These caveats might be good or bad, depending on your desired outcome. They are good because you can clearly differentiate between real orders and any editing you had to do afterward. You can still attribute a real dollar value to campaigns or other actions, which is probably more accurate reporting because the campaign or action during the visit probably did not cause the refund. This way you are tying the campaign to what it was designed to do, instead of blaming it for a customer asking for a refund because of a faulty product or some unrelated cause.

They are bad because you might see some funny reports for any given time period if edits aren't done in the same day. Revenue numbers might not always exactly match up. Also, the actual value of a transaction can't be tied back to the same user. They will always belong to two separate users.

Advanced Ecommerce

To extend these principles, some companies may find it useful (or even necessary) to automate this process with dynamic scripts that execute the JavaScript for refunds or cancellations behind the scenes. The script could make the refunds belong to a consistent traffic source, like "admin". The JavaScript involved would be simple, but the dynamic scripting could be complex.