Google AdWords Conversion Tracking - The Good, The Bad and The Rest

If you use Google AdWords, and you have online activity that you want visitors to do, then AdWords Conversion Tracking is probably what you want. Before you leap in to gleefully use it, you need to know what works and what doesn’t… Here’s an outline that should help you to work out what is happening and why.

When a search engine user clicks on your advert, then Google drops a cookie on that users’ web browser. If that user, with that browser, buys later and reaches a page with the Google Conversion Tracking Code, the cookie is checked. If the cookie exists and is in the right date range, Google will count the originating click as a success.

If the user reached your site from a web browser at the office, goes home and buys using the web browser at home, then that transaction isn’t identified. If the user deletes cookies regularly, then transactions can’t be identified. If the user has disabled JavaScript on the browser, then transactions can’t be identified.

Quantifying those problems? In reverse order, web analytics companies often offer a count of users that have disabled JavaScript. It’s usually less than 10% - so your actual web sales may be up to 10% more than Google reports, for this one cause. Users do delete cookies - many users deny third party cookies completely. If you are using Google’s Search system, then the cookies are served from the same domain, a first party cookie. About 5% of real users deny first party cookies. However, up to 900% (yes, almost ten times the volume) of the Google Search impression volume comes from Google’s Search Network partners - and for those, the Google cookie is a third party cookie. Third party cookie rejection has been reported at up to 30%, but is usually estimated at around the 10% range. So there’s probably another 8 to 10% or so of transactions originating from Google’s partners, that aren’t identified. Browsing at the office and buying at home (or vice versa) - we’ve not seen any credible figures for this and we suspect it depends on the product type, but we’d be surprised if it exceeded 10%.

Using Conversion Tracking

Let’s make sure that the process is really clear.

1. Sign up for AdWords
2. Sign up for Google AdWords Conversion Tracking
3. Add Google AdWords Conversion Tracking Code to the Order Confirmation Page

This means that you must have access to add JavaScript to the Order Confirmation Page. This will be a problem for affiliates, because they don’t control the order confirmation page (usually - I can imagine e-Commerce platforms that do so, but I don’t know of any). It can even be a problem for people using an e-commerce shop, as many of these don’t allow adding JavaScript to the Order Confirmation Page.

The Tracking Code is unique for each AdWords Account. Strictly the code is common, but has a unique account ID embedded. That’s why it doesn’t work for affiliates - the vendor would need to add a piece of JavaScript for each affiliate, potentially dozens or even thousands of tracking codes.

The next task is to test that the code is working. You’ll need to click on one of your own adverts. You have to pay money to do this - no good clicking from inside AdWords, you have to do a search and click on one of those fee-bearing adverts. Then follow your order process and look for the order confirmation (thank you) page. Somewhere on that page should be a Google Feedback button. If you see that, your order has been passed to Google.

Conversions and Transactions

Google defines a Transaction as happening each time that the Conversion Code tag is triggered. This happens when a user views the page, or hits the refresh button. A Conversion is a single user that makes one or more Transactions.

Timing The Conversion

Google places limits on the leads. Adverts only result in a conversion if the advert was 30 days or less from the purchase (or signup, or whatever the action is). So, assume that today is the 30th Sept. If a user had clicked on advert on September 1st and buys on 30th Sept, the click is counted as a transaction. If the user had instead bought on the 2nd October, then the lead would not count as a transaction.

Slightly more confusing is how the transaction is reported. If you pull off a report, you’ll need a report that covers the 1st September (from the example above) - because that is when the advert is shown. The conversion tracking system shows you how effective the clicks are at generating sales, not your daily sales activity. Some products have zero-latency - the sale is always made on the day of the click. Other products, such as holidays, may have more than 90 days latency - so the sale may happen well after the lead period has expired. Unless your reports cover your latency period, the bulk of transactions may not be counted.

What Next?

So… you have the code on your Order Confirmation Page and you are seeing Transactions. Now what?

If you simply dumped the code that Google gave you, straight on the page, you’ll be recording a Sales Value of 1.00 Currency Unit (it isn’t specified - it’s just a Currency Unit) for each sale. This will let you calculate a CPA - how much it costs to have a user take action.

• CPA is Advertising Cost divided by Transactions

You can, if you know what you are doing, report the sales value (with or without shipping, etc), by modifying the JavaScript. That way you can start to approach calculating an ROI rather than a CPA.

• ROI is (Profit less Advertising Cost) divided by Advertising Cost.

But… Google counts the sales value for every transaction, even if the transaction isn’t actually a new sale. This overstatement of sales tends to lead to a high ROI.

The cause of the duplicate counting of transactions is that Google doesn’t protect against it and e-Commerce providers don’t design their systems to deliver transaction measurement javascript precisely once. Because of this pair of failures, when a user reactivates the order confirmation page or Thank You page, the JavaScript is run again. Since the code contains no way to pass a unique order ID to Google, there is no way for Google to deduplicate orders - though rewriting the Google JavaScript to prevent duplicate submission is an option for competent JavaScript programmers.

Compensating for the errors

If you know that your customers only order once per day, but you have more than one transaction per conversion, then you know that you have a duplicate order submission problem. If the order value for your products is constant (e.g. if you sell only one thing and people only ever buy one at a time) then you can estimate the sales value by using the conversion count rather than the transaction count.

However, if you sell a wide range of products, such as different priced holidays, the actual sales value is a probability cloud, when there are more transactions than conversions. This can be handled, but means that you really ought to be using fuzzy arithmetic or similarly stats based techniques rather than simple deterministic programming.

Knowing the various causes for errors and having customer specific estimates for the magnitude of them, allows calculating a corrected ROI. This can be used to report, or even automatically bid.