Noise or Music?

How-to Match Google Analytics Transactions With Reality

Categories: GDPR & Privacy, Implementation Fundamentals, Metrics Understanding, Setup Accuracy / Comments: 1

Share Button

If you have a transactional site, then of course you will want your transactional and product data as measured by Google Analytics, to match the real sales numbers that your back-end system collects. However in reality, these never exactly match due to a number of issues. These include:

1) Processing time differences; 2) Returns; 3) Blocked tracking; 4) Cross-domain tracking issues – the most problematic.

I discuss these next, but first…

What is an acceptable level of difference..?

Whether comparing Google Analytics e-commerce data or other metrics against your back-end systems, I use a traffic light system to determine if a difference requires action:

digital-analytics-accuracy

The above guidelines are on a per metric basis. That is, they are not a summation of the discrepancies found.

So, from an e-commerce perspective, what can cause such differences between your Google Analytics reports and reality?

1. Differences Due To Processing Time

A classic example of this is when payment details received after working hours are processed by your back-end system the next day (or next working day if on a weekend). Some systems also batch process transactions i.e. process after NN transactions received. However, Google Analytics reports a transaction at the time of purchase. Unfortunately, there is not a lot that can be done to minimise this other than to allow for it when trying to reconcile numbers.

Tip: Ensure the timezone of your Google Analytics account matches the time zone of your back-end sales system so that the beginning and end of day times match i.e. the comparing of apples with apples metaphor.

2. Differences Due To Returns

All e-commerce organisations have to deal with product returns at some point, whether because of damaged or faulty goods, order mistakes, or other reasons such as a simple change of mind. Your back-end system will take account of these, but what about Google Analytics? It is possible to account for returns within your Google Analytics reports by processing a negative transaction.

However, I do NOT recommend processing returns in GA for two reasons:

  • Returns are not representative of your marketing or website effectiveness. For example, if I search online for “running shoes” and then make a purchase from your website, that is a perfectly good transaction—one that reflects the effectiveness of your website and its marketing. If subsequently I decide I don’t like the shoes and return them, this would be because of the product (perhaps a quality issue). The return is quite separate from the effectiveness of your marketing—just because I return my shoes does not mean the marketing investment for that product should change.
  • Aligning web visitor data with internal systems is always imperfect as returns usually take place well after the original purchase—therefore in a different reporting period. This results in confusion, more so than simply leaving the original transaction in place.

In other words, Google Analytics is a tool to measure the digital footprints of your customers so that you can understand and optimise their journey—have them more likely to purchase, or purchase more. Google Analytics is not designed to be a back-end account reconciliation system. They are very different tasks that should not be combined.

3. Differences Due To Blocked Tracking

Visitors always have the right to block or delete the Google Analytics tracking cookies. If so, either data will not be collected (visitor blocked your cookie), or your visitor count is over-inflated (visitor subsequently deleted your cookie).

Until the Edward Snowden affair, the deletion of cookies by users was considered relatively low and consistent. However, this may now change. You can minimise the problem by having a clear, easy-to-read, and accessible privacy policy on your website. This is not a trivial matter—most are overly long and full of legal jargon there to protect the business rather than the visitor. Getting this right is a key aspect of building trust in your brand.

Tip: Useful post:  A 10-Point Best Practice Privacy Guide for Working With Google Analytics.

4. **Differences Due To Cross-domain Tracking**

I highlight this section because it is the most problematic for users. In this scenario I am referring to the use of third-party payment gateways. For example, you host your product content and checkout system on your website, but use a payment provider to take the actual payment (the card details of your customers). This is a popular choice for e-commerce because it frees your organisation of the tight security and privacy obligations required when processing payments. Example third-party providers include: Authorize.net; Briantree; PayPal; Sage; Stripe; WorldPay and many others.

Some third-party payment providers allow you to modify their payment pages to include your Google Analytics tracking code. If so, you will need to ensure that cross-domain tracking is setup correctly. Doing so allows the Google Analytics tracking cookie of your visitor to be passed onto the third-party site. In this way, the complete visitor journey, across both websites, is correctly tracked – that is, combined as a single session with the correct campaign/referrer attribution.

Tip: If you can add tracking code to your payment gateway pages, use Google’s very nice Linker plugin to do this (analytics.js) – so much easier to setup than previously!

Most payment providers do not allow modification of their payment pages, for example PayPal and WorldPay. Therefore you cannot directly capture payment steps, or completed transactions. If you find yourself in this situation a workaround is required…

Workarounds When Your Gateway Does Not Allow Tracking:

A) Redirection—Least reliable though most often used

A redirection is the page your customer is returned to on your site when their transaction completes. Many payment gateways offer this feature. Provided this page is unavailable to visitors other than via the redirection, you 
can place your e-commerce tracking code on the redirected page.

However, a major issue of this method is that a high proportion of customers will either not click the redirected link (it is not a required action for them so why would they bother?), or will not wait for the auto-redirect to take place—Paypal et al want the customer to have time to read the transaction completion details before redirecting them away to your site (again, why would a visitor bother to wait?).

Because of the unreliability of redirection, expect to see 50% transactions lost.

Tip: If you are using redirection, don’t forget to add your third-party domain to the Referral Exclusion list of Google Analytics. Otherwise a new session will be started and attribution lost.

B) Track Your Purchaser’s Intent—Flawed but not too bad

This method tracks a transaction at the point when your visitor is just about to click away to your payment gateway. The obvious caveat is that you are not tracking completed transactions, but their intent to purchase. Perhaps the visitor’s credit card details are declined, or they change their mind at the last minute. Whatever the reason, your Google Analytics e-commerce reports will only be a rough guide to transaction activity.

That said, I have found tracking the purchaser’s intent to be more accurate than the Redirection method. A typical over-counting error is 20%.

Tip: Conduct as much form validation as possible prior to the last click of intent. That way, you give the intended purchaser the best possible chance of completing their payment and your data being accurate.

C) Server-Side Callback—Most reliable though most technical

Best methodThe standard method of Google Analytics tracking is via the use of JavaScript code snippets embedded on your web pages. However, it is also possible to create a data hit server-side. That is, with no pageview required. You achieve this using the Google Analytics Measurement Protocol.

This works by your third-party gateway communicating with a “listener page” on your website when a payment is confirmed. The listener detects and processes these messages on your merchant backend. Most merchant shopping systems have such a listener page built-in e.g. Woocommerce has this for Paypal via its Instant Payment Notification method. When your listener page is pinged (the callback), you programmatically query the order data and build the needed transaction hit using the measurement protocol. The transaction hit is a structured URL that is sent directly to Google Analytics.

This method does require some serious back-end work by your web development team. That is, prior to purchase they will need to save the visitor’s Google Analytics ID (clientId), their ip address and user-agent (browser signature). This information is recalled and used in the transaction hit when the callback is received. The reason for this requirement is to ensure the information sent from your gateway hit “connects” with the rest of the visitor’s journey on your site. Otherwise a new session will be started and attribution lost.

If available from your gateway (and your Dev Team), this method is 100% reliable.

Credit: Thanks to David Vallejo for reviewing the technicalities of item 4.

What e-commerce data reconciliation issues have you encountered? More importantly I would love to hear about your fixes and work arounds. Please comment below.

Share Button

Comments (most recent first)

  1. Rabah Rahil says:

    Fantastic Article Brian. Question: I have a Woocommerce store that recorded lets just make up some numbers and say 5418$ in sales for the month of Oct, with shipping taken out it goes down to 4752$.

    Now when I check GA, my ecommerce only reported 4428$. So according to the stop light strategy I am currently hovering in that green yellow area. Timezones are correct as well. Any troubleshooting strategies? Thanks!

    Cheers,

    R

Leave a Reply

Your email address will not be published. Required fields are marked *

Anti-spam question (required):

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© Brian Clifton 2018
Best practice privacy statement