Setting up cross-domain tracking of e-commerce transactions with Google Analytics and FastSpring

The problem

You have a website running Google Analytics (with the latest tracking code). You are selling widgets using a 3^rd party online store provided by FastSpring.

You would like to open Google Analytics, display a list of all your sales, and be able to see where your paying customers are coming from. You want to know what websites they are being referred from, what search keywords they are using to find your site, and which pages on your site they are landing on. You also want to know which keywords (organic or paid) and which landing pages are earning you the most money.

The non-solution

FastSpring boasts easy Google Analytics integration, so getting your e-commerce transactions to show up in your Analytics reports is a piece of cake. Pretty much all you need to do is enter your Analytics profile number in the FastSpring management panel and set “E-commerce website” to “Yes” in your profile settings, if you haven’t done so already.

You can now see all your sales in Analytics. However, when you start looking at the referrals and keywords that led to the sales, you will get a nasty surprise: All your sales appear as though they were referred from your site! Instead of “cheap widgets”, or whatever keywords your customers use to find your site, you’ll see “(direct)”. Instead of Google, you’ll see “yourwidgetsite.com”, or whatever you called your silly widget site. This will not stand!

Here’s why Analytics loses track of the referral information: The Google Analytics code on your website’s pages recognizes visitors by a cookie which stores a unique visitor ID. However, this cookie is assigned to your domain (yourwidgetsite.com). When a visitor leaves your site and enters your FastSpring store (at sites.fastspring.com), the Google Analytics code FastSpring added to your store pages does not have access to that cookie. So what it does is create a brand-new tracking cookie. And the only information it has is the referring page on yourwidgetsite.com, which is why the transaction will be shown as having been referred from yourwidgetsite.com.

The proper solution

1.

First, change the Google Analytics code on all your pages to:

<script type="text/javascript">
var gaJsHost = (("https:" == document.location.protocol) ? "https://ssl." : "http://www.");
document.write(unescape("%3Cscript src='" + gaJsHost + "google-analytics.com/ga.js' type='text/javascript'%3E%3C/script%3E"));
</script>
<script type="text/javascript">
var pageTracker = _gat._getTracker("UA-XXXXXX-1");
pageTracker._setAllowHash(false);
pageTracker._setAllowLinker(true);
pageTracker._trackPageview();
</script>

Of course, you should replace “UA-XXXXXX-1” with your actual profile ID. If your website consists of multiple subdomains that you want to track under a single Analytics profile, you should also add this line:

pageTracker._setDomainName("yourwidgetsite.com");

This line will ensure that GA will use only one cookie (for yourwidgetsite.com) rather than a separate cookie for each subdomain.

It is critical that you use the exact same code on all your pages. Google Analytics is very sensitive and will set a new cookie when it detects the slightest change in the tracking code from one page to another. When this happens, you lose information on what your customer was doing before.

Google’s official help tells you to use pageTracker._setDomainName(“none”) instead of pageTracker._setAllowHash(false), but this solution is not recommended by the gurus at the Analytics Help forum. Caleb Whitmore says:

setDomainName(“none”) will make GA set the cookies to the full, EXPLICIT domain of the current hostname.  Thus, if someone is on “mysite.com” and then clicks to a page on “www.mysite.com” they’ll get new cookies on the “www” domain, or vice-versa.”

2.

Add the exact same code (with the exception of the _setDomainName line) to your FastSpring store pages. First, you need to disable Google Analytics tracking in the FastSpring management panel. FastSpring does not let you customize the tracking code and they use a very old version of the code anyway (from back when Google Analytics was known as Urchin).

You will need to insert the proper GA code into your store page template. In the FastSpring panel, go to “Styles” and create a new style (if you haven’t created one before). You will need a ZIP file with your current style files. You can get this file if you e-mail FastSpring. Unzip the file, then open a file named “window.xhtml”. Add the tracking code described above (with the exception of the _setDomainName line) right after the <body> tag.

3.

Change all the links from yourwidgetsite.com to your store at FastSpring to look like this:

<a href="https://sites.fastspring.com/..."
onClick="pageTracker._link(this.href, true); return false;">Buy my widget</a>

This code will take all the information stored in the GA tracking cookie for yourwidgetsite.com and append it to the URL query string used to navigate to your online store. The GA tracking code on the target store page will retrieve all this data from the query string and put it into the new cookie (assigned to sites.fastspring.com) that it will create. That way, all the information about your visitor’s previous activities will be preserved.

Remember that for the new cookie to get this information, every single link to your store must look as shown above.

4.

Now the GA code on your store pages has access to all the interesting information on search keywords, landing pages, etc. The only remaining problem is that no transactions are being recorded, since you disabled FastSpring’s built-in Analytics support in step 2. We will fix that now.

In the FastSpring management panel, go to “External Tracking”. This is where you previously disabled Google Analytics tracking. Now you are going to turn the tracking back on, but with the updated Analytics code.

Click “Add Custom Tracking Method”. Name it something like “Google Analytics (new code)”. Choose “Free-form XHTML Fragment”. Paste the following code into the text box:

<script type="text/javascript">
try {
pageTracker._addTrans(
"#{order.reference}",          // Order ID
"",                        // Affiliation
"#{order.subTotal.textValue}", // Total
"#{order.tax.textValue}",      // Tax
"",                            // Shipping
"#{order.address.city}",       // City
"#{order.address.region}",     // State
"#{order.address.country}"     // Country
);

<repeat var="item" value="#{order.allItems}">
pageTracker._addItem(
"#{order.reference}",     // Order ID
"#{item.productName}",   // SKU
"#{item.productName}",    // Product Name
"",                      // Category
"#{item.priceTotal.textValue}",   // Price
"#{item.quantity}"        // Quantity
);
</repeat>

pageTracker._trackTrans();
} catch(err) { }
</script>

Whereas the code you added to window.xhtml (your store Style) is inserted into every page of your FastSpring store, the above code appears only on the order confirmation page (near the bottom). It sends some basic transaction data to Analytics, then it takes each order item and sends information about it to Analytics as well (the <repeat> loop).

A few comments are in order:

• FastSpring has no SKU’s or product ID’s, but Analytics needs this parameter — otherwise it does not record all the line items in an order correctly. So the best solution is to pass the product name as the SKU.
• #{order.subTotal.textValue} is passed as the “Total”, because the order amount before taxes and shipping is probably what you are interested in. If you’d rather see the total amount paid by the customer in your Analytics reports, you can change it to #{order.total.textValue}.
• “Shipping” is left empty because FastSpring does not provide that variable.

Neither the above variables nor the <repeat> construct are documented anywhere in the manuals that FastSpring provides to sellers. I got this information from Ryan Dewell, the VP of Software Development at FastSpring. He has mentioned to me that FastSpring will be updating its Google Analytics support, so it is possible that full Analytics integration will eventually be possible without all the hacking described here.