Data discrepancies for completed orders

Differences between web analytics data vs. back-end order systems data

[mph88888]

Have any of you been responsible for resolving data discrepancies between 1) completed orders tracked by a back-end ordering system and 2) web analytics data tracking these same orders? Examples would include an airline ticket purchased online or a loan application completed online. Assuming that these two data sources will rarely be the same, what are the contributing factors that may cause such discrepancies and what technical issues can be addressed to reduce this gap?

[cgrantski]

Back end numbers could be lower because of orders that were cancelled after being entered on the web, for example due to card declines, fraud or irregularities ... or which the customer cancelled.

Depending on the tracking system for the web site, it's possible that multiple views of the receipt page will generate multiple "orders" in the web stats.

[shorebreak]

Agreed, multiple views of the success page can cause overtracking of conversions. This is the problem with depending on pixel-based tracking.

[mph88888]

Thanks for the input.

We are actually seeing higher back-end system numbers than web stat numbers for applications. The primary data collection method we use is Javascript tagging (w/cookies to identify unique visitors). Image pixel tags are also used for non-Javascript visitors. Both sets of numbers follow the same day-to-day up and down movement throughout the month which is quite encouraging, however we'd just like to do everything we can to reduce the gap between them, or at least explain to management with confidence why it exists.

Anything else that we might be missing here?

[shorebreak]

I was just reading on another thread how Norton Internet Security 2004 blocks affiliate links and cookies on surfers' computers. I'm not technical and so couldn't tell you a mechanism whereby the Norton phenomenon would explain your data discrepancy, but it wouldn't surprise me if there was some sort of a connection.

[webmasterworld.com...]

[Receptional]

Agreed, multiple views of the success page can cause overtracking of conversions. This is the problem with depending on pixel-based tracking.

Isn't there a way to only have the javascript file run the first time a cookied user loads the conversion page? That would help the duplicates.

We see this on one of our sites, but never thought to fix it. The user is given a password on the page, so they seem to use the page as a memory chip for the password.

[cgrantski]

One reason I can think of for back-end numbers being higher than web ack page numbers would be the ack page not being viewed (the person clicks away from the site or page before the page either starts to load or finishes loading). This can be a problem especially if the JS tag is at the end of /body and the buyer's connection is slow.

For starters, in case it's the slow-load problem, compare your count of tag hits to the count of ack page view (or, better yet, ack page VISITS which will pretty much avoid the double-viewing issue). If the two methods agree, then the problem isn't likely to be related to clicking away before the tag loads. But it still could have to do with people not seeing the ack page, for some reason.