Orders Counted Twice When the Receipt Page Reloads

Sales the bank never saw

At the end of the month, the owner of an online shop compares the revenue in Google Analytics with the deposits from the payment processor. Analytics shows the larger figure, by a wide margin.

The shop's own order list agrees with the bank, give or take refunds. The gap is in Analytics, where some order numbers appear twice and a few three times.

Nobody bought anything twice. The page confirming each order told Analytics about the sale every time it loaded, and it loaded more often than anyone expected.

How a sale reaches Analytics

On a shop with ecommerce tracking, the receipt page carries a few lines of code listing the order number, the total, the tax, the shipping and each item.

When the page loads, that code sends the details to Analytics, which records a transaction. It does not check whether the order number has arrived before.

So the count of sales in Analytics is really a count of receipt page loads. Usually the two match; the exceptions are what the owner is looking at.

Ways one order is counted again

A receipt page can be loaded many times for one order, by shoppers and by staff:

• A refresh, by a shopper waiting for the order number or delivery estimate.
• A bookmark or browser history, when the shopper returns days later.
• Links in the confirmation email that open the same receipt page.
• The payment page sending the shopper back twice, after a second click on its return button.
• Test orders placed by staff after each change to the shop.
• Orders later cancelled or refunded, which stay in Analytics as sales.

The last is not a duplicate, but it widens the same gap. The first three grow with every shopper who likes to check on an order.

Finding the duplicates

In Analytics, the transactions report under Ecommerce lists each order number with its revenue. An order counted twice shows twice the revenue and quantity of the real order.

A custom report is quicker: the transaction ID as the dimension and transactions as the metric. Sort by transactions, and every order above one has been counted again.

Test orders are usually easy to spot by staff names, the shop's own address, odd amounts or products called test. Note their numbers so they can be left out of comparisons.

A worked example

A vintage audio shop restores and sells turntables, receivers, amplifiers and speakers, in its shop and through its website. Most online orders are a single large item.

The owner noticed when a month's Analytics revenue sat well above the deposits. The custom report showed several receivers and turntables recorded two or three times under one order number.

Two causes stood out. The confirmation email linked to the receipt page, so each customer checking on a delivery added the sale again, and the owner tested the checkout with real orders, later cancelled.

The developer changed the shop so the tracking code is printed only the first time a receipt is shown, with a mark saved on the order. Orders from the staff test account never carry it.

The email now links to an order status page without tracking code, and a note in Analytics marks the date of the change, since earlier duplicates stay in the reports.

Each receipt now reports its sale once, when the order is placed, so the revenue credited to each source of visitors describes real orders.

Why a filter is the wrong tool

Filters in an Analytics view work on each hit as it arrives. They include or exclude hits by address, page or other details, but cannot compare a hit with earlier ones.

So no filter can tell a shopper's first view of the receipt from a refresh a minute later. Both arrive looking identical.

A filter on the office's internet address catches tests placed there, but not those placed from a phone or from home. And filters never correct what is already recorded.

The fix belongs in the shop

The shop knows what Analytics cannot: whether this order has been reported before, and whether it is a test. So the decision to send a sale belongs in the shop's code.

The usual approach is a mark saved with each order when the tracking code is first printed. Every later view of that receipt shows the order but leaves the code out.

Test orders need a way to identify themselves, such as a staff account or a test payment setting, and the shop skips the tracking code when it sees one.

Cancelled orders and refunds

An order cancelled the next day stays in Analytics as a sale. The usual remedy is to send a matching transaction with negative amounts, which the developer can attach to the shop's cancel button.

For a shop with few cancellations, a monthly list kept beside the reports may do. Either way, the shop's order list remains the record.

Switching to the new tracking code

Many shops still run the classic Analytics code. Universal Analytics, out of beta since April 2, writes its ecommerce lines differently, so moving to it means rewriting this part of the receipt page anyway.

If the switch is planned, make the fix part of the same job, and test both a first view and a refresh before the new code goes live.

The counter-case

Analytics will never match the bank to the dollar. Refunds, fees, deposits that arrive days later and browsers that block tracking code all open small gaps in both directions.

For the books, the shop's order list is the record, and Analytics is a guide to where sales come from. A small, steady difference is normal.

Duplicates are different. They inflate exactly the figures used to judge ads and campaigns, crediting whichever source the repeat visit came from, so a large or growing gap deserves fixing.

Counting each order once

1. Compare a month of Analytics revenue with the shop's order list.
2. Build a custom report of transactions by order number.
3. List the duplicates and the test orders.
4. Print the tracking code only on a receipt's first view.
5. Skip the code for staff test orders.
6. Point email links to an order status page.
7. Note the date of the fix in Analytics.

Step four is the fix itself. The rest finds the problem or keeps the record straight, but only a receipt that reports each order once stops new duplicates.

The switch itself, and the checks to make before and after it, are laid out in Universal Analytics is out of beta, from earlier this month.

Frequently asked questions

West Coast Media Solutions Inc. provides web design, web development, hosting, digital marketing, and business consulting to organisations across Canada, drawing on more than twenty-five years in the field.